Привет! Я — Лёша, принципал дизайнер, решаю бизнес-задачи с помощью дизайна уже больше 15-ти лет. Это моя первая статья из небольшой, но насыщенной серии, и она полностью посвящена дизайн-процессам и взрослому, результативному подходу к работе. Я постараюсь рассказать все очень кратко, насколько это возможно чтобы не потерять суть, но емко. Сделаю это так, чтобы все процессы стали понятны даже новичку.

Думаю большинство читателей уже знакомы с известной системой «Double diamond» (двойной ромб), разработанной Британским Советом по дизайну еще в далеком 2005-м году. Называть его в русском варианте «Двойной алмаз» некорректно. Алмаз многогранен, а суть подхода именно в двух, при необходимости бесконечно повторяющихся этапах дивергенции и конвергенции внутри каждого ромба.

Если говорить простыми словами, то суть заключается в том, что сначала мы расширяем наш поиск во все возможные стороны, и только потом приступаем к поиску решений, объединяя все полученные знания, при этом сужая фокус внимания. Мы делаем какие-то выводы из полученных данных и оставляем только самое важное из того что мы смогли выяснить. У каждого ромба в этой системе есть два этапа (расширение и последующее объединение):

1. Discovery (Исследования) — Этап дивергенции (Расширение поиска)

2. Define (Определение) — Этап конвергенции (Объединение знаний)

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

Diamond 1 (Проблема)

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

Часть первая (Исследования):

• Интервью со стейкхолдерами

• Аналитика и сбор данных

• Интервью с пользователями

• Опросы

• Исследование рынка

• Сравнение конкурентов

Часть вторая (Определение):

• Возможности, потребности, задачи

• Сегментация пользователя

Исследования (Discovery)

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

Интервью со стейкхолдерами

Начинать нужно с интервью со стейкхолдерами, и для начала нам нужно определить круг стейкхолдеров, чьи интересы затрагивает наша проблема. Это могут быть прямые стейкхолдеры, такие как Product Manager, Team Lead, CEO, так и косвенные, такие как разработчики, маркетологи, аналитики, юристы и специалисты поддержки.

Важные пункты при проведении интервью:

1. Предупреждаем заранее, и отправляем запрос на интервью, в котором сразу сообщаем цель нашего интервью, наша цель — глубоко понять проблему со всех сторон, и нам нужен опыт и видение этого человека. Говорим о формате интервью, обычно это короткая беседа минут на 30. Озвучиваем темы которые хотим затронуть (проблемы/ограничения/”истории с полей”). Уточняем доступность на этой неделе и сами предлагаем несколько слотов на выбор.

2. Всегда объясняем контекст исследования, например: "Я запускаю серию исследовательских интервью на этапе Discovery чтобы изучить проблему низкой конверсии на выдачу карты, и понять, где главная боль пользователей" (При этом в нашей голове оно должно звучать примерно так: “У нас юзеры не заказывают пластик, почему? Что им мешает, и нужен ли он им на самом деле, как сделать так чтобы они его захотели?” Если этого не происходит, и мы не можем описать проблему простыми словами, значит мы сами её ещё не понимаем и надо думать дальше).

3. Заранее готовим свой список вопросов.

4. Не спрашиваем готового решения, спрашиваем "Почему?", "Что?" и "Как?”. Помним что мы пришли чтобы выяснить настоящую проблему, а не собирать список пожеланий. Нам нужен чужой опыт и видение.

5. Слушаем не перебивая, чаще задаваем вопрос “Почему?”, не боимся быть “Почемучкой”, помним про золотое правило “5 почему”.

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

7. Всё фиксируем, записываем аудио и видео с разрешения, если разрешения нет, то фиксируем всё от руки на бумаге, или как удобнее, чтобы это не отнимало много времени. Диктофон на смарт-часах — прекрасное изобретение :) Цитаты помогут нам защищаться в будущем.

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

9. Обращаем внимание на эмоции которые вызывают наши вопросы, отмечаем самые резонансные.

10. Делаем краткое саммери в котором описываем выявленную проблему, риски, ограничения и противоречия между стейкхолдерами если они есть.

11. Визуализируем карту проблем, мы — дизайнеры, а не программисты. Визуальный дизайн в первую очередь это работа с текстом. Сухой текст всегда воспринимается хуже чем текст+картинка. Поэтому стараемся отобразить всё так чтобы можно было быстро понять суть происходящего, а всматриваться и вчитываться только ради деталей. Можно использовать Miro или FigJam, и делимся результатами с командой. Так мы даём понять что услышали собеседников, и это создаём общую картину для команды.

Проведя интервью со стейкхолдерами переходим к отделу аналитики.

Аналитика и сбор данных

Если у нас есть свой отдел аналитики — это здорово, и мы всегда можем отправить запрос на сбор данных, которые нас интересуют, либо получить уже готовые. А при серьезном подходе и сразу размечать данные для создания “золотого стандарта” для последующего обучения ML моделей.

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

На этапе когда мы говорим “Кажется с нашим разделом “Автоплатежей” какая-то проблема, думаю его сложно найти” — мы находимся на стадии “просто гипотезы”. А вот когда аналитика нам подтвердит это цифрами, и покажет что 80% наших пользователей никогда не открывали страницу “Автоплатежей”, это превратится в реально подтвержденную проблему, которую надо решать.

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

Какие запросы для понимания пользователей и их поведения мы можем направлять аналитикам?

Запросы сегментации и активности

• Покажите основные сегменты наших пользователей по демографии и ключевым поведенческим паттернам (например: "Молодые родители”, ”Женщины средних лет”, “Активные инвесторы”, “Редкие плательщики”)

• Как выглядит “путь нового пользователя”? На каких шагах мы теряем больше всего пользователей?

Поведенческий анализ

• Покажите воронку “перевода денег”. На каких шагах самый высокий отток?

• Есть ли у нас группы пользователей, которые выполняют неочевидные последовательности действий для достижения цели? (Если такие группы есть и их много, то скорее всего мы где-то ошиблись в проектировании)

Ошибки и отказы

• На каких экранах/шагах самый высокий процент ошибок или отмененных действий?

• Какие поисковые запросы в приложении чаще всего возвращают нулевой результат?

Анализ поддержки

• Какие темы являются самыми частыми причинами обращений в службу поддержки? Можем ли мы увидеть, с какого экрана приложения чаще всего поступают эти обращения?

• По каким запросам самый высокий процент повторных обращений? (Так мы можем увидеть нерешенную проблему)

Тренды и метрики здоровья продукта

• Покажите динамику ключевых метрик (Retention Rate, NPS, CSAT) для разных сегментов пользователей. Где мы видим наибольшее падение или рост? (Тут важно понимать какие метрики нам нужны, далеко не все фичи измеряются ключевой метрикой для вашего продукта (“North star metric”))

• Как наши метрики выглядят в сравнении с аналогичным периодом прошлого года?

Валидация наших гипотез через цифры

• Есть гипотеза, что сложный процесс верификации отпугивает новых пользователей. Покажите каков процент успешного завершения этого процесса с первой попытки?

• Мы предполагаем, что пользователи не находят функцию “Автоплатеж”. Покажите, сколько пользователей, которые регулярно делают ручные платежи за ЖКУ, ни разу не заходили в раздел “Автоплатежей”?

О чём стоит помнить при составлении запросов аналитике:

1. Максимально конкретно определяем чего хотим, например кто в нашем понимании “активный пользователь”, это пользователь бывший онлайн хотя бы раз за 30 дней, или пользователь совершивший транзакцию?

2. Просим данные, а не выводы, в идеале просим и сырые данные. Иногда важно посмотреть на анонимный путь пользователя (user journey) чтобы увидеть реальные сценарии. Просто графиков зачастую недостаточно.

Интервью с пользователями

Проводя интервью с пользователями стоит руководствоваться все теми же правилами что при интервьюировании стейкхолдеров: мы просто внимательный слушатель, 80% времени мы слушаем, и 20% времени задаём вопросы. При подготовке интервью с пользователями хорошо провести короткие встречи со стейкхолдерами причастными к гипотезе, которую мы хотим проверить, они помогут составить вопросы, будут больше вовлечены в процесс и будут больше нам доверять во время защиты наших решений. Так же хорошо пригласить их в наблюдатели.

Немного советов и краткий гайд для интервью с пользователями:

1. Четко определяем цели. Например не "понять пользователей", а конкретно: "Понять, как мелкие предприниматели ведут учет расходов и почему они до сих пор используют для этого Excel, а не наш продукт?"

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

   • Вступление где мы представляемся и объясняем цель интервью, упоминаем о конфиденциальности и берем согласие на запись. Если респондент не знает вашу роль на продукте, то лучше сказать что вы маркетолог и хотите улучшить продукт. Почти всегда когда я говорил что я дизайнер, у собеседников просыпалась творческая жилка и они пытались воплотить свои идеи моими руками (обычно даже у фрилансеров истории в духе “Вы стоите рядом и говорите мне как нужно сделать” — это х2 к ценнику, мы здесь не за этим).

   • Разминка буквально на пару минут, где мы задаем легкие вопросы о роли, опыте, контексте ("Чем вы занимаетесь?", "Как выглядит ваш обычный день?")

   • Основная часть, в ходе которой мы задаём вопросы связанные с целью исследования. Помним что нас интересуют реальные кейсы и прошлые события и поведение пользователя. Гипотетические вопросы связанные с будущим не задаём. Вопросы связанные с будущим можно задавать только когда пользователь говорит что ему “Вот тут нужна еще одна кнопка ‘Button’”, тогда можно спросить какую задачу он бы с ее помощью решал.

   • Завершение, тут мы спрашиваем есть ли ещё что-то важное в контексте что мы не обсудили, с кем нам еще нужно было бы поговорить, и благодарим за интервью.

3. Ищем респондентов. Это наверное самый сложный и важный этап, нужно очень тщательно отбирать респондентов, ведь один “халявщик” или “фантазёр” может всё испортить. Мы не гонимся за количеством, нам важно качество, обычно 5-7 интервью достаточно чтобы выявить 80% проблем. При этом нам надо четко определить кого мы хотим видеть на интервью (например: "пользователи, которые пользовались фичей “Х” хотя бы раз за последнюю неделю, при этом не совершили целевое действие").

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

4. Проводим само интервью. Стараемся создать максимально комфортную и непринужденную атмосферу, чтобы у респондента было ощущение что он общается со своим старым знакомым. Во время общения смотрим на невербальные знаки: паузы, вздохи, смена интонации — это явный признак что человек говорит о чём-то важном для него. Не пытаемся решить задачу на месте и не задаём наводящих вопросов в духе “А вам сложно было…?”, лучше спросить “Как прошло ваше знакомство с …?”.

5. Обрабатываем данные. В идеале сразу после интервью обсуждаем с наблюдателем какие ключевые инсайты удалось выяснить, и какие сложились первые впечатления. После чего занимаемся расшифровкой данных, для этого можно использовать Otter.ai или Trint.com например. В крайнем случае делаем пометки по ключевым моментам.

6. Сортируем. Используем аффинити-сортировку, выписываем все интересные цитаты, а потом группируем их по темам и собираем смысловую карту в Miro или FigJam. Это поможет нам выявить паттерны.

7. Формулируем инсайты и рекомендации. Инсайт — это наблюдение + контекст + причина. Например: "Мы заметили, что пользователи не используют функцию автоплатежей. Это важно, потому что это одна из ключевых функций нашего приложения. Мы думаем, это происходит из-за того, что эту функцию сложно найти в интерфейсе". Далее идут рекомендации, рекомендации должны быть конкретными и привязанными к инсайтам. Например: “Раз пользователи не находят автоплатежи, предлагаем добавить кнопку “Автоплатежи” в список прошлых платежей и закрепить ее сверху/в начале списка”.

8. Готовим презентацию команде. Не бросаем в общий чат гугл-документ чтобы сами разбирались, а готовим хорошую полноценную презентацию, в которой рассказываем небольшую историю, в которой раскрываем цели исследования, показываем самые яркие цитаты, инсайты и выявленные паттерны. (На стадии аффинити-сортировки тоже можно привлекать участников команды чтобы улучшить понимание и увеличить вовлеченность, а заодно и упростить вашу защиту). В конце презентации подводим итоги и говорим какие гипотезы подтвердились/опроверглись? Предлагаем свои решения и спрашиваем что будем делать дальше (дизайн, разработка, новое исследование)?

   Я всегда помню, что моя роль как дизайнера — не просто "поговорить с пользователями", я делаю это чтобы потом быть амбассадором пользователя внутри команды. Моя задача превратить разные мнения опрошенных в структурированные, проверенные данные, на основе которых уже можно принимать уверенные решения. При этом я помню и про интересы бизнеса, но пользователь для меня всегда важнее, во всех дебатах я остаюсь на стороне пользователя, ведь недовольный пользователь просто уйдёт в другой продукт.

   Опросы

1. Определяем цель и философию опроса

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

2. Фокусируемся на проблеме и составляем вопросы

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

Открытые — когда мы хотим получить развернутый ответ чтобы понять контекст (например: "Опишите процесс как вы планируете отпуск.")

Поведенческие — когда хотим узнать о реальных поступках, а не о намерениях( например: "Вспомните, когда вы откладывали деньги на какую-то цель последний раз. Что вы делали?")

Вопросы о боли/радости — задаём чтобы выявить самые эмоциональные точки (например: "Что самое раздражающее в процессе перевода денег людям из ваших контактов?"

Вопросы ранжирования — задаём когда хотим понять приоритеты(“Расставьте по важности: скорость перевода, его бесплатность, простота процесса.") Это всегда очень сложный момент и к результатам нужно подходить очень вдумчиво и неспешно, результаты могут быть однозначными только если у нас участвовала только одна заранее определенная группа пользователей и большинство из них ответило примерно одинаково.

3. Определяем аудиторию и канал распространения

Аудитория: Определяем кто нас интересует. Новые пользователи? Потерянные? Активные?

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

Канал:

• Внутри продукта: (Pop-up с помощью Typeform или Survicate например). Лучше подходит для таргетинга на конкретных пользователей (например тех, кто только что завершил определенное действие).

• Рассылка по email: Подходит для более длинных опросов, но использовать можно только для лояльных пользователей. Если мы все же решились отправлять емейл письма неактивным пользователям, еще и с неким опросом, пытаясь выяснить почему они перестали пользоваться нашим продуктом, увеличиваем временные промежутки между отправленными письмами так: День >> 2 Недели >> Месяц >> 3 месяца >> Год >> Никогда. И обязательно предлагаем некие бонусы при возвращении :)

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

Немного советов при составлении опросов:

1. Не даем подсказок в вопросах ( вместо “Вам не кажется что процесс перевода слишком долгий?" спрашиваем "Что вам не нравится в процессе перевода?”).

2. Не задаем вопросы о будущем ("Купили бы вы нашу новую газонокосилку?”) — Люди плохо предсказывают свое поведение.

3. Не задаем слишком абстрактные вопросы ("Что вы думаете о финансовой грамотности?”)

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

Если у нас небольшая команда и мы только начинаем, то можем использовать самые обычные гугл-формы чтобы проводить опросы среди друзей и знакомых, давая им попользоваться нашим продуктом. Конечно для статистически значимых данных их должно быть не меньше 600, а лучше 1000+, но иногда и 30 помогают лучше увидеть проблему, когда на один вопрос все отвечают одинаково и указывают нам на наличие ошибок.

Исследование рынка

Исследование рынка зачастую необходимо даже на старте разработки новой фичи, не говоря уже о новом продукте. Первое что вы должны выяснить — это запросы самого рынка, его общий объем, потенциальный объем, и объем рынка на который можете рассчитывать вы (PAM, TAM, SAM, SOM). Где и как собирать данные при исследовании рынка — это довольно обширная тема, которая достойна отдельной статьи. Здесь я упомяну только что очень важно перепроверять данные, несколько раз, всегда. Если ошибиться здесь, то потом все результаты нашего труда, какими бы отличными они ни были, вылетят в трубу, оставшись горьким опытом и дырой в бюджете.

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

Сравнение конкурентов

Создаём отдельную доску в Miro или FigJam, где разложим всех конкурентов по полочкам (в первую очередь крупных игроков, и игроков из нашего региона, если продукт локальный), создаём список плюсов и минусов из того что у них есть в интерфейсах. Это всё есть в открытом доступе и всегда можно скачать продукт/заказать демо, чтобы потрогать его руками.

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

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

Помните, голова дизайнеру дана чтобы думать, а не чтобы запоминать. Всё что можно делегировать — делегируем! Делегировать можно и удобным инструментам, не обязательно это должны быть другие люди.

Определение (Define)

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

1. Синтез данных (Data Synthesis)

Собираем нашу "Стену инсайтов" (Affinity Mapping) в Miro или FigJam, и начинаем искать общие паттерны. Группируем наши стикеры по темам, например, "Страх ошибки", "Нехватка времени", "Непонимание терминов”, названия для групп придут сами по себе и будут по сути нашими ключевыми инсайтами.

2. Определение возможностей, потребностей и задач (Opportunities, Needs, Tasks)

Теперь нам нужно проанализировать сгруппированные инсайты, чтобы сформулировать выводы. Определить потребности, задачи и наши возможности.

• Потребности (Needs): Что пользователям нужно на самом деле?

  "[тип пользователя], нуждается в [потребность], чтобы [причина/ценность]"

  Например: «Частный предприниматель[тип пользователя], нуждается в возможности быстро отделять личные траты от бизнес-расходов при оплате с телефона[потребность], чтобы не тратить часы в конце месяца на разбор операций по выписке, и избежать ошибок при подаче налоговой отчетности[причина/ценность]»

• Задачи (Tasks): Конкретные действия, которые пользователь должен выполнить, чтобы удовлетворить свою потребность. "Внести платеж", "Найти историю операций", "Настроить уведомление".

• Возможности (Opportunities): Как мы, как команда, можем удовлетворить эти потребности? Основываясь на потребности "быстро отделять личные траты от бизнес-расходов…", возможность может звучать так: "Можем ли мы создать систему быстрой фильтрации и сортировки платежей на мобильной платформе, которая снимет с пользователя когнитивную нагрузку, и облегчит подачу налоговой отчетности? Можем ли мы автоматизировать эти процессы чтобы минимально привлекать пользователя к задаче?".

3. Сегментация пользователей (User Segmentation)

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

• Персоны (User Personas) (вымышленные, но реалистичные(!) профили, представляющие ключевые сегменты. Включают демографию, цели, боли, мотивацию и цитаты из реальных интервью).

  *Очень важно не выдумывать за пользователей, но при этом слышать что они нам говорят. Так например во время интервью для одной крупной продуктовой сети магазинов, я слышал как ключевые потребители (Женщины 30-45 лет) часто упоминали, что покупают дешёвый майонез одной марки потому, что заботятся о членах своей семьи. На защите для бизнеса это могло бы звучать как полная чушь, и абсолютное непонимание пользователей. Ведь могло казаться что в таком кейсе люди ограничены в средствах и покупают дешёвый майонез просто чтобы сэкономить и закрыть дневное окно калорий, потому что майонез дешёвый и при этом суперкалорийный.

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

• Архетипы Потребителей (Jobs-to-be-Done (JTBD)): Альтернативный подход, в котором мы фокусируемся на работе, которую пользователь хочет выполнить с помощью нашего. "Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]".

Например: "Когда я получаю зарплату [ситуация], я хочу быстро распределить деньги по счетам [мотивация], чтобы чувствовать контроль над финансами и не беспокоиться о долгах [ожидаемый результат]".

4. Формулировка проблемы (Problem Statement)

Это — главный итог всего первого ромба. Одна-две четкие фразы, которые определяют, какую проблему мы собираемся решать. Если мы на данном этапе всё ещё не можем сформулировать проблему для решения, мы можем повторять те предыдущие пункты исследований, в которых как нам кажется недостаточно данных для уверенных выводов. Этот процесс может быть по сути бесконечен, но не стоит переусердствовать ведь всегда есть какие-то сроки передачи в разработку :) Что нужно на выходе:

"[Тип пользователя] нуждается в [потребность], потому что [выявленный инсайт]. Наша текущая ситуация [текущая проблема] вызывает [негативное последствие]".

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

Итог: Что у вас должно быть после этапа Define

Прежде чем переходить ко второму ромбу (поиску решений), у нас должен быть пакет документов, понятный команде и стейкхолдерам:

1. Сформулированная проблема (Problem Statement) — "что" мы решаем.

2. Набор ключевых инсайтов — "почему" мы решили решать именно это.

3. User Personas или JTBD — "для кого" мы это делаем.

4. Карта путешествия пользователя (Current State User Journey Map) — "как" проблема выглядит в контексте всего их опыта.

Что нам делать дальше?

Дальше нам надо согласовать все эти артефакты со всей продуктовой командой и стейкхолдерами. Только когда все понимают и согласны с проблемой, можно приступать ко второму ромбу (Diamond 2: Solution) и начинать генерировать идеи для ее решения — мозговые штурмы, скетчи, прототипы. Обо всём об этом я поговорю во второй части этой статьи.

Все эти фреймворки сами по себе классные вещи и иногда они действительно нужны все, но важно уметь выбирать наиболее важные и минимально необходимые для текущей проблемы, при этом помнить насколько они ресурсоёмки. Ведь каждый час каждого участвующего в данном фреймворке сотрудника оплатит бизнес. Так для нас CJM например может выглядеть как 1-6, а то и 12+ месяцев работы, а для бизнеса это будут сотни тысяч долларов. И вот тут наша задача убедить бизнес что это хорошее вложение средств и взамен он получит заметно больше.

Чем нам могут помочь нейросети?

Итак, мы наконец добрались до той части статьи, где я расскажу что же мы можем сделать если у нас нет достаточных ресурсов для проведения широких продуктовых исследований? Допустим мы обычный небольшой стартап из 3-7 человек и не можем себе позволить заказать в агентстве живые интервью с пользователями, своих у нас еще нет, но при этом хотим решить настоящую проблему( которая вполне себе может отличаться от наших изначальных предположений).

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

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

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

Так как же нам помогут понять наших пользователей нейросети?

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

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

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

Да, некоторые форумы закрывают доступ нейросетям, как например Reddit закрыл доступ для всех нейросетей, оставив доступ только для Gemini от Google, потому что Google платит за доступ к сайту. Но я верю что и остальные либо оплатят доступ, либо всегда будут те, кто это уже сделал, и нам придется выбирать из списка наиболее нам подходящие.

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

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

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

Это было отличным решением, так как учить пользователя чему‑то кардинально новому всегда тяжело, за последние 15 лет уже сформировались привычные паттерны поведения и взаимодействия с интерфейсами. Но это не значит что то, что мы видим сейчас уже идеально, ведь всегда есть куда расти. Вспомним хотя бы на iOS 26 и динамические таббары с поиском внизу экрана, прям под нашим пальцем, которые иногда превращаются просто в одну целевую кнопку. Это прям гениально, я искренне восхищен таким решением.

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

1. Action (Срочные и важные) — Важные письма требующие от пользователя каких‑то срочных действий

2. Review (Важные, но не срочные) — Письма важные, но не срочные

3. Other (Другие) — Промо, рассылки, чеки и прочая реклама, на которую вы сами подписались

4. All mail (Вся почта) — Вся почта вместе (Без спама конечно)

Вот несколько примеров цитат, которые мы разбирали:

"Stop showing 10 separate emails for the same Slack thread. Collapse them like Discord messages.”

”I don’t need more features — I need clarity. Tell me what’s critical, hide the rest, and let me trust the system”

Таким образом, благодаря нейросетям мы выяснили более приоритетные боли пользователей, которые надо было решать. Честно говоря в нашем списке оказалось около 80-ти болей (из которых мы закрыли около 30-ти на этапе МВП), которые беспокоят пользователей электронной почты, но самыми приоритетными оказались эти. И мы с ними успешно справились :-)

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

Творите добро :-)