Как работать над дизайн-системой в одиночку: ключевые вызовы и лайфхаки
Бывают ситуации, когда весь проект ложится на одного человека. Тогда вы не просто дизайнер — вы сразу продакт, менеджер, аналитик и даже тестировщик. Любое решение, от выбора цвета до формата передачи токенов в код, проходит через вас.
Я оказался в такой ситуации, когда компания активно занималась ребрендингом. Нужно было обеспечить единый визуальный язык для веба и мобильного приложения, а ресурсов на отдельную команду не было. Не менее важным моментом, связанным с ребрендингом были сжатые сроки. В этой статье я расскажу, с какими задачами и вызовами сталкиваешься, работая над дизайн-системой в одиночку, и как их преодолевать без потери качества (и здравого смысла).
С какими задачами придется столкнуться
Проектирование архитектуры дизайн-системы: слои токенов, связки файлов, процессы взаимодействия с разработкой.
- Создание базовых сущностей: цветовая палитра, типографика, дизайн-токены. Это фундамент, без которого невозможно строить UI-компоненты.
- Разработка UI-компонентов: кнопки, поля ввода, модальные окна, выпадающие списки — все, что потом используется в продукте.
- Документация: описания компонентов, примеры использования, правила нейминга токенов.
- Коммуникация: встречи с дизайнерами и разработчиками, чтобы объяснять логику решений.
- Поддержка: исправление багов, добавление новых паттернов, обновление старых.
Фактически, это одновременно проектирование, управление, коммуникация, техническая интеграция и поддержка.
Ключевые вызовы
1. Приоритизация
Самая опасная ловушка — пытаться сделать все сразу. Я установил правило: сначала база (палитра, типографика, токены), затем простые UI-компоненты (кнопки, инпуты), а уже потом сложные паттерны (формы, карточки).
2. Коммуникация
Дизайнеры думают в терминах «цвета» и «стили», разработчики — в «переменных» и «классах». Нужно уметь переводить идеи с одного языка на другой. Например, цвет «button-brand-background-hover» в Figma для фронтенда может быть переменной $color-cmt-button-brand-background-hover-day: $color-green-l-60 в CSS.
3. Согласование терминологии
Нейминг токенов — один из главных источников путаницы. Для веба и мобильных платформ требования к названиям часто разные. Несогласованные названия приводят к дублированию и багам. Изначально планировал поддерживать один слой токенов компонентов – для разработки web и мобильного приложения. Но позже выяснилось, что разработкчики мобилки используют отличные нейминги от web, пришлось параллелить токены и использовать другой неймниг в мобильном приложении.
4. Параллельная поддержка разных платформ
В моем случае мы не смогли сделать единую базу токенов для веба и мобильного приложения из-за технических ограничений. Пришлось вести их параллельно и обновлять в двух местах.
Мой подход к работе в одиночку
- Начал с базы. Без палитры, типографики и токенов невозможно было двигаться дальше.
- Figma как центр. Все макеты и спецификации в одном месте, чтобы разработчики всегда имели актуальные данные.
- Отдельная документация для веба и мобайла. Да, это двойная работа, но иначе можно и «двух соснах заблудиться».
- Фиксация решений. Каждое согласованное изменение сразу заносилось в документацию. Это экономило часы на повторные обсуждения.
- Малые итерации. Внедрял систему кусками, например, сначала только кнопки и их состояния, потом только карточки и т.д.
Лайфхаки и приемы
- Timeboxing. Выделял конкретные часы на документацию, иначе она занимала весь день. Тут стоит оговориться. Так как сроки на разработку дизайн-системы были довольно сжатые, документацию приходилось писать довольно короткую, а то и, порой описывать короткие видео с описанием поведения компонента, чтобы сократить на нее время.
Уже после запуска проводил опросы среди разработчиков и дизайнеров по качеству документации, чтобы закрыть пробелы в документации.
- Чек-листы для себя. Например, список обязательных свойств для каждого токена или компонента.
- Систематизация токенов сразу. Лучше потратить неделю на обдуманную структуру, чем потом месяц на рефакторинг.
- Мини-демо. После каждого крупного обновления показывал команде результаты. Это повышало вовлеченность и помогало выявлять ошибки на раннем этапе.
- Визуализация прогресса. Использовал доску в Notion с колонками «В работе / Готово / Релизнуто». Это мотивирует.
Ошибки, которых стоит избегать
- Отсутствие обсуждения с разработкой на старте — потом придется переименовывать десятки токенов.
- Попытка сделать все сразу — итогом станет усталость и хаос в системе.
- Отложенная документация — если не зафиксировать решение сразу, оно забудется или исказится.
- Перегрузка себя — берите ограниченное число задач на неделю.
Что помогает не выгореть
- Делиться прогрессом — даже с небольшой аудиторией внутри компании.
- Отмечать маленькие победы — каждый новый компонент или улучшенный гайд — это шаг вперед.
- Комбинировать задачи — тестировать компонент и параллельно писать документацию по нему.
- Заложить буфер — на согласования и непредвиденные правки.
Настроить процессы среди дизайнеров – сделать мини-брифы, по которому дизайнер сможет составить задачу на доработку компонента. Благодаря такому подходу, я сократил достаточное количество времени на ресерч задачи.
Работа над дизайн-системой в одиночку — это марафон, а не спринт. Но при четких приоритетах, дисциплине и правильной коммуникации можно построить систему, которая переживет не одно масштабирование продукта.
Дизайн-система — это не про «красивые кнопки». Это про скорость разработки, консистентность и снижение техдолга.
📎 Чек-лист для дизайнера дизайн-системы
1. Определите базу (палитра, типографика, токены).
2. Согласуйте синтаксис токенов с разработкой на старте.
3. Выберите единый инструмент для документации и артефактов.
4. Фиксируйте все решения сразу.
5. Внедряйте систему итерациями.
Больше о работе команды в tg-канале: