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