Сценарий — это описание того, как человек добивается своей цели на сайте: с чего начинает, что делает дальше, что может пойти не так и чем всё заканчивается. Без сценариев проектирование превращается в набор аккуратных экранов, между которыми нет связи, а обсуждение макета сводится к спору о вкусах. Ниже — как мы описываем сценарии и что с ними делаем дальше.
Чем сценарий отличается от общих слов
Формулировка «пользователь заходит на сайт и оставляет заявку» не даёт проектировщику ничего. Она верна для любого сайта и не порождает ни одного требования к странице.
Рабочее описание выглядит иначе: «Мастер по ремонту получил ссылку из рекламы, открыл её с телефона прямо на объекте, ищет цену и срок выполнения, готов написать в мессенджер, звонить не хочет, времени у него пять минут». Из одного абзаца сразу следует несколько требований: цена должна быть видна без прокрутки в несколько экранов, срок указан рядом с ценой, кнопка мессенджера присутствует, форма короткая, страница обязана открываться на мобильном интернете среднего качества.
Разница в конкретике. Сценарий полезен ровно настолько, насколько из него можно вывести решения по интерфейсу.
Что должно быть в описании
| Элемент | Пример | На что влияет |
|---|---|---|
| Кто | Владелец небольшого магазина, не разбирается в технике | Язык текстов, объём пояснений |
| Откуда пришёл | Поиск, реклама, рекомендация коллеги | Что человек уже знает, а что нужно объяснить на странице |
| Цель | Понять стоимость и сроки, сравнить с другим подрядчиком | Состав первого экрана и блока с ценами |
| Условия | Телефон, слабый интернет, пять минут времени | Вес страницы, размер элементов, длина текстов |
| Шаги | Что человек делает по порядку до результата | Схема переходов и навигация |
| Что может пойти не так | Не нашёл цену, форма требует лишнего, нет ответа | Состояния ошибок и подсказки |
| Чем заканчивается | Оставил заявку и получил подтверждение с номером | Экран после отправки, письмо, следующий шаг |
Неудачные ветки обязательны
Большинство макетов описывают идеальный путь: человек нашёл нужное, заполнил форму, получил результат. В жизни ломается именно всё остальное, и на эти ситуации у интерфейса обычно нет ответа.
- Поиск ничего не нашёл. Что показываем вместо пустого экрана: похожие позиции, подсказку по формулировке, форму запроса.
- Товара нет в наличии. Предлагаем аналог, уведомление о поступлении или срок поставки.
- Форма не отправилась. Понятно ли, какое поле заполнено неверно, и сохранились ли остальные данные.
- Оплата не прошла. Куда попадает человек и как повторить попытку, не собирая заказ заново.
- Человек вернулся через два дня. Осталось ли содержимое корзины, помнит ли сайт выбранный город.
Каждый такой случай должен иметь свой экран и подсказку, что делать дальше. Это дешевле придумать на этапе проектирования, чем добавлять в спешке после запуска.
Откуда брать материал
Сценарии не сочиняют за столом. Есть четыре источника, которые дают фактуру почти бесплатно.
- Переписка и записи звонков. Самый честный материал: видно, какими словами люди формулируют задачу и что спрашивают в первую очередь.
- Вопросы к менеджерам. Если один и тот же вопрос задают каждый день, ответа на него на сайте нет.
- Аналитика. Страницы, с которых чаще всего уходят, запросы во внутреннем поиске, доля мобильных посетителей, шаги оформления, где обрывается путь.
- Короткие интервью. Трёх-пяти разговоров с клиентами хватает, чтобы увидеть повторяющиеся места. Спрашивать нужно о прошлом опыте, а не о предпочтениях: «расскажите, как выбирали в прошлый раз», а не «что бы вам хотелось видеть на сайте».
Сколько сценариев нужно
Для сайта услуг обычно достаточно трёх-пяти основных сценариев: первичный подбор, сравнение с конкурентом, повторное обращение, обращение по проблеме. Для интернет-магазина добавляются оформление заказа, возврат и отслеживание. Больше десяти описаний никто не читает, и они перестают работать как инструмент.
Сценарии стоит ранжировать: какой из них приносит основную часть выручки, какой встречается реже, но стоит дорого при ошибке. Приоритет определяет, какому пути достаётся лучшее место на экране.
Как оформлять описание
Форма записи вторична, важна дисциплина. Мы обычно держим сценарии в одном документе: короткое имя, абзац о человеке и условиях, нумерованные шаги, отдельный список исключений, строка с признаком успешного завершения. Одна страница на сценарий — верхняя граница, дальше начинается описание ради описания.
Полезно рядом с каждым шагом отмечать, какими данными располагает система в этот момент: знаем ли мы город посетителя, авторизован ли он, есть ли товар в корзине. Половина спорных вопросов на этапе разработки — именно об этом, и ответ дешевле зафиксировать заранее.
Если в проекте несколько ролей — покупатель, менеджер, кладовщик, — сценарии разносим по ролям. Смешивать их в одном описании не стоит: у ролей разные цели, разная частота работы с системой и разная терпимость к лишним шагам.
Как использовать сценарий дальше
Сценарий становится критерием приёмки. Берём готовый макет и проходим по шагам: на каждом шаге проверяем, есть ли на экране то, что человеку нужно именно сейчас, и не спрятано ли оно за прокруткой или лишним переходом. Если элемента нет, правим до вёрстки, пока правка стоит часы, а не дни.
Тот же документ работает как техническое задание для текстов: копирайтер видит, на какой вопрос отвечает блок. И как основа для проверки после запуска: сравниваем, совпадает ли реальное поведение посетителей с описанным путём.
Частые ошибки
- Сценарий описывает интерфейс, а не задачу человека: «нажимает на кнопку в шапке» вместо «ищет, как связаться».
- Один сценарий на все аудитории. Оптовый покупатель и частное лицо ведут себя по-разному, и объединять их в одно описание бессмысленно.
- Описан только успешный путь, ошибки оставлены на усмотрение разработчика.
- Сценарии написали и убрали в папку. Если по ним не проверяют макеты, они не влияют ни на что.
- Требования вписаны в сценарий постфактум, под уже нарисованный макет. Тогда это не инструмент проверки, а оправдание решений.
Нужна помощь
Мы описываем сценарии, собираем по ним прототипы и проверяем решения до того, как начинается вёрстка, — так правки стоят дешевле, а спорных мест в приёмке остаётся меньше. Если нужен разбор текущего сайта или проектирование нового раздела, обсудим проектирование интерфейсов и предложим порядок работ.
