Привет, читатель!

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

Прототип позволяет на ранних этапах дизайна рассмотреть и «пощупать» часть продукта или продукт в целом, при этом не привлекая ресурсы разработки. Та же Figma позволяет собирать очень правдоподобные прототипы, которые помогают дизайнеру и команде в целом протестировать, проанализировать юзабилити.

Важная миссия прототипов – наглядно демонстрировать пользовательский опыт и помогать его исследовать.

Когда дизайнер делает макеты страниц сайта, проектирует навигацию по интерфейсу или формирует интерактивные взаимодействия – ему очень важно перепроверить себя и убедиться, что всё делается в нужном ключе. И очень часто тут помогают прототипы.

В некоторых ситуациях можно обойтись минимальной детализацией, а иногда желательно приблизить прототип к реальному продукту. И тут возникает вопрос: как понять, когда и насколько подробным должен быть прототип? Чтобы на него ответить, нужно сначала определиться с целью прототипирования.

Цель #1: Проверка работы целевых действий

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

Пример кликабельного прототипа экранов
Пример 1

Давай смоделируем такую ситуацию на сайте электронных книг: по данным системы аналитики только очень малая часть аудитории переходит в профиль для оформления абонемента. Для наглядности представим, что по сценарию пользователь видит возможность покупки абонемента только после перехода в раздел «Мои покупки» внутри профиля.

У вас есть гипотеза, что можно сократить путь – перенести абонемент непосредственно в раздел профиля, без перехода на отдельную страницу. Можно быстро собрать прототип с новым сценарием пути пользователя и показать его в качестве решения.

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

Цель #2: Проверка удобства микровзаимодействий

Когда мы добавляем товары в корзину, выбираем на карте адрес и способ доставки или оставляем чаевые – всё это может происходить в рамках одного окна. Но для этого мы совершаем на экране несколько взаимодействий.

Иногда можно заметить места, когда взаимодействия пользователя с интерфейсом можно считать проблемными. Часто вариантов решения по улучшению взаимодействия может быть несколько. Чтобы проще было выбрать подходящее решение, обычно делают несколько прототипов с микровзаимодействиями.

Пример 2

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

  1. Сделать поисковые подсказки по аналогии с поиском в браузере Google.

  2. Расширить поиск, чтобы он работал по любым параметрам книг: наименование книги, автор, жанр и так далее.

  3. Сделать и то и другое.

Исходя из примера, можно собрать целых три прототипа взаимодействия с поиском, каждый из которых можно (и нужно) тестировать отдельно.Конечно на это уйдёт больше времени, чем на создание простого кликабельного прототипа экранов. Но не стоит сильно переживать: даже если ни один из вариантов решения не подойдёт, такие прототипы собирать проще, чем прототип всего интерфейса целиком.

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

Цель #3: Проверка зон рисков юзабилити

Когда вносите большие изменения в дизайн продукта или делаете интерфейс с нуля, важно увидеть всю картину целиком и проверить формируемый пользовательский опыт. Раннее тестирование на детализированном прототипе поможет увидеть узкие места: где-то не очень удобно получилось, где-то пользователь может запутаться.

Детальный правдоподобный прототип всего интерфейса поможет увидеть работу будущего интерфейса целиком и выявить зоны риска юзабилити.

Прототип должен работать так, чтобы с его помощью можно было пройти по всем ключевым точкам интерфейса — здесь полезно опираться на пользовательские сценарии (userflow).

Пример пользовательского сценария

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

Памятка

  • Простой кликабельный прототип экранов поможет быстро проанализировать и протестировать путь пользователя. Можно обойтись минимальной детализацией экранов.

  • Детальный прототип микровзаимодействий поможет оценить удобство взаимодействия на отдельных этапах пути пользователя и найти эффективное решение или компромисс. Необходима высокая детализация прототипа в рамках взаимодействий.

  • Правдоподобный прототип всего интерфейса поможет увидеть работу будущего интерфейса целиком и на ранних этапах выявлять зоны риска юзабилити. Необходима максимальная детализация и правдоподобность прототипа.

Надеюсь, статья для тебя была познавательной. Напомню, что это лишь моё видение, моё понимание использования прототипов как инструмента решения задач дизайнера.