21 день против 14: как единственный дизайнер выбил ресурсы на развитие дизайн-системы

В 2020 году я был единственным продуктовым дизайнером в B2B/B2C SaaS-команде, и компания не собиралась нанимать второго. UI-кит в Figma, который мне достался, не совпадал с продакшеном. Фронтенд и QA это устраивало: компоненты стилизовали на лету, вёрстку проверяли на глаз, а несогласованность они блокером не считали.

Мне нужна была дизайн-система. Никто её не просил. Так я получил поддержку CEO и CTO и довёл adoption до 100%.

Сначала аудит, потом пилот

Я прошёл продукт экран за экраном и собрал инвентарь в Figma, со скриншотами и заметками. Приоритет задавала частота использования, поэтому первые компоненты достались тому, что больше всего тормозило фронтенд.

Учебный сценарий внедрения замораживает работу над фичами, а мне как единственному дизайнеру это было не по карману. Поэтому каждая новая фича стала пилотом. Я собирал компоненты внутри живых задач и проверял их в реальных условиях. Ещё я синкался с фронтенд-лидом, чтобы договориться об именах компонентов и интерактивных стейтов.

Питч: одна задача, измеренная дважды

В конце 2020 года я показал результаты на синке с руководством. Одна задача занимала около 21 рабочего дня до системы. Задача того же типа на новых компонентах заняла около 14 дней.

CEO утвердил роадмап, потому что метрика была понятной и переводилась в деньги. CTO поддержал архитектуру: цвета, стили текста и выравнивание со Storybook, где Figma и Storybook служат единым источником правды. Мне официально выделили 6 часов в неделю на систему.

Запрос был небольшой: 6 часов в неделю, без новых людей и без паузы в продукте. Доказательства уже лежали в продакшене.

Разработке и QA нужен был свой аргумент

CEO убедили цифры. Фронтенду и QA надо было увидеть всё на реальных фичах, слайда для этого не хватило бы.

Для разработчиков система означала готовые компоненты вместо кастомного CSS на каждый экран. Для QA она означала меньше попиксельных проверок вёрстки. Фронтенд-лид стал главным сторонником системы в своей команде, а консистентность как база для UX стала общей целью.

После запуска я драйвил adoption через design review сборок перед передачей в QA.

Сейчас система обслуживает 4 фронтенд-разработчиков, 4 дизайнеров и 3 QA-инженеров. Time-to-market сократился примерно на 30%, а команда экономит около 100 инженерных часов в месяц на сборке UI. За 5 лет это 6000+ часов разработчиков, без учёта дизайна и QA.

Питч в пяти ходах

В таком порядке я бы повторил его снова.

1. Измерить одну реальную задачу дважды. Взять задачу, которую бизнес уже знает, фичу среднего размера, сделать один раз по-старому и один раз на своих компонентах и сравнить срок поставки. Дни согласуют, а процент консистентности нет.
2. Запустить пилот внутри живой работы. У сайд-проекта нет цифр, потому что им никто не пользуется. Пилот внутри фичи их даёт и не блокирует роадмап.
3. Просить часы. Я просил 6 часов в неделю. Легко согласиться, легко проверить через квартал, и после первого результата можно расти.
4. Подготовить отдельный аргумент для каждого в комнате: стоимость для CEO, архитектуру для CTO, меньше кастомного CSS для разработчиков, меньше проверок вёрстки для QA.
5. Найти сторонника в разработке до встречи. Имена я согласовал с фронтенд-лидом до питча.

В моём роадмапе было пять шагов: базовая линия, ядро компонентов, ключевые паттерны, выравнивание с кодом, документация. Решение приняли по 21 против 14.

Что изменилось с Claude Code

К 2023–2024 годам система срезала time-to-market примерно на 30%, и на это ушли годы работы. Сейчас тот же результат получается гораздо быстрее. С Claude Code я могу зайти в Figma и собрать дизайн-систему в десятки раз быстрее, чем раньше. Правила пишу я и всё проверяю руками. То, что занимало полгода, можно сделать примерно за неделю.

Питч остаётся тем же: измерить одну задачу дважды и попросить часы. Цифры просто появляются раньше, поэтому разговор с CEO и CTO можно провести на второй неделе, а не на втором году.