Как я Делал Документацию Для Дизайн-системы RitM
Что: дизайн-система
Где: Wildberries
Роль: продуктовый дизайнер
Цель и задача
Нужно было сделать документацию по дизайн-системе, которой смогут пользоваться все — от джуна до сеньора.
В WB накопилась куча разрозненных компонентов и правил. Каждая команда работала по-своему, и это стало проблемой — продукты выглядели по-разному, новички тонули в хаосе, а опытные дизайнеры постоянно переспрашивали друг у друга «а как правильно?».

Классика жанра для больших команд:
  • Правила есть, но где они лежат — непонятно
  • Существующая документация написана так, что проще самому разобраться
  • Новый человек первую неделю только ищет, где что
В чём проблема?
В WB взялись за сложную задачу: сделать единую дизайн-систему для всех продуктов. Для этого появилась отдельная команда: «Отдел автоматизации дизайна» под руководством Владислава Ткаченко.

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

Проблема: систему разрабатывали параллельно с документацией. Дизайнеры уже работали и задавали вопросы, пока я писал. Что-то менялось, приходилось переписывать.
Ещё требование: структура должна быть гибкой. Разделы можно переставлять или менять местами без проблем.

Больше всего вопросов было про цвета. Какой оттенок где использовать, как красить макеты, какие правила применения.
Что было сделано?
Надоели мёртвые текстовые мануалы — собрал интерактивную документацию в Figma. Теперь всё работает, а не просто лежит.

Что сделал:
  • Разобрал старый хаос и выстроил структуру. Получилось 40+ гайдов — от базовых компонентов до сложных сценариев.
  • Разбил по разделам: компоненты, поверхности, стенды, обновления. Чтобы не искать нужное по всему файлу.
  • Собрал отдельный UI-кит для самой документации. Если учишь делать красиво, показывай красиво. Свёл все пропсы, названия и состояния в стринговые переменные — от enabled до SM. Всё лежит в одном месте, новые гайды собираются быстрее.
  • Сделал живые примеры. Кликаешь на компонент — открывается в новой вкладке и показывает, как работает в прототипе. Никаких статичных картинок.
  • Вместо очередной свалки инструкций — документация, которой удобно пользоваться.
Результаты
Получился инструмент, который собрал всю информацию о компонентах в одно место — с их состояниями и правилами использования.

Дизайнеры теперь не роются в файлах. Навигация работает интуитивно: от общего к деталям.
Обновлять стало проще. Изменился компонент — поправил ссылку или добавил примечание. Новые люди разбираются в проекте быстрее, изучая готовые паттерны.
Что это значило для меня
Этот проект оказался сложнее, чем я думал. Сначала казалось — ну что там, сверстать документацию. А по факту пришлось разбираться в продукте с нуля, копать глубже.
👌 Что я понял: дизайн-система — это отдельный продукт. Со своими пользователями (дизайнерами и разработчиками), со своими болями, со своей логикой.
Чему научился:
  • Системное мышление. Раньше кнопка была просто кнопкой. Теперь вижу связи: где используется, почему такая, как влияет на остальное. Пришлось выстроить архитектуру информации с учётом этих связей.
  • Понимание пользователя. Дизайнеру не нужны длинные объяснения. Ему нужно быстро найти: как работает, где код, какие варианты. Переделывал структуру три раза, пока не дошло.

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