Продуктовый дизайн и пользователи
Метрики из модуля 5 показывают, что происходит. Этот модуль — про то, почему. Кто на самом деле ваш пользователь и какую задачу он решает, когда берёт в руки ваш продукт.
Урок 1: Jobs To Be Done — что человек реально «нанимает» ваш продукт делать
Классический пример Клейтона Кристенсена: сеть фастфуда изучала, кто покупает милкшейки, изменяя рецептуру — продажи не выросли. Оказалось: люди покупали милкшейк утром по дороге на работу — он «нанимался» на работу «занять руки и растянуть скучную поездку на 40 минут», а не только «утолить голод». Совсем другие конкуренты оказались в кадре, когда компания смотрела только на другие милкшейки.
Формат JTBD: «Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]». Не «кто мой пользователь», а «какую работу они на меня нанимают».
Ещё один реальный пример: Airbnb. Ранняя команда обнаружила, что путешественники «нанимают» Airbnb не просто на работу «где переночевать» — для этого вполне хватает отеля. Настоящая задача формулировалась иначе: почувствовать себя местным и быть частью района, а не туристом в стеклянной коробке отеля. Именно этот сдвиг — от «ночлег» к «принадлежность месту» — определил, какие функции продукта оказались важны (истории и профили хозяев, районы вместо районов-достопримечательностей), а какие конкуренты стали настоящими: не только другие площадки бронирования, а вообще любой способ «влиться» в город, включая каучсёрфинг и советы друзей.
Главная ошибка: определять JTBD через категорию продукта («нанимают трекер калорий») вместо реальной задачи («нанимает, чтобы не чувствовать вину после еды»). Первое ограничивает конкурентов другими трекерами. Второе показывает, что настоящий конкурент — любой способ закрыть ту же эмоцию, включая неочевидные.
Самопроверка: почему JTBD нельзя придумать за столом, надо брать из интервью?
Потому что настоящая мотивация часто не та, которую человек назовёт сам в лоб — она вскрывается в том, как он описывает своё поведение и контекст в интервью, а не в ваших догадках за рабочим столом.
Задание: сформулируйте JTBD вашего продукта по формату выше, опираясь только на цитаты из интервью из модуля 3. Если в формулировке есть название вашей категории продукта — перепишите.
Урок 2: User Persona — не выдумка, а синтез реальных данных
Самая бесполезная вещь в продукте — персона со стоковым фото, выдуманным именем и хобби, которая висит в презентации и ни на что не влияет.
Хорошая персона собрана из реальных интервью модуля 3, а не выдумана, и содержит только то, что меняет решения:
| Включать | Не включать, если не влияет на решения |
|---|---|
| Контекст использования (где, когда, с каким устройством) | Возраст, хобби, семейное положение «for flavor» |
| Реальные pains/gains из VPC (модуль 1) | Выдуманные «ценности» без источника |
| Дословные цитаты из интервью | Сток-фото и выдуманное имя |
Проверка качества персоны проста: можете ли вы указать, какая строка взята из какого именно интервью. Не можете — это выдумка.
Самопроверка: почему возраст и хобби иногда всё-таки стоит включать в персону?
Если они реально меняют решение — например, возраст влияет на размер шрифта в интерфейсе. Правило одно: любой атрибут должен вести к конкретному решению, иначе это декорация.
Задание: соберите персону строго по таблице выше, один абзац. Каждый пункт — со ссылкой на реальное интервью.
Урок 3: Продуктовый дизайн и основы UX
Три принципа из эвристик Нильсена, которые ломают больше всего:
- Видимость статуса системы — пользователь всегда знает, что происходит (загрузка, успех, ошибка)
- Предотвращение ошибок — легче не дать совершить ошибку, чем показать красивое сообщение после
- Согласованность — одинаковые действия выглядят одинаково везде — не учите пользователя заново
Бонус: два шага к приличному UI с ИИ-агентом
Самая частая ошибка при сборке интерфейса через ИИ — сразу просить «сделай красивый интерфейс». Агент тут же начинает писать код, до того как вы вообще решили, какая палитра, шрифты и настроение подходят именно вашему продукту. Результат часто обезличен и похож на любой другой ИИ-сгенерированный сайт.
Принцип, описанный в статье nakodil.site про workflow через Claude Code, верен: разделить задачу на два шага — сначала бриф по дизайну (палитра, шрифты, лейаут, anti-patterns), потом только сборка компонентов по этому брифу. В оригинале это делается через установку стороннего npm-пакета и подключение внешнего MCP с API-ключом — мы намеренно не тянем вас туда вслепую (незнакомый пакет, чужой API — лишний риск без необходимости). Вот тот же принцип без установок — два промпта подряд:
Промпт 1: «Прежде чем писать код, сделай короткий дизайн-бриф для [описание экрана]: палитра 4-6 цветов с hex-кодами, пара шрифтов для заголовков/текста, концепция лейаута в двух предложениях»
Промпт 2: «Теперь собери [конкретный экран/компонент] по этому брифу, строго следуя палитре и шрифтам выше»
Разделение решает ту же проблему, что и бриф в связке 2 модуля 1: конкретная задача даёт конкретный результат, расплывчатая «сделай красиво» — никогда.
Самопроверка: почему разделение на два промпта работает лучше, чем один большой?
Потому что в одном запросе ИИ должен одновременно придумать дизайн-решения и писать код — он чаще скатывается к шаблону. Разделённый бриф можно прочитать и поправить до того, как написана хоть строка кода.
Задание: попросите вашего ИИ-агента сделать дизайн-бриф для главного экрана вашего MVP по промпту 1 выше. Только потом попросите собрать компонент.
Урок 4: Прототипирование
Прототип — способ проверить решение до того, как оно стало дорогим.
Низкая точность (low-fi) — бумага, квадратики вместо кнопок. Подходит, когда проверяете логику экранов, а не визуал.
Высокая точность (hi-fi) — выглядит как готовый продукт. С ИИ-агентом граница размывается: часто быстрее собрать рабочий экран по связке 3, чем имитировать его в Figma.
Правило выбора: если сомневаетесь в логике (порядок шагов, структура) — low-fi за минуты. Если логика ясна, а нужно проверить реакцию на внешний вид (связка 4 модуля 1: продукт, которым не стыдно пользоваться) — hi-fi.
Самопроверка: почему тестировать логику на low-fi дешевле, чем на готовом интерфейсе?
Потому что на готовом интерфейсе люди комментируют цвета и шрифты, отвлекаясь от того, работает ли вообще логика переходов. На бумаге комментировать цвет нечего.
Задание: выберите уровень точности для вашего MVP и обоснуйте выбор одним предложением: что именно вы сейчас проверяете — логику или внешний вид?
Урок 5: CJM — путь клиента через ваш продукт, а не только сам продукт
JTBD и персона из уроков 1-2 объясняют, кто клиент и зачем он приходит. CJM (Customer Journey Map) показывает весь путь целиком — включая то, что происходит до и после того, как человек открыл ваш продукт.
CJM строится из трёх слоёв на каждом этапе пути:
| Слой | Вопрос |
|---|---|
| Что делает пользователь | Его реальные действия на этом этапе |
| Что делает сервис | Как продукт отвечает на эти действия |
| Болевые точки | Что вызывает сомнение, тревогу или трение именно здесь |
CJM для сайта записи Насти, этап за этапом.
1. Узнаёт про мастерскую. Пользователь: видит карточку в Яндекс.Картах или узнаёт от знакомой. Сервис: карточка с фото работ и понятным описанием услуги. Боль: непонятно, работает ли мастер именно с её типом окна.
2. Записывается на замер. Пользователь: открывает форму, выбирает удобную дату. Сервис: показывает свободные слоты, подтверждает запись. Боль: не видно, сколько будет стоить приблизительно — форма не даёт ориентир по цене до звонка.
3. Ждёт визита мастера. Пользователь: ничего не делает, просто ждёт. Сервис: ничего не делает тоже. Боль: нет ни одного напоминания или подтверждения — тревога «а вдруг забыли про меня».
4. Получает готовые шторы. Пользователь: примеряет, оценивает результат. Сервис: просит оставить отзыв. Боль: не знает, что делать, если что-то не понравилось — нет очевидного пути обратной связи до отзыва.
Разбор сразу показывает: главная проблема CJM Насти — не в форме записи, а в третьем этапе, где сервис вообще ничего не делает. Простое автоматическое напоминание за день до визита закрывает самую тревожную боль пути, хотя формально это не связано с самой формой записи.
Работа с CJM никогда не заканчивается. Как только вы добавляете новый шаг в продукт (например, форму «сколько денег и когда готовы вернуть» из кредитного примера, знакомого другим курсам по CJM) — сразу проверяете, какие новые болевые точки он приносит с собой, и достраиваете карту, а не считаете её законченным документом.
Самопроверка: почему CJM для этапа «Ждёт визита мастера» показывает пустые графы «что делает сервис», хотя формально там «ничего не происходит»?
Именно пустая графа — самый ценный сигнал CJM: она показывает момент, где сервис оставляет пользователя один на один с тревогой, хотя мог бы этого не делать. Пустое действие сервиса на этапе ожидания почти всегда означает недостающее уведомление, статус или подтверждение — то, что легко добавить, но легко и не заметить, если смотреть только на сам продукт, а не на весь путь.
Задание: постройте CJM своего продукта минимум из 3 этапов по трём слоям (пользователь / сервис / боль). Найдите этап, где графа «что делает сервис» пустая или почти пустая — это ваша первая кандидатская гипотеза для бэклога из модуля 2.
Урок 6: От дизайна к разработчику — user story и архитектура
Прежде чем передавать наработки разработчику, стоит различать два родственных, но разных инструмента для формулировки задачи.
JTBD (урок 1) — ситуативная сегментация: «Когда [ситуация], я хочу [мотивация], чтобы [результат]» — фокус на контексте, а не на человеке.
User Story — персонифицированная сегментация: «Как [тип пользователя], я хочу [действие], чтобы [результат]» — фокус на роли конкретного типа пользователя. Для той же формы записи: «Как клиентка, которая уже выбрала ткань, я хочу видеть примерную цену до звонка мастеру, чтобы понять, укладываюсь ли в бюджет».
Оба формата рабочие — JTBD лучше вскрывает настоящую мотивацию (модуль 3), User Story привычнее командам разработки и проще ложится в бэклог как отдельная задача.
Три стороны цифрового продукта: заказчик (вкладывает деньги и время, ждёт прибыли или другого эффекта), пользователь (получает пользу, если она реально решает его задачу) и техническая реализация (что вообще возможно сделать в имеющихся условиях). Хороший продукт балансирует все три — если тянуть только в сторону заказчика (много рекламы, мало пользы) или только пользователя (бесплатно и без монетизации), баланс рушится.
Функциональная архитектура — в отличие от CJM, которая описывает субъективный опыт, функциональная архитектура — это формальный алгоритм: что именно делает система шаг за шагом, чтобы выполнить конкретную функцию, включая ветвления (что если пользователь ошибся, что если сервер не ответил). Когда в процессе участвует несколько сторон одновременно (клиент, сервис, мастер, курьер) — такие сценарии удобно рисовать как плавательные дорожки (swimlane): отдельная дорожка на каждого участника, чтобы сразу видеть, кто и что делает параллельно.
Информационная архитектура — «скелет» продукта отдельно от того, как он выглядит и работает: навигационная структура (иерархия разделов и страниц) и структура данных. Простой инструмент для структуры данных — ER-диаграмма: сущности (прямоугольники, например «Клиентка», «Заказ», «Мастер») связаны действиями (ромбы, например «оформляет», «выполняет»).
Информационная архитектура сайта Насти. Навигация: Главная → Портфолио → Форма записи → Личный кабинет клиентки. Сущности для ER-диаграммы: Клиентка (имя, телефон, адрес) — оформляет → Заказ (дата замера, статус, сумма) — выполняет → Мастер (Настя, расписание).
Когда писать ТЗ: концепция (стратегическое видение — CJM, персоны, задача продукта) готовится первой. Техническое задание (детальное решение — функциональная и информационная архитектура, интерфейсы) — второй, и не в самом начале работы над продуктом: до того как видение утрамбовано, детальное ТЗ придётся переписывать заново при первом же изменении курса.
Самопроверка: чем функциональная архитектура принципиально отличается от CJM, если обе описывают «что происходит на каждом шаге»?
CJM описывает субъективный опыт человека — что он чувствует и делает, включая эмоции и сомнения, и специально допускает неопределённость («болевая точка», а не точный сценарий). Функциональная архитектура — формальный, однозначный алгоритм системы: для каждого шага и каждого возможного ответа пользователя должно быть чётко прописано, что именно делает система дальше, без места для интерпретации.
Задание: перепишите гипотезу из модуля 2 в формате User Story («Как [тип пользователя], я хочу..., чтобы...»). Сравните с JTBD-формулировкой этой же гипотезы из урока 1 — какой из двух форматов яснее объясняет разработчику, что строить?
У вас есть JTBD, персона из реальных данных, карта пути клиента и понимание, как передать это разработчику — через user story, функциональную и информационную архитектуру. Следующий модуль — разработка: техническая грамотность, ТЗ и быстрый MVP с ИИ.