✨ Саммари кейса
Проблема: В Комусе несколько команд разрабатывали свои компоненты независимо друг от друга. Компоненты хранились в разных файлах, привязанных к задачам в Jira. Найти и переиспользовать их было почти невозможно — приходилось открывать десятки файлов. Одни и те же кнопки и инпуты существовали в нескольких версиях, легаси копилось, визуальные расхождения множились.
Решение: Автор взял в оборот дизайн-систему и создал единое ядро — Core. В нём собраны дизайн-токены и базовые компоненты. Каждая команда получила свою библиотеку, но менять Core могли только библиотекари. Это разграничило зоны ответственности и сняло конфликты.
Запустили регулярные встречи, назвали систему «Скрепка», завели телеграм-канал для анонсов. Обновления публиковали через библиотеки Figma с версионированием.
Результат:
Решение: Автор взял в оборот дизайн-систему и создал единое ядро — Core. В нём собраны дизайн-токены и базовые компоненты. Каждая команда получила свою библиотеку, но менять Core могли только библиотекари. Это разграничило зоны ответственности и сняло конфликты.
Запустили регулярные встречи, назвали систему «Скрепка», завели телеграм-канал для анонсов. Обновления публиковали через библиотеки Figma с версионированием.
Результат:
- NPS вырос с −75 до 100
- Поиск компонента: с нескольких минут до секунд
- Сборка драфтовой страницы: с пары часов до 20 минут
- Пропали хотелки уровня «давайте кнопку сделаем оранжевой»
- Дизайнерам и разработчикам стало проще работать
Как я запускал Дизайн-систему скреПка
Что: дизайн-система
Где: комус
Роль: продуктовый дизайнер
Цель и задача
В Комусе есть несколько команд: витрина, личный кабинет, чекаут, ПКОЗ, мобильное приложение, поиск. У каждой — свои компоненты. Их много, все разные, со своим легаси. Каждая команда поддерживает свои компоненты, но найти их сложно.
Обычно всё сводилось к куче файлов, привязанных к задачам в Jira. В рамках задачи делался новый компонент, который потом сложно было переиспользовать — его просто не найти среди файлов.
Задача: создать единое ядро системы, разделить зоны ответственности и сделать так, чтобы компоненты можно было легко находить и переиспользовать.
Обычно всё сводилось к куче файлов, привязанных к задачам в Jira. В рамках задачи делался новый компонент, который потом сложно было переиспользовать — его просто не найти среди файлов.
Задача: создать единое ядро системы, разделить зоны ответственности и сделать так, чтобы компоненты можно было легко находить и переиспользовать.
Проблема
Проблем было несколько:
Это замедляло сборку страниц, плодило визуальные расхождения и создавало напряжение между командами.
- Нет единого источника. Каждая команда хранила компоненты у себя. Одни и те же кнопки и инпуты существовали в нескольких версиях.
- Легаси тянется за каждой командой. Компоненты обновлялись хаотично, старые версии оставались в файлах и продолжали использоваться.
- Поиск занимал много времени. Дизайнер не мог быстро найти нужный компонент — приходилось открывать десятки файлов.
- Переиспользование не работало. Новый компонент, сделанный под задачу, оставался в том же файле и не попадал в общую базу.
- Хотелки вместо стандартов. Каждая команда могла сделать «кнопку оранжевой и круглой» — и это уходило в прод.
Это замедляло сборку страниц, плодило визуальные расхождения и создавало напряжение между командами.
Что было сделано?
Core — ядро системы
Я взял в оборот дизайн-систему и начал приводить в порядок иерархию. Так появился Core — фундамент, в котором хранятся дизайн-токены (цвета, типографика, отступы, радиусы, тени) и базовые компоненты: кнопки, инпуты, чекбоксы, радио. Сейчас я бы все компоненты делал в отдельном файле, но тогда в этом не было необходимости.
В итоге все компоненты лежат в одном файле (повторюсь: сейчас на это табу, но тогда можно было).
В итоге все компоненты лежат в одном файле (повторюсь: сейчас на это табу, но тогда можно было).
Библиотеки команд
На встрече предложил простое правило: команда = файл. Так появились «подсистемы» ядра — библиотеки.
Каждая команда получила свою библиотеку с организмами. Приведу парочку примеров:
Дизайнер команды имел власть над своими организмами, но не мог менять Core. Библиотекари — я и моя коллега — отвечали за ядро. Это разграничение сняло конфликты: команды не спорили, чья кнопка главнее.
Каждая команда получила свою библиотеку с организмами. Приведу парочку примеров:
- Витрина – в ней лежали мини-карточки, фильтры для листинга, карусели для карточек.
- Чекаут – весь блок саммари, карточки товаров.
- Личный кабинет – бенто-блоки для главной лк.
Дизайнер команды имел власть над своими организмами, но не мог менять Core. Библиотекари — я и моя коллега — отвечали за ядро. Это разграничение сняло конфликты: команды не спорили, чья кнопка главнее.
Процессы и коммуникация
Запустил регулярные встречи по дизайн-системе. На них дизайнеры совместно обсуждали, чего в системе не хватает.
А обновления публиковали через библиотеки Figma — с версионированием и описанием изменений.
Завёл телеграм-канал который стал единой точкой входа: туда пушили анонсы, чтобы никто не пропустил новое. На канал подписались и разработчики и продакты.
А обновления публиковали через библиотеки Figma — с версионированием и описанием изменений.
Завёл телеграм-канал который стал единой точкой входа: туда пушили анонсы, чтобы никто не пропустил новое. На канал подписались и разработчики и продакты.
Замер результата
Проводил опросы по удовлетворённости работой с системой. Замерял NPS среди пользователей дизайн-системы — дизайнеров, продактов и разработчиков.
Раньше NPS был −75: большинство респондентов ставили низкие оценки и не рекомендовали систему (скорее ui kit чем систему) коллегам. После внедрения «Скрепки» NPS вырос до 100 — все опрошенные (15 человек) готовы её рекомендовать.
Раньше NPS был −75: большинство респондентов ставили низкие оценки и не рекомендовали систему (скорее ui kit чем систему) коллегам. После внедрения «Скрепки» NPS вырос до 100 — все опрошенные (15 человек) готовы её рекомендовать.
Результаты
Метрики:
Качественные изменения:
- NPS: с −75 до 100 (это чудо какое-то!).
- Поиск компонента: с нескольких минут до нескольких секунд.
- Сборка драфтовой страницы: с пары часов до 20 минут.
Качественные изменения:
- Скорость сборки выросла за счёт стандартизации и единого ядра.
- Пропали хотелки. Больше нет запросов уровня «А давайте кнопку сделаем оранжевой и круглой?».
- Дизайнерам стало легче. Появился положительный настрой, ушла рутина поиска.
- Разработчикам проще. Они знают, что все компоненты теперь собраны в одном месте и подчиняются единым стандартам.
- Прозрачность обновлений. Телеграм-канал стал единой точкой входа для новостей системы.
Что это значило для меня
Я не просто «разложил компоненты по полочкам». Я создали экосистему: Core как фундамент, библиотеки как зоны ответственности команд, «Скрепка» как общий язык.
Самым сложным было не разложить компоненты по файлам, а убедить команды, что это не отберёт у них власть. Пришлось объяснять: Core — это не контроль, это фундамент. Вы сохраняете свои компоненты, но теперь они не дублируются и не конфликтуют.
Один из дизайнеров сказал: «Раньше я тратил время на поиск актуального дивайдера. Теперь всё под рукой. И я уверен, что он не сломается завтра». Вот это главный результат.
Самым сложным было не разложить компоненты по файлам, а убедить команды, что это не отберёт у них власть. Пришлось объяснять: Core — это не контроль, это фундамент. Вы сохраняете свои компоненты, но теперь они не дублируются и не конфликтуют.
Один из дизайнеров сказал: «Раньше я тратил время на поиск актуального дивайдера. Теперь всё под рукой. И я уверен, что он не сломается завтра». Вот это главный результат.
👌 Я убедился: дизайн-система — это не только про компоненты, а ещё про доверие и предсказуемость. Когда дизайнер знает, где лежит дивайдер, и уверен, что он не сломается завтра, он думает о продукте, а не о том, как выжить в хаосе.
А стандартизация не убивает креативность. Она освобождает время для неё.