Принципы сборки задачи и работы с инструментом описаны - теперь полезно увидеть, как они выглядят в применении к конкретным типам интерфейсных задач, а не в абстракции. ↓
Ниже - конкретные задачи с применением всей методологии: внятный сценарий, поведение, границы, критерии приемки и блок для ИИ.
Эти сценарии покрывают большинство UI-задач: прерывающий сценарий, first-time experience, поведение формы, состояние ошибки.
Тип 1: Прерывающий сценарий
Это пример на локскрины и явный следующий шаг.
# Экран предупреждения о достижении лимита контактов ## Проблема Пользователь упирается в лимит контактов в момент импорта и получает отказ без понятного следующего шага. ## Сценарий Пользователь загружает CSV, система считает, что после импорта лимит тарифа будет превышен. ## Что проектируем Попап предупреждения до запуска импорта. ## Гипотеза Пользователь теряется, потому что блокирующее сообщение не дает альтернативы. Если показать цифры и два явных пути до старта импорта - он примет решение без отрыва от процесса. ## Как должно работать - вместо старта импорта открывается модальное окно - в заголовке сказано, что лимит будет превышен - в теле показаны 3 числа: лимит тарифа, текущая база, сколько контактов добавит импорт - ниже 2 действия: «Увеличить лимит» и «Импортировать в пределах лимита» - если выбран второй вариант, система импортирует только допустимый остаток и показывает, сколько строк пропущено ## Что не входит - переработка страницы тарифов - изменение механики лимитов ## Критерии приемки - пользователь узнает о лимите до старта импорта - в окне есть один основной и один вторичный сценарий - после частичного импорта пользователь видит итог: импортировано / пропущено ## Инструкции для ИИ - Проверь, описано ли поведение модального окна для всех состояний - Найди граничные случаи: лимит превышен ровно на 1 контакт, у пользователя нет прав на апгрейд тарифа - Проверь, можно ли по критериям приемки однозначно принять результат - Не предлагай новый сценарий, пока не укажешь пробелы в текущей постановке
Тип 2: Первое касание продукта
Пример на first-time experience и адаптивное "пустое" состояние.
# Пустое состояние списка тикетов для новой команды ## Проблема Новый аккаунт попадает в пустой список тикетов и не понимает, что делать дальше. ## Сценарий Команда создала workspace, но еще не получила ни одного обращения. ## Что проектируем Первое пустое состояние экрана «Обращения». ## Гипотеза Новая команда не знает с чего начать, потому что пустой экран не предлагает первого шага. Структурированный empty state с одним основным действием даст понятный вход без необходимости изучать продукт самостоятельно. ## Как должно работать - в центре экрана иллюстрация, заголовок и короткий текст в 2 строки - основной action: «Подключить канал» - вторичный action: «Создать тестовый тикет» - ниже блок «Что дальше» из 3 шагов: подключить email, назначить ответственного, проверить тестовый тикет - если хотя бы один канал уже подключен, пустое состояние меняется: основной action становится «Создать тестовый тикет», блок про подключение скрывается ## Что не входит - мастер настройки каналов - обучение агентов ## Критерии приемки - пустой экран не оставляет пользователя без действия - состояние меняется после подключения первого канала - на экране не более двух кнопок действий ## Инструкции для ИИ - Проверь, описаны ли все состояния: после подключения канала, после получения первого тикета, после создания тестового тикета - Найди пробелы в логике адаптивного пустого состояния - Проверь, не конфликтует ли «не более двух кнопок» с блоком «Что дальше» - На выходе дай список незакрытых вопросов до передачи в разработку
Тип 3: Поведение формы
Пример на фикс бизнес-процесса через UI.
# Inline-выбор ответственного в форме новой сделки ## Проблема Менеджеры пропускают поле ответственного, из-за чего сделки создаются без автора/постановщика. ## Сценарий Пользователь создает сделку из общей формы. ## Что проектируем Поведение и интерфейс блока «Ответственный» внутри формы. ## Гипотеза Поле пропускается, потому что выглядит опциональным и пустым. Предзаполнение текущим пользователем и inline-редактирование убирают оба барьера без изменения структуры формы. ## Как должно работать - поле «Ответственный» находится в верхней части формы, сразу после названия сделки - по умолчанию подставляется текущий пользователь - справа от имени есть ссылка «Изменить» - при нажатии открывается компактный выпадающий список без перехода на отдельный экран - в списке сначала 5 последних выбранных сотрудников, ниже поиск по всем сотрудникам - если пользователь меняет ответственного, новое значение сохраняется в форме сразу без отдельной кнопки ## Что не входит - переработка всей формы сделки - правила распределения сделок ## Критерии приемки - у новой сделки всегда есть предзаполненный ответственный - смена ответственного делается без ухода со страницы - список последних выбранных сотрудников показывается только при наличии истории ## Инструкции для ИИ - Проверь поведение при граничных состояниях: новый пользователь без истории, пустая команда, поиск без результатов - Найди неоднозначности в критериях: что значит «только при наличии истории»? - Укажи вопросы, которые нужно закрыть до передачи в разработку - Не предлагай переработку формы - это вне рамки задачи
Тип 4: Состояние ошибки
Делаем уведомления понятными.
# Уведомление об ошибке подключения рекламного кабинета ## Проблема После неуспешного подключения источника пользователь видит общий текст ошибки и не понимает, можно ли исправить проблему самому. ## Сценарий Подключение рекламного кабинета завершилось ошибкой. ## Что проектируем Уведомление об ошибке на экране источников данных. ## Гипотеза Пользователь не пытается исправить ошибку, потому что не понимает, его ли это зона ответственности. Разделение ошибок на «исправимые мной» и «подождать» с одним конкретным действием снизит число брошенных подключений. ## Как должно работать - в карточке есть статус «Подключение прервано» - ниже одна главная причина из справочника ошибок человеческим языком - под причиной один основной action: «Исправить и повторить» - если ошибка связана с доступами, под кнопкой показывается ссылка «Как выдать доступ» - если ошибка временная, вместо ссылки показывается текст «Можно повторить позже» без инструкции - кнопка повторной попытки запускает сценарий заново из текущего экрана ## Что не входит - новый центр диагностики - переработка всех статусов источников ## Критерии приемки - пользователь видит причину ошибки без технического текста - для исправимой ошибки есть явное действие - повторная попытка запускается без перехода в другой раздел ## Инструкции для ИИ - Проверь, описаны ли все типы ошибок или только два из примера - Найди пробелы: что показывается, если ошибка не попадает в справочник - Проверь, достаточно ли критериев приемки для всех состояний карточки - На выходе укажи незакрытые граничные случаи
Примеры показывают, как выглядит зрелая задача в финальном виде, но не описывают процесс, через который она к этому виду приходит. Следующая статья закрывает именно этот вопрос: как выстроить контур проверки, который позволяет отличить задачу, готовую к передаче, от задачи, которая лишь кажется готовой.