Авито — дизайн-система как «внутренний продукт» с сильным слоем поддержки, токенизацией и курсом на публичность

дизайн-система — это не «верстать компоненты в Figma», а обслуживать коллег как пользователей, поддерживать их, управлять ожиданиями и поставлять изменения предсказуемо.

Главное

дизайн-система — это не «верстать компоненты в Figma», а обслуживать коллег как пользователей, поддерживать их, управлять ожиданиями и поставлять изменения предсказуемо.

Фокус: реальная «производственная» сторона дизайн-системы (поддержка пользователей, процессы и SLA), токены и семантические переменные, единый источник правды для платформ, автоматизация (скриншот-тесты, выгрузка токенов), документация и стратегия портала (в т.ч. внешняя).

Контекст: спикер пришёл в команду уже после того, как дизайн-система была создана и обоснована; детали защиты перед бизнесом не раскрыты.

Контекст

1. Контекст: открытость и «публичность по умолчанию»

Кейс подчёркивает важную тенденцию: дизайн-системы чаще других внутренних артефактов оказываются «снаружи» и могут быть открыты. Причина прагматичная: компоненты уже видны в продукте, остаётся описать правила и сделать витрину. Публичность рассматривается как способ упростить работу с подрядчиками, соискателями и партнёрами, а также как канал обмена компетенциями между компаниями.

Позиционирование и цели

дизайн-система — это не «верстать компоненты в Figma», а обслуживать коллег как пользователей, поддерживать их, управлять ожиданиями и поставлять изменения предсказуемо.

Состав системы

2. Дизайн-система «внутренний продукт»: пользователи — это коллеги

В отличие от внешнего продукта, у дизайн-системы пользователи находятся «внутри забора»: это дизайнеры и разработчики компании. Это меняет природу работы: обратная связь приходит быстро и напрямую, а ошибки и поломки становятся заметны мгновенно. Кейс подчёркивает, что значительная часть времени уходит не на создание новых компонентов, а на поддержку: ответы в чате, разбор тикетов, помощь с обновлениями и устранение багов.

4. Токены: медленный старт, большая подготовка и семантика

Токены начали внедрять не сразу: сначала команда наблюдала за практикой на рынке, экспериментировала и учитывала ограничения инструмента (в т.ч. ограничения по режимам/модам). Отдельно подчёркивается, что внедрение токенов — это большая подготовительная работа: нужно понять, какие значения реально используются, задать им смысловой контекст и подготовить перекраску тем.

5. Пример «техдолга»: замена логотипа и систематизация включений

Кейс показывает типичную боль «без системы»: даже простой ребрендинг превращается в поиск десятков ручных включений. В примере с обновлением логотипа команда нашла и систематизировала множество отдельных мест использования, после чего собрала их в единый компонент. Это не только ускоряет будущие изменения, но и превращает «хаос включений» в управляемый объект.

Документация

7. Документация и портал: «всеми способами» → к единой витрине

Документация ведётся разными способами (внутренние системы, Figma), но целевое направление — собственный портал. Портал важен не только как «место ссылок»: для полноценного использования нужны витрина компонентов, настройки, хороший поиск и удобная навигация. В интервью подчёркивается, что качество поиска — критично, иначе пользователи не будут заходить и система останется «часть здесь, часть там». Также обсуждается подключение нейросетевых механизмов для поддержки: если модель сможет отвечать хотя бы на часть вопросов, это кратно разгрузит команду.

Синхронизация дизайна и кода

6. Единый источник правды: выгрузка из Figma → платформы (автоматизация)

В кейсе описан курс на единый источник правды для всех платформ. Если сейчас каждая платформа может восстанавливать переменные «по образу и подобию», то целевое состояние — автоматизированная выгрузка контекста (переменные, семантика, токены) из Figma через серверный слой и регулярное обновление (например, раз в день). Это снижает необходимость ручных уведомлений и уменьшает риск расхождений между платформами.

Контроль качества

8. Как держать систему актуальной: обратная связь, тесты и SLA

Актуальность поддерживается сочетанием каналов. Во‑первых, автоматизированные решения для разработки (например, скриншот‑тесты), которые подсвечивают расхождения с эталоном. Во‑вторых, обратная связь от сообщества пользователей внутри компании (дизайнеры и разработчики), которая напрямую пополняет бэклог. В‑третьих, регулярные исследования удовлетворённости (опросы + глубинные интервью) и развитие процессов внесения изменений. Дополнительно упоминается стремление к понятным SLA по времени реакции на обращения и к выравниванию реализаций между платформами.

Масштабирование и внедрение

3. Принципы: удобство потребителей + консистентность и скорость

В основе принципов — ориентация на потребности пользователей дизайн-системы. При выборе между «красивой» сборкой компонента и удобством использования приоритет отдаётся удобству: если параметр сложно найти, пользователи начнут разбирать компоненты и снижать ценность системы. На бизнес-уровне цели остаются классическими: консистентность и снижение time-to-market.

Уникальные практики и «фишки» кейса

1. DS как внутренний продукт с коллегами-пользователямиГлавный сдвиг в голове команды: мы не «верстаем компоненты», мы обслуживаем коллег. Значительная часть времени уходит не на новые компоненты, а на поддержку — чат, тикеты, помощь с обновлениями, разбор багов. Обратная связь приходит быстро и напрямую.

2. Публичность по умолчаниюКомпоненты уже видны пользователям в продукте, поэтому нет смысла прятать правила и витрину. Открытая DS снижает трение с подрядчиками и соискателями, даёт канал обмена компетенциями с другими компаниями, привлекает внешних потребителей.

3. SLA на обращенияПрозрачные обещания: за 2–4 недели гарантированно получишь своё обновление. Делает внесение изменений предсказуемым для потребителей и снимает с них тревогу «когда же дойдут руки».

4. Скриншот-тесты как защита от рассинхронаАвтоматические скриншот-тесты подсвечивают расхождения с эталоном: если что-то разъехалось с макетом, команда видит сигнал сразу. Расхождения не накапливаются месяцами, а становятся триггером задачи.

5. Опросы удовлетворённости + глубинные интервьюРегулярный замер не только шкалой «удобно/неудобно», но и глубинное интервью по всему флоу работы с DS. Даёт качественные инсайты, которые в чате никто не напишет.

6. Семантические переменные на всех слояхВнедрение токенов пошло медленно и с большой подготовительной работой: сначала инвентаризация значений, потом семантика, потом темы. Результат — единый язык цветов в коде, дизайне и частично в сервисе.

7. MCP-сервер Figma как единый источник правдыЦель — автоматизированная выгрузка переменных, семантики и токенов из Figma через серверный слой. Платформы получают актуальный «слепок» раз в день без ручных уведомлений. Снижает расхождения и ручной труд.

8. Нейросеть поверх гайдлайнов в чате поддержкиСкормить все гайды нейросети и закрыть хотя бы 50% типовых вопросов автоматически — кратно разгружает DS-команду, освобождая её для реальной работы.

Выводы и принципы

9. Что можно перенять другим командам

Избранные цитаты