предыдущий шаг

Принципы сборки задачи и работы с инструментом описаны - теперь полезно увидеть, как они выглядят в применении к конкретным типам интерфейсных задач, а не в абстракции. ↓

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

Эти сценарии покрывают большинство UI-задач: прерывающий сценарий, first-time experience, поведение формы, состояние ошибки.

Тип 1: Прерывающий сценарий

Это пример на локскрины и явный следующий шаг.

billing-limit-warning.md
# Экран предупреждения о достижении лимита контактов

## Проблема
Пользователь упирается в лимит контактов в момент импорта
и получает отказ без понятного следующего шага.

## Сценарий
Пользователь загружает CSV, система считает, что после импорта
лимит тарифа будет превышен.

## Что проектируем
Попап предупреждения до запуска импорта.

## Гипотеза
Пользователь теряется, потому что блокирующее сообщение не дает альтернативы.
Если показать цифры и два явных пути до старта импорта - он примет
решение без отрыва от процесса.

## Как должно работать
- вместо старта импорта открывается модальное окно
- в заголовке сказано, что лимит будет превышен
- в теле показаны 3 числа: лимит тарифа, текущая база,
  сколько контактов добавит импорт
- ниже 2 действия: «Увеличить лимит» и «Импортировать в пределах лимита»
- если выбран второй вариант, система импортирует только допустимый
  остаток и показывает, сколько строк пропущено

## Что не входит
- переработка страницы тарифов
- изменение механики лимитов

## Критерии приемки
- пользователь узнает о лимите до старта импорта
- в окне есть один основной и один вторичный сценарий
- после частичного импорта пользователь видит итог: импортировано / пропущено

## Инструкции для ИИ
- Проверь, описано ли поведение модального окна для всех состояний
- Найди граничные случаи: лимит превышен ровно на 1 контакт,
  у пользователя нет прав на апгрейд тарифа
- Проверь, можно ли по критериям приемки однозначно принять результат
- Не предлагай новый сценарий, пока не укажешь пробелы в текущей постановке

Тип 2: Первое касание продукта

Пример на first-time experience и адаптивное "пустое" состояние.

helpdesk-empty-state.md
# Пустое состояние списка тикетов для новой команды

## Проблема
Новый аккаунт попадает в пустой список тикетов
и не понимает, что делать дальше.

## Сценарий
Команда создала workspace, но еще не получила ни одного обращения.

## Что проектируем
Первое пустое состояние экрана «Обращения».

## Гипотеза
Новая команда не знает с чего начать, потому что пустой экран не предлагает
первого шага. Структурированный empty state с одним основным действием
даст понятный вход без необходимости изучать продукт самостоятельно.

## Как должно работать
- в центре экрана иллюстрация, заголовок и короткий текст в 2 строки
- основной action: «Подключить канал»
- вторичный action: «Создать тестовый тикет»
- ниже блок «Что дальше» из 3 шагов: подключить email,
  назначить ответственного, проверить тестовый тикет
- если хотя бы один канал уже подключен, пустое состояние меняется:
  основной action становится «Создать тестовый тикет»,
  блок про подключение скрывается

## Что не входит
- мастер настройки каналов
- обучение агентов

## Критерии приемки
- пустой экран не оставляет пользователя без действия
- состояние меняется после подключения первого канала
- на экране не более двух кнопок действий

## Инструкции для ИИ
- Проверь, описаны ли все состояния: после подключения канала,
  после получения первого тикета, после создания тестового тикета
- Найди пробелы в логике адаптивного пустого состояния
- Проверь, не конфликтует ли «не более двух кнопок» с блоком «Что дальше»
- На выходе дай список незакрытых вопросов до передачи в разработку

Тип 3: Поведение формы

Пример на фикс бизнес-процесса через UI.

crm-assignee-picker.md
# Inline-выбор ответственного в форме новой сделки

## Проблема
Менеджеры пропускают поле ответственного, из-за чего сделки создаются без автора/постановщика.

## Сценарий
Пользователь создает сделку из общей формы.

## Что проектируем
Поведение и интерфейс блока «Ответственный» внутри формы.

## Гипотеза
Поле пропускается, потому что выглядит опциональным и пустым.
Предзаполнение текущим пользователем и inline-редактирование убирают
оба барьера без изменения структуры формы.

## Как должно работать
- поле «Ответственный» находится в верхней части формы,
  сразу после названия сделки
- по умолчанию подставляется текущий пользователь
- справа от имени есть ссылка «Изменить»
- при нажатии открывается компактный выпадающий список
  без перехода на отдельный экран
- в списке сначала 5 последних выбранных сотрудников,
  ниже поиск по всем сотрудникам
- если пользователь меняет ответственного, новое значение
  сохраняется в форме сразу без отдельной кнопки

## Что не входит
- переработка всей формы сделки
- правила распределения сделок

## Критерии приемки
- у новой сделки всегда есть предзаполненный ответственный
- смена ответственного делается без ухода со страницы
- список последних выбранных сотрудников показывается
  только при наличии истории

## Инструкции для ИИ
- Проверь поведение при граничных состояниях: новый пользователь без истории,
  пустая команда, поиск без результатов
- Найди неоднозначности в критериях: что значит «только при наличии истории»?
- Укажи вопросы, которые нужно закрыть до передачи в разработку
- Не предлагай переработку формы - это вне рамки задачи

Тип 4: Состояние ошибки

Делаем уведомления понятными.

analytics-connection-error.md
# Уведомление об ошибке подключения рекламного кабинета

## Проблема
После неуспешного подключения источника пользователь видит общий
текст ошибки и не понимает, можно ли исправить проблему самому.

## Сценарий
Подключение рекламного кабинета завершилось ошибкой.

## Что проектируем
Уведомление об ошибке на экране источников данных.

## Гипотеза
Пользователь не пытается исправить ошибку, потому что не понимает,
его ли это зона ответственности. Разделение ошибок на «исправимые мной»
и «подождать» с одним конкретным действием снизит число брошенных подключений.

## Как должно работать
- в карточке есть статус «Подключение прервано»
- ниже одна главная причина из справочника ошибок
  человеческим языком
- под причиной один основной action: «Исправить и повторить»
- если ошибка связана с доступами, под кнопкой показывается
  ссылка «Как выдать доступ»
- если ошибка временная, вместо ссылки показывается текст
  «Можно повторить позже» без инструкции
- кнопка повторной попытки запускает сценарий заново
  из текущего экрана

## Что не входит
- новый центр диагностики
- переработка всех статусов источников

## Критерии приемки
- пользователь видит причину ошибки без технического текста
- для исправимой ошибки есть явное действие
- повторная попытка запускается без перехода в другой раздел

## Инструкции для ИИ
- Проверь, описаны ли все типы ошибок или только два из примера
- Найди пробелы: что показывается, если ошибка не попадает в справочник
- Проверь, достаточно ли критериев приемки для всех состояний карточки
- На выходе укажи незакрытые граничные случаи

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