Прототипы и макеты: как согласовывать интерфейс

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

Кейс: кнопка отмены у всех заказов

В магазине «Узелок» дизайнер нарисовал экран заказа. На нём есть кнопка «Отменить заказ», и нарисована она одинаково для любого статуса. По условному бизнес-правилу БП-01 из статьи 02-11 заказ можно отменить, пока он не передан курьеру. Выходит, для заказа в статусе «Передан курьеру» кнопка либо должна исчезнуть, либо вести к понятному отказу. В макете об этом ни слова.

Это типичная находка при сверке: макет красив и логичен для главного случая, но не покрывает остальные. Дальше разберём, как такие пробелы находят и как о них сообщают.

Набросок, макет и прототип

Слова «макет» и «прототип» в командах часто смешивают, поэтому договоримся о значениях. Обычно различают три вида:

• Набросок (wireframe) - схематичная структура экрана. Показывает, где что стоит. Без цвета и картинок, не кликается.
• Макет (mockup) - статичный визуальный дизайн: цвета, шрифты, иконки. Взаимодействия в нём нет.
• Прототип (prototype) - модель с интерактивностью. По ней можно пройти путь пользователя и проверить переходы.

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

Что проверять в макете

Макет сверяют с требованиями по четырём слоям:

1. Поля. Все ли поля и кнопки из требований нарисованы, нет ли лишних.
2. Состояния. Нарисован ли только успешный случай или есть загрузка, пустой список и ошибка. Состояния экрана подробно разобраны в статье 02-17.
3. Ошибки. Что увидит покупатель, если действие невозможно. В кейсе это отказ в отмене.
4. Тексты. Совпадают ли подписи кнопок и названия статусов с теми, что записаны в требованиях и у поддержки.

К этому списку добавляют проверку правил: каждое бизнес-правило, которое влияет на экран, должно где-то отражаться. Для полей форм и проверок ввода есть отдельная статья 02-16.

Как оставить комментарий дизайнеру

Комментарий вида «тут как-то непонятно» заставляет дизайнера гадать, что имелось в виду. Полезный комментарий отвечает на четыре вопроса:

• где: какой экран и какой элемент;
• что не так: что именно отсутствует или расходится с требованием;
• основание: ссылка на требование или правило;
• что ожидаем: какое поведение или текст нужны.

Для кейса комментарий мог бы выглядеть так: «Экран отмены заказа. Нет текста для заказа в статусе «Передан курьеру». Основание: БП-01, отмена после передачи невозможна. Ожидаем сообщение об отказе и кнопку «К заказу»». Ссылка на требование превращает мнение в замечание, которое можно проверить и закрыть.

Где это встречается в работе

• Согласование нового экрана перед началом разработки.
• Приёмка готового интерфейса, когда его сверяют с макетом и требованиями.
• Обсуждение изменений, когда после правки требований нужно обновить макет.
• Подготовка тест-кейсов: по макету видно, какие состояния придётся проверять.
• Работа в инструментах дизайна, например в Figma (статья 11-04).

Итог

Набросок показывает структуру, макет показывает внешний вид, прототип показывает путь пользователя. Макет сверяют с требованиями по полям, состояниям, ошибкам и текстам. Замечание дизайнеру пишут по схеме «где, что не так, основание, что ожидаем».

Что дальше

Дальше разберём экранные формы и проверки ввода (статья 02-16) и состояния экрана (статья 02-17).