Как проектировать редкие пользовательские сценарии в цифровом продукте
Первое число месяца. Бухгалтер открывает сервис, чтобы закрыть отчётность. Данные, сроки и порядок проверки он знает. На экране десять равноправных карточек. Прошлый черновик и следующий шаг среди них не выделены. Вместо работы приходится восстанавливать маршрут по меню.
Специалист не обязан хранить в голове карту продукта, которым пользуется раз в месяц. Редкий сценарий проверяет сам интерфейс: показывает ли он прошлый статус, нужный объект и следующее действие. Повторный онбординг здесь только добавит экран, который хочется закрыть.
За 30 дней интерфейс успевает стать чужим
При ежедневной работе человек запоминает маршрут. Редкий сценарий живёт по другим правилам. Между двумя визитами меняются задачи, документы и обстоятельства, а детали интерфейса уходят из памяти.
Nielsen Norman Group объясняет это через три фактора: частоту, давность и контекст. Чем реже и дальше по времени использовалась информация, тем труднее её воспроизвести. Узнать знакомый вариант в меню проще, чем вспомнить название команды с нуля.
Про триггеры возврата и сохранённую корзину мы уже писали в статье про Duolingo. Здесь другая половина маршрута: человек уже вернулся. Теперь сервис должен помочь ему продолжить задачу.
Дата регистрации ничего не говорит о знании конкретного сценария. Аккаунту может быть три года, а операцию человек выполнял дважды. Это нормальная частота использования, поэтому интерфейс должен быстро возвращать контекст.
Тур показали в январе, кнопка понадобилась в марте
Большой тур при первом входе плохо решает эту задачу. Пользователь видит подсказку в январе, а нужная кнопка понадобится в марте. К тому моменту от тура остаётся смутное ощущение, что где-то всё уже объясняли.
Подсказка сильнее работает рядом с действием: короткая расшифровка поля, пример формата, подпись у редкой иконки, история последней операции. Человеку не нужно заново изучать продукт. Ему нужен контекст в тот момент, когда возник вопрос.
Я бы проверял каждую подсказку простым вопросом: помогает ли она сделать следующий шаг прямо сейчас. Обзор возможностей, приветствие и рассказ о пользе сервиса этот тест обычно не проходят.
Первый экран должен вернуть три вещи
Возвращение начинается с восстановления позиции. На входе нужны три ответа:
Где я? Название операции должно совпадать с языком пользователя, письма или документа, который привёл его в сервис.
Что уже сделано? Нужны сохранённый прогресс, выбранные параметры, статус и дата последнего действия.
Что делать дальше? Одна заметная кнопка с понятным результатом полезнее набора равноправных действий.
В GOV.UK Design System для длинных процессов рекомендуют сохранять прогресс и возвращать человека к месту остановки. Этот приём нужен не каждому продукту, но принцип точный: сервис продолжает прерванный разговор.
Плохой вариант встречает пользователя дашбордом из десяти карточек. Хороший показывает, что декларация заполнена на четыре шага из пяти, черновик сохранён две недели назад, а сейчас нужно проверить итог и отправить.
Лишние функции лучше оставить на втором слое
У редкого пользователя есть конкретная цель и мало терпения к устройству системы. На первом слое ему нужны основные действия. Настройки, исключения и расширенные параметры можно раскрывать по запросу.
В исследовании 2024 года послойное раскрытие функций рассматривают как подход для нерегулярных пользователей и повторного освоения после перерыва. Выводы там предварительные: в эксперименте участвовали 42 начинающих военных специалиста, работавших со сложным интерфейсом планирования миссий. Переносить стоит сам принцип, без обещаний универсального эффекта.
У подхода есть обратная сторона. Пять уровней «Показать ещё» превращают простоту в раскопки. Критичное действие, статус и последствия решения остаются на поверхности. Второй слой подходит для того, что требуется части пользователей или возникает в особом случае.
Тест 30-го дня: пять вопросов вместо общего «понятно?»
Обычный тест сразу после знакомства показывает, насколько быстро человек учится. Редкий сценарий требует другой проверки. Дайте участнику выполнить задачу, выдержите паузу или пригласите человека, который давно не открывал этот раздел, и смотрите на первое возвращение.
Пять вопросов:
Понимает ли человек, где оказался, без объяснения модератора?
Видит ли он результат прошлого визита и актуальный статус?
Находит ли следующее действие по формулировке, а не методом перебора?
Понимает ли, что произойдёт после нажатия?
Может ли самостоятельно исправить ошибку или отменить действие?
Вместо общего вопроса «всё понятно?» полезнее измерять время до первого правильного действия, возвраты на предыдущие экраны, открытия справки, незавершённые попытки и обращения в поддержку. Эти сигналы показывают, где интерфейс переложил память о процессе на человека.
Редкая операция иногда должна идти медленнее
Ускорять любой редкий сценарий опасно. Ежемесячный повторный платёж можно подготовить заранее: подставить прошлые реквизиты, показать сумму и дать подтвердить. Годовое изменение прав доступа требует другого темпа: явного списка затронутых ролей, предпросмотра и отдельного подтверждения.
Частота определяет объём помощи, а цена ошибки — объём проверки. Чем реже действие и серьёзнее последствия, тем больше контекста интерфейс должен показать перед финальной кнопкой.
Вернёмся к бухгалтеру. Его задача не изменилась: проверить прошлый период и отправить отчёт. Хороший экран сразу покажет черновик, статус и следующий шаг. Через месяц тот же интерфейс вернёт контекст за несколько секунд.
Разбираете редкий сценарий в действующем продукте? Мы можем пройти его глазами вернувшегося пользователя, найти места, где интерфейс требует лишней памяти, и собрать план UX-доработок.
