1. Личные наблюдения и интуиция – «я вижу проблему, мне кажется, это нужно решить»
2. Гипотезы от стейкхолдеров – «начальник думает, что это нужно пользователям»
3. Реальные потребности пользователей – «мы спросили пользователей, и они подтвердили»

• Какие реальные боли и потребности есть у людей?
• Какие из них стоит решать вашей команде?
• Что вообще волнует вашу аудиторию?

• Как люди реально ведут себя, а не как они говорят, что ведут себя?
• Какие есть закономерности?
• Как контекст влияет на поведение?

• Какие ценности, ожидания, страхи у целевой аудитории?
• Как они видят мир?
• Почему они делают именно так, а не иначе?

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

• Краткое объяснение принципов поискового исследования (discovery research) от Дэвида Трэвиса
• Три примера стартапов, которые успешно провели поисковое исследование, от Джефа Готельфа

• Что сделала IKEA: посетила более 1000 домохозяйств, чтобы выяснить:
• Как устроены индийские дома?
• Как проходит повседневная жизнь семьи?
• Какие особенности ведения хозяйства?

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

• Почему 1 – Потому что занятые и забывчивые
• Почему 2 – Потому что нет системы напоминаний
• Почему 3 – Потому что забывают установить напоминание
• Почему 4 – Потому что не знают, как часто нужно поливать их конкретное растение
• Почему 5 – Потому что разные растения нужно поливать по-разному, в зависимости от сезона и условий

1. Опишите разных людей, связанных с темой
2. Разбейте тему на подтемы
3. Разбейте подтемы на еще более мелкие фрагменты
4. Разбейте деятельность на этапы

Может помочь объяснение в учебнике Карен Хольцблатт про фокус исследования, с.64−65, и инструкция, как его задавать, с.66−70

• Не полагайтесь только на популярные статьи и видео
• Ищите первоисточники: исследования, научные работы, оригинальные отчеты
• Причина: популяризаторы часто упрощают или неправильно интерпретируют данные

• «В статье говорится, что люди любят минимализм» (это чьё-то мнение)
• «В исследовании 500 респондентов 65% выбрали минималистичный дизайн» (это данные)ё
• Вопрос: Если вы видите утверждение, есть ли за ним исследование? Если нет – это мнение.

• Если вы не разбираетесь в теме, вполне нормально начать с авторитетных источников
• НО: это временное решение. По мере изучения темы переходите к первоисточникам.

Неправильно: «Приложение А имеет 5 функций, приложение Б имеет 7 функций»

Правильно: «Почему каждое приложение выбрало именно эти функции? Какую потребность они пытаются решить? Как они это понимают?»

• Wizard of Oz
• Консьержcкие эксперименты (Concierge MVP)
• Совместное прохождение сценариев (Scenario Walk-through)
• Ранжирование концепций (Ranking Concepts)
• Низкодетализированные прототипы (Lo-Fi Prototype Test)

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

1. Пользователь получает Google-форму с вопросом: «Какие комнаты вам нужно убрать?»
2. Он заполняет форму и отправляет
3. «Волшебник» вручную (в Google Docs) составляет персонализированный чек-лист уборки с советами
4. Отправляет пользователю уведомление: «Ваш чек-лист готов»
5. Раз в неделю спрашивает: «Вы уже убрали? Как прошло?»
6. После месяца спрашивает: «Насколько полезным был наш сервис?»

• Бесплатно, без разработки
• Можно собрать фидбэк 10-20 пользователей
• Время на волшебника: ~15 минут на пользователя в неделю
• Если людям не нравится → не тратим время на разработку

1. Пользователь получает форму: «Расскажите про ваше растение и условия (температура, влажность, освещенность)»
2. Отправляет заполненную форму
3. Волшебник составляет персонализированный график ухода за конкретным растением в конкретных условиях
4. Раз в 3-4 дня сервис спрашивает: «Что-то изменилось в условиях или состоянии растения?»
5. По результатам опроса волшебник обновляет советы и график
6. Через месяц: «Насколько полезным был адаптивный график?»

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

1. Схема работы «сервиса» – как волшебник будет его имитировать?
2. Длительность и условия – сколько времени будет длиться тест? Что означает успех?
3. Привлечение пользователей – где вы найдете 10-20 участников?
4. Требуемая разработка – нужны ли вспомогательные инструменты? (Google Forms, MailChimp, Telegram?)
5. Требуемые ресурсы – сколько часов в неделю вы потратите?
6. Измеряемые показатели – что вы будете отслеживать? (open rate, количество ответов, регулярность использования?)
7. Собираемая обратная связь – как вы будете спрашивать фидбэк? (интервью, анкета, чат?)
8. Критерии успеха – что означает, что идея валидна? (люди используют сервис 2+ раз в неделю? 50%+ открывают письма?)

• Google Forms – для сбора информации от пользователей
• Google Sheets – где волшебник обрабатывает данные
• MailChimp – для рассылок с персонализированным контентом
• Telegram/WhatsApp – для взаимодействия с пользователем
• IFTTT, Make, n8n – сервисы-интеграторы, которые помогают автоматизировать простые цепочки

• Вы хотите глубоко понять потребность пользователя
• Нужно собрать много качественного фидбэка
• Хотите понять, что именно нужно автоматизировать
• Продукт требует сложного взаимодействия

• Проблема: Какой разрыв между текущей и желаемой ситуацией волнует пользователей?
• Цифровое решение: Как вы будете решать эту проблему с помощью цифрового сервиса?
• Ручное решение: Как вы будете оказывать услугу вручную?
• Pitch (продажа): Как вы будете коммуницировать ценность потенциальным клиентам?
• Чек-лист: Что не нужно забывать перед тем, как предложить MVP клиентам?

• Места: Где офлайн можно найти целевую аудиторию?
• Facebook группы: Какие сообщества в соцсетях относятся к вашей аудитории?
• Twitter хеш-теги: Какие хеш-теги использует ваша аудитория?
• LinkedIn группы: Какие профессиональные сообщества?
• И другие каналы

1. Цель: Что вы хотите достичь и узнать?
2. Pitch: Как презентовать услугу потенциальному клиенту? (Какие слова использовать?)
3. Точки взаимодействия: В какие моменты консьерж общается с пользователем?
4. Шаблоны и чек-листы: Как структурировать свою работу в каждый момент? (Какие вопросы задавать? Какой фреймворк использовать?)
5. Важные вопросы: Если вы узнали что-то новое – как об этом узнать больше?

1. Рекрутинг и координация: Как привлечь пользователей? Как их координировать?
2. Поддержка консьержа: Что команда делает, чтобы консьерж мог выполнять свою работу? (Готовит материалы, анализирует данные, дает обратную связь)
3. Сбор обратной связи: Как собирать фидбэк от пользователей? (Отдельные интервью, анкеты)
4. Оценка успешности: Работает ли это? Достигнули ли критериев успеха?
5. Использование успеха: Если успешно – что дальше? (Приглашаем на юзабилити-тест? На рассылку? В тг-канал?)

1. Консьерж должен записывать свои взаимодействия с участниками (что было? как прошло? что сказал пользователь?)
2. Независимо собирайте обратную связь (пусть не только консьерж говорит о том, как прошло, но и пользователь заполняет анкету)
3. Учитывайте стеснение – пользователь может стесняться давать негативный фидбэк консьержу, особенно если услуга бесплатная
4. Минимизируйте коммуникацию – общайтесь только по делу (приглашение, инструкции, сбор фидбэка, дебриф). Иначе рискуете повлиять на процесс.
5. Вносите изменения быстро – если что-то явно не работает, не продолжайте исследование. Обсудите с консьержем промежуточные итоги и корректировки.

1. Исследователь презентует сценарий – как люди будут использовать вашу идею в реальной жизни
2. Просит респондента сопоставить – «Узнаёшь ли ты себя в этом сценарии?»
3. Респондент комментирует каждую часть сценария – «Это реально? Я так делаю?»
4. Оценивает, как вписывается в жизнь – «Это удобно? Где это не будет работать?»
5. Даёт критику и впечатления – «Мне нравится, но я бы сделал вот так...»

1. Ситуация, жизненный контекст – Где происходит? Когда? В какой ситуации?
2. Поведение пользователя – Что пользователь делает? На том же уровне детализации, что и в ваших исследованиях.
3. Взаимодействие с вашим решением – Как он пользуется вашим решением? (Избегайте технических деталей! Фокусируйтесь на том, что делает человек и что делает система)
4. Реакция пользователя – Что он чувствует? Как он реагирует?
5. Результаты – К чему привело использование? Решилась ли его проблема?

• НЕ описывайте все кнопки и вкладки (это не сценарий интерфейса)
• Описывайте поведение и эмоции
• НЕ пишите про возможные функции
• Пишите про один ключевой сценарий

1. Объясните процесс – «Я буду читать сценарий, ты слушаешь. Потом мы обсудим, узнаешь ли ты себя в этом сценарии»
2. Дайте респонденту прочитать или покажите – Пусть сам прочитает, не только слушает (это важнее)
3. Оставьте место для первых реакций – «Что ты думаешь? Узнаёшь себя?»
4. Обсуждайте пошагово – Идите от начала к концу, чтобы сохранять структуру
5. Связывайте с его опытом – «А у тебя как? Ты делаешь так же или по-другому?»
6. Не спешите объяснять – Если респондент не понимает - сначала узнайте в чём трудность, потом помогайте

• Нравится ли идея? (эмоциональная реакция)
• Правильно ли понимается идея? (когнитивная реакция)
• Вспоминается свой опыт VS чужой (релевантность)
• Легко вписать в жизнь VS нужна гипотетическая ситуация (реалистичность)
• Замечания требуют корректировок VS полного переделки (серьёзность проблем)

• У вас есть несколько разных подходов к одной проблеме
• Вы не знаете, какой подход предпочтут пользователи
• Нужно быстро отсеять неудачные идеи

1. Контекстный сценарий – полное описание (см. метод выше)
2. Видео – показываете, как работает идея
3. Макеты с комментариями – рисунок + пояснения
4. Текстовое описание – просто описываете в свободной форме
5. Что угодно – главное, чтобы все концепции были в одном формате

1. Каждая концепция должна начинаться с проблемы – «Мы решаем проблему X с помощью подхода Y»
2. Все концепции видны одновременно – пусть участники видят все варианты (чтобы не повторяли)
3. Участники говорят последовательно – один высказывается, потом другой (не все вместе)
4. Есть набор вопросов для каждого – «Какая концепция тебе нравится? Почему?» (все отвечают на одни и те же вопросы)
5. Модерируйте обсуждение – следите, чтобы обсуждение не превратилось в случайный разговор

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

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

• «Что происходит на этом экране?»
• «Что здесь нужно сделать?»
• «Что будет, если сделать это?»

• «Что сейчас произошло? Это то, что ты ожидал?»

1. Контент должен соответствовать сценарию – нельзя использовать заглушки типа «Lorem ipsum»
2. Объясняйте условности – «Это черновик, не обращай внимание на красоту. Представь, что это работает»
3. Давайте пользователю частичный контроль – пусть сам листает экраны, но вы контролируете темп
4. Не подсказывайте – если пользователь не понимает, не говорите «здесь нужно нажать на кнопку», спросите «что ты хотел бы сделать?»
5. Если тупик, не спешите объяснять – сначала поймите в чём трудность, потом помогайте

1. За любым решением стоит определение проблемы – если вы не знаете, какую проблему решаете, решение будет неправильным
2. Исследование нужно для понимания контекста – не просто «люди хотят это», а «в этом контексте, для этих людей, решающих эту задачу»
3. Деятельность > продукт – изучайте, как люди решают проблему сейчас, а потом предлагайте новый способ
4. Метод «5 почему» помогает отойти от деталей – если вы видите «люди забывают полить», копайте глубже до «люди не знают, как правильно ухаживать в их условиях»
5. Secondary research – это фундамент – но помните про первоисточники и отличайте мнение от данных
6. Если идея логична, она где-то уже существует – изучите конкурентов не по фичам, а по подходам
7. Lean UX = быстрое тестирование гипотез – Wizard of Oz и консьержные эксперименты позволяют проверить идею без разработки
8. Валидация = понимание потребности – если люди готовы регулярно пользоваться сервисом (даже если это волшебник) → идея валидна