на русском · in english

At the entrance there are always high-level requirements from product manager or from the project documentation. Usually it looks like a request, less often in more detail with hypotheses already put forward. For example, we want to add the ability to like publications in the news feed or add the ability to add QR codes to your profile.

1. Understanding

I understand high-level requirements. I write out goal and mission. I note how we will understand that the result will be achieved — the criteria of success. Most often, this is some kind of indicator in numbers. I specify the target audience.

• More about understanding Naer and Zviahin so far only in russian

Best practice:

• draw a system diagram of the task,
• synchronize this understanding with team members.

2. Discovery

I need the analysis to formulate a large number of valid hypotheses. I have several working methods.

1. Analysis of the current solution, if there is one, or a personal idea of the solution to the problem. We are experienced designers, we can immediately tell what can be improved.
2. Competitor Analysis.
3. User feedback analysis. Work with reviews in fear and with what arrives at the support service.
4. Analysis of feedback from other departments, if appropriate. For example, a commercial department or a marketing department.
5. In-depth interviews with a potential audience.
6. Analysis of the metric that we are using. Desk research. As a rule, we are not the first in the world to do this, and quite a lot of articles with research and best solutions have been written about many practices. We cannot say that they will suit us, but it is worth studying.
7. Data analysis.

3. Hypothesis formulation and low-fi prototypes

After the analysis, I have a lot of ideas and I try to formalize them using the mask.

• If we do (idea), then it can positively affect the (success criterion), because (why is this a good idea).

For each hypothesis, I usually make simple and cheap prototypes. It helps to live with the idea and explain it to others. Sometimes it helps to find new hypotheses.

Next, we prioritize each hypothesis. Priority is estimated by two parameters:

• how much does the hypothesis help to achieve the goal or mission (from 0 to 10) together with the product manager,
• how technically difficult it is to implement (also from 0 to 10) together with engineers.
  For each hypothesis, I divide one by the other and get a coefficient. We sort and get what needs to be taken into work in the first place.

Best Practice:

• make design session, show prototypes and diagrams to other designers in the team, analysts, and product manager. There we make a decision what ideas we go ahead with,
• check the best ideas with corridor tests. This helps to find some gaps in the interface.

4. Scoping and Hi-fi prototypes

We started by understanding the problem. Next, we thought big when we generated hypotheses. Take this larger-scale vision, this long-term plan or dream, and then start small, break it down into the smallest pieces. And keep removing functionality until you get the least valuable solution. We usually do this together with the product manager.

For a better solution, I make layouts, make all the states, work with the syntax of interface elements and text. I write explanatory notes for developers and animate screens and interface elements.

Best Practice:

• look at user scenarios through the development levels,
• check every screen with my checklist,
• check the result with corridor tests. This helps me find some gaps in the interface,
• note this task, I will need to be returned to after some time and check the result with expectations,
• give the layouts to another designer for a design review so that he looks through them and tries to find some gaps and errors,
• give the layouts for a product review so that the analyst or product manager compares the layouts with the user story.

5. Review of the result and launch!

After the tests, I do a review of the result to compare what I have planned with the result. Next comes the launch.

6. Analysis of the result

After some time, depending on the task, I return to the task and analyze the result together with the product manager. Did the results match our expectations? We draw conclusions. For convenience, I fix tasks with dates and conclusions in a Google Table, without any rocket science.

Then iterations, iterations and iterations. If everything is bad, we return to point one, if it is good, too, but with new goals.

— That’s a long time!

This whole process sounds complicated and long, yes. However it must be noted that in reality this is not as long as it seems. The first 6 steps of the average task complexity are done within 1-2 working days. Moreover, the ideal process is described here, in real life, some items are skipped or automated.

Design process · big project →