Rose debug info

Subscribe to this blog


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

This is my ideal process for working on a task. I don’t think it should be like this for everyone, but it works well for me. At the entrance, there are always high-level requirements from the product manager. Sometimes I describe them myself, if necessary. It usually looks just like a request, less often more detailed, with ready-made hypotheses.

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. I specify the target audience.

Best practice:

  • synchronize this understanding with team members.

2. Analysis

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

  • Analysis of the current solution, if any.
  • Competitor analysis. Desk research.
  • Analysis of user feedback. Work with reviews in stores and with what arrives in support.
  • Interviews with users. Communication and search for ideas.
  • Analysis of the metric that is being boosted. 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.

Best practice:

  • collect requests and ideas from other departments. For example, customer support, sales department, or marketing.

3. Formulation of hypotheses

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).

What I do is formulate as many hypotheses as possible. Next, we set the priority for each hypothesis. The priority is estimated by two parameters: how much the hypothesis helps to achieve the goal or mission, and how difficult it is to implement it technically.

Best practice:

  • identify how hypotheses help to achieve the goal or mission together with the product manager, are technically difficult to implement together with developers.

4. Low-fi prototypes

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 seek out new hypotheses.

Best Practice:

  • make design session, show prototypes 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,
  • make information architecture and navigation at this stage.

5. High-fi prototypes

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.

6. Markup and transfer to development

If the task is for the web, then after the markup I try to review it. If the project is not too complex, I can make markup by myself. After that, the markup is passed to development. And lastly to testing.

7. Review of the result

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

8. 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. Then, 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.

 191   6 mo   about
Ctrl ←Principles