OZON РЕДИЗАЙН ЧАТОВ
cкорокомандная работа в рамках
дизайн-интенсива
LUMISPACE ПЕТ-ПРОЕКТ
проектировала сценарии поиска
для сервиса ментальной поддержки
HIREHI
cтартап, агрегатор IT-вакансий,
моя роль и кейсы
LumiSpace – сценарии поиска
Контекст
LumiSpace — приложение для поддержки ментального здоровья. Оно помогает найти подходящую практику под текущее состояние и пройти ее внутри приложения. Я работала над ним в рамках курса продуктового дизайна UXROCK.
Моя роль
Я отвечала за полный цикл дизайна продукта: от декомпозиции задачи и исследования пользователей до продуктовой логики, проектирования сценариев, визуальной концепции, hi-fi прототипа и UX-тестирования.
Задача
Спроектировать MVP ключевых экранов основного пользовательского пути: от поиска подходящей практики до ее прохождения и рефлексии.
После декомпозиции брифа я зафиксировала задачи:
Миссия для пользователя
быстро находить поддержку под текущее состояние: как в кризисный момент, так и для регулярной практики.
Задача для бизнеса
вырастить DAU до 1000 за первые полгода, сформировать базу лояльных пользователей и увеличить конверсию в подписку.
Под это определила ключевые метрики: DAU, MAU и Retention показывают, насколько продукт становится привычкой. Конверсия и NPS — про рост бизнеса.
Метрики помогли определить фокус
Основной пользовательский путь выглядел так:
поиск практики → прохождение практики → переписка с чат-ботом.
В качестве фокуса я взяла метрики регулярного использования — DAU, MAU и Retention.
Я предположила, что один из факторов, который может влиять на регулярность, — насколько быстро пользователь находит подходящую поддержку и решает свою задачу в моменте.
Поэтому для детальной проработки я сфокусировалась на первом участке пути — поиске практики.
Моя гипотеза:
чем проще путь до релевантной практики, тем выше вероятность, что пользователь решит свою задачу и вернется к продукту снова.
Чтобы понять, что может мешать этому пути и каким должен быть поиск, я пошла разговаривать с пользователями.
Две модели поведения — разные требования к поиску
По итогам глубинных интервью я выделила две поведенческие персоны — Гуру и Кризисный боец.
Главное различие — в контексте обращения за поддержкой. Гуру чаще осознает свое состояние и готов исследовать разные способы самоподдержки. Кризисному бойцу сложнее долго фокусироваться и разбираться в вариантах — ему нужна более быстрая и понятная помощь.
Гуру
хорошо знаком со всеми техниками самопомощи, исследует и пробует новое, регулярно занимается с психологом, использует AI-инструменты и адаптирует их под себя. Выстраивает регулярную практику и осознанно подбирает её под состояние.
Мотиваторы:
– осознавать своё состояние и находить подходящие способы самопомощи
– регулярно поддерживать себя, пробуя новые техники и получая удовольствие от процесса
– иметь под рукой эффективные техники на случай острого момента
Барьеры:
– AI-ассистент неправильно понимает запрос
– в момент острой панической атаки нет возможности долго что-то искать и выбирать
Кризисный боец
вспоминает о ментальном здоровье только в моменты кризиса. Не знает, как выбрать подходящую технику и не понимает, как интегрировать ее в свою жизнь, к AI относится с осторожностью. Довольно консервативен в выборе источника информации, полагаясь главным образом на рекомендации. Регулярной практики нет — приходит за помощью, когда уже плохо.
Мотиваторы
— отвлечься от тревожных мыслей без больших усилий
— быстро снять стресс «здесь и сейчас»
— не тратить много времени на подбор и изучение техники
Барьеры
— не понимает своих потребностей и не знает, как выбрать подходящую технику
— тяжело долго концентрироваться на чём-то одном
Ключевой персоной для дальнейшего проектирования я выбрала Гуру: такие пользователи лучше понимают ценность продукта, а забота о себе чаще уже встроена в их жизнь.
При этом поведение пользователя может меняться в зависимости от состояния: даже Гуру в сложный момент может нуждаться в более простом и быстром пути к поддержке. Поэтому сценарии Кризисного бойца тоже важно было учитывать в решении.
Но главное различие оказалось в языке запроса
Различался не только контекст, но и то, как пользователи описывают свое состояние.
Как рассказывают о своем состоянии?
Кто-то может сформулировать конкретно: «испытываю тревогу». Другой человек описывает состояние через эмоцию: «мне плохо» или «мне грустно».
В первом случае пользователь уже понимает, что с ним происходит, и может сформулировать более точный запрос. Во втором — может не знать ни названия состояния, ни того, какую практику ему искать.
Это изменило требования к поиску: нельзя рассчитывать на один способ формулирования запроса и на один универсальный путь до практики. Интерфейс должен учитывать и язык пользователя, и количество усилий, которое он готов потратить на поиск в конкретный момент.
Проверила, как с этой проблемой работают другие продукты
На российском рынке у лидеров по загрузкам есть только фильтры по категориям, но нет полноценного поиска — это барьер для «Гуру», который любит исследовать и находить новое.
Международный гигант InsightTimer принимает только точные термины, эмоциональный запрос не работает. Meditopia лучше понимает состояние, но выдаёт список из десятков вариантов — человек в кризисе может растеряться.
То есть готового решения, которое учитывало бы обе персоны, в моей выборке не нашлось, поэтому я посмотрела на смежные продукты с похожей логикой навигации по большой библиотеке: Яндекс Музыку и МТС Музыку, благодаря которым мне удалось сформулировать основные требования к поиску:
1 — две оси навигации: тип практики × состояние пользователя;
2 — поиск по смыслу: например, «тревога» и «тревожность» должны приводить к релевантным практикам.
Прежде чем рисовать сценарии, зафиксировала продуктовую логику
На этом этапе уже было понятно, какую проблему должен решать поиск, но мне не хотелось проектировать его изолированно от остального продукта.Поэтому перед основными сценариями я зафиксировала несколько системных вещей, которые должны были влиять на интерфейс.
01. Как продукт понимает контекст пользователя
Я продумала онбординг и балльную систему определения поведенческой модели. Она задает стартовый контекст для персонализации, но не закрепляет за пользователем одну персону: модель меняется вместе с его поведением. Так рекомендации и работа Луми могут адаптироваться к текущему состоянию человека.
02. Как должен вести себя Луми – AI-ассистент02. Как должен вести себя Луми
Дальше зафиксировала, как функции AI-ассистента могут различаться для двух персон.При этом я не привязывала пользователя к одной модели навсегда: интервью уже показали, что даже Гуру в определенный момент может нуждаться в более простом сценарии.Я описала возможные функции AI-ассистента, его Tone of Voice и характер.Мне было важно заранее определить эту логику, потому что Луми должен был восприниматься не как механический чат-бот, а как поддерживающий помощник, который может участвовать в разных точках пользовательского пути.
03. Как устроен контент
Перед проектированием поиска я отдельно описала сущность «Практика» и ее атрибуты.Это позволило зафиксировать, с какими данными работает поиск и по каким параметрам пользователь сможет находить и уточнять контент.
04. Как продукт будет зарабатывать
Параллельно я продумала модель монетизации: что входит в платный тариф и как работает пробный период.Мне было важно определить это до детальной проработки сценариев, чтобы не добавлять бизнес-ограничения постфактум, а сразу учитывать их в продуктовой логике.
После этого я перешла к happy flow основного пути и отдельно углубилась в поиск: проработала логику состояний и взаимодействий — поведение интерфейса при скролле и переключении тегов, переходы между сущностями, историю поиска и крайние состояния, например запрос без результатов.
Решение: один контент, три пути к нему
К этому моменту у меня сложилось несколько требований:
Что нужно пользователю
- пользователь может прийти как с точным запросом, так и с описанием состояния;
- иногда он готов исследовать и сравнивать, иногда ему нужна помощь максимально
быстро; - один и тот же человек в разные моменты может нуждаться в разных сценариях;
- поиск должен понимать смысл запроса;
- если сформулировать запрос сложно, продукт должен помочь это сделать.
Из этих требований выросло основное решение: одна библиотека контента — три способа добраться до практики.
01. Каталог — когда хочется исследовать
Каталог — сценарий для самостоятельного исследования. Он в первую очередь рассчитан на Гуру, который готов изучать варианты, сравнивать и выбирать практику под себя.
Поэтому я не веду пользователя по одному заранее заданному пути: он может начать
с подходящей ему оси навигации, постепенно сузить выбор с помощью чипов и сравнить практики в ленте. Если контекста достаточно — запустить практику сразу, если нет — перейти в карточку за подробностями. Так каталог дает пользователю контроль над выбором, но помогает постепенно сократить пространство поиска.
Детали, которые помогают выбирать
быстрее
В каталоге я старалась давать достаточно контекста для выбора прямо в ленте — без лишних переходов и необходимости разбираться в терминологии.
Бейджи
Показывают вторую характеристику практики прямо в ленте. Не нужно переключаться между осями или открывать карточку, чтобы понять, подходит ли практика.
Категории
Названы через результат, а не термин
«Успокоиться» или «снять стресс» проще соотнести со своим состоянием, даже если пользователь не знает название подходящей техники.
02. Поисковая строка — когда запрос уже есть
Она подходит обеим персонам: Гуру может искать конкретную технику, а Кризисный боец — описывать свое состояние. Поэтому поиск работает не только по точному совпадению, но и по смыслу.
Поиск я проектировала в контексте всего пользовательского пути: после выбора практики пользователь переходит к ее прохождению, а затем — к рефлексии.
Детали, которые делают путь проще
Снимаем фрустрацию на старте
История возвращает к прошлым запросам,
а рекомендации помогают начать, если пользователь еще не сформулировал новый.
Ускоряем поиск
Выдача обновляется уже во время ввода — пользователю не нужно формулировать запрос целиком, чтобы увидеть подходящие практики.
Помогаем уточнить запрос
Адаптивные чипы адаптируются под логику запроса: если искали по цели, фильтры предложат уточнить способ, и наоборот. Система не дублирует, а помогает уточнить запрос
Продолжаем сценарий после практики
После практики Луми предлагает зафиксировать свое состояние. Так пользователь может заметить эффект практики, а продукт — лучше понимать его состояние и точнее подбирать дальнейшую поддержку.
03. Луми — когда сформулировать запрос сложно
Изначально для уточнения практики можно было использовать классические фильтры.
Но в контексте продукта для ментальной поддержки у них есть ограничение: фильтры требуют одновременно осознать своё состояние и принять несколько решений, а это может создавать высокую когнитивную нагрузку на пользователя.
Поэтому вместо классического набора фильтров я использовала Луми.
Он задаёт те же четыре вопроса: о намерении, способе, времени и сложности, но по очереди. Это снижает нагрузку и не требует длительной концентрации. Если пользователь затрудняется с ответом, ассистент уточняет запрос и помогает.
Луми не вынесен в отдельный сценарий — обратиться к нему можно прямо в процессе поиска. Точки входа доступны на главной, в каталоге и поисковой строке, поэтому пользователю не нужно прерывать текущий путь, чтобы попросить помощи с подбором практики.
Один контент — разные пути к нему
В итоге поиск не привязан к конкретной персоне. Пользователь может выбрать способ исходя из своего состояния и того, насколько точно он может сформулировать запрос в моменте.
Каталог — когда хочется исследовать, поисковая строка — когда запрос уже есть, Луми — когда нужна помощь с его формулировкой. При этом все три сценария работают с одной библиотекой и сходятся в общем пользовательском пути: поиск → практика → рефлексия.
Следующим шагом я собрала сценарии в hi-fi прототип и проверила, насколько понятной эта логика оказывается в реальном взаимодействии.
Как проверяла решение?
Чтобы понять, насколько интерфейс справляется с реальной задачей пользователя,
я использовала два метода: сначала качественный UX-тест на hi-fi прототипе, затем тест первого клика.
Тесты отвечали на разные вопросы.
- качественный тест помог увидеть живое взаимодействие с интерфейсом и обнаружить места, где поведение пользователя расходится с задуманным сценарием.
- тест первого клика позволил отдельно проверить обнаруженную проблему на большей выборке
Качественный тест дал сигнал
Информант соответствовал профилю Гуру: регулярно практиковал и хорошо ориентировался в инструментах самоподдержки.
Задача была такой:
«Представьте, что вы только что испытали сильный стресс. Попробуйте найти дыхательную практику».
Информант справился и нашел практику через каталог, используя ось «Способ». Но в процессе обнаружился неожиданный барьер. Когда он захотел воспользоваться поисковой строкой, он не смог найти точку входа — иконка поиска прошла мимо его внимания.
Один информант — это сигнал, а не основание делать общий вывод. Поэтому следующим шагом я решила проверить, единична ли проблема.
Проверила сигнал тестом первого клика
Я сформулировала гипотезу:
иконка поиска не считывается как точка входа — пользователи не выбирают её первой, когда ищут конкретную практику.
Для проверки провела тест первого клика через Pathway на 15 респондентах — активных и ситуативных пользователях приложений для ментальной поддержки, практикующих от одного до четырех раз в неделю.
Результат:
от 51% до 95% участников не выбрали иконку поиска первой точкой входа.* Доверительный интервал составил ±22%.
Выборка небольшая, поэтому диапазон широкий, но даже его нижняя граница показала, что наблюдение из качественного теста не ограничивается одним пользователем.
Тест нашел проблему — а не готовое решение
По результатам проверки я сформулировала несколько вариантов решения:
Что можно сделать?
- заменить иконку полноценной поисковой строкой;
- перенести точку входа в более ожидаемое место;
- увеличить ее визуальный вес относительно остальных элементов.
Но данных, чтобы выбрать один из них, пока не было. Следующим шагом я бы проверила варианты повторным тестом первого клика или A/B-тестом.
В рамках MVP изменение точки входа я осознанно вынесла за границы проекта: проблема зафиксирована, варианты решения сформулированы, следующий метод проверки определен.
Итоги
В рамках курса удалось заложить основу продукта: визуальную концепцию, характер и ключевой путь поиска практики, состоящий из трёх сценариев — каталог, поисковая строка, ассистент Луми.
Все три работают на одну задачу: быстро найти поддержку под текущее состояние. Каждый путь учитывает язык, которым пользователь описывает своё состояние — от названия техники до «мне грустно».
Сценарий также закрывает потребность бизнеса и ключевую задачу: чем короче и точнее путь до нужной практики, тем выше шанс, что пользователь вернётся завтра. А регулярный возврат — это DAU и фундамент для конверсии в подписку.
Еще немного визуала
