Перейти к основному содержимому

Работа с дизайнерами

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

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

Что нужно понимать​

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

Основные темы​

До реализации​

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

Общий словарь​

  • Одинаковые названия токенов и компонентов с обеих сторон
  • Дизайн-система, на которую могут сослаться обе стороны
  • Шкалы отступов и типографики вместо произвольных значений
  • Умение заметить, что макет и код разошлись

Передача в разработку​

  • Что должно быть в передаче помимо самих экранов
  • Поведение, которое существует только у кого-то в голове: анимация, фокус, пустое состояние, ошибка
  • Различия между платформами, о которых договорились, а не придумали на ходу
  • Где задавать вопросы, чтобы ответ не потерялся в переписке

Обратная связь​

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

Постоянно​

  • Держать реализацию и дизайн в согласии, пока меняются оба
  • Возвращать дизайнеру то, что аналитика говорит о дизайне
  • Строить дизайн-систему вместе, а не параллельно

Уровни​

УровеньКак это выглядит
JuniorРеализует макеты точно и спрашивает, когда чего-то не хватает.
MiddleДо начала работы проверяет макет на пробелы, заранее поднимает вопрос стоимости, сохраняет верность макету во всех состояниях и на всех размерах.
SeniorРаботает с дизайном на уровне системы, а не отдельных экранов, договаривается о балансе замысла и стоимости и не даёт макету и коду разойтись.

Практика​

Для начала​

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

  • Сломайте экран контентом Реализуйте экран, а потом подайте в него самый длинный реалистичный текст и самый крупный размер шрифта.

  • Называйте вещи одинаково Сравните названия компонентов в макете с теми, что в коде. Приведите их к одному виду.

Глубже​

  • Разменяйте стоимость на замысел Найдите дорогую деталь, разберитесь, зачем она нужна, и предложите более дешёвый способ добиться того же.

  • Проведите дизайн-ревью Покажите собранную версию и соберите замечания, пока ещё есть время что-то сделать.

  • Соберите компонент вместе За один заход определите с дизайнером варианты и API общего компонента.

Проверьте себя​

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

Материалы​

  • Design systems 101 — Nielsen Norman Group о том, что входит в дизайн-систему и кто её поддерживает; именно этот артефакт изначально снимает большую часть трений при передаче в разработку.
  • Design Systems Handbook — бесплатная книга, написанная сразу для обеих сторон. Здесь важны главы про общий словарь и про управление системой.
  • Material 3 foundations — общий источник, на который может сослаться и дизайнер, и разработчик в споре об отступах или анимации; на этом многие споры быстро и заканчиваются.
  • Refactoring UI — чтобы разработчик мог обсуждать визуальные решения на языке дизайнера, а не только реализовывать их.
  • Figma Dev Mode — механика передачи макетов, которой пользуется большинство команд, включая то, как токены и компоненты попадают в код.