Спецификация дизайна сайта: состояния интерфейса до начала разработки

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

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

1. Отделите дизайн-решения от красивых экранов

Передача дизайна в разработку, или handoff, — это передача согласованных правил интерфейса вместе с макетами. Экран показывает конкретный момент. Спецификация добавляет условия: что запускает действие, какие данные нужны, что видит человек во время ожидания и как продолжает работу после неудачи. Для бизнеса важно, чтобы эти решения не возникали случайно во время вёрстки.

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

Этот документ не является запросом на выбор студии. Если вы ещё сравниваете исполнителей, отдельно пригодится материал о RFI, RFP и RFQ для выбора подрядчика. Здесь речь о другом решении: какие именно сведения команда должна получить перед реализацией уже определённого дизайна.

2. Соберите матрицу состояний, а не коллекцию копий

Состояния интерфейса описывают ответ компонента на ситуацию. Для поля это пустое значение, ввод, фокус и ошибка; для списка — загрузка, результат, отсутствие результатов и сбой. Не каждому блоку нужны все варианты. Выбирайте те, которые действительно могут возникнуть в согласованном сценарии, и объясняйте, почему остальные не применяются.

Разделите внешний вид и поведение

Цвет кнопки при наведении не объясняет, можно ли нажать её во время запроса. Так же нарисованный индикатор ожидания не определяет момент своего исчезновения. Рядом с визуальным вариантом запишите три вещи: событие входа в состояние, доступные действия и условие выхода. Если ответ зависит от сервера, отметьте эту зависимость для обсуждения с разработчиком.

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

Не смешивайте разные причины отсутствия данных

«У вас ещё нет сохранённых товаров» и «По этим фильтрам ничего не найдено» требуют разных действий. В первом случае уместен переход в каталог, во втором — изменение условий поиска. Недоступные данные не стоит показывать как нулевой результат: это другая причина, другой текст и, возможно, другая возможность повторить запрос.

3. Опишите сообщения, фокус и возвращение к работе

Не оставляйте тексты ошибок на конец проекта. В спецификации нужны реальные формулировки, место показа и момент появления. Для поля электронной почты полезнее «Укажите адрес в формате [email protected]», чем «Некорректное значение». При этом формат проверки должен соответствовать согласованным правилам данных, а не случайному ограничению макета.

В пояснении к критерию WCAG 3.3.1 об идентификации ошибок W3C указывает: автоматически обнаруженную ошибку ввода нужно описать текстом и обозначить проблемный элемент. Красная рамка может дополнять объяснение, но не заменяет его. Это конкретное требование к ошибке, а не подтверждение доступности всего сайта.

Отдельно определите поведение клавиатурного фокуса — текущего элемента, с которым человек взаимодействует без мыши. Куда он переходит после открытия диалога, закрытия окна или неудачной отправки? В макете покажите видимое выделение, а в примечании опишите ожидаемый маршрут. Окончательное решение проверяют уже в реализованном интерфейсе.

Сообщение «Сохранено» или «Ничего не найдено» может появляться без перехода на другую страницу. WCAG 4.1.3 о сообщениях о состоянии объясняет, как такие изменения должны быть программно доступны вспомогательным технологиям без обязательного перевода фокуса. Не требуйте одинакового оповещения для каждого изменения: способ объявления зависит от контекста и важности события.

На этапе дизайна достаточно отметить, какое сообщение должен получить человек и должна ли его работа прерываться. Разработчик определяет технический способ, а тестировщик проверяет результат. Для более широкого контекста есть материал GL.ua о дизайне с акцентом на доступность; спецификация состояний охватывает лишь часть этой задачи.

4. Пройдите условный пример заявки на расчёт

Условный пример: компания принимает через сайт запросы на расчёт стоимости мебели. Посетитель выбирает тип изделия, оставляет контакт и добавляет комментарий. Бизнес-цель — получить обращение, на которое можно ответить. Это учебный сценарий, а не описание клиента или результата GL.ua.

От нажатия до подтверждения

До отправки форма показывает обязательные поля и подсказки. Если контакт не заполнен, после попытки отправки появляется конкретное объяснение рядом с полем. Комментарий остаётся на месте. В рекомендациях WAI по сообщениям в формах приведены подходы к общему списку ошибок и пояснениям рядом с полями. Спецификация определяет нужную комбинацию для этой формы, а не копирует все варианты одновременно.

Если локальные проверки пройдены, кнопка переходит в состояние «Отправляем». В этом условном решении повторное нажатие недоступно до завершения текущего запроса. Нужно отдельно согласовать, можно ли менять поля во время ожидания и какие введённые значения сохранятся после неудачной попытки. Визуальное состояние кнопки само по себе не определяет эти правила.

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

5. Проверьте контент и адаптивность до вёрстки

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

Адаптивность описывайте как правила перестроения, а не только пару «компьютер — телефон». Укажите, какие элементы меняют порядок, что остаётся видимым и как ведут себя таблицы и длинные списки. Точные границы ширины команда выбирает под контент и компоненты. Отдельно проверяйте промежуточные размеры: два согласованных экрана не описывают все ситуации между ними.

Для многоязычного сайта проверьте тексты разной длины. Укажите источник шрифтов, доступные начертания и правила для иконок. Экспортированные материалы должны соответствовать тем, которые использованы в макете.

6. Согласуйте пакет и пройдите нумерованную проверку

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

До начала разработки пройдите проверку прототипа ниже. Перед запуском сайта повторите те же сценарии на реализации: кликабельный макет не доказывает, что сообщения, переходы и работа с данными выполнены правильно.

1. Пройдите главный маршрут от начального условия до подтверждённого результата.
2. Для каждого действия проверьте ожидание, успех и неудачу. Найдите состояния без выхода.
3. Подставьте длинные и отсутствующие значения и проверьте несколько ошибок в форме одновременно.
4. Пройдите маршрут на узком и промежуточном экране. На готовом сайте дополнительно проверьте клавиатуру и объявление важных сообщений.
5. Сопоставьте макеты, тексты и библиотеку компонентов. Устраните противоречия и зафиксируйте одну версию для реализации.
6. Запишите нерешённые зависимости и согласуйте, какие из них блокируют старт. Перед публичным запуском проверьте их закрытие на рабочем сценарии.

Для приёмки уже готового продукта используйте отдельный план. Материал о приёмке корпоративного сайта касается следующего этапа. Передача дизайна определяет ожидаемое, а приёмка проверяет фактическое; эти процедуры связаны, но не подменяют друг друга.

7. Оцените сроки, стоимость и риск избыточной детализации

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

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

Самые большие риски — противоречивые версии, несогласованные ответы сервера и требования, которые появляются после старта. Фиксируйте дату и версию пакета, а изменения описывайте через влияние на сценарии, макеты и проверки.

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

Согласованный дизайн-пакет делает изменения видимыми до программирования. Передайте GL.ua (Глянец) перечень главных сценариев и имеющиеся макеты, чтобы обсудить разработку сайта и согласовать объём подготовки дизайна к реализации.