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

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.

2. “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.

3. “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.

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

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.

• Applying systems thinking in product design Shekman Tang
• Creating systems not destinations Paul Adams

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

• Miroverse Step – 2 – CJM Kate Syuma

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 →
Poster, PDF 2.3 MB

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

Глобально дизайнер сталкивается с тремя типами задач в своей повседневной жизни. Первый тип — просто что-то поправить. Второй решить какую-то маленькую задачу. Третий — сделать большой проект. В зависимости от типа задачи зависит и подход к ней.

1. «Что-то поправить» — самый простой. Тут не нужно что-то выдумывать, нужно пойти и поправить. Будет сложно с точки зрения процесса что-то тут сделать не так.

2. «Решить маленькую задачу» в рамках большого проекта. Например, мы хотим добавить возможность лайкать публикации в ленте новостей или добавить возможность добавлять QR-коды в свой профиль. Чтобы почитать процесс для маленькой задачи переходи сразу в пункт номер пять.

3. «Сделать большой проект». Это что-то более крупное, что состоит из десятка, сотен, тысяч задач второго типа. И самое главное в этом подходе разбить большой проект на более мелкие задачи. Итак, если речь идет о третьем типе, то сначала нужно ↓

1. Понять цели

Как правило, это встреча со всеми заинтересованными сторонами. Вместе мы описываем цель и миссию. Определяем аудиторию для которой мы делаем продукт. Выписываем основные гипотезы, которые имеют прямую связь с целью и миссией. Для каждой гипотезы описываем критерии успеха — набор высокоуровневых метрик и индикаторов.

• Подробнее о понимании задачи Миша Наер и Иван Звягин

2. Посмотреть на продукт с высоты

Нам нужно как-то понять объёмы продукта и какие другие системы продукт потенциально может зацепить. Для этого есть несколько простых способов, которые я использую. Важно отметить, что чаще всего лучше использовать все, чтобы расширить кругозор.

1. Системные карты. Искушение для многих дизайнеров состоит в том, чтобы сразу перейти к разработке интерфейса. Но проектирование конкретных взаимодействий на таком раннем этапе может помешать разработке основ вашего продукта. В рамках воркшопа со всеми заинтересованными сторонами нужно описать проект через системные карты.

• Applying systems thinking in product design Shekman Tang
• Creating systems not destinations Paul Adams

2. Карта пользовательских сценариев. Помогает посмотреть на продукт под другим углом и чуть шире, мы как бы выходим за грани продукта и пытаемся понять как пользователь найдет продукт, как поймет специфику работы и так далее. Какие есть роли, какие этапы, какие на этих этапах есть цели и действия. В рамках воркшопа со всеми заинтересованными сторонами нужно описать продукт через карту пользовательских сценариев. Важно отметить, что это всего лишь наше представление и представление заинтересованных сторон. В реальности все может быть иначе и нужно эту карту отвалидировать с потенциальными пользователями на этапе исследования.

• Miroverse Step – 2 – CJM Kate Syuma

Хорошая практика прямо на этой встрече, в виде воркшопа, набросать потенциальный план исследования.

3. Убедиться, что мы на правильном пути

Настало время валидации концепции и поиска точек роста. На это у меня есть несколько простых способов.

1. Глубинные интервью. Отличный способ найти новые инсайты, точечно. Но не стоит сразу их брать в работу, лучше всего их отвалидировать пунктами 2 и 3.
2. Опросы. Количественное исследование, которое может подтвердить инсайты из пункта 1 и дать поводы для размышления в отрыве от качественных исследований.
3. Анализ данных. Количественное исследование, которое может подтвердить инсайты из пункта 1 и дать поводы для размышления в отрыве от качественных исследований.
4. Анализ конкурентов. Верхнеуровнево посмотреть набор функций ваших прямых и косвенных конкурентов. Это поможет вам найти что-то новое и проверить то, что у вас уже есть.
5. Анализ метрики, которую бустим. Кабинетное исследование. Как правило мы делаем это не первые в мире и про многие практики написано достаточно много статей с исследованиями и лучшими решениями. Нельзя сказать, что они подойдут нам, но изучить стоит.
6. Анализ пользовательского фидбэка. Работа с отзывами в сторах и с тем, что прилетает в службу поддержки. Там часто есть алмазы, которые могут подтвердить вашу идею или гипотезу.

Все эти способы могут изменить вашу модель из пункта номер два.

4. Приоритезировать и разбить на версии

Далее нам нужно всю нашу концепцию разделить на маленькие пользовательские истории, приоритизировать их и разделить на версии.

Итак, в комнату входит карта пользовательских историй. Это такая визуализация скоупа решения. Помогает нам определить минимальный жизнеспособный продукт и его эволюции. Ниже есть хорошее видео, которое объясняет как это работает за три минуты.

Для приоритезации историй по важности можно использовать фреймворк moscow, а для технической сложности фреймворк t-shirt size.

В итоге мы имеем десятки, сотни, тысячи пользовательских историй, которые приоритезированы и разбиты на версии.

5. Индивидуально подойти к каждой истории

Далее работаем с каждой историей (маленькой задачей) по похожему процессу, но всё же, немного другому.

1. Понимание задачи
2. Дискавери
3. Формулирование гипотез и низкоуровневые прототипы
4. Скоупинг и высокоуровневые макеты
5. Ревью результата и запуск!
6. Анализ результата и новые итерации

Подробнее про дизайн-процесс маленькой задачи →
Постер, ПДФ 2.3 МБ

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

What are these tests for

So, at this stage you already have prototypes and formulated hypotheses. Now it remains to shake this bag and make sure that everything works as intended. Or rather, check the interface, icons, signatures, accents, and so on.

It’s simple

We have already formulated hypotheses, so we just write them out. We formulate tasks for users.

We are preparing a clickable prototype, if it is needed. We fix the “gates”, in other words, the conversion marks of the interface. For example: opening a form, successful completion, sending, and so on.

We are looking for participants for testing. We conduct testing and mark all the most important things. We draw conclusions and analyze them. Bingo, 100% percent you will change your attitude to your ideal prototypes.

1 step. Define hypotheses

Hypotheses are assumptions that we are going to test in the course of the study. It is better to formulate it according to the template: “If we do (the idea), then he will be able to positively influence (the criterion of success), since (why is this idea good)”.

2 step. Choose a testing method

All testing methodologies are divided into unmoderated and moderated according to the degree of independence of the task by respondents, as well as by the location of the respondent and the interviewer at the time of testing.

First click. The research participant follows the link and gets a very simple task. For example: “Where would you click to find information about leasing programs?”, “Choose leasing to purchase the selected car”. Only the first click is recorded. If the majority of respondents click “wrong way”, it signals that there are usability problems on the screen.

Side by side. The essence of the method is to compare two options and choose one based on the principle of better visibility or recognition of the target object. Respondents are asked to compare two images of the interface or select a specific element on two versions of the image. For example: “Find and select the A1 payment method”, “Which of the banner options is more recognizable for the material ‘Cars for leasing on ave’”.

For patency. The method is closest to moderated testing. It assumes the presence of the interviewer next to the respondent at the time of the test. We select conversion points and give the respondent a task that should lead him along the path you need. As a result, the facts of passing the points are recorded and notes are made about the difficulties encountered by the user.

Moderated testing. With such a check, the user performs the assigned tasks in relation to the product or service, while the researcher or moderator watches him in real time. Each of the above methods can be moderated. The reliability of the results and the depth of the insights obtained during such testing is considered better than when using methods without moderation.

3 step. Respondents’ choice

For testing, we need representatives of the target audience who are faced in real life with the tasks that are described in the testing tasks. However, the corridor test makes allowances in this matter, and absolutely all direct or indirect Internet users can become respondents.

Five to eight respondents are enough to identify interface problems. If all respondents face the same difficulty— this is a reason to stop testing, make edits to the prototype and start testing a new version.

If the resources and time to work on the site are very limited, we are guided by the principle: “less is better than nothing.” Three respondents are better than none.

4 step. Task formation

The quality of the results and their objectivity directly depends on the formulation of questions and tasks in testing. Checklist for the formulation of the task:

1. Described accurately.
2. Announced in full.
3. Relevant to the respondent’s experience.
4. It is possible to perform without prompts.

5 step. Preparation of the prototype

A test prototype can be:

1. Interactive clickable prototype.
2. A test version or a working website.
3. Just a picture.

Checklist for testing the prototype:

1. Scripts are executed.
2. There are different options for executing the script.
3. Texts, numbers and visual content are similar to the real ones.
4. There are no errors and typos in texts and figures.
5. There are no hints.
6. It is possible to quickly return to the beginning of the script.

6 step. Testing process

Properly conducted testing will be less stressful for the respondent, will be easier to moderate and, therefore, will give more relevant results. Advice – shut up, listen to the respondent and do not prevent him from not understanding anything.

The respondent speaks most of the time during testing. The moderator speaks only if absolutely necessary. Any intervention by the moderator affects the course of the experiment and distorts the data.

If the respondent has stopped “thinking out loud” – remind him about it: “So… So, you think that... What do you see here? Tell me what happened.”

Questions often force the respondent to take a defensive position. You can replace questions with motivational phrases like: “Tell me a little bit about it... Describe it in more detail... Share your feelings... Let’s talk about it... Help me understand...”.

In what cases to help:

1. The respondent should feel that you are encouraging him, not the product.
2. If the respondent has tried several methods of action and asks for help.
3. The respondent thinks that the task is completed, but it is not.

How to do it:

1. Focus on the task, remind the purpose of the task.
2. Make a general hint: “Remember how you started doing the task”, “You have already seen it”.
3. To say directly what to do next.

It is important to record the moments where the respondent encountered difficulties. After testing, we ask the respondent a few questions. You don’t have to follow the direct recommendations for changing the site that the respondent will express during the conversation. Conclusions and recommendations are usually made from observing behavior, not from a conversation.

7 step. Recording of results and conclusions

Even at the stage of hypothesis formulation, we recommend creating a table containing decomposed hypotheses and tasks for testing with the content of user steps or beaten conversion points.

After each meeting, record the test result in the table: whether the hypothesis was confirmed, whether the respondent coped with the task without errors. We also add insights and other notes describing the user’s behavior at a particular step of the task.

Based on this document, we draw conclusions about the confirmation or non-confirmation of the hypothesis, as well as formulate new ones, if necessary.

Table for recording results

Table template in Google Docs