Дизайн-спецификация к интерфейсу

В этой статье:

• Что такое дизайн-спецификация

• Типы дизайн-спецификации

• Пошаговое создание

• Заключение

Что такое дизайн-спецификация

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

Есть инструмент, который поможет сделать процесс передачи макетов в разработку в разы эффективнее, сократить количество созвонов и синхронизировать видение интерфейса в команде. Мы называем его спецификация (простите, аналитики) вёрстки или «дизайн-спецификация» (для некоторых она может быть знакома как функциональная спецификация интерфейса). Не путайте с ТЗ, и аналитической спецификацией.

Определение
Дизайн-спецификация / спецификация вёрстки – это пояснения к работе элементов интерфейса и значимым параметрам в вёрстке, фиксирующие ограничения системы, а также  правила поведения элементов при действиях пользователей и при ответе системы.
Дизайн-спецификация не ограничивается только сводом правил, но также служит инструментом коммуникации и фиксирования договорённостей в команде. Во время проработки интерфейса дизайнер взаимодействует с аналитиком, тестировщиком, ux-писателем, владельцем продукта, разработчиками. Все участники влияют на конечный результат, а важные моменты фиксируются в спецификации.

В этой статье я опишу, как создавать дизайн-спецификацию в продуктовой разработке, когда звонить разработчику и как коннектиться с коллегами. После прочтения сможете классные спеки составлять.
Рабочий инструмент – Figma.

Типы дизайн-спецификаций

На просторах интернета можно найти такие артефакты, близкие или входящие в понятие «спецификации»:

• Макеты-экраны, отражающие состояния системы крупным планом, иногда с небольшими подписями

• Созвон и устное объяснение разработчику «как это работает» (устная спецификация)

• Последоветельность экранов, обозначающая путь пользователя

• Интерактивные прототипы

• Сопроводительные многостраничные текстовые документы

• Микс из всего перечисленного

Мы в команде тоже использовали схожие артефакты, а затем пришли к такой комбинации:

1. Небольшой перечень экранов (интерфейс крупным планом для демонстрации размещения проектируемых элементов или адаптива всей страницы)

2. Основной пользовательский путь экранами, если важно

3. Документ с перечисленными элементами страницы и пояснениями к их работе

Всё это входит в наше понятие дизайн-спецификации. И, так как спецификация – инструмент коммуникации, она сопровождается некоторыми организационными процессами. Например, у нас есть несколько «приёмок», в ходе которых мы коллегам демонстрируем макеты и устно передаём спецификацию, дополняя её по ходу демонстрации.

Давайте теперь посмотрим на ещё одну классификацию. Согласно NNGroup есть три типа спецификаций:

1. Спецификация элементов

2. Функциональная спецификация

3. Контентная спецификация

В SimpleOne продукты разрабатываются по единой дизайн-системе, где описаны базовые компоненты, шрифты и стили, поэтому далее о «спецификации элементов» я упомяну лишь частично. Сфокусируемся на двух оставшихся типах согласно определению от NNGroup: «функциональной» и «контентной» спецификациях.

Функциональная спецификация фокусируется на том, как интерфейс и системы должны работать. Контентная спецификация содержит пояснения к самому контенту: сообщениям, иллюстрациям.

Пошаговое создание спецификации

К моменту первой приёмки дизайн-спецификация уже должна быть готова.

Ранее мы использовали текст и указатели для создания спецификации, также плагин DesignDoc [Spectral], теперь перешли на Annotations для Dev Mode.

В процессе создания спецификации мы пошагово указываем все составляющие функциональной спецификации:

1. Дефолтное состояние интерфейса

2. Целевое состояние (после взаимодействия пользователя со системой)

3. Результат взаимодействия в целевом сценарии

4. Корнер-кейсы (edge cases) до/после взаимодействия с системой

5. Отображение в разных частях системы (если применимо)

6. Отображение на разных разрешениях / устройствах (адаптив, web, mobile)

7. Состояния загрузки (если релевантно)

Давайте пройдёмся по каждому шагу на примере интерфейса складов для продукта ITAM.

Шаг 1. Дефолтное состояние интерфейса

Здесь важно описать все элементы, которые находятся в разрабатываемом интерфейсе / на экране.

Если был создан новый компонент — указать все его состояния. Покажите хинты (всплывающие подсказки), подпишите, что происходит при нажатии на кнопки, что открывается в новой вкладке, а что в текущей. Не перепутайте курсоры: вид курсора также настраивается разработчиком.

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

Шаг 2. Целевое состояние интерфейса

Подпишите элементы, которые изменились и почему. Если появились новые – также укажите их.

Шаг 3. Конечный результат после взаимодействия

Как и в шаге 2 подпишите новые состояния ранее упомянутых элементов. Если какие-то действия пользователя ограничиваются или, наоборот, появляются новые возможности – также укажите. Например, у меня на скриншоте нельзя изменить количество к резерву, но можно сначала отменить резерв для всех активов.

Шаг 4. Краевые случаи

Отобразите состояния элементов, для которых возможно изменение в нецелевых сценариях – корнер-кейсах. Задайтесь вопросом: а что, если контента будет здесь больше? Или не будет совсем? Также проработайте сценарии с ошибками.

Шаг 5. Отображение в разных частях системы

Если ваш интерфейс имеет разное отображение для разных пользователей или, возможно, должен отображаться в разных стилях – покажите, как это будет выглядеть. В нашем случае этого не понадобилось.

Шаг 6. Отображение на различных устройствах

SimpleOne – это адаптивный web-интерфейс. Поэтому у меня указано как смещаются / скрываются элементы при уменьшении ширины окна и как он выглядит на мобильных разрешениях.

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

Спецификация контента

Мы не выделяем спецификацию контента отдельно как тип, а прорабатыаем вместе с состояниями интерфейса внтури функциональной спецификации. Иконки проходят ревью дизайнеров, а тексты правят технические писатели, выполняющие функции ux-писателей в команде. Мы стараемся сделать тексты легко читаемыми и дружелюбными к пользователям, таким образом, формируя черновой вариант для коллег.

После проработки дизайн-спецификации

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

Процесс создания спецификации можно ускорить: если до макетов были проработаны и согласованы UC (сценарии использования) с перечнем корнер-кейсов – останется только перенести описание в макеты на конкретные элементы и добавить недостающие.

Заключение

Спецификация помогает дизайнеру перепроверить себя и уменьшать возможные созвоны и внезапные выработки решений на «позабытые» состояния.

Также она помогает всей команде: тестировщик будет по ней составлять тест-кейсы и сверяться при возникновении дефектов, ux-писателю она понадобится, чтобы быстро вникнуть в контекст для корректировки текстов, а владельцу продукта поможет удостовериться, что его устроит конечный результат и допущения, принятые из-за ограничений разработки.

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

А как у вас происходит фиксирование правил работы интерфейса? Поделитесь в комментариях.