Когда впервые появилась идея чек-листа самопроверки макетов, я воспринял её как очередную бюрократию. Ещё один документ, который никто не будет читать. Казалось, и без него всё под контролем: опытная команда и выстроенные процессы. Но когда дизайнеров в моём направлении стало не семь, а пятнадцать, а количество продуктов увеличилось в три раза, стало ясно, что без простого инструмента контроля качества мы утонем в хаосе.
Привет, Хабр! Я Илья Гордеев, руковожу командой дизайна внутренних продуктов в X5 Tech. В этой статье расскажу, как мы создали чек-лист самопроверки, какие сложности прошли при внедрении и как он помогает экономить время на ревью, держать планку дизайнерам, а команде работать быстрее и чище.
Когда дизайнеров стало больше, а новичков приходило по двое сразу, они начали повторять одни и те же вопросы:
Где лежат мастер-макеты?
Где найти Tone of Voice и дизайн-систему?
Что считается «готовым» для передачи в разработку?
Параллельно в разных продуктах копились свои правила оформления: имена файлов, слои, состояния компонентов.
Переход с одного продукта на другой превращался в квест, даже опытным дизайнерам приходилось тратить время на то, чтобы просто разобраться, «как тут принято».
А на лида ложилась дополнительная нагрузка: проверка оформления, чистка макетов, ловля мелких ошибок. Это съедало часы, которые можно было потратить на развитие и стратегию.
Поэтому мы в отделе решили сделать инструмент, который:
снимет с лида рутину;
ускорит онбординг;
задаст единый стандарт качества.
Так родилась идея чек-листа.
Как создавался чек-лист
Первым делом решили посмотреть, что уже есть внутри компании. В каждой команде были свои решения: кто-то прописывал стандарты в Confluence, кто-то просто озвучивал требования на ревью, но единого списка не существовало, каждый работал по-своему. Поэтому чек-лист для дизайнеров пришлось создавать с нуля.
Обсуждения с коллегами-тимлидами помогли нащупать три главные «зоны боли»:
оформление файлов;
состояния экранов;
работа с компонентами дизайн-системы.
Дальше пошли копать глубже. Пересмотрели десятки шаблонов и открытых чек-листов, чтобы понять, кто и как решает похожие задачи.
Checklist Design — каталог чек-листов для компонентов, флоу и бренд-элементов.
Design System Checklist (open-source) — для планирования, построения и масштабирования дизайн-системы.
Design Review Checklist — шаблон проверки дизайна, покрывающий принципы, интерфейс, юзабилити и др.
Design System Checklist от Jacob Olenick — более детализированный чек-лист с шагами-звеньями: discovery, токены и компонентная база.
Design System Checklist от UXPin — чек-лист для создания эффективной и масштабируемой дизайн-системы.
Из этих источников мы собрали свой набор. Добавили пункты про компоненты, флоу, бренд-элементы, инвентаризацию паттернов, цвета и текстовые стили. Появился и важный блок «готовность дизайна»: структура, стандарты, риски, задачи.
Чтобы навести порядок, мы использовали GPT. Вот пример промта:
«Составь чек-лист самопроверки макета в Figma перед передачей в разработку для корпоративного продукта. Исключи банальные пункты и сосредоточься на техническом качестве».
Как обычно, чат выдал и дельные идеи, и мусор. Вроде: «Убедись, что выравнивание ровное». Зато из его ответов родилась структура — разделить весь список на три блока: оформление, UI-стек и дизайн-система.
Первый рабочий вариант не был коротким и простым. Стало очевидно, что главное — найти баланс. Если сделать мегасписок, его никто не станет использовать, а слишком короткий не решит проблем. Поэтому некоторые пункты мы намеренно выкинули:
«Проверь контраст текста по WCAG» — избыточно для внутренних интерфейсов, где палитра уже стандартизирована.
«Проверь ховеры всех кнопок» — бессмысленно при использовании компонентов из дизайн-системы.
«Добавь описание задачи в Notion» — хорошая практика, но не универсальная: у каждого продукта своя база знаний.
Другие пункты наоборот появились после пары реальных кейсов. Например, мы сталкивались с повторяющейся проблемой. Иногда дизайнеры передавали в разработку файл, где среди слоёв оставался процесс работы. После этого мы добавили пункт:
«В файле мастера в слоях нет примеров, процесса работы и прочего».
Вскоре мы подняли его в самый верх списка. Потому что он спасал от критических ошибок. А позже добавили к нему примеры и скриншоты.
После нескольких итераций у нас остался более компактный список. Всё лишнее убрали. Всё, что реально помогает — оставили.
Внедрение в команду
Запускали чек-лист по классике. Сначала дали его одной команде, чтобы посмотреть, что получится. Первые пару недель это был настоящий эксперимент. Мы проверяли, насколько чек-лист вообще применим к нашим задачам.
Сбор обратной связи
Запуск прошёл хорошо. Мы договорились, что перед отправкой макета в разработку дизайнеры пройдут по чек-листу и оставят комментарии. Напишут, в каких местах возникли вопросы, сложности или дубли.
После этого мы собрали команду и обсудили впечатления. Обсуждение заняло почти час. Мы разбирали, какие пункты оказались неясными, где формулировки слишком длинные, а что реально помогает в работе, а не просто выглядит красиво.
В итоге мы добавили и переработали ещё несколько пунктов.
Добавили проверку состояния «пустых экранов». Потому что эта проблема всплывала в каждом втором проекте.
Переписали пункт про типографику. Сделали его короче и привязали к токенам дизайн-системы Join.
Добавили пункт про состояние заполненной формы, чтобы проверять макеты не только «в нуле», но и при вводе реальных данных.
Но без споров, конечно, не обошлось.
Обсуждение в команде
Часть дизайнеров, как и я на старте, воспринимала чек-лист как контроль и бюрократию. У некоторых возникал вопрос вроде:
«Зачем тратить время на галочки, если я и так всё знаю?».
Поэтому мы договорились протестировать подход без давления. Просто пройтись по пунктам перед сдачей макета и посмотреть, действительно ли это экономит время на ревью.
Результаты не заставили себя ждать. Через пару недель скепсис начал проходить. Многие дизайнеры отметили, что чек-лист помогает не забывать про мелочи, особенно когда работа идёт под дедлайнами и внимание рассеивается. В какой-то момент это стало заметно всем, и отношение к чек-листу изменилось с настороженного на рабочее. Но вместе с этим возник новый вопрос: «Когда его необходимо использовать, а когда нет?».
Почему убрали обязательность
Изначально мы хотели сделать чек-лист обязательным шагом каждой задачи, но оказалось, что такой подход работает не везде. Внутренние продукты очень разные. В одном случае дизайнер вносит небольшие правки, а в другом – делает полноценный редизайн.
Поэтому мы оставили чек-лист инструментом самопроверки. Если задача крупная или идёт в разработку, дизайнер проходит по всем пунктам. В остальных случаях использует чек-лист по ситуации.
Со временем это превратилось в рабочую привычку. Никто не заставляет, но все используют, просто потому, что так быстрее и чище.
Практика использования
Чек-лист лучше всего проявил себя в трёх сценариях.
1. Мастер-макеты. Передача в разработку стала чище, без лишних артефактов.
Пункт чек-листа: «В файле мастера в слоях нет примеров, процесса работы и прочего, всё это смотри в оформлении проекта».
Как помогает
Раньше при передаче макета в разработку, в слоях часто оставались старые версии экранов, заметки или тестовые варианты. И разработчики тратили время, пытаясь понять, что из этого финальный вариант.
Теперь у нас работает простое правило. Мастер-файл — это «чистая зона», где остаётся только то, что реально идёт в прод.
Однажды дизайнер оставил в слоях прототипный экран, и в разработку ушёл не тот вариант. После этого случая пункт стал обязательным.
2. Онбординг. У джунов и мидлов появилась «шпаргалка», как делать правильно.
Пункт чек-листа: «Экраны подписаны и пронумерованы согласно порядку во флоу (1.1, 1.2, 2.1.1 и т. д.) с кратким описанием».
Как помогает
Для новичков это буквально карта навигации. Раньше они открывали файл и терялись, не понимая, где начало сценария и какие экраны связаны между собой.
Теперь по нумерации видно весь поток, а короткие подписи помогают быстро понять логику.
Один из участников команды поделился, что именно эта структура позволила за пару дней разобраться в чужом проекте. Тогда как раньше на это уходила неделя.
3. Унификация. Макеты разных продуктов стали выглядеть и структурироваться одинаково.
Пункт чек-листа: «Экраны собраны на компонентах дизайн-системы, отступы и скругления соответствуют токенам Join».
Как помогает
До чек-листа в продуктах встречались похожие, но всё же «свои» кнопки и поля. Когда дизайнер переходил на другой проект, приходилось тратить время, чтобы понять отличия от общего стандарта.
После внедрения пункта «только компоненты Join» визуальная консистентность заметно выросла. Даже если один дизайнер уходит и на его место приходит новый, он открывает файл и сразу видит знакомую структуру. Как будто «всё из одного мира».
Эффекты для команды:
нагрузка на тимлида по проверке снизилась ~на 30–40%;
уменьшилось количество возвратов задач;
по 1-1 стало заметно, что выросла самостоятельность дизайнеров.
Да, на старте чек-лист немного замедляет работу, но в долгую он окупается снижением количества правок и времени на ревью.
Как внедрить у себя
Если захотите запустить подобный чек-лист в своей команде, вот пошаговый сценарий, который сработал у нас.
1. Определите боли
Начните не с шаблона, а с проблем.
Соберите 3–5 типичных ошибок, из-за которых тратится время. Это может быть беспорядок в слоях, неочевидные состояния экранов или вопросы от разработчиков. Такой список станет реальной основой для будущего чек-листа.
? Ошибка, которую можно избежать: не пытайтесь сразу написать «идеальный чек-лист». Попробуйте сделать хотя бы минимально полезную версию, а не сразу «библию дизайна».
2. Соберите первый драфт
Используйте референсы. Это могут быть готовые чек-листы вроде Checklist Design, Design System Checklist или мой шаблон.
Посмотрите, какие пункты пересекаются с вашими болями, и адаптируйте под контекст ваших продуктов.
? Совет: попросите ChatGPT структурировать список, но не копируйте всё подряд. Отбирайте только то, что действительно решает проблемы вашей команды.
3. Протестируйте на одной команде
Запустите пилот на одном проекте.
Дайте дизайнерам пройтись по чек-листу при подготовке макета к разработке и соберите обратную связь. Зафиксируйте, что работает, что мешает, а чего не хватает.
? Совет: не делайте чек-лист сразу обязательным. Пусть команда привыкнет и увидит пользу на практике.
4. Проведите ревизию
После первых двух недель соберите всех участников и обсудите, какие пункты помогли, какие оказались лишними, а какие стоит добавить.
Удалите лишнее и упростите запутанные формулировки. Чем короче и яснее чек-лист, тем выше шанс, что его будут использовать.
5. Масштабируйте и закрепите
Расширьте использование чек-листа на другие команды.
Добавьте его в шаблон Figma-файлов или Wiki-документацию.
Закрепите практику на этапе подготовки к разработке. Принцип простой: передаёшь макет, проверяешь его по чек-листу.
? Совет: со временем чек-лист перестаёт быть инструментом контроля и становится культурой качества. Если команда использует его сама, значит, он работает.
Итоги
Чек-лист не претендует на идеальность. Он прежде всего закрывает визуально-технические ошибки: оформление файла, состояния экранов, работу с компонентами дизайн-системы. В этом его сила. Он должен быть простым и рабочим инструментом, а не перегруженной терминами и смыслами бесконечной простыней.
Сильные стороны:
убирает хаос в макетах, которые идут в разработку;
снижает количество возвратов задач;
ускоряет онбординг новичков;
задаёт единый стандарт для разных продуктов.
Но многое и не учтено, и это нормально! Любой чек-лист отражает конкретные боли команды и должен меняться вместе с командой и расти с продуктами.
Если у вас есть похожий опыт или свои находки, буду рад обсудить, как у вас решается вопрос качества макетов. Делитесь примерами и практиками в комментариях.
Почитать больше про системный подход к дизайну в X5 Tech:
Моя статья как создавался: «Единый стандарт дизайн-подхода в X5 Teсh»
Статья Георгия о цветах: «33 оттенка зелёного. Как мы проектировали темизированные палитры для внутренних интерфейсов Х5»
Стандарт по текстам от Саши: «Синергия дизайнеров и техписов: создание единых стандартов Tone of voice»
✌️ Авторский канал в Телеграм про дизайн — процессы, рост, управление