Александр
Пользовательский сценарий описывает, кто пытается решить задачу, чего хочет добиться и в каких условиях действует. Он связывает исследование с решениями в интерфейсе: какие сведения показать, где дать выбор и что делать, если привычный путь прервался.
Возьмём пример внештатного дизайнера, который готовит логотип для клиента. На его основе пройдём семь шагов: от изучения реальной работы до проверки прототипа в Pixso. Отдельно обозначим предположения, чтобы правдоподобный рассказ не подменял результаты исследования.
Что такое пользовательские сценарии в дизайне
Определение сценария
Пользовательские сценарии в контексте дизайна — это описания того, как человек решает задачу с помощью продукта или услуги. В них важны цель, действия и условия, которые влияют на выбор. Например, внештатный графический дизайнер должен подготовить логотип для клиента в сжатые сроки. Сценарий уточняет, какие исходные материалы у него есть, кто согласует результат и что может задержать работу.
В разных отраслях задачи отличаются. Пациенту в удалённом месте может понадобиться консультация врача через приложение телемедицины. Студенту перед экзаменом — доступ к учебным материалам, практическим заданиям и обратной связи. Каждый такой пример становится полезнее, когда вместо общей цели появляется конкретная ситуация и наблюдаемый результат.
Ключевые элементы
Роли пользователей
Существуют различные типы ролей пользователей. Например, начинающие пользователи - это новички в работе с продуктом, и им может потребоваться больше рекомендаций и простой в понимании интерфейс. Опытные пользователи, напротив, более опытны и могут искать расширенные возможности и быстрые клавиши. В случае с инструментом для дизайна начинающий дизайнер может быть напуган сложными функциями проектирования, в то время как опытный пользователь может стремиться изучить расширенные возможности редактирования векторов.
Для сценария согласования важны две роли: дизайнер редактирует работу, клиент просматривает результат и формулирует замечания. Их задачи и права различаются, даже если оба хорошо знакомы с цифровыми инструментами.
Цели
Цели могут быть краткосрочными, например, быстро найти определенный инструмент в программе, или долгосрочными, например, создать законченный проект. Для мобильного банковского приложения краткосрочной целью может быть проверка баланса счета, а долгосрочной - подача заявки на кредит.
В примере с логотипом цель — получить понятную обратную связь по конкретному варианту до согласованного срока. «Нажать кнопку отправки» — действие, но ещё не результат: клиент должен получить доступ и понять, какой вариант обсуждается.
Контекст
Контекст включает в себя физическую среду (например, использование мобильного приложения в переполненном метро) и временной контекст (например, использование инструмента продуктивности в рабочее время). Например, пользователю, использующему приложение для фитнес-трекинга во время пробежки в парке, необходимо быстрое отображение данных в связи с физической активностью и обстановкой на улице.
Для нашего примера допустим, что клиент открывает материал с телефона между встречами, а дизайнер работает за ноутбуком. Это пока условие учебного кейса. Для реального проекта его нужно подтвердить интервью, наблюдением или другими данными.
Сценарий, пользовательская история и поток действий
| Формат | Что фиксирует | Пример для согласования |
|---|---|---|
| Пользовательская история | Кратко выражает потребность роли и ожидаемую пользу. | Как дизайнер, хочу получить замечания к нужному варианту, чтобы внести согласованные изменения. |
| Сценарий | Описывает цель в конкретных условиях, действия, препятствие и результат. | Клиент с телефона открывает второй вариант логотипа, уточняет замечание и отправляет ответ до встречи. |
| Поток действий | Показывает переходы, решения и ветвления в интерфейсе. | Открыть ссылку → получить доступ → выбрать вариант → оставить замечание → увидеть подтверждение. |
Эти форматы дополняют друг друга. Сценарий может появиться до подробных экранов; поток помогает проверить, поддерживает ли выбранный интерфейс нужный результат.
Почему пользовательские сценарии важны для дизайна
Сценарий делает обсуждение конкретным: команда рассматривает задачу человека вместе с ограничениями. Он помогает обнаружить пробелы в проекте, но сам по себе не доказывает, что описанное поведение действительно происходит.
Понимание потребностей пользователей
Например, при разработке фитнес-приложения ситуация «у человека короткий обеденный перерыв и мало места» подсказывает вопрос: нужна ли ему короткая тренировка без оборудования? Это гипотеза для проверки, а не основание заранее выбрать интенсивность нагрузки. В кейсе дизайнера аналогичный вопрос — достаточно ли клиенту просмотра с телефона, чтобы дать точное замечание.
Поддержка решений при проектировании
Если исследование показывает, что пользователи редактора документов не находят форматирование, команда может проверить другое расположение команд. В дизайн-инструменте похожий сценарий помогает оценить поиск, названия и группировку слоёв. В Pixso можно собрать варианты макета и обсудить их на конкретной задаче; из этого не следует, что любая функция продукта была разработана именно по такому исследованию.
Облегчение коммуникации
Пользовательские сценарии служат общим языком для дизайнеров, разработчиков и заинтересованных сторон. При представлении идеи нового продукта хорошо продуманный сценарий типа «Владелец малого бизнеса использует платформу электронной коммерции для управления запасами и обработки заказов» может облегчить понимание функциональности продукта для нетехнических заинтересованных сторон. Это также поможет получить обратную связь от всех сторон, вовлеченных в процесс разработки.
В обсуждении согласования логотипа сценарий разделяет две проблемы: «клиент не может открыть файл» и «клиент открыл не тот вариант». Для них нужны разные решения, поэтому общий запрос «упростить совместную работу» слишком широк.
Семь шагов создания пользовательского сценария
Каждый шаг должен оставлять понятный результат: данные, формулировку цели, описание условий, сценарий, схему, вывод проверки или обновлённую версию. Начните с задачи, которую команда готова исследовать и улучшать.
1. Проведите исследование пользователей
Используйте сочетание опросов, интервью и наблюдений для сбора данных от широкого круга пользователей. Опросы могут дать широкое представление о предпочтениях пользователей, интервью позволяют глубже изучить их опыт, а наблюдения позволяют выявить реальные модели использования. Например, при изучении инструментов проектирования опросы позволяют узнать о желаемых функциях, интервью - о болевых точках, а наблюдения - о том, как пользователи взаимодействуют с существующими инструментами в своей рабочей среде.
Для согласования спросите о последнем завершённом проекте: как передавали варианты, где обсуждали изменения и как понимали, что ответ относится к нужной версии. Записывайте источник каждого наблюдения. Рекомендации GOV.UK по изучению потребностей предлагают отделять данные о реальных пользователях от предположений команды.
2. Определите чёткие цели
Разграничьте основную и второстепенные цели. В фоторедакторе человек может сначала улучшить снимок, затем поделиться им. В сервисе путешествий семье может быть нужен пакет с перелётом, проживанием и экскурсиями в пределах бюджета, а самостоятельному путешественнику — быстро забронировать недорогое жильё. Не объединяйте разные задачи в один маршрут только потому, что они относятся к одной отрасли.
В нашем кейсе сузим задачу: дизайнеру нужно получить замечания к варианту «Логотип B». Критерий результата — клиент отправил ответ, связанный с этим вариантом, а дизайнер может его найти. Создание самого логотипа и итоговое утверждение бренда остаются отдельными сценариями.
3. Добавьте реальный контекст
Учитывайте физические, социальные и технические условия. В навигационном приложении контекст движения требует лаконичных указаний; в социальной сети важно, кому виден материал; в видеосервисе — что происходит при слабой связи. Условия должны менять проектное решение, а не служить декоративным описанием.
Для клиента, который открывает логотип с телефона, проверьте размер изображения, читаемость названия версии и доступность поля замечания. Если доступ по ссылке ограничен, добавьте ветку «Нет доступа»: человек должен понять, как запросить разрешение и где продолжить после его получения.
4. Опишите роли на основе данных
Персоны полезны, когда отражают подтверждённые различия в задачах, опыте и ограничениях. Например, в финансовом сервисе могут различаться задачи начинающего инвестора, человека, планирующего пенсию, и владельца сложного портфеля. В магазине — поиск модной вещи и покупка необходимых товаров в пределах бюджета. Возраст сам по себе не доказывает поведение или потребность.
Для текущего сценария достаточно двух рабочих описаний: «дизайнер, который готовит варианты и обрабатывает замечания» и «клиент, который просматривает и комментирует». Добавьте ограничения прав и доступные устройства, если они подтверждены. Непроверенные характеристики пометьте как вопросы исследования.
5. Визуализируйте сценарий и соберите прототип
Используйте раскадровку для ситуации человека и блок-схему для переходов и развилок. Например, путь оформления заказа включает корзину, подтверждение данных и результат оплаты; сценарий объясняет, зачем человек проходит этот путь и что может ему помешать.
В Pixso подготовьте кадры проектируемого сервиса: список вариантов, просмотр «Логотип B», отправку замечания, подтверждение и отсутствие доступа. Свяжите их переходами. В подписи к каждому кадру укажите цель, доступное действие и ожидаемый результат. Проверять нужно согласование конкретного варианта, поэтому не добавляйте в прототип весь редактор графики.
Комментарии команды оставляйте у соответствующего кадра или перехода. Экраны проектируемого сервиса и переходы прототипа показывают задуманный процесс; они не создают в Pixso новую встроенную систему согласования.
6. Проверьте и доработайте сценарий
Попросите вероятного пользователя выполнить задачу, наблюдая за его действиями. Цель проверки — выяснить, какие предположения подтверждаются, а какие нет. В сценарии бронирования, например, затруднение с фильтрами может потребовать изменения интерфейса, терминов или самого описания задачи.
Нейтральное задание для нашего кейса: «Вам прислали второй вариант логотипа. Сообщите дизайнеру, что подпись под знаком нужно сделать крупнее, и убедитесь, что замечание отправлено к нужному варианту». Не добавляйте «нажмите B, затем кнопку комментария»: так вы подскажете путь, который собирались проверить. Этот принцип соответствует рекомендациям GOV.UK по заданиям для юзабилити-тестирования.
Зафиксируйте, нашёл ли человек нужный вариант, понял ли ограничение доступа, заметил ли подтверждение и смог ли найти отправленное замечание. Отдельно записывайте наблюдение и интерпретацию: «открыл первый вариант» — факт сессии; «названия слишком похожи» — возможное объяснение, которое ещё нужно проверить. После исправлений повторите релевантную задачу.
7. Обновляйте сценарий по новым данным
Возвращайтесь к сценарию, когда меняются роли, доступ, устройства или реальные способы работы. Поводом может стать повторяющееся обращение в поддержку, новая схема согласования или наблюдаемая проблема в тестировании. Само появление новой технологии или рыночной темы ещё не означает, что нужно менять сценарий.
Храните дату пересмотра, источник изменения и затронутый шаг. Например, если клиентам теперь нужен совместный ответ нескольких согласующих, обновите критерий завершения и ветки обсуждения. Старую гипотезу сохраните в истории, чтобы команда понимала причину изменения.
Готовый пример сценария согласования
Соберём описанные решения в одну карточку. Условия ниже задают учебный кейс; в рабочем проекте у каждого существенного предположения должен появиться источник.
| Поле | Содержание |
|---|---|
| Роль и цель | Клиент хочет передать дизайнеру замечание к варианту «Логотип B». |
| Триггер | Получена ссылка на два подготовленных варианта перед встречей. |
| Контекст | Клиент открывает ссылку с телефона; дизайнер обрабатывает ответ позже с ноутбука. |
| Основной путь | Открыть ссылку → распознать «Логотип B» → написать замечание → отправить → увидеть его у нужного варианта. |
| Препятствие | Нет доступа. Клиент запрашивает разрешение; после получения возвращается к тому же материалу. |
| Критерий завершения | Замечание видно клиенту и доступно дизайнеру вместе с названием варианта. |
| Что проверить | Понятно ли различие вариантов на телефоне, обнаружим ли путь восстановления доступа и заметен ли результат отправки. |
Передайте команде карточку, связанные экраны, открытые вопросы и результаты наблюдений. Такой набор помогает обсуждать конкретную задачу и проверять изменения в интерфейсе на следующей итерации.
