Привет, Хабр! Меня зовут Даша, я проектировщик интерфейсов в Selectel.

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

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

Шаги, примеры оформления и полезный шаблон ищите под катом. Рассчитываю, что текст будет полезен джунам и мидлам как в дизайне, так и во фронтенд-разработке.

Почему передача макетов в разработку — не такой простой процесс, как может показаться на старте

Решение дизайн-задачи предполагает прохождение определенных шагов. Независимо от фреймворка, в котором работает дизайнер, их можно разделить на четыре основных этапа:

1. Определение проблемы и задачи (исследования и анализ).
2. Проектирование решения (идея, прототип, тестирование).
3. Передача в разработку, внедрение решения.
4. Валидация результата и доработка.

Основные этапы решения дизайн-задачи.

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

Сложность и нюансы третьего этапа легко недооценить (по крайней мере, так было у меня, когда я попала в большой и сложный продукт). Ведь к нему вы приступаете после того, как проделали огромную работу. А именно:

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

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

Скорее всего, по любой из причин (перегруз задачами, ограниченные сроки, неопытность — выберите любую) вы забыли проработать какие-то состояния, кейсы или сценарии. Например, когда у клиента низкая скорость интернет-соединения или когда система не подгрузила часть данных в интерфейс. Более того, фронт, покопавшись в коде, с высокой вероятностью мог найти какие-то технические ограничения, которые вы пропустили при подготовке макетов или на этапе командного груминга.

Когда я начала работу в сложном продукте, прошла через все стадии принятия этой проблемы:

• отрицание: «Да нет, я не могла забыть про удаление услуги»,
• гнев: «Да это же очевидно, что тут может быть пустое состояние! Разве нет?»,
• торг: «Ну так изменение настроек такое же, как в другой фиче. Просто сделай также!»,
• депрессия: «Мне не быть хорошим дизайнером, я опять забыла вот это в макетах…»,
• принятие: «Да, я не продумала кейс, когда может быть много строчек в таблице, сейчас доработаю. Хм, кажется, стоит составить список, что надо проверять перед передачей макетов в разработку».

Так и родился этот чек-лист — ссылка на интерактивный шаблон в Notion ждет вас в конце текста.

Когда макеты готовы, я проверяю их по описанным в тексте пунктам. И по опыту скажу, что количество вопросов от фронтенд-разработчика сильно снижается. Фича быстрее доезжает в прод. Так происходит из-за того, что:

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

Чек-лист для дизайнера

Шаг 1. Проверьте, все ли сценарии взаимодействия с объектами вы предусмотрели

Практически любая фича попадает под базовый концепт разработки, который называется CRUD: создание (create), чтение (read), модификация (update), удаление (delete). Например, в панели my.selectel.ru при проектировании раздела управления пользователями, у которых есть доступ к аккаунту, важно учитывать, что:

• пользователя можно создать = create,
• данные о пользователе можно посмотреть = read,
• созданного пользователя можно отредактировать (изменить имя, телефон, роли доступа и другие данные) = update,
• пользователя можно удалить = delete.

Более того, в некоторых фичах могут быть специфические операции. Например, в случае с пользователями в my.selectel.ru можно отправить повторное приглашение в аккаунт.

CRUD-операции — это основа, о которой всегда нужно помнить. Но помимо этого, чтобы ничего не упустить, рекомендую составить базовую карту объектов, где будут учитываться: объект, данные и параметры объекта, действия с эти объектом.

Вот так может выглядеть эта карта на примере объекта «пользователь»:

• объект — пользователь,
• данные и параметры объекта — имя, телефон, id, email и другие (данные можно разделить на системные и вводимые пользователем. Последние — на обязательные для ввода и необязательные),
• действия, доступные пользователю при работе с объектом — создать пользователя, отредактировать, удалить и другие.

Пример карты атрибутов и действий объекта.

Подробнее о разных картах объектов и объектно-ориентированном подходе в дизайне читайте в тексте по ссылке.

Шаг 2. Оцените, как тот или иной объект будет выглядеть при минимальном и максимальном количестве данных

Как-то раз я забыла на макете про пагинацию в таблице. В итоге пришлось просить бэкенд-разработчика внепланово взять задачу в работу, а потом угостить кофе :)

Данные в интерфейсе бывают разные — часть из них приходит из базы данных, часть пользователь вводит вручную. И в том, и в другом случае нужно предусмотреть четыре состояния:

• Данные отсутствуют

Например, пользователь не заполнил необязательное поле в анкете. Как будет в таком случае отображаться анкета: поля будут пустыми или там будет прочерк? Или, может, заглушка «Данных нет»?

• Данных мало

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

• Данных много

Например, когда в таблице 100 строк — в таком случае будет пагинация или бесконечный скролл? Или, например, в поле для ввода ФИО пользователь ввел очень длинную фамилию, которая не помещается в поле. Как выводить такие данные? Отрезать часть фамилии, прятать за многоточие и при наведении показывать тултип с полной фамилией или переносить часть текста на вторую строчку?

• Достигнут лимит данных

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

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

Шаг 3. Проверьте, учли ли вы разные варианты завершения пользовательского сценария

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

Давайте разберем на примере оформления заказа в магазине разные варианты развития сценария, которые стоит учесть в макетах:


Пять основных пользовательских сценариев.

→ success (успешный сценарий) — тут все понятно: пользователь успешно положил товар в корзину, ввел данные доставки, провел оплату и счастливо ждет свой заказ.
→ error (ошибка) — что-то пошло не по плану, пользователь не смог оформить заказ. Здесь особенно тщательно стоит разобрать, какие ошибки могут случиться:

• на стороне продукта. Например, произошла ошибка на сервере и система «легла»,
• на стороне пользователя. Например, пользователь ввел некорректные данные в поле доставки, и система валидирует это поле, как ошибочное.

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

• loading (загрузка) — момент сценария, когда системе нужно время для загрузки данных. Например, при загрузке корзины, когда пользователь сложил в нее много позиций. Здесь стоит уточнить у разработчиков, в какой момент система может уйти «думать».
• onboarding (знакомство) – первое прохождения сценария. Например, когда пользователь впервые оказался в корзине, с помощью подсказок можно показать, где вводить данные о доставке, а где искать искать похожие товары.
• empty state (пустое состояние) — момент сценария, когда по каким-то причинам данных на странице нет. Например, в ситуации, когда пользователь очистил корзину.

Шаг 4. Продумайте на этапе проектирования фичи, как она будет пересекаться с другими интерфейсами в продукте

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

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

Шаг 5. Сверьтесь с ролевой моделью продукта

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

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

Пример правила из UX-спецификации.

Шаг 6. Покажите разработчику состояния компонентов, которые вы используете в макетах

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

Если в продукте, в котором вы работаете, есть дизайн-система и сторибук – прекрасно! В таком случае все, что нужно сделать — убедиться, что у разработчика есть ссылки на все нужные библиотеки. Но если дизайн-системы нет, выделите время и один раз самостоятельно для всех базовых компонентов визуально покажите все состояния. Лучше это сделать в отдельном файле Figma (или в другом редакторе, с которым вы работаете — Sketch, Adobe XD, Pixo).

У любого компонента-атома (здесь можно почитать подробнее про атомарный подход) есть базовые состояния:

• enabled,
• hover,
• pressed,
• focused,
• activated и selected,
• disabled,
• loading.

Пример визуализации разных состояний компонента.

Подготовьте описания сложных компонентов-организмов.

Даже при наличии дизайн-системы вы наверняка в своих фичах будете создавать и использовать кастомные сложные компоненты: карточки, сложные аккордеоны, выпадающие списки с большим количеством данных. Для них также стоит описать и визуализировать базовые состояния, которые перечислены пунктом выше (enabled, hover и другие). При этом дополнительно рекомендую зафиксировать параметры подобных компонентов:

→ Опишите зону клика

Рассмотрим пример с чекбоксами в выпадающем списке. Область клика будет включать в себя только текст, чекбокс или всю строку? Спойлер: третий вариант выигрышнее. В материале по ссылке хорошо объяснили, почему.

→ Определите, как изменяются ширина и высота компонента: являются ли они фиксированными или тянутся?

Например, карточки будут фиксированной ширины в 320px независимо от разрешения экрана, или они будут тянуться пропорционально экрану?

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

Выпадающий список может иметь разное количество значений. В этой ситуации важно показать, как они будут выводиться. К примеру, в списке можно выводить только пять из 20, а остальные прятать под внутренний скролл.


Пример описания компонента-организма для разработчика.

Рекомендую такие спецификации держать в том же редакторе, в котором собираете макеты.

Шаг 7. Визуализируйте поведение интерфейса для разных разрешений экрана

Еще на этапе обсуждения стратегии развития продукта определяется, стоит ли вкладывать ресурсы в поддержку сервиса для разных устройств — кому-то достаточно только десктопной версии, кому-то только мобильной. Все зависит от поведения и потребностей ваших пользователей. Определить, какие устройства в приоритете, помогут отчеты инструментов веб-аналитики — Yandex Metrika, Google Analytics, Amplitude и другие.

• Если ваша целевая аудитория пользуется несколькими устройствами (классическая тройка — десктоп, планшет, смартфон), не забудьте подготовить под них адаптив.
• Если вы делаете дизайн для продукта под одно ключевое разрешение — например, веб-сервис под стандартные экраны 1280 — опишите, что будет, если его откроют с экрана 1920 (это тоже десктоп). И опишите крайний кейс, когда в ваш продукт зайдут с мобильного телефона.

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

Вишенка на торте: что пригодится в работе разработчику и другим членам команды

Вот список доработок к макетам, которые не займут много времени и точно снимут часть вопросов.

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

→ Добавьте рубрикатор на страницу, где храните макеты. Когда в фиче много сценариев, страница в Figma (или в любом другом редакторе) выглядит, как пасьянс из макетов.

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


Пример рубрикатора для макетов в Figma.

→ UX-спецификация. Подготовьте текстовое описание основных сценариев фичи. Например: «Сценарий удаления запускается при клике на кнопку “Удалить”. После клика выводим модальное окно с подтверждением, окно фиксированное по ширине…»

→ Если нет времени писать отдельную UX-спецификацию, можно оставить комментарии разработчикам прямо в Figma. Рядом с макетом всегда можно оставить пояснения, как ведет себя интерфейс. Поверьте, разработчик будет рад :)

→ Комментарии тестировщикам, если что-то из макетов не ушло в релиз. Бывают ситуации, когда релиз уже вот-вот, а какие-то ответвления сценария явно в него не попадут. Отметьте для тестировщиков, какие экраны поедут в следующий релиз фичи – так они не потратят время на вопросы о том, почему эта часть не сделана.

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

Шаблон чек-листа и заметки на полях

Чтобы вам было удобнее проверять готовность макетов к передаче в разработку, я подготовила чек-лист в Notion. Переходите по ссылке, создавайте копию и используйте в рабочих задачах. И не стесняйтесь кастомизировать инструмент под себя — пробуйте и делитесь обратной связью:)

И помните: далеко не все получается предусмотреть — это ок! Ни одна фича не была с первого раза выкачена в прод идеально. Если что — коллеги или пользователи подскажут вам, что нужно будет доработать.

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