Собрал мультибрендовую дизайн-систему аж для семи брендов
Д
Джексон Стей
·22 мин читать
Собрал мультибрендовую дизайн-систему аж для семи брендов
Статья была полезной?
Статья о дизайне-системе в Figma — местами будет использоваться терминология этого инструмента, основные понятия объясняю по ходу.
Я пришёл в компанию, в которой было семь брендов. С улицы и не скажешь, что под ними один шаблон — над разрозненностью поработали как следует: свои фоны, свои цвета, своя подача. Но в основе лежал один и тот же шаблон. А внутри файлов структуры не было никакой. Ни связи между брендами, ничего. Всё на группах и фреймах. Компоненты почти не использовались: под каждую новую задачу, в каждом новом файле кто-то рисовал новую кнопку — вот прямо под этот раздел. Ни о какой системности речи не шло. Ни внутри бренда, ни между брендами.
Смотреть на это спокойно я не мог — и не из брезгливости. Я видел, сколько это стоит. Нарисовал флоу KYC один раз — иди рисуй его ещё семь раз, и каждый раз почти с нуля, потому что переиспользовать нечего. Вот где горело время.
Это история о том, как я собрал из этого хаоса дизайн-систему и возглавил переход на неё: про фундамент и токены, про стену в 28 тем и про миграцию трёхсот тысяч слоёв. Начну с того, почему так продолжаться не могло.
Каждый раз, когда нужно было рисовать новые экраны на этой старой системе, начиналось одно и то же. Лид ходил и подмечал ошибки: тут шрифт не из этого бренда, тут цвет кнопки не наш, тут радиус чужой. И так у всех — не потому что дизайнеры были криворукие, а потому что система была негодной. Она не давала ни одной опоры, поэтому ошибиться было проще, чем не ошибиться.
Так дизайнерская работа превратилась в подмечательство. Лид ловил ошибки глазами, по одной — а глазами ловишь не всегда. И даже когда ловишь, это уже последствие, а не причина. Корень был не в ошибках. Корень был в том, что каждый экран приходилось размножать руками по семи брендам. Ошибки — просто то, что из этого сыпалось.
Я случайно узнал про Figma Variables и начал тестировать. Собрал тестовые микро-экраны и стал проверять: а может ли по переключению меняться цвет? радиус? текст? Оказалось — может. И в этот момент я понял, что на этом можно строить систему.
Дальше я перерыл всё. Весь интернет, курсы, сидел в тематическом чате в телеграме. Не за вдохновением — мне нужно было убедиться, что проблема не локальная и что подход рабочий. И там же дошёл до главного: дизайн-система — это не библиотека компонентов. Это другой процесс работы. Компоненты — то, что видно сверху. А под ними лежит процесс, в котором экран рисуется один раз и расходится на все бренды сам.
Вся арифметика была простая. Если работа на годы вперёд — это рисовать каждый флоу по семь раз вручную, то дешевле один раз построить так, чтобы экран рисовался один раз и масштабировался на все бренды автоматически. Скорость и масштабирование — вот что система покупала на самом деле. То, что вместе с этим исчезал целый класс ошибок, было приятным бонусом, а не целью.
Доказывать это на словах было бесполезно — на словах меня бы и слушать не стали. Поэтому я собрал прототип на Figma Variables. Одна и та же страница, одни и те же кнопки, переключатель режимов.
Переключаю режим — и страница меняет всё, что нужно, разом: радиусы кнопок, цвета кнопок, цвета фонов, все цвета, все шрифты. За секунду. То, на что в старых файлах уходила неделя ручной работы по семи брендам.
Я показал это лицу, принимающему решение — CPO. Демка оставила сильное впечатление: разговор сразу перестал быть теоретическим. Это и был зелёный свет.
Дизайн-системы обычно продают как единообразие и красоту. Это их и хоронит — разговор сразу уходит в спор о вкусе.
Я не сказал ни слова про красоту. Я продавал скорость и масштаб: один экран вместо семи, минус неделя ручной работы на каждой крупной фиче. Разговор стал не про вкус, а про деньги и сроки.
Метрика | Как было | Как стало |
|---|---|---|
Новый раздел на 7 брендов | ~3–4 дня дизайна + примерно по дню ручной раскатки на каждый из остальных 6 | ~3–4 дня в системе, дальше расходится по брендам автоматически |
Базовые визуальные ошибки | сыпались постоянно, ловил их лид глазами | заданы системой, выбрать неправильное нельзя |
Онбординг нового дизайнера | недели на семь файлов | дни на одну систему |
Система не отменяла работу над самим решением. Она отменяла его ручное размножение по семи брендам — а это и был основной расход.
Продать оказалось легче, чем построить. Я сел пересобирать первый же экран и тут же выяснил, что не знаю базовых вещей. Как задать отступы, чтобы они не были случайными — а в старых файлах их были сотни, все на глаз. Как назвать цвет, чтобы он не развалил всё на втором бренде. На втором бренде он и развалился. Но об этом чуть позже — сначала про фундамент.
Первый же экран показал главное: старую систему чинить бессмысленно. От неё оставалась только идея — как корабль, который перестроили целиком, а название то же. Надо было строить заново, с правильным фундаментом. И первый вопрос фундамента — самый скучный. Размеры.
Когда я прогнал флагманский бренд через аудит, оказалось, что значений отступов в нём — сотни. 13, 18, 22, 30 пикселей. Не потому что так задумано, а потому что каждый ставил на глаз.
Я положил в основу одну шкалу:
4 8 12 16 20 24 32 48 64До 24 — кратно четырём, выше — кратно восьми. В слое отступов других чисел не существует: нет значения в шкале — поставить его нельзя.
Я не доказывал, что эта шкала единственно правильная. Мне нужна была такая, которую легко держать в голове, легко отдать в код (8px чисто переводится в rem при базовом размере 16px, без дробных пикселей) и трудно нарушить случайно. На мелких расстояниях точность давала четвёрка, на крупных порядок держала восьмёрка. Похожая логика есть в Bootstrap, Material, Polaris. Я не изобретал велосипед — я перестал давать выбор.
Со шрифтами я пошёл так же: меньше вариантов, меньше случайности. Минимально достаточный набор ролей — четыре заголовка, три размера основного текста, подпись, текст кнопки. Не идеальная типографическая шкала, а ровно то, без чего не собрать экран. Изыски ломаются первыми, поэтому на старте — только роли.
С устройствами то же. По аналитике аудитория была в основном мобильной, поэтому базовые стили я делал сначала под мобайл, остальное достраивал вверх. Три ширины:
Устройство | Ширина |
|---|---|
Мобайл (база) | 360 |
Лэптоп | 1024 |
Десктоп | 1400+ |
Три ширины вместо пяти-шести брейкпоинтов у больших фреймворков — меньше мест, где макет может разъехаться.
Дальше я взялся за цвет — и сделал ошибку, которая кажется логичной, пока у тебя один бренд.
Я покрасил кнопку в 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 — компонент на контрастной поверхности (светлое на тёмном).
У компонента есть булево свойство inverted: true/false. false — берёт base-токены, true — inverted. Никаких «если бренд тёмный — возьми другой цвет». Компонент вообще не знает, в каком он бренде и какого цвета фон под ним. Он знает только одно: на какой поверхности стоит — base или inverted. Реальный цвет подставит система токенов.
Для светлого бренда base и inverted разрешаются в разные значения:
bg.neutral.base.500.default → primitive.white.500
bg.neutral.inverted.500.default → primitive.brown.800
fg.neutral.base.500.default → primitive.brown.800
fg.neutral.inverted.500.default → primitive.white.500А вот ход, который всё сшил. Что делать с тёмным брендом, у которого поверхности и так тёмные? Заводить под него отдельную логику — значило вернуть компоненту знание о бренде. Вместо этого у тёмного бренда base и inverted разрешаются в одно и то же значение:
bg.neutral.base.500.default → primitive.grey.800
bg.neutral.inverted.500.default → primitive.white.500
fg.neutral.base.500.default → primitive.grey.800
fg.neutral.inverted.500.default → primitive.white.500Свойство inverted у тёмного бренда технически есть, но визуально ничего не меняет. И в этом вся выгода: компонент настраивается одинаково во всех брендах, без исключений вроде «на тёмном бренде inverted не показывать». Один и тот же компонент встаёт в любой бренд и сам разрешается правильно.
К этому моменту система уверенно держала пару брендов. Я выдохнул — и сел считать комбинации. И тут арифметика перестала сходиться.
Один бренд — это не одно оформление. Любой бренд может быть светлым-классическим, тёмным-классическим, светлым-VIP или тёмным-VIP. Две независимые оси — тема и класс — дают четыре оформления на бренд. На семь брендов это двадцать восемь комбинаций. А Figma на тот момент давала четыре мода на коллекцию.
Дальше обычно идёт вопрос: ну заплати за тариф подороже. Я проверил. На Enterprise лимит был сорок. И даже это меня не спасало: двадцать восемь я закрывал, но бренды росли и будут расти — рано или поздно я упёрся бы в сорок так же, как уперся в четыре. Покупать Enterprise ради временной отсрочки никто бы не стал, да и проблему он не решал. Дело было не в числе модов. Дело было в самой модели.
Первое, что предлагают, — разнести двадцать восемь комбинаций по нескольким коллекциям, раз в одну не влезает.
Не работает. Возьми один токен — bg.brand.base.500.default. Он должен разрешаться в своё значение для каждой комбинации: бренд 1 светлый-классический, бренд 1 тёмный-классический, бренд 1 светлый-VIP, бренд 1 тёмный-VIP, дальше бренд 2 со всеми четырьмя, и так все двадцать восемь. Это один и тот же токен, живущий в двадцати восьми модах.
Разнести его по коллекциям — значит разорвать его на куски. В одной коллекции он один токен, в другой — уже другой, и связь между ними теряется. А мне нужен был именно один токен, который сам подставляет нужное значение под нужную комбинацию. Несколько коллекций этого не дают — они дробят то, что должно быть единым.
Тогда я пошёл искать плагин — как почти все, кто упирается в лимит инструмента. Плагинов, которые обещали обойти лимит, было несколько. Идея у всех общая: дублировать коллекции и переключать значения на лету.
Сначала всё выглядело победой. Макет переключается, цвета меняются — работает. А потом я поправил мастер-компонент и увидел, что часть экранов не обновилась.
Под капотом было вот что. Переключая тему, плагин переписывал значения прямо в инстансах. Инстанс формально оставался инстансом, но переписанные значения превращались в локальные переопределения. И следующая правка мастера в эти места уже не доходила. Для системы это то же самое, что навсегда потерять связь с мастером.
А вся система держалась ровно на обратном: мастер один, инстансы тянут из него. Плагины предлагали разменять это на красивое переключение. Мне нужна была не картинка на секунду. Мне нужна была живая связь с мастером.
Если инструмент переписывает значение в инстансе, он выигрывает секунду на переключении и проигрывает систему на следующем обновлении.
Костыль поверх нативных переменных отпадал. Нужен был не переключатель, а другой источник истины.
Token Studio я выбрал не потому, что у него больше функций. Он менял саму модель сборки темы.
В нативной Figma мод — это строка в плоском списке внутри коллекции. В Token Studio тема — это пересечение групп. Группа «Бренд», группа «Оформление» (классика/VIP), группа «Устройство» — и любая комбинация собирается из них, как точка в кубе. Те самые оси, которые в Figma не пересекались, тут были устроены прямо: включаешь нужные наборы под нужный мод — и тема готова.
И, важнее, источником истины переставала быть Figma. Токены жили в JSON — отдельно от макетов, под версионированием. А Figma становилась потребителем: местом, где токены применяют и проверяют, но не местом, где они рождаются.
Git, экспорт в код, больше типов токенов, чем нативные — всё это шло бонусом. Но причина была не в этом. Причина была в модели: темы стали собираться из пересечения осей, а не лежать плоским списком модов.
Выбрать Token Studio оказалось легче, чем перевести в него старый файл.
Вся система была построена на сырых значениях и нативных переменных. Чтобы она поехала на токенах, каждый слой нужно было переподключить заново. Слоёв с цветами было порядка трёхсот тысяч. Вручную это не делается — физически.
Спас плагин Apply Tokens. Он, кажется, от тех же разработчиков, но я узнал
О нём я узнал абсолютно случайно, перебирая множество материалов по теме. Он сопоставлял значения слоёв с соответствующими токенами и обновлял их группами. Работает не идеально, но именно с его помощью я перенёс весь бренд. Без него я просто не представляю, как бы я подключал триста тысяч слоёв по одному.
Это не было одним кликом, а заняло недели работы. Однако это была работа, которую стало вообще возможно выполнить.
Это не была временная альтернатива из-за ограничения 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 задаются токенами в Token Studio.
На практике обновление VIP — это не ручная переборка, а быстрая процедура: удалить старый VIP-файл, скопировать актуальный классический, убрать старые стили и переменные, выгрузить VIP-тему из Token Studio и применить токены ко всем страницам. В итоге VIP-файл отражает свежие классические дизайны, но в цветах VIP. Никакой второй ручной сборки — VIP всегда автоматически следует за классикой.
Архитектура наконец структурировала систему, разделив её на управляемые части: компоненты — общие и нейтральные, бренды — изолированные, токены и структуры поступают каждый своим входом и только в одну сторону. Оставался единственный вопрос: какие результаты дала эта работа за год?
Прошло больше года. То самое ревью, которое когда-то было «диктантом» — «не тот шрифт», «не тот цвет кнопки», — больше не так актуально. Базовые правила теперь контролирует система. На ревью снова обсуждают дизайн, а не исправляют чужие ошибки.
Главный результат заключается не в красивых метриках, а в том, с чего теперь начинается работа над экраном. Раньше работа начиналась с поиска цвета и шрифта: открой нужный бренд, найди актуальную кнопку, не перепутай оттенок. Теперь работа начинается со сценария и логики. Целый класс ручного труда и ошибок просто исчез из процесса.
Новый раздел больше не рисуется семь раз. Он собирается один раз в системе и распространяется по брендам через токены. Новый дизайнер теперь не работает с семью разрозненными файлами, а использует одну систему. Базовые элементы — отступы, типографика, цвет — больше не являются вопросом вкуса на ревью: они заданы, и невозможно выбрать ошибочную настройку.
Семь брендов теперь функционируют на единой системе. И это больше не зависит только от меня: я подготовил документацию — не «как это сделать», а как пользоваться системой. Как добавить новый бренд, как применить токены, как не уничтожить связь с мастером. Когда каркас был готов, команда перенесла дизайны на систему вместе со мной — я учил людей работать с ней. Система организована так, чтобы в ней могла работать вся команда, а не только один автор.
Один урок я недооценил в начале: хорошо организованная система не внедряется сама собой.
Команда разработки сначала воспринимала её как что-то чисто дизайнерское, что только добавляет им требования. Я сидел рядом и показывал на их задачах, как система облегчает именно их работу — один источник токенов вместо ручного переноса цветов и размеров из макета. После этого они стали на моей стороне. Систему пришлось продвигать не только среди руководства, но и среди команды, которая будет с ней работать. Это отдельный процесс, который требует усилий.
Второй урок — это необходимость дисциплины. В какой-то момент я ввёл компонентные токены там, где с запасом хватало семантики. И вскоре я понял, что система усложняется быстрее, чем появляется польза: лишние токены — лишние места, где всё может рассогласоваться. Я откатил внесённые изменения.
Правило, которое я теперь применяю с первого дня любого проекта: лишний уровень абстракции оправдан гораздо реже, чем кажется. Если вы сомневаетесь — выбирайте более простое решение.
Отдельно о выборе инструмента, так как это частый вопрос. Я выбрал Token Studio не из-за лимитов Figma, а с целью довести систему до кода. Токены хранятся в JSON под версионированием: один и тот же источник подходит как для дизайна, так и для фронтенда. Благодаря этому дизайн-система превращается из библиотеки макетов в продукт, который может использовать вся команда. Если бы мне пришлось выбирать снова, я бы оставил всё как есть.
Следующий шаг уже спроектирован: автоматический мост «токены → код», чтобы синхронизация проходила без ручного вмешательства. Архитектура под это уже готова — это вопрос внедрения, а не пересборки.
Год назад я открывал файлы, где одна кнопка существовала в десяти версиях, и работа дизайнера сводилась к исправлению чужих ошибок. Сегодня та же работа снова о дизайне: семь брендов функционируют на единой системе, и команда перестала тратить усилия на проблемы, которые система больше не допускает.
Если вы находитесь в подобном хаосе — не ждите, пока кто-то решит задачу внедрения системы. Я не ждал. Я увидел проблему, собрал доказательства, что без системы процесс обречён на неудачу, убедил ключевого человека и довёл проект до реализации. То, что никто не заказывал систему, оказалось не помехой, а преимуществом: я создавал её так, как считал правильным.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…