Сценарии нужны, чтобы понимать как и зачем в идеале будут использовать продукт, и связать это с решениями в дизайне:​

• Описываем события и деятельность, в которой продукт будет полезен → прорабатываем сценарий использования → можем продумать функции и интерфейс продукта.​
• Изучаем контекст использования продукта → готовим сценарий использования → формулируем корректное задание для тестирования (что именно просим сделать, какие шаги важны).​
• Определяем сценарий задачи → прописываем жизненный цикл пользователя (до, во время, после использования) → понимаем, какие показатели можно измерить для оценки (успешность, время, удовлетворённость и т.п.).​

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

Персонаж (persona) в подходе А. Купера (Goal‑Directed Design):​

• Группирует пользователей на основании их потребностей и целей, а не случайных демографических признаков.
• Добавляет детали для психологической достоверности, часть из них может быть выдумана (но опирается на реальные паттерны).​

Обычно персонаж включает:​

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

Персонаж «Анна» (помощник главного бухгалтера, живёт в Балашихе, ездит в Москву) показывает, как из описания жизни можно вывести цели и паттерны:​
Конечные цели:

• встретиться с друзьями в центре после работы;
• аккуратно парковаться, не нарушая ПДД.​

Эмоциональные и жизненные цели:

• не тратить много денег;
• чувствовать себя в безопасности вечером, возвращаясь на машине.​

Поведенческие паттерны:

• паркуется подальше в зоне с меньшей стоимостью, заранее смотрит тарифы;
• пополняет парковочный счёт «впритык» со счёта мобильного;
• периодически проверяет штрафы через приложение.​

Такие паттерны формируют набор сценариев (поездка в центр, встречи, парковка в незнакомом районе, проверка штрафов), которые дальше можно описывать текстом или в journey map.

Слайды вводят три типа персонажей:​

Ключевой

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

Дополнительный

• другие интересные группы, которые уступают по важности ключевым.

Отрицательный

• пользователи, которых вы не хотите видеть (или для которых продукт не предназначен).​

Персонажи — это способ чётко сказать:​

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

Логика строится поверх аффинити‑диаграммы:

1. У вас есть интерпретации и категории (например, «занимается с преподавателем», «играет в группе», «занимается сама, пытается не забивать», «имеет свою систему занятий»).​
2. Вы видите повторяющиеся комбинации характеристик и выделяете типы пользователей.
3. Для каждого типа формируете персонажа: объединяете интерпретации в целостное описание человека и его сценариев.

Персонажи — это способ собрать и упорядочить данные о пользователях таким образом, чтобы было видно:

• у разных групп действительно разные потребности;
• у каждой группы есть свои цели;
• это даёт основу для выделения направлений развития продукта (под какие цели и потребности мы проектируем).

Персонажи дают:

• структуру для описания общих характеристик и сценариев;
• удобный формат для общения в команде (вместо «абстрактного пользователя»);​
• основу для набора сценариев (у каждого персонажа есть собственные ключевые сценарии).​

Примеры в майноре:​

• командная работа в бакалавриате: несколько персонажей‑одногруппников с различными целями и паттернами поведения в проектной работе;
• трудоустройство разработчиков: ключевой персонаж‑разработчик с целями, барьерами, сильными сторонами и сценариями поиска работы.​

Персонажи — полезный, но не идеальный инструмент:​
Плюсы:

• выделение групп по потребностям — полезное упрощение;
• дают удобную структуру для фиксации общих характеристик и сценариев.​

Минусы:

• не всегда вызывают эмпатию — команда может не доверять «обобщениям» и вымышленным деталям;
• теряется связь с источниками данных («откуда это взялось?»), если не показывать, на каких заметках основан персонаж;
• в реальности люди не делятся на жёсткие типы, границы размыты;
• есть риск стереотипизации и проектирования «по ощущениям», без проверки данными.​

Поэтому в слайдах далее вводится модель идентичности как более «данно‑центричный» способ описания пользователей.

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

В отличие от персонажей, это многомерная модель: один и тот же человек может принадлежать к нескольким «идентичностям» одновременно (I do, I am, I like и др.).

По Holtzblatt & Beyer, модель идентичности:​

• многомерна: один и тот же человек может относиться к нескольким классификациям одновременно (например, по отношению к планированию, к риску, к обучению);
• фокусируется на идентичности — том, как люди видят себя в данной сфере жизни («я такой человек, который…»), а не только на внешних характеристиках.​

Это позволяет избежать жёсткого деления на типы и ближе держаться к данным.

Шаги:​

Собираете все высказывания, в которых респонденты описывают:

• личные предпочтения,
• представления о себе,
• ценности («я такой, кто…», «я обычно…», «для меня важно…»).

На основе этих высказываний выделяете группы, например:

• I do (что я делаю регулярно, какие практики у меня есть);
• I am (кем я себя считаю в этой сфере);
• I like (что мне нравится, к чему тянет).​

Построение происходит по аффинити‑заметкам:

• сначала все заметки о респондентах в целом;
• затем разделение на группы по смыслу;
• далее — интерпретации для каждой группы.​

Результат — карта идентичностей (как на слайде с кругами «Deal Hunter», «Avid Traveler», «Culture Sponge» и т.п.), где каждая «сущность» описывает тип отношения к активности, а не готовый «портрет человека».

Что можно описывать:​

• Виды ситуаций и поведения — типичные контексты, в которых люди действуют.
• Структуру деятельности — этапы и шаги, которые человек проходит.
• Отдельное событие (детально) или общие виды деятельности, или отдельные сценарии.​

Мы можем:

• перечислять и классифицировать отдельные события;
• описывать варианты и этапы одной и той же деятельности;
• описывать разные виды деятельности внутри одной сферы.​

Подробные принципы иерархии задач — у К. Кунявского (с. 508–521) и у Э. Холл (с. 124, 130–132).

Текстовый сценарий —полнотекстовое описание деятельности пользователя, включая мысли, намерения, переживания и неудобства.​
Согласно Goal‑Directed Design:​

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

Элементы сценария:​

• цели, задачи, намерения пользователя;
• контекст и ситуация;
• поведение пользователя;
• поведение системы;
• реакции пользователя;
• результаты и последствия.

Пример (упрощённо по слайду):​
Джон перед сном вспоминает, что нужно выставить будильник. Он смотрит в календарь, видит раннюю встречу и решает встать к 8. Приложение рекомендует 7:27 из‑за рассвета, но Джон раздражён: его окна выходят на запад, рекомендация бессмысленна. Он закрывает шторы от света машин, утром просыпается невыспавшимся и в темноте, с неприятными ощущениями от резкого звука будильника.
Здесь видно:

• цель (проснуться вовремя),
• контекст (вечер, привычки, календарь),
• поведение системы (рекомендация «по солнцу»),
• неудобство и реакция пользователя.

User journey — метод, специально заточенный под описание последовательности этапов.​
Особенности:​

• применяется, когда событие имеет ясные этапы;
• чаще всего описывает взаимодействие клиента с сервисом, не обязательно цифровым;
• удобно выделять «подъёмы» и «провалы» опыта (эмоциональные пики и провалы на разных шагах);
• часто используется для оценки качества сервиса и поиска узких мест.​

Пример (упрощённый) journey работы с юристом:​

1. Пользователь получает запрос в компанию.
2. Запрос партнёром передаётся ответственному юристу.
3. Партнёр, юрист и стажёры идут на встречу с клиентом.
4. На встрече партнёр собирает бриф.
5. После встречи стажёры дополняют и оформляют бриф, согласуют его с юристом.
6. Юрист отправляет бриф клиенту для подтверждения постановки задачи.

• Хорошие описания метода — у NN/g (Journey Mapping 101) и в кейсах по медицине (пример mental‑health платформы).

«Day in the life» — способ описать день пользователя целиком:​

• общий контекст и устройство дня;
• перечисление ключевых контекстов и ситуаций в течение дня;
• краткое описание каждого сценария (не обязательно очень подробно).​

Метод подробно описан у Holtzblatt (с. 149–164) и хорошо сочетается с моделью идентичности: вы видите, как разные идентичности проявляются в разных частях дня.