Дизайн без дизайнера

Я работаю в Райффайзенбанке с командами, у которых нет своего дизайнера, и помогаю им сделать качественный UX и UI. В большинстве случаев алгоритм его создания в разных продуктах один и тот же. Если у вас нет своего дизайнера, вы вполне можете пройти его самостоятельно. Как это сделать — рассказываю 😊

У команды есть продукт, который она создает и развивает. Часто этот продукт представлен digital-сервисом с его собственным интерфейсом. Пользователям должно быть легко и удобно решать в нем свои задачи, а у команды должна быть возможность гордиться высокими метриками. Но как этого добиться — не всегда понятно.

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

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

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

Бывают продукты, которые нацелены на широкие массы. В таких случаях невозможно выделить конкретные персоны с яркими отличительными чертами, поскольку продукт делается буквально «для всех».

Для таких кейсов можно использовать фреймворк Jobs-To-Be-Done. В нем пользователи сегментируются по «работам», на которые они нанимают ваш продукт.

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

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

Цель можно сформулировать в свободной форме, но ещё удобно использовать User Story или Job Story.

История пользователя — это требования к разрабатываемой системе, которые сформулированы на повседневном или деловом языке пользователя. Она дает Agile-команде возможность контролировать степень полезности продукта для клиента или конечного пользователя и применяется как основа для оценки работы.

User Story — быстрый способ документировать требования клиента без необходимости разрабатывать объемные формализованные документы и впоследствии тратить ресурсы на их поддержание. Такой способ позволяет оперативно и без дополнительных затрат реагировать на быстро меняющиеся требования реального мира.

Job Story — это история работы, которую пользователю необходимо выполнить. При ее описании главное — не персональные характеристики пользователя, а особенности и контекст выполняемой задачи.

В основе концепции Job Story лежит мысль о том, что пользователь «нанимает» наш продукт, чтобы решить свою задачу. Помимо самой задачи, существует еще и контекст — ситуация, в которой задача возникла. Контекст, в свою очередь, может стать источником гипотез и идей для развития продукта.

User story подойдет вам, если:

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

Job Story подойдет вам, если:

ваш продукт предназначен буквально «для всех», а различия обнаруживаются только в контексте его использования. Например, кто-то покупает технику Yamaha из-за надежности, а кто-то — чтобы похвастаться перед друзьями.

Проследите, как пользователь достигает своей цели, применяя ваш продукт?

Есть удобный фреймворк, позволяющий достаточно подробно описать путь пользователя, ничего при этом не упустить и выявить барьеры, препятствующие достижению цели. Его название знакомо многим — Customer Journey Map (CJM).

CJM состоит из стадий жизненного цикла клиента/пользователя, конкретных шагов и слоев информации.

Проще всего понять принцип построения CJM на примере:

Чтобы построить CJM, вам нужно:

Почему пять-восемь человек достаточно? Ответ здесь.

После того, как вы построили CJM, нарисуйте вайрфреймы (черновики экранов) для каждого шага пользователя. Необязательно делать красивые макеты. Можно нарисовать от руки на бумаге или на доске — дизайнеры тоже так делают: )

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

Наконец-то вы можете превратить ваши вайрфреймы в красивый UI: )

Если вы работаете в крупной организации — у вас скорее всего есть дизайн-система.

В Райффайзенбанке — это дизайн-система Vienna. Она содержит библиотеку готовых компонентов в коде, из которых можно быстро собрать готовый front-end для любого digital-продукта.

Применение дизайн-системы облегчает работу разработчиков и обеспечивает соответствие гайдлайнам.

Если дизайн-системы в вашей организации нет — это повод задуматься о её создании: )

Также вы всегда можете найти готовый UI Kit на просторах интернета — сейчас их очень много на любой вкус. Например, здесь или здесь. Можно выбрать любой UI Kit, который вам больше нравится, и собрать из него красивые макеты или даже готовый front-end.

Несмотря на длинное описание, все вышеописанные действия доступны каждому. Согласны?

#дизайн #интерфейсы