Собрал мультибрендовую дизайн-систему аж для семи брендов

Статья про дизайн-систему в Фигме — местами будет терминология этого инструмента, основные понятия объясняю по ходу.

Я пришёл в компанию, где было семь брендов. С улицы и не скажешь, что под ними один шаблон — над разрозненностью поработали как следует: свои фоны, свои цвета, своя подача. Но в основе лежал один и тот же шаблон. А внутри файлов структуры не было никакой. Ни связи между брендами, ничего. Всё на группах и фреймах. Компоненты почти не использовались: под каждую новую задачу, в каждом новом файле кто-то рисовал новую кнопку — вот прямо под этот раздел. Ни о какой системности речи не шло. Ни внутри бренда, ни между брендами.

Смотреть на это спокойно я не мог — и не из брезгливости. Я видел, сколько это стоит. Нарисовал флоу KYC один раз — иди рисуй его ещё семь, и каждый раз почти с нуля, потому что переиспользовать нечего. Вот где горело время.

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

Я не ждал, пока систему закажут. Я доказал, что без неё нельзя

Дизайнерская работа превратилась в подмечательство

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

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

Случайно наткнулся на то, на чём можно строить

Я случайно узнал про Figma Variables и начал тестировать. Собрал тестовые микро-экраны и стал проверять: а может ли по переключению меняться цвет? радиус? текст? Оказалось — может. И в этот момент я понял, что на этом можно строить систему.

Дальше я перерыл всё. Весь интернет, курсы, сидел в тематическом чате в телеграме. Не за вдохновением — мне нужно было убедиться, что проблема не локальная и что подход рабочий. И там же дошёл до главного: дизайн-система — это не библиотека компонентов. Это другой процесс работы. Компоненты — то, что видно сверху. А под ними лежит процесс, в котором экран рисуется один раз и расходится на все бренды сам.

Решение было не озарением, а счётом

Вся арифметика была простая. Если работа на годы вперёд — это рисовать каждый флоу по семь раз вручную, то дешевле один раз построить так, чтобы экран рисовался один раз и масштабировался на все бренды автоматически. Скорость и масштабирование — вот что система покупала на самом деле. То, что вместе с этим исчезал целый класс ошибок, было приятным бонусом, а не целью.

Одна страница, которая поменяла всё за секунду

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

Переключаю режим — и страница меняет всё, что нужно, разом: радиусы кнопок, цвета кнопок, цвета фонов, все цвета, все шрифты. За секунду. То, на что в старых файлах уходила неделя ручной работы по семи брендам.

Я показал это лицу, принимающему решение — CPO. Демка оставила сильное впечатление: разговор сразу перестал быть теоретическим. Это и был зелёный свет.

Как я продал — не «красиво», а минус неделя

Дизайн-системы обычно продают как единообразие и красоту. Это их и хоронит — разговор сразу уходит в спор о вкусе.

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

Система не отменяла работу над самим решением. Она отменяла его ручное размножение по семи брендам — а это и был основной расход.

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

Фундамент: отступы и рождение токенов

Первый же экран показал главное: старую систему чинить бессмысленно. От неё оставалась только идея — как корабль, который перестроили целиком, а название то же. Надо было строить заново, с правильным фундаментом. И первый вопрос фундамента — самый скучный. Размеры.

Сначала размеры

Когда я прогнал флагманский бренд через аудит, оказалось, что значений отступов в нём — сотни. 13, 18, 22, 30 пикселей. Не потому что так задумано, а потому что каждый ставил на глаз.

Я положил в основу одну шкалу:

  4  8  12  16  20  24  32  48  64

До 24 — кратно четырём, выше — кратно восьми. В слое отступов других чисел не существует: нет значения в шкале — поставить его нельзя.

Я не доказывал, что эта шкала единственно правильная. Мне нужна была такая, которую легко держать в голове, легко отдать в код (8px чисто переводится в rem при базовом размере 16px, без дробных пикселей) и трудно нарушить случайно. На мелких расстояниях точность давала четвёрка, на крупных порядок держала восьмёрка. Похожая логика есть в Bootstrap, Material, Polaris. Я не изобретал велосипед — я перестал давать выбор.

Типографика и устройства — тем же ножом

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

С устройствами то же. По аналитике аудитория была в основном мобильной, поэтому базовые стили я делал сначала под мобайл, остальное достраивал вверх. Три ширины:

Три ширины вместо пяти-шести брейкпоинтов у больших фреймворков — меньше мест, где макет может разъехаться.

Primary 500, который развалил систему

Дальше я взялся за цвет — и сделал ошибку, которая кажется логичной, пока у тебя один бренд.

Я покрасил кнопку в Primary 500. И карточку — тоже в Primary 500. На флагмане всё сходилось: кнопка и карточка действительно были одного оттенка.

А на втором бренде связь рассыпалась. Кнопка должна была остаться брендового цвета, а карточка — уйти в другой акцент. Карточка тут уже не Primary 500, а что-то вроде Secondary 300. И вся система поехала.

Дальше пошёл каскад. Меняю Primary 500 — вместе с кнопкой едет карточка. Чиню карточку отдельно — появляется локальный костыль, а следом отъезжает третий элемент, который на первом бренде случайно вышел того же оттенка. В какой-то момент стало ясно: я управляю не цветом. Я управляю совпадением, которое было верным ровно для одного бренда.

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

Грамматика имени: один раз и навсегда

Так я пришёл к семантике. Я зафиксировал единую грамматику имени, по которой строится каждый цветовой токен в системе:

• свойство — bg (background, фон) или fg (foreground, то есть текст, иконки и прочий контент поверх фона);

• тон — роль цвета: brand, neutral, positive, negative, warning, info;

• поверхность — base или inverted (про это ниже);

• ступень — место на шкале 0–999, где 500 — середина;

• состояние — default, hover, focus, disabled и так далее.

Цвет кнопки теперь не Primary 500, а роль: bg.brand.base.500.default. Это не «тот самый синий» — это роль, на которую каждый бренд подставляет свой оттенок. И 500 тут уже не называет цвет: это середина шкалы внутри роли. Ошибка Primary 500 была не в числе. Она была в том, что имя притворялось назначением.

Три уровня токенов

Из этой идеи выросла трёхуровневая структура. Я дошёл до неё своими граблями, а потом увидел, что так устроены зрелые системы — IBM Carbon, Polaris, Spectrum.

Уровень 1 — примитивы. Сырые значения: primitive.white.500 = #FFFFFF. В дизайне напрямую не используются никогда — только как сырьё для ссылок.

Уровень 2 — семантика. bg.brand.base.500.default ссылается на примитив. Это основной слой, в котором работает дизайнер: тут живёт назначение, а не оттенок.

Уровень 3 — компонентный. То же имя, но с префиксом компонента: button.bg.brand.base.500.default. Понадобился он не сразу. Пока я делал первый бренд, я всё красил в семантику. А когда другому бренду кнопка потребовала свой, нестандартный цвет — я завёл отдельный токен только под кнопку. Технически это просто: создаёшь новые переменные и переподключаешь их в компоненте.

Правило, к которому я пришёл: компонентный уровень — только когда без него никак. Сомневаешься — семантика. Каждый лишний уровень потом поддерживаешь ты сам: больше токенов — больше мест, где система расходится.

Светлое, тёмное и пара base / inverted

Светлый бренд я собрал. Следующий оказался тёмным — и тут система пошла на новый виток. Был тёмный текст на светлом фоне, а теперь всё наоборот: светлый текст на тёмном.

Тут легко сделать ошибку — зашить «тёмный фон, светлый текст» прямо в компоненты тёмного бренда. И получить два разных набора компонентов: одни для светлых брендов, другие для тёмных. Тупик: каждый новый бренд — новый набор.

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

Так появилась пара base / inverted — как свойство компонента:

• base — компонент на «родной» поверхности (в светлом бренде это тёмное на светлом);

• inverted — компонент на контрастной поверхности (светлое на тёмном).

У компонента есть булево свойство inverted: true/false. false — берёт base-токены, true — inverted. Никаких «если бренд тёмный — возьми другой цвет». Компонент вообще не знает, в каком он бренде и какого цвета фон под ним. Он знает только одно: на какой поверхности стоит — base или inverted. Реальный цвет подставит система токенов.

Для светлого бренда base и inverted разрешаются в разные значения:

bg.neutral.base.500.default      →  primitive.white.500bg.neutral.inverted.500.default  →  primitive.brown.800fg.neutral.base.500.default      →  primitive.brown.800fg.neutral.inverted.500.default  →  primitive.white.500

А вот ход, который всё сшил. Что делать с тёмным брендом, у которого поверхности и так тёмные? Заводить под него отдельную логику — значило вернуть компоненту знание о бренде. Вместо этого у тёмного бренда base и inverted разрешаются в одно и то же значение:

bg.neutral.base.500.default      →  primitive.grey.800bg.neutral.inverted.500.default  →  primitive.white.500fg.neutral.base.500.default      →  primitive.grey.800fg.neutral.inverted.500.default  →  primitive.white.500

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

К этому моменту система уверенно держала пару брендов. Я выдохнул — и сел считать комбинации. И тут арифметика перестала сходиться.

Стена в 28 тем и как Token Studio спас проект

Один бренд — это не одно оформление. Любой бренд может быть светлым-классическим, тёмным-классическим, светлым-VIP или тёмным-VIP. Две независимые оси — тема и класс — дают четыре оформления на бренд. На семь брендов это двадцать восемь комбинаций. А Figma на тот момент давала четыре мода на коллекцию.

Дальше обычно идёт вопрос: ну заплати за тариф подороже. Я проверил. На Enterprise лимит был сорок. И даже это меня не спасало: двадцать восемь я закрывал, но бренды росли и будут расти — рано или поздно я упёрся бы в сорок так же, как уперся в четыре. Покупать Enterprise ради временной отсрочки никто бы не стал, да и проблему он не решал. Дело было не в числе модов. Дело было в самой модели.

Почему несколько коллекций не спасали

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

Не работает. Возьми один токен — bg.brand.base.500.default. Он должен разрешаться в своё значение для каждой комбинации: бренд 1 светлый-классический, бренд 1 тёмный-классический, бренд 1 светлый-VIP, бренд 1 тёмный-VIP, дальше бренд 2 со всеми четырьмя, и так все двадцать восемь. Это один и тот же токен, живущий в двадцати восьми модах.

Разнести его по коллекциям — значит разорвать его на куски. В одной коллекции он один токен, в другой — уже другой, и связь между ними теряется. А мне нужен был именно один токен, который сам подставляет нужное значение под нужную комбинацию. Несколько коллекций этого не дают — они дробят то, что должно быть единым.

Ложный путь: плагины-переключатели

Тогда я пошёл искать плагин — как почти все, кто упирается в лимит инструмента. Плагинов, которые обещали обойти лимит, было несколько. Идея у всех общая: дублировать коллекции и переключать значения на лету.

Сначала всё выглядело победой. Макет переключается, цвета меняются — работает. А потом я поправил мастер-компонент и увидел, что часть экранов не обновилась.

Под капотом было вот что. Переключая тему, плагин переписывал значения прямо в инстансах. Инстанс формально оставался инстансом, но переписанные значения превращались в локальные переопределения. И следующая правка мастера в эти места уже не доходила. Для системы это то же самое, что навсегда потерять связь с мастером.

А вся система держалась ровно на обратном: мастер один, инстансы тянут из него. Плагины предлагали разменять это на красивое переключение. Мне нужна была не картинка на секунду. Мне нужна была живая связь с мастером.

Если инструмент переписывает значение в инстансе, он выигрывает секунду на переключении и проигрывает систему на следующем обновлении.

Костыль поверх нативных переменных отпадал. Нужен был не переключатель, а другой источник истины.

Token Studio: не больше колонок, а другая модель

Token Studio я выбрал не потому, что у него больше функций. Он менял саму модель сборки темы.

В нативной Figma мод — это строка в плоском списке внутри коллекции. В Token Studio тема — это пересечение групп. Группа «Бренд», группа «Оформление» (классика/VIP), группа «Устройство» — и любая комбинация собирается из них, как точка в кубе. Те самые оси, которые в Figma не пересекались, тут были устроены прямо: включаешь нужные наборы под нужный мод — и тема готова.

И, важнее, источником истины переставала быть Figma. Токены жили в JSON — отдельно от макетов, под версионированием. А Figma становилась потребителем: местом, где токены применяют и проверяют, но не местом, где они рождаются.

Git, экспорт в код, больше типов токенов, чем нативные — всё это шло бонусом. Но причина была не в этом. Причина была в модели: темы стали собираться из пересечения осей, а не лежать плоским списком модов.

Цена решения: миграция трёхсот тысяч слоёв

Выбрать Token Studio оказалось легче, чем перевести в него старый файл.

Вся система была построена на сырых значениях и нативных переменных. Чтобы она поехала на токенах, каждый слой нужно было переподключить заново. Слоёв с цветами было порядка трёхсот тысяч. Вручную это не делается — физически.

Спас плагин Apply Tokens. Он, кажется, от тех же разработчиков, но я узнал о нём абсолютно случайно, перерыв кучу материалов по теме. Он сопоставлял значения слоёв с подходящими токенами и проставлял их пачками. Работает не идеально — но именно им я перенёс весь бренд. Без него я просто не представляю, как переподключал бы триста тысяч слоёв поштучно.

Это был не один клик, а недели работы. Но это была работа, которую вообще стало возможно сделать.

Почему Token Studio, а не натив — даже сегодня

Это не была временная подпорка под лимит Figma. Это был архитектурный выбор, и я бы повторил его сейчас, когда Figma подняла лимиты.

Натив решает вопрос тем внутри Figma. Но дизайн-система живёт не только в макетах — она должна доходить до кода, иначе остаётся красивой библиотекой. Token Studio держит токены в JSON под версионированием: один и тот же источник лежит готовым и для дизайна, и для фронтенда. Именно это превращает систему из набора компонентов в продукт, на котором работает вся команда.

Token Studio решил проблему тем. Но обнажил проблему веса: после миграции файл стал тяжёлым — загрузка тянулась, переключение тем подлагивало, правка компонента отзывалась задержкой. Одна большая библиотека с семью брендами внутри — это была следующая стена.

Компоненты без бренда, бренды без связей

Токены уехали в Token Studio, дизайны остались в Figma, и теперь всё это надо было разнести по файлам так, чтобы семь брендов не топили производительность и не ломали друг друга. Вопрос был уже не про токены — он был про то, как разложить систему по файлам. И первое решение тут звучит как ересь.

Самое странное решение: общая библиотека без токенов

Я убрал из общей библиотеки компонентов все токены. Цвета в ней — голый hex.

Звучит дико: вся система на токенах — а кнопки в библиотеке покрашены сырыми значениями. Но иначе не работает. Если зашить в общий компонент брендовую переменную, эта переменная уже принадлежит одному конкретному бренду. И любой другой бренд, импортируя ту же кнопку, унаследует не форму, а чужую ссылку на цвет.

Поэтому общий компонент не должен знать о бренде ничего. Его дело — форма: структура, состояния, размеры, поведение. Голый hex держит компонент нейтральным. Цвет приходит позже, уже в брендовом файле.

Library хранит форму. Брендовый файл подставляет цвет.

Два файла, две роли

Отсюда выросла двухфайловая модель. Каждый бренд обслуживают ровно два файла.

Library — общие компоненты: кнопки, поля, чекбоксы, переключатели, теги, алерты, тултипы, модалки. Все их состояния и эффекты — ховер, фокус, нажатие, неактивность, тени. Текстовые стили — но только структура: семейство, начертание, размер, интерлиньяж, без брендовых шрифтов. Цвета — голый hex. Ни переменных, ни брендовой логики. Library вообще не знает, что такое бренд. Это фабрика формы, а не готовый крашеный экран.

Брендовый файл (свой на каждый бренд) — Figma-переменные, выгруженные из Token Studio (отдельно бренд, отдельно устройства); брендовые компоненты, которые принадлежат только этому бренду; и сами дизайны — экраны и флоу.

Когда дизайнер тащит кнопку из Library в брендовый файл, она приходит нейтральной, как лежала в Library. Дальше Token Studio применяет к ней токены бренда: структура наследуется из мастера в Library, цвет привязывается к переменным этого бренда.

Изоляция: бренды не видят друг друга

Дальше — горизонталь. Брендовые файлы между собой не связаны вообще.

Бренд A никогда не импортирует из бренда B, не ссылается на его токены и не меняется от правок в нём. Все смотрят только вверх — на Library. Друг на друга — никогда.

В старой единой библиотеке сломанный токен в одном бренде задел бы все семь разом. Теперь это физически невозможно: ошибка в бренде C не дотягивается до бренда D, а эксперимент в бренде B не уронит прод бренда A. Каждый бренд — самостоятельная единица, подключённая только к общей структурной базе.

Изоляция стоила дублирования: каждый бренд держит свою копию переменных. Но покупала главное — ошибка перестала быть общей.

Два входа, а не один поток

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

Первый — токены. Они рождаются в JSON под версионированием, Token Studio выгружает их в брендовый файл как переменные. Второй — форма. Компоненты втекают из Library и красятся уже на месте. Это два разных входа в один файл, а не поток с боковой веткой: Library живёт вне токенной цепочки.

И у каждого входа своё правило, в одну сторону. Токены нельзя править руками прямо в Figma как источник — правка идёт в JSON и приезжает вниз заново; иначе дизайн и код разъедутся, и через месяц никто не найдёт, где правда. А Library всегда втекает в бренд, и никогда наоборот — бренд не пишет обратно в общую библиотеку.

Два правила, без которых перенос ломается

Файловая архитектура не спасает, если сами компоненты собраны хрупко. Тут хватит двух правил — остальное увело бы в отдельный чек-лист.

Boolean — для «показать/скрыть», variant — для типа или состояния. Иконку в кнопке включают булевым свойством, а не отдельным вариантом. Начнёшь плодить варианты под каждую мелочь — число комбинаций компонента взрывается, и перенос между файлами превращается в перебор сотен вариантов.

Fill / Hug / Fixed — по роли слоя, а не на глаз. Кнопка обнимает контент, поле тянется по контейнеру, иконка фиксирована. Выставишь это произвольно — компонент, перенесённый в бренд с другой шириной макета, поедет, и каждый бренд придётся чинить руками. Ровно то, от чего мы уходили.

VIP выводится из классики, а не строится заново

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

На практике обновление VIP — это не ручная пересборка, а короткая процедура: удалить старый VIP-файл, дублировать актуальный классический, снять с копии старые стили и переменные, выгрузить из Token Studio VIP-тему и применить токены ко всем страницам. На выходе VIP-файл повторяет свежие классические дизайны, но в VIP-цветах. Никакой второй ручной сборки — VIP всегда едет следом за классикой автоматически.

Архитектура наконец разрезала систему на управляемые куски: компоненты — общие и без бренда, бренды — изолированы, токены и структура втекают каждый своим входом и только в одну сторону. Оставался последний вопрос: что всё это дало за год работы?

Год спустя: результаты

Прошло больше года. То самое ревью, которое когда-то было диктантом — «не тот шрифт», «не тот цвет кнопки», — больше не про это. Базовые правила держит система. На ревью снова обсуждают дизайн, а не ищут чужие опечатки.

Что система дала

Главный результат не в красивой метрике, а в том, с чего теперь начинается работа над экраном. Раньше — с цвета и шрифта: открой нужный бренд, найди актуальную кнопку, не перепутай оттенок. Теперь — со сценария и логики. Целый класс ручного труда и целый класс ошибок просто ушли из процесса.

Новый раздел больше не рисуется семь раз. Он собирается один раз в системе и расходится по брендам через токены. Новый дизайнер входит не через семь разрозненных файлов, а через одну систему. А база — отступы, типографика, цвет — больше не вопрос вкуса на ревью: она задана, и выбрать неправильное нельзя.

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

Внедрение — это отдельная работа

Один урок я недооценил вначале: хорошо устроенная система не внедряется сама.

Разработка поначалу смотрела на неё как на дизайнерскую штуку, которая только добавляет им требований. Я сел рядом и показал на их же задачах, как система снимает работу именно с них — один источник токенов вместо ручного переноса цветов и размеров из макета. После этого они были на моей стороне. Систему пришлось продавать не один раз наверх, а ещё и команде, которая будет в ней жить. Это отдельная работа, и её делаешь руками.

Сложность нужно держать в узде

Второй урок — про дисциплину. В какой-то момент я завёл компонентные токены там, где с запасом хватало семантики. И быстро поймал, что система усложняется быстрее, чем растёт польза: лишние токены — лишние места, где всё может разойтись. Откатил.

Правило, которое теперь со мной с первого дня любого проекта: лишний уровень абстракции оправдан реже, чем кажется. Сомневаешься — бери проще.

Token Studio был и остаётся верным выбором

Отдельно про инструмент, потому что это частый вопрос. Token Studio я выбрал не под лимит Figma, а под цель — довести систему до кода. Токены живут в JSON под версионированием: один и тот же источник готов и для дизайна, и для фронтенда. Это и превращает дизайн-систему из библиотеки макетов в продукт, на котором работает вся команда. Вернувшись назад, я бы оставил всё как есть.

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

Что бы я сказал тому, кто в том же хаосе

Год назад я открывал файлы, где одна кнопка жила в десяти версиях, а работа дизайнера сводилась к отлову чужих ошибок. Сегодня та же работа снова про дизайн, семь брендов держатся на одной системе, и команда перестала тратить внимание на то, что система больше не пропускает.

Если вы в том же хаосе — не ждите, пока кто-то закажет систему. Я не ждал. Я увидел проблему, собрал на одной сцене доказательство, что без системы процесс обречён, продал это решающему человеку и довёл до продакшна. То, что систему никто не заказывал, оказалось не помехой, а преимуществом: я строил её так, как считал правильным.