Привет, я — Лёша, визионер и эксперт в области продуктового дизайна. Специализируюсь на создании инновационных, интуитивно понятных и коммерчески успешных продуктов (Web, Mobile, Desktop). Это моя вторая статья из серии посвященной дизайн-процессам, и в ней мы поговорим о втором ромбе системы Double Diamond и о том как же нам теперь закрыть выясненную боль пользователя, и превратить наши идеи в живой, простой, понятный и удобный продукт. Поехали!
В первой статье мы выяснили настоящие проблемы и боли наших пользователей, какие у нас есть технические, финансовые и временные ограничения. Благодаря этому мы обзавелись надёжным фундаментом для решения реальных проблем, подтвержденных реальными данными.
Теперь пора перейти от проблем к решениям. Если первый ромб был про "Что?" и "Почему?", то второй — про "Как?".
Второй ромб так же состоит из двух, потенциально бесконечно повторяющихся внутри до нахождения нужного решения, фаз: Develop(Разработка) и Deliver (Доставка/Внедрение)).
Develop (Разработка)
На этом этапе наша основная задача — это сгенерировать максимальное количество идей и концепций, которые смогут решить проблемы, выявленные на предыдущей фазе Определение(Define), чтобы потом оставить только лучшие решения, отвечающие всем требованиям и закрывающие выявленные проблемы. Их может быть несколько, и для таких случаев существуют А/Б тесты, чтобы с помощью них выяснить наиболее эффективное решение.
HMW-вопросы / "Как мы можем...?" (How Might We...?)
Для начала нам нужно превратить наши ключевые инсайты в вопросы, основанные на этих инсайтах с формулировкой "Как мы можем...?" (How Might We...?).
Пусть для примера нам поручили разработать рекламный баннер для “Готовых пакетов инвестиций” внутри банковского приложения, при этом мы должны учесть доступность для людей с ограниченными возможностями (ЛОВ).
На первом этапе исследований мы выяснили что пользователи с нарушением зрения часто не замечают старый баннер на экране захвата, а пользователям с когнитивными нарушениями сложно разобраться в содержимом второго экрана, который мы создали следуя закону, по которому мы не должны создавать "Ложное банковское впечатление”, и обязаны предупредить что "Доходность не гарантирована" и "Инвестиции не застрахованы АСВ(Агентством по страхованию вкладов)" — Федеральный закон № 177-ФЗ от 23 декабря 2003 года «О страховании вкладов в банках Российской Федерации».
Пример инсайта: "ЛОВ с нарушениями зрения сложно найти баннер среди другого контента”.
Пример HMW-вопроса:
"Можем ли мы сделать баннер "Готового пакета инвестиций" визуально более контрастным и доступным для скринридеров, чтобы пользователи с нарушениями зрения не пропускали его?"
“Можем ли мы упростить юридическое предупреждение на первом экране после баннера, чтобы пользователи с когнитивными нарушениями легко его поняли?”
Такие вопросы помогают нам сфокусироваться на нашей проблеме, при этом оставляют огромное поле для экспериментов, мы помним что нас останавливают только технические ограничения, сроки, и возможно слишком объемный и нецелесообразный бюджет.
Сформировав HMW-вопрос можно сходить с ним в нейросети и выяснить какие готовые решения уже есть на рынке, к чему люди привыкли и какие могут быть подводные камни и корнер-кейсы. Это очень полезный этап, он поможет нам подойти к брейнштормам уже более подготовленными.
Вот моя структура запроса для нейросетей при поступлении новой задачи:
[Условия/продукт] - [задача/особенности] - [возможные решения/лучшие практики/подводные камни/корнер-кейсы] - [наша роль]
Например: У нас есть банковское приложение, которое мы делаем доступным для людей с ограниченными возможностями (условия/продукт), и нам нужно разработать баннер “Готового пакета инвестиций” для захвата с главной страницы (задача/особенности). Подскажи возможные решения, укажи на что стоит обратить внимание, какие существуют лучшие практики, какие могут быть подводные камни и корнер-кейсы, расскажи как эту задачу решили крупные игроки на рынке(возможные решения/лучшие практики/подводные камни/корнер-кейсы). Помни что я продуктовый дизайнер(наша роль).
Я такими запросами пользуюсь регулярно, и несмотря на весь мой опыт, очень часто это бывает реально полезным.
Брейнштормы и генерация идей (Ideation)
Теперь наша задача провести структурированные сессии с командой, со всеми причастными к разработке нашей фичи (разработчики, маркетологи, менеджеры). Тут стоит упомянуть что договариваться нужно сразу со всеми, а не проводить отдельные брейнштормы с разработкой, отдельные с маркетологами. Разнообразие взглядов для нас критично, и мы хотим чтобы все слышали всех. Для точки входа будем использовать наши сформированные HMW-вопросы.
Есть несколько методов проведения брейнштормов, вот самые популярные (Если вы видите что во время брейншторма идеи генерируются плохо, попробуйте комбинировать методы брейншторма прямо в процессе, познакомив участников с новыми условиями):
Классический брейншторм: Количество важнее качества, никакой критики, только поток идей.
Мозговой штурм "по-немецки" (Brainwriting): Идеи записываются молча, чтобы избежать влияния самых громких или авторитетных голосов.
Безумные Восьмерки (Crazy 8’s): Быстрый скетчинг 8 идей за 8 минут для генерации множества концепций.
SCAMPER: Система вопросов для потенциальной трансформации существующего продукта (Где мы задаём вопросы что мы можем: Заменить, Объединить, Адаптировать, Увеличить, Убрать, Перевернуть).
Обратный брейншторм: Иногда можно использовать обратную логику и генерировать максимально неудобные решения, чтобы глядя на них точнее понимать каких решений мы точно хотим избежать. Плюс такие сессии помогают снять эмоциональное напряжение в команде. Например: "Как бы мы сделали этот баннер максимально недоступным?” Тут часто можно удивиться на что способны наши коллеги :)
В результате у нас должна получиться большая стена в офисе, FigJam или Miro-доска, заполненная сырыми идеями и набросками, от самых очевидных до безумных.
В нашем примере мы фокусируемся в первую очередь на доступности: Генерируем идеи, которые решают конкретные проблемы доступности (например, разные варианты CTA, разные визуальные метафоры, альтернативные форматы баннера — не только визуальная карточка, но и, например, аудио-уведомление или виджет).
Отбор и приоритизация решений
Влияние vs. Усилия, или Ценность vs. Сложность (Impact vs. Effort)
Теперь нам нужно оставить несколько самых жизнеспособных концептов для дальнейшей проработки, и главным помощником тут будет матрица приоритизации. Её главная задача сузить множество идей до нескольких реализуемых концепций, а потом среди них выявить идеи, которые в нашем примере обеспечат наибольшее улучшение доступности (Impact) при наименьших затратах на разработку (Effort).
Тут всегда стоит помнить о таком когнитивном искажении как ошибка планирования, при котором мы часто смотрим на вещи слишком оптимистично, и несмотря на наш прошлый опыт рассчитываем на более короткие сроки. Поэтому сроки всегда стоит рассматривать с неким запасом. Главная опасность неверной оценки сроков заключается в том, что мы неверно определяем ценность концепта, и реальные усилия на графике из-за этого будут смещены вправо. Таким образом в реальной жизни концепт должен находиться в разделе “Никогда”(Денежная яма), а мы его поместили в “Поэтапно”(Дополнительное), поставив в один из ближайших спринтов или закинув в беклог на самый верх списка. Либо мы поместили его во “Всегда”(Лёгкая победа), а на самом деле его место в “Редко”(Высокие ставки), ведь несмотря на очевидную выгоду нам придется потратить намного больше усилий чтобы выкатить этот концепт в продакшн.
Результат: Потраченный бюджет и время команды на неприоритетную задачу.
Скетчи, Концепции, Сториборды
Итак, мы отобрали несколько (обычно 2-3) наиболее перспективных концепций, теперь нам нужно их визуализировать, чтобы можно было их легко обсуждать и тестировать. Важно учитывать весь путь пользователя (В нашем примере это должен быть путь от клика на баннер до непосредственного инвестирования). Какие инструменты нам могут в этом помочь?
Скетчи интерфейсов: Быстрые, грубые наброски экранов на бумаге или в Фигме.
Сториборды или Customer Journey Maps: Рисуем как пользователь будет взаимодействовать с нашим решением в контексте своей истории. Показываем как решение вписывается в его жизнь и решает боль.
Пути пользователя или User flow: Древовидные схемы, описывающие весь путь пользователя. Я часто вижу как их стараются пропустить на этапе разработки, и зря, на мой взгляд это один из лучших способов визуализации всех сценариев и алгоритмов. (Часто инсайты приходят именно во время рассматривания таких “листочков” на дереве, и мысли “О! Кажется на этом шаге мы упустили …, а вот тут пользователь наверняка захочет…”).
Концепт-карты или Mind map: Создаём коллажи или схемы, которые передают "дух" или основную ценность идеи. Используем если остальных инструментов для защиты недостаточно и в процессе решения проблемы сильно задействованы эмоции пользователя.
Соответствие WCAG: В нашем случае уже на этом этапе стоит оцениваеть идеи с точки зрения соответствия принципам доступности (WCAG). И идеи с высоким потенциалом улучшения доступности должны иметь приоритет.
В результате у нас должны быть 2-3 детально описанные, приоритизированные дизайн-концепции (например, "Концепция А: Контрастный баннер с крупной CTA" и "Концепция Б: Скрытый баннер, активируемый скринридером").
Формирование гипотез
Визуализировав наши концепты нам нужно сформировать гипотезы, которые мы будем проверять. Зачем мы это делаем? Чтобы перед этапом доставки (внедрения) у нас были идеи, концепты и проверяемые цифрами гипотезы, которые потенциально решают нашу проблему. Чтобы в дальнейшем нам оставалось только сузить фокус и выбрать лучшее.
Структура гипотез:
Мы считаем, что [реализация этой функции/изменения]
Для [этой группы пользователей]
Приведет к [этому конкретному результату]
Мы будем правы, если [увидим это метрическое подтверждение]
Пример: "Мы считаем, что если мы добавим контрастный баннер с увеличенной зоной клика (≥44×44 dp) и явно обозначенной ARIA-role кнопки, то пользователи с нарушениями зрения (использующие скринридеры) и пользователи с нарушениями моторики, смогут успешно найти и кликнуть на баннер. Мы будем правы, если это приведёт к увеличению конверсии из показа в клик — Conversion Rate (CR) данного баннера среди сегмента ЛОВ на 20% и снижению жалоб в техподдержку о недоступности элемента на 50%.
*Почему я использую в примере цифры в 20% и 50%? Это реальные цифры для нашего кейса. В действительности при такой проблеме мы должны сократить разрыв кликрейта (CR) между обычными пользователями и ЛОВ. Если обычный кликрейт баннера составляет около 5%, то наш нынешний баннер скорее всего имеет CR близкий к 0% из-за невозможности взаимодействия. Так почему же здесь я ставлю амбициозные цели в 20% как минимум, если CR обычного пользователя всего 5%?
Я это делаю всегда, а в конкретном нашем случае я это делаю потому, что в данном кейсе мы своим решением снимаем барьер у ключевой группы пользователей. А устранение барьера всегда приводит к более высокому росту конверсии, чем мелкие UX-правки, где рост обычно находится в районе 2−5%. Плюс ко всему я рассчитываю на психологический эффект инклюзивности, когда люди, которые раньше не могли воспользоваться этим элементом, впервые смогут успешно с ним взаимодействовать.
Снижение жалоб должно стать еще более внушительным. Так я считаю, что справлюсь с задачей, только если количество жалоб и баг-репортов, связанных с недоступностью станет как минимум на 50% меньше.*
Гипотезы для нас очень важны, так как сформировав гипотезы мы сможем перейти от "мне кажется" к проверяемым цифрами утверждениям.
Deliver (Доставка/Внедрение)
Мы приближаемся к финалу, настало время протестировать наши дизайн-концепции, отобрать лучшие из них, доработать и подготовить к реализации.
Прототипы
Первое что мы должны сделать для хоть сколько-то сложной фичи — это интерактивные прототипы. В зависимости от самой задачи прототипы могут быть:
Простые Low-Fidelity (Lo-Fi): могут состоять просто из схематичных блоков элементов интерфейса, основная цель которых показать структуру и воркфлоу.
Сложные High-Fidelity (Hi-Fi): выглядят и работают почти как настоящий продукт, с реальным дизайном, анимацией и интерактивностью.
В зависимости от сложности самих прототипов нужно подбирать подходящие инструменты, так для большинства прототипов достаточно встроенных прототипов в Фигме, а для более сложных (как в нашем случае когда нужна звуковая имитация скринридера) лучше использовать ProtoPie.
*Очень важно помнить что любые прототипы должны тестироваться в “полевых условиях” чтобы по-настоящему почувствовать наше решение. Если мы проектируем приложение для фитнеса, и нам нужно спроектировать экран внутри упражнений, то нам надо встать и начать делать упражнения перед тем как начать тестировать наше приложение.
Ведь поведение человека в разных условиях будет абсолютно разным. Например моторика на пульсе 65 и 120+ у всех совершено разная. И пока мы проектируем аккуратные и эстетичные кнопки просто сидя перед своими ретина мониторами, считая их идеальными, то во время упражнений нам самим же захочется сделать эти кнопки крупнее, и вообще оставить только одну, и никогда не убирать её из зоны тапа большого пальца.*
Тестирование с пользователями
Прежде чем нести наши прототипы реальным пользователям мы должны убедиться что они проходят нашу экспертную дизайн-проверку.
Контраст: проверяем контрастность текста на фоне для соответствия правилам WCAG (я использую в фигме плагин "A11y - Color Contrast Checker")
Интерактивные зоны и логика элементов: Проверяем все элементы наших макетов. Проверяем контент заголовков (Заголовок должен быть всегда однозначным и четко описывать содержимое контента ниже, если нас не устраивает длина текста ищем альтернативные варианты), и их иерархию(H1-H2-H3-H4-H5), проверяем все поля ввода, наличие всех состояний для всех элементов, ошибки, ссылки, кнопки, лейблы, уведомления.
*Все элементы должны трактоваться всегда однозначно, и пользователь должен всегда понимать где он находится, что ему может предложить система на данном экране, и что произойдёт если он начнёт взаимодействовать с тем или иным элементом. Не должно быть ситуаций когда пользователь не может прогнозировать поведение нашей системы, и тем более не должно быть ситуаций с неверными обещаниями. (Пример плохого интерфейса платёжных терминалов — это когда пользователь долго смотрит на него и думает: “Да куда ж тут нажать, зараза!”).
Если мы создаём продукт доступный для всех групп пользователей, то в качестве подсказки можно использовать шпаргалку A11y Annotation Kit.*
Создавая прототипы в фигме всегда лучше использовать переменные (variables), интерактивные компоненты, логику с условиями привязанную к переменным (conditional logic) и конечно же секции (sections) ведь мы можем линковать переход не на отдельный фрейм а на целую секцию, внутри которой будет исполнятся нужный нам сценарий на нескольких фреймах, помним что внутри секции стартовым фреймом считается левый верхний. Это поможет нам сократить размеры наших прототипов в десятки раз, при этом они останутся интерактивными и сохранят в себе всю логику взаимодействий. Для макетов со сложными прототипами так же будет не лишним делать описание состояний и взаимодействия как на макетах предназначенных для передачи в разработку.
Когда прототипы прошли нашу экспертную дизайн-проверку, можно переходить к этапу тестирования на реальных пользователях. Перед этим хорошо проверить прототипы внутри команды и дать всем “прокликаться”. В идеале, если можно воспроизвести реальные условия использования, нужно их имитировать (помним про пример с фитнес приложением). На этапе проверки прототипов инсайты приходят особенно часто, и эти этапы пропускать нельзя.
Хороший кейс — это привлечь экспертов для тестирования прототипов (В нашем примере нам нужны опытные пользователи скринридеров например)
Сценарий Тестирования
Модерируемое тестирование в некотором роде похоже на интервью с пользователями и правила его проведения во многом похожи. У нас так же есть стадия знакомства/разогрева, где мы должны создать спокойную комфортную обстановку и объяснить пользователю, что мы тестируем интерфейс, а не его самого, и нам нужны честные ответы, которые в будущем помогут улучшить взаимодействие. Мы так же по возможности не сознаёмся что являемся дизайнерами на проекте, а представляемся маркетологами или продакт менеджерами. Далее следует стадия проверки самой гипотезы, проверка корнер-кейсов, сбор фидбека, и обязательная фиксация метрик успеха.
Разогрев:
Устанавливаем контакт, убеждаемся что респондент чувствует себя комфортно(заранее настраиваем оборудование для записи экрана/аудио) просим совершить какие-то привычные действия внутри приложения, например проверить баланс на главном экране.
Критические задачи и проверка гипотез:
Задача 1 (Обнаружение): Формулируем задачи не давая подсказок. На этом этапе мы пытаемся выяснить за сколько шагов (свайпов/кликов) пользователь нашел баннер? Прошел ли он мимо него?
Пример: "Представьте, что вы решили впервые попробовать инвестировать небольшую сумму, но не хотите сами выбирать акции. Найдите предложение на главном экране, которое поможет вам начать инвестировать."
Задача 2 (Понимание): Мы хотим выяснить насколько хорошо пользователь понимает наш интерфейс, нет ли у нас неоднозначных или мусорных элементов несущих дополнительную когнитивную нагрузку. В нашем примере мы хотим проверить все ARIA-labels: Прочитал ли скринридер четко заголовок и описание? Читались ли лишние или бессмысленные элементы?
Пример: "Теперь, когда вы нашли это предложение, пожалуйста, расскажите, что именно ваш скринридер прочитал. Как вы поняли, что это 'Готовый пакет инвестиций'?"
Задача 3 (Взаимодействие): На этом этапе мы выясняем как происходит взаимодействие с элементами интерфейса. В нашем примере мы проверим доступность (A11y — accessibility) нашей CTA: Была ли кнопка легко активирована (особенно при навигации Tab или свитч-контролем)? Не было ли ошибочных нажатий?
Пример: "Отлично. Пожалуйста, нажмите на это предложение, чтобы продолжить."
Корнер-кейсы:
Задача 4 (Смена контекста): На этом этапе нам нужно выяснить не появляются ли новые барьеры при переходе на новые экраны и убедиться что пользователь не теряет контекст. В нашем примере мы захотим выяснить объявил ли скринридер новый заголовок страницы сразу после перехода?
Пример: "Вы перешли на новый экран. Расскажите, как вы поняли, что именно изменилось. Где вы сейчас находитесь?”
Задача 5 (Алерты и предупреждения): В зависимости от задачи у нас могут быть совершенно разные экраны предупреждениями и мы должны выяснить что язык их предельно простой и понятный пользователю, и эти предупреждения не имеют двояких смыслов. В нашем примере мы захотим выяснить является ли предупреждение простым и доступным для чтения скринридером? Понятно ли оно пользователю (особенно с когнитивными нарушениями)?
Пример: "На этом экране есть важное юридическое предупреждение о рисках. Пожалуйста, найдите его и прочитайте, как оно сформулировано.”
Задача 6 (Отказ): Всегда проверяем путь отказа от использования и удобного закрытия. В нашем примере мы будем проверять доступность кнопки закрытия: Легко ли была найдена кнопка "Назад" / "Закрыть"? Была ли ее ARIA-метка понятна?
Пример: "Представьте, что вы передумали. Пожалуйста, вернитесь на главный экран или закройте это предложение.”
Фидбек
Обязательно собираем фидбек, мы здесь только ради этого. Нам нужны инсайты и личные впечатления. Задаём интересующие нас вопросы:
"Что было самым простым в использовании этого баннера/экрана?"
"Что было самым запутанным или трудным?"
"Было ли в прочитанной информации что-то, что заставило вас сомневаться или почувствовать себя неуверенно?"
"Если бы вы могли изменить одну вещь в этом баннере, что бы это было?"
Метрики
Собираем метрики чтобы получить объективное подтверждение, что наше решение работает, и выявить новые, незаметные прежде проблемы. Метрики, которые нас волнуют:
Успешность выполнения задачи (Success Rate): Смог ли пользователь успешно кликнуть (Да/Нет).
Время выполнения (Time on Task): Сколько времени заняло обнаружение баннера.
Количество ошибок (Errors): Сколько раз пользователь ошибочно свайпнул мимо баннера или нажал на неверный элемент.
Также записываем дословные комментарии пользователя о том, что он слышит и думает.
Итерации и доработки
Получив фидбек возвращаемся к своим прототипам и вносим изменения. Это небольшой цикл внутри больших циклов, и если мы уверены что собранных данных нам достаточно для дальнейшей работы, то следуем такой схеме:
Создаём Прототип -> Тестируем -> Собираем инсайты -> Дорабатываем напильником
Наша цель довести наше решение до возможного совершенства в рамках отведённых для этого сроков. Вообще в дизайне есть такое понятие как “Достаточно хорошо” (Good enough) и сроки доставки в прод, и зачастую нам приходится решать что в нашем случае будет попадать под это определение. Но это тема для отдельной статьи, сейчас мы говорим об идеальных условиях. Если на этом (впрочем как и на любом другом) этапе мы понимаем что для дальнейшей работы нам нужно больше данных, то возвращаемся к предыдущему этапу, в котором по нашему мнению есть пробел. Это может быть не только этап из второго ромба “Решение”, но и любой этап из первого ромба “Проблема”.
Финальный UI-кит и дизайн-система
Настало время собирать наши макеты в чистовик и передавать в разработку. Тут всё будет зависеть от того создаёте ли вы что-то с нуля, либо используете уже готовые компоненты существующей дизайн-системы и от утверждённых дизайн-процессов в команде. Как бы то ни было, но вот пару советов при подготовке макетов:
Дизайн-систему лучше строить на переменных (Variables) через систему примитивов-алиасов-токенов с дефолтной семантикой вида компонент-категория-состояние-роль (component-category-state-role). Есть прекрасный инструмент для генерации семантики ваших токенов — https://namedesigntokens.guide. Полноценной дизайн-системой она станет когда наш UI-kit обзаведется описанием всех компонентов, и эти самые компоненты появятся в коде у разработчиков, чтобы они могли их точно так же копировать и вставлять куда надо.
Все элементы дизайн-системы и сами макеты должны иметь описание их состояний и правил использования. Все временные комментарии оставляем с помощью комментариев в фигме, а действующие всегда либо с помощью аннотаций, либо в отдельных фреймах рядом с макетами.
Все компоненты должны настраиваться снаружи и иметь правильную семантику, внутри фиолетовых компонентов не должно быть ‘Frame12517345’.
Всегда используем автолейауты, все макеты должны быть респонсив и не должны разваливаться на глазах при изменении размера
Дизайн-система должна быть консистентной (не используем разные компоненты для один и тех же кейсов в разных местах системы)
Показываем флоу с описанием взаимодействия и логики для разработчиков
Экспортируем все иллюстрации/анимации/иконки в нужных размерах и форматах для разработки
Отвечаем на вопросы разработки
Главная цель на данном этапе это максимально гладко передать нашу работу в разработку, минимизировав вопросы и недопонимание. Даже погруженный в продукт разработчик может не понимать что происходит на новых экранах, не говоря уже о разработчиках недавно прошедших онбординг. Наши макеты должны быть понятны всем.
Поддержка в процессе разработки и тестирование финальной реализации
Подробнее о работе с макетами и этапах их подготовки с последующей проверкой чек-листами перед отправкой на ревью, и проверке билдов на соответствие дизайну я расскажу в третьей части моей статьи :-)
Чуть не забыл, никогда не влюбляйтесь в ваши идеи, какими бы классными они вам ни казались, пользователи могут их не принять. И чтобы не принимать отказы близко к сердцу лучше изначально не влюбляться в свои идеи. А отказов будет много, ведь на этапе отбора лучших идей мы должны быть безжалостными и не позволять субъективному мнению влиять на конечное решение.
Творите добро :-)