Design Process Management in Product Development
When developing a digital product, regardless of which team you are involved in, you will see that when you manage your workflow process in the right way, the results will be higher quality and less tiring. In this article, I will convey how we built up our design process and how we manage it.
Let’s say, you have a task or a new product that need to be designed; The design process will begin with the arrival of a new feature that needs further development or improvement. These design tasks typically come from the Product team, the Customer Success team, or the Design team.
First, I would like to talk about the tasks assigned to the Design team before coming to the JIRA processes. Although, to me, a work without reason is not a need nor a problem.
If what we need is a feature, it is expected that the Development team within the company have to fill this feature with well-rounded reasons. What I mean is, at the end of the day if we add a new feature, this feature needs to answer to questions like these:
- What is this feature? What do we expect to add to the product?
- Why do we need this feature?
- Who will use this feature? Whom are we designing this for?
- What is the order of importance?
These questions can be diversified or reduced. Frankly, I wanted to share the general expectations that came to my mind while writing the article.
If what we are looking at is something that needs improvement rather than a new feature, this time our Customer Success team, who best understands our customers, will answer those questions for the Production team.
And you know what happens also? They might come up with some data. They can support their theses with the type of data that we can monitor our users, track their movements, we can create specific funnels and observe also many many things that I can’t come up right now. Of course, we don’t use data to prove what the problem is or to explain a more accurate way. Rather we use data to understand the problem better and to create a solution while solving the problem. We use the tool called Fullstory to collect all this data.
While explaining the different design stages, I’ll title it as how we named the stages in JIRA. This way it will be more easy to understand.
To-Do Stage
In this process, one of the above-mentioned types of tasks is already assigned to the Design team by the Product Management team.
At this beginning stage, the whole Design team has accepted the assigned task, understood it, and have a general idea of the task. Nevertheless, the task is assigned to the team with all the details and all explanations documented, regardless of which team is involved in the production process. This is to help everyone in the process to be transparent and avoid miscommunications. Furthermore, when a question comes to his/her mind, the person can look back at the documentation and find the answer without needing to talk to anyone and provide answers to the questions mentioned above at any time.
Of course, when I say that, I don’t want to be misunderstood; it is out of the question to assign it and disappear. As a company with an optional remote controlled Production team we use Slack and Zoom.us for online interviews and other perks. For example, the compatibility of Slack and the other apps/software that we use becomes one integrated tool that collects all the communication between each other.
In Socio, we briefly describe this process as follow;
Once the Product team comes up with the next batch of features, the Product Manager and the Lead Designer works on creating mockups and setting up requirements. Once that is done, they create the detailed task on JIRA and put it in the “To do” stage in the sprint.
In-Progress Stage
In this process, we are working on the task assigned to us. Of course, if this article was just about a task/work I was working on, there would be more to tell, but as to mention it briefly there is not much to tell.
We can define the task assigned to us as the process we need to finish within the expected time, on top of the requirements of the task. Since this is a process of production it can be a lot more detailed, therefore, it will be better if I talked about that in another article.
In Socio, we briefly describe this process as follow;
Looking at that task’s initial mockup and requirements, the Lead Designer drags this task to “In Progress” and starts their work by creating the concept design and building alternatives until deciding on a single version to present. Once this is ready to be presented to the Product Manager, the Lead Designer uploads the designs to Zeplin, shares the link on the task and drags the task to “Ready to test”.
Ready to Test Stage
In this process, as a Design team, after we accomplishing our work in to-do process, we send the task over to Lead Designer and Product Manager for additional testing.
As you know, we are influencing many different factors when designing the digital interface. Therefore, we also pay additional attention to factors beyond visual concern when designing. One of the things we expected from our designs during the testing phase is that they meet the requirements/needs/critical points of these factors. For this reason, a point you sometimes skipped in your designs will return to you in this process. Sometimes you can make mistakes on the software side, the needs side of your users, or even the visual side. It is important that you identify and fix them during the testing phase.
Also, you may sometimes need to test your designs, experiences you created, flow and logic to see if it is working or not. Which, I think it is the best method that will give you the healthiest return when it is done for the right target audience. You may not always have the time, opportunity or the budget, but whenever you get the chance I can advise you to do it directly on your own users through various digital services. Again, the details of these issues should be addressed within a separate article.
In Socio, we briefly describe this process as follow;
Once the task is in “Ready to Test”, the Product Manager and Lead Designer goes through the entire Zeplin and creates all the feedback. 🚨 We keep all the feedback in Zeplin to streamline the process. The Product Manager and the Lead Designer works together until all feedback is resolved and the product is ready for the handoff. The Product Manager approves the task as a whole.
Ready to Release Stage
We are ready!
We’ve just completed the assigned task. We have come to the end of a task process with experiences ranged from bad to good. What will happen now? Is everything done?
Of course not.
We must treat the design with the same intensive care from previous stages as we hand it over to the Software Development team.
Aside from the layout of our design file, we also should specify the points we needed to explain in the delivery process in the system we use for the handoff.
In Socio, we use Zeplin in the handoff process. From the moment the designs come to the testing stage, they are in the Zeppelin system. However, designs are shared with the Software Development team only when they are completely ready. In this way, we can take notes, discuss and collect feedback on screens with the wonderful note-taking feature of Zeppelin. Also, we are able to document the entire task while submitting to the Software Development team.
We also offer user flow prototypes of all of our jobs at MarvelApp so that everyone in the company can see the work and to have full knowledge of the flow.
Finally, we add the access links of all of these services to the relevant task in JIRA and successfully complete the handoff process.
Other Articles from Me
I’ll be looking forward to seeing all your valuable comments and critics. Feel free to let me know if there is anything that I skipped or that you would do differently.
To end the article, I would like to add a subtext:
Designers can make a mistake; their designs may be bugged. What is important is that sooner or later these should be recognized and fixed. We apply this thinking process in Socio.
On the side note, I would like to share the playlist that accompanied me while writing this article.
