Когда дизайн-системой пользуется одна команда, плохой Developer Experience (DX) можно пережить. Но когда подключаются 3–5+ команд — DX превращается из «приятного дополнения» в важный фактор масштабирования.

Почему об этом мало говорят? • Размытая зона ответственности. Дизайнеры фокусируются на UX/UI, разработчики — на коде. DX живет на стыке, и часто за него просто некому отвечать. • Сложность метрик. Легко посчитать количество компонентов. Но как измерить когнитивную нагрузку или сложность интеграции решения в проект? • Иллюзия работоспособности. Если компонент можно использовать (пусть и через костыли), система считается живой. Боль разработчика становится фоновым шумом, пока не приведет к отказу от работы с дизайн-системой.

Если дизайнеру удобно собирать экраны в Figma, а разработчику приходится тратить часы на поиск пропсов или борьбу с документацией — система не работает. Она становится балластом. И чем больше команд, тем тяжелее этот балласт.

Что такое хороший DX в нашей практике?

1. Единый язык (Naming Consistency) Токен color-primary в Figma = color-primary в коде. Никаких btn-bg-active vs primaryButtonBackground. Разница в нейминге = когнитивная нагрузка × N команд. Мы синхронизируем имена на этапе проектирования, а не постфактум.

2. Документация как часть задачи Никаких внешних баз знаний. Документация пишется прямо в Figma и поставляется разработчику вместе с задачей. Разработчик получает всё необходимое в одном месте: контекст, спецификацию, состояние. Не нужно гадать, где искать актуальную инфу.

3. Обратная связь через RFC (Request for Comments) При росте числа команд фидбек в чатах превращается в хаос. Теперь любые предложения по улучшению DX проходят через RFC. Это дает прозрачность: каждая команда видит, что её боль услышана и будет решена системно, а не точечно.

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

DX — это не про только про «удобство». При масштабе — это про предсказуемость, скорость и удержание талантов.

А сталкивались ли вы с тем, что при росте команд DX деградировал? Как решали? Делитесь в комментариях!

#DesignSystem #DeveloperExperience #DX #Frontend #DesignOps #TechLead #UXUI #SoftwareEngineering #RFC #Scale