Rose debug info
---------------

Subscribe to this blog

Design process

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

If you need such a poster in good quality, write to me at ivanzviahin@gmail.com

Globally, each and every designer faces three types of tasks in their daily life. The first type is just about fixing something. The second group are likely to resolve some small problem. And lastly, they happen to do a big project. Depending on the type of task, there may come a different approach.

  1. “Fix something” is by far the simplest one. There is no rocket science in here. What we do is go handle it. It might be difficult from the point of view of the process to do something wrong here.
  1. “Solve a small problem” in a large project. For instance, we may desire to add up the ability to like publications in the news feed or attach the ability to build on QR codes to your profile. To read process for a small task go straight to point five.
  1. “Do a large project”. This is something way bigger, which consists of dozens, hundreds, thousands of tasks from the second point. And  most importantly, in this approach we are to break a large project into smaller tasks. So, when it comes to the third type, then first you need to ↓

1. Understanding goals

As a rule, this is a meeting with all stakeholders. Together we describe goal and mission and  define the audience for which we the product will be made. We write out the main hypotheses that have a direct connection with the goal and mission. For each hypothesis, the success criteria are described and outlined — a set of high-level metrics and indicators.

2. Taking a birdview of product

In here we have to understand the scope of the product and what other systems the product can potentially hook. There are a few simple ways that I tap into to sort it out. It must be noted that most often is it better to make use of everything to broaden your horizons.

  1. System diagrams. The temptation for many designers is to go straight to interface development. Yet designing interactions at such an early stage can interfere with the development of the basics of your product. As part of a workshop with all stakeholders, you need to describe the project through system diagrams.
  1. User journey map. It helps tremendously to look at the product from another perspective. We go beyond the edges of the product and try to understand how the user will find the product, how he will understand the specifics of the work, etc. What are the roles, what are the stages, what are the goals and actions at these stages. As part of a workshop with all stakeholders, you need to describe the product through a user journey map. It is important to note that this is just our representation and the representation of stakeholders. In reality, everything may be different and you need to verify this card with potential users at the discovery stage.

It is a good practice at this meeting to outline a potential discovery plan.

3. Make sure we are on the right track

It is time to validate the concept and search for growth points. I have a few simple ways to accomplish this.

  1. In-depth interviews. A great way to find new insights, point-by-point. However, you should not immediately take them to work, it is best to validate them with points 2 and 3.
  2. Surveys. A quantitative study that can confirm the insights from point 1 and give reasons for reflection in isolation from qualitative research.
  3. Data analysis. A quantitative study that can confirm the insights from point 1 and give reasons for reflection in isolation from qualitative research.
  4. Competitor analysis. Top-level view of the set of functions of your direct and indirect competitors. This will help find something new and check out what you already have.
  5. Analysis of the metrics used. 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 already been written about many practices. We cannot say that they will suit us, but they are worth studying.
  6. Analysis of user feedback. Work with reviews in stores and with what arrives at the support service. There are often diamonds there that can confirm your idea or hypothesis.

All these ways can change your model from point two.

4. Prioritizing it and splitting into versions

Next, we need to divide our entire concept into small user stories, prioritize them and divide them into versions.

So, a map of user stories. This is such a visualization of the solution scope, which helps us determine the minimum valuable product and its evolution. Below is a good video that explains how it works in three minutes.

To prioritize stories by importance, you can use moscow framework, and t-shirt size framework for technical complexity.

As a result, we have dozens, hundreds, thousands of user stories that are prioritized and divided into versions.

5. Approaching each story individually

In a while, we work with each story (a small task) by a similar process, but still a little different.

  1. Understanding the task
  2. Discovery
  3. Formulation of hypotheses and low-fi prototypes
  4. Scouping and high-fi prototypes
  5. Review the result and launch!
  6. Result analysis and new iterations

Learn more about the design process of a small task →

 160   1 mo   about   casestudy   process
Next