|
Professor Seleznov
|
Я продуктовый дизайнер с опытом более шести лет. В Лемана Тех работаю над продуктами ITSM-системы и касс.
В 2025 году я лидировал разработку чек-листа для передачи макетов в разработку. В этой статье кратко расскажу про процесс создания, сложности и ошибки, а также дам артефакт — сам чек-лист.
Чек-лист появился как побочный продукт более глубокой проблемы — потерь качества и времени на стыке дизайна и разработки. Важно: он изначально не задумывался как регламент или обязательное правило. Это был вспомогательный инструмент для снижения количества конфликтов, разночтений и улучшения коммуникации между ролями.
Это была не инициатива «давайте всё задокументируем» и не попытка внедрить стандарт ради стандарта. Была конкретная потребность — улучшить качество продукта на выходе.
От дизайнеров я часто слышал, что разработчик сделал «не совсем так», как на макетах. Копнул чуть глубже — а там компоненты не из дизайн-системы, проблемы с отступами, стилями и прочее. И такие проблемы встречаются очень часто в большинстве команд (спасибо, кэп). Напрягает, что это не пытаются решить: это проблемы, о которых все знают, но редко говорят о них, как будто это норма — так и должно быть.
Проблема
Формально процесс выглядел корректно:
- дизайнер передаёт макеты;
- разработка начинает реализацию;
- в процессе возникают вопросы;
- часть решений принимается на ходу.
На практике это приводило к системным симптомам:
- разработчики регулярно задают одни и те же вопросы;
- дизайнер злится, потому что «всё же есть на макетах»;
- часть решений принимается без участия дизайнера;
- итоговая реализация расходится с задуманной;
- правки обсуждаются, но не всегда доходят до реализации, чтобы не срывать сроки.
Ключевая проблема была не в компетенциях и не в «плохом дизайнере» или «невнимательных разработчиках». Проблема была в отсутствии общего понимания, что именно считается «достаточной передачей макетов».
Каждый действовал по-своему:
- дизайнер — из логики визуальной целостности и пользовательского флоу;
- разработчик — из логики реализации и технических ограничений;
- продакт и тимлид — из логики сроков и приоритетов.
И нигде это не сходилось в одну точку.
Решение
Я начал не с документа. Первым шагом стало формирование рабочей группы из дизайнеров и разработчиков. Задача была простой и сложной одновременно — исследовать реальный опыт обеих сторон.
Исследование и выравнивание контекста
В состав рабочей группы входили 10 дизайнеров и разработчиков разного уровня компетенций в своей роли. Вместе мы собирали референсы подобных чек-листов из других компаний и формировали список болей, которые есть у каждой из сторон при передаче макетов.
Работа была выстроена следующим образом: сначала каждый из участников фиксировал свои боли, потом мы все вместе обсуждали каждую из них и группировали по проблемам. Такие вопросы, как коммуникация в команде, споры при проведении дизайн-ревью, незнание горячих клавиш и функционала Figma, сразу были оставлены на потом, так как это большие темы, которые требуют погружения в каждую проблему.
По списку болей были составлены гипотезы, которые мы пошли проверять в глубинных интервью у разработчиков. Это были не просто интервью, а совмещённые с наблюдением. Сначала дизайнер наблюдал, как разработчик верстает по макету, задавал уточняющие вопросы. Далее дизайнер продолжал интервью по оставшимся гипотезам, которые не были выявлены при наблюдении.
Важно было понять не то, «как должно быть», а как есть на самом деле.
Проблемы со стороны дизайнеров мы сравнивали с проблемами разработчиков. Нужно было понять, это недоработка макета или другая проблема, связанная с коммуникацией, процессами внутри команды или с незнанием инструмента.
Опыт разработчиков
Мы разобрали:
- как они читают макеты и верстают по ним;
- где чаще всего возникают вопросы;
- какие решения им приходится принимать самостоятельно.
Выяснилось, что большая часть проблем возникает из-за отсутствия контекста решений:
- как компонент ведёт себя в разных состояниях;
- как ориентироваться в слоях и структуре;
- где допустимы отклонения, а где нет.
Опыт дизайнеров
Со стороны дизайнера картина была не менее показательной:
- уверенность, что «и так всё понятно»;
- слабое понимание документации дизайн-системы;
- собственная логика компонентов вместо системной;
- отсутствие ясности, какие вещи критичны для разработки;
- отсутствие согласованности, когда несколько дизайнеров работают над одним продуктом.
Формирование чек-листа
Только после этого появился чек-лист. Он не отвечал на вопрос, как правильно делать дизайн. Он отвечал на другой, более приземлённый вопрос.
Достаточно ли информации, чтобы разработка могла реализовать решение без догадок?
Чек-лист не проверял дизайн-решения, он проверял готовность к реализации и фиксировал:
- наличие всех состояний;
- проработку корнер-кейсов;
- понятность логики поведения;
- согласованность компонентов;
- технические ограничения и допущения.
В ходе исследования стало ясно, что часть проблем решается не процессами, а базовым выравниванием инструментального контекста. Многие разработчики просто не знали, как эффективно пользоваться Figma: от горячих клавиш и навигации по слоям до перехода к основному компоненту и применения всех фишек Dev Mode. После появления чек-листа мы провели встречи, где дизайнеры объясняли свой контекст принятия решений, а разработчиков обучали тонкостям Figma (горячие клавиши, логика работы компонентов, слои и отступы).
Ошибки и сложности
Ценность чек-листа — в рекомендательном характере: он опора, напоминание и точка сверки, а не обязательное правило или инструмент управления поведением команд. В командах, где взаимодействие между дизайном и разработкой уже выстроено, попытка навязать единый сценарий передачи макетов воспринимается как избыточный контроль и вызывает сопротивление. В таком виде чек-лист перестаёт помогать и начинает мешать.
Основные сложности и ошибки в процессе создания:
- сложная фасилитация больших групп, где каждый тянет одеяло на себя;
- крайне низкий отклик на формы и опросы (около 5 человек);
- частичное использование чек-листа (10–15 человек);
- необходимость постоянного «пиара» материала, чтобы он оставался на слуху;
- изначально лишний ресурс, потраченный на асинхронный сбор обратной связи вместо живого обсуждения.
Ключевые риски
- Превратить чек-лист в регламент —формальность убивает смысл.
- Использовать его как инструмент контроля. Если чек-лист — способ «поймать на ошибке», доверие исчезает мгновенно.
- Не обновлять. Продукт меняется, команда меняется — чек-лист тоже должен эволюционировать.
Выводы
Важным результатом стал не сам чек-лист. Исследование дало фокус, куда двигаться дальше. Стало понятно, что значительная часть проблем лежит вне документа. Со стороны разработчиков есть недостаток базовых знаний работы с Figma и непонимание ими логики дизайнерских решений. У дизайнеров отсутствует представление о реальных сложностях разработки, существует разрыв в коммуникациях между командами, работающими над одним продуктом, а также регулярный выход за рамки возможностей дизайн-системы. Чек-лист лишь подсветил эти зоны и задал направление для дальнейшей работы — обучения, коммуникации и выравнивания контекста.
Сейчас чек-лист больше помогает при онбординге новых сотрудников. Во многих командах со сложившимися процессами он способствует разрешению споров.
Если дизайнер не может передать решение так, чтобы его можно было реализовать, значит, решение ещё не закончено.
Чек-лист — лишь артефакт, а не волшебная таблетка. Он работает только в связке с живой коммуникацией и взаимным пониманием.
Чек-лист передачи макетов в разработку
1. Передача макета
Есть апрув от команды. Вы договорились, что макеты готовы и идут в разработку.
Сформирована правильная ссылка на макет.
Это не должна быть просто ссылка на документ. Ссылка должна вести на конкретный фрейм, откуда разработчику надо начинать смотреть макет.
2. Брейкпоинты
Макеты должны быть спроектированы с учетом всех брейкпоинтов дизайн-системы (добавьте основные брейкпоинты из вашей ДС в этот пункт).
Брейкпоинты могут быть изменены по согласованию с командой.
Возможно в вашей команде на основе веб-аналитики выбраны другие популярные экраны. Или вы проектируете интерфейс под конкретные устройства, например, кассы.
3. Компоненты
В макетах использованы компоненты из дизайн системы, если они отвечают потребностям функционала.
Полезные ссылки (сюда нужно добавить ссылки из вашей ДС):
- библиотека веб-компонентов в Фигме
- библиотеки мобильных компонентов в Фигме
- Storybook и Github — готовые компоненты в коде
Если есть различия компонента от логики в документации, нужно подсветить это в макетах.
Ссылки на корпоративные ресурсы — куда писать, если есть вопросы по компонентам.
Если используются кастомные компоненты
- Новый компонент должен быть создан с учётом общепринятых паттернов;
- Описана логика работы. Дана ссылка на описание или показано на макете стрелкой;
- Добавлены все состояния: Default, Hover, Pressed, Disabled, Focused;
- Учтены пограничные состояния. Например, в текстовом блоке минимум/максимум символов, прописаны ограничения по кол-ву символов в полях ввода, учтены и описаны самые длинные и короткие тексты;
- Учтены размеры всех целевых экранов пользователей;
- Компоненты стилизованы под дизайн-систему.
4. Пустые состояния форм и корнер-кейсы
- Учтены на основных разрешениях экранов (см. пункт 2);
- Отрисованы состояния переполнения контейнеров;
- Сделаны шиммеры (скелетоны) или лоадеры экранов и блоков: определён с командой порядок загрузки частей страницы. Если нужно, отрисована поэтапная подгрузка или заглушки;
- Показаны состояния скролла;
- Описаны состояния валидации в формах ввода текста и написан текст к ошибкам валидации;
- Описан текст к снэкбарам: успех / неуспех;
- Спроектированы экраны ошибок 4ХХ, 5ХХ;
- Проведена редактура текста: все формулировки проверены и исправлены согласно Редполитике, макеты содержат актуальный и реальный текст или максимально приближенный, в тексте нет ошибок.
5. Слои
Нет лишних вложенностей
✅ Правильно
❌ Неправильно
Нет скрытых слоёв, если они не скрыты свойством компонента Boolean
👀 Пример
Не использованы Group внутри компонента без необходимости (кроме иллюстраций)
Иллюстрации обёрнуты во фрейм, без дробных значений. Растровые изображения нужно также оборачивать во фрейм.
☑️ Допустимо
❌ Неправильно
6. Консистентность
В макетах единая консистентность на всех экранах продукта
- Отступы;
- Скругления углов;
- Стили цветов и шрифтов;
- Одинаковая логика работы элементов;
- Например, поведение кнопок, раскрывающегося списка, навигации, кастомных компонентов или виджетов должно быть одинаково на всех экранах.
Примечание
Особенно у команд, которые взаимодействуют друг с другом, реализуют отдельные части большого продукта. Например, когда много продуктовых команд и много микрофронтов, нужно учитывать перечисленные выше пункты между командами.
7. Описание макетов
В макете четко выделена часть, передаваемая в разработку
- Отмечена актуальность: какой экран или элемент актуальный, а какой ещё в работе;
- Экраны и их элементы рекомендуется передавать в сегменте, который можно целиком передать в разработку;
- По договорённости с командой разработки макет можно разделить на итерации и каждую итерацию поместить в свой сегмент.
Должен прослеживаться сценарий с пошаговым объяснением действий пользователя
Рекомендуется сегментировать: должны быть выделены части по JTBD или по задаче. Видеоописание и анимированный прототип сценария приветствуется, но не исключает необходимости описания сценария или конкретной задачи в самом макете.
Каждая секция — это отдельная задача / сценарий / JTBD / user flow.
Описание задачи / сценария / JTBD / user flow
Пояснения располагаются рядом с местом, к которому они относятся
- Пояснения могут соединяться стрелками с вариантами, другими пояснениями и экранами, важно, чтобы они были чёткие и по делу;
- В пояснения можно заносить информацию, взятую из интервью или технических ограничений: как должно работать, как должно мапится, откуда должна приходить информация, чтобы быть корректно реализованой.
8. Размеры
Размеры компонентов и вложенных элементов выражены целыми значениями. Объекты, которые имеют дробные значения (например, иконки или изображения), должны находиться в контейнерах.
✅ Правильно
❌ Неправильно
Расстояния между элементами и сами элементы должны быть кратны 2 px.
Иначе на проде элементы могут отображаться некорректно.
9. Цвет и стили
Все стили цвета указаны переменными.
✅ Правильно
❌ Неправильно
Все шрифты указаны переменными.
✅ Правильно
❌ Неправильно
Если используется шрифт или цвет не из дизайн-системы, создайте локальные стили и пометьте это для разработчиков.
10. Анимация
- Если анимацию нужно реализовывать разработке, то она должна быть покадрово собрана и описана, или нужно передать собранный LottieFile;
- По договорённости с командой разработки можно для примера найти на другом ресурсе анимацию, которую надо реализовать.
Важно!
Не вносить правки в макеты, которые отданы в разработку!
Если всё же требуются изменения, то лучше сделать следующей итерацией. При этом нужно уведомить об изменениях разработку и дать новую ссылку на макеты.
-Источник
|
