Перевёл хаотичную ручную настройку под бренд клиента (правка сотен цветовых переменных, пересборка иконок и шрифтов, раздельная сверка под iOS и Android) в управляемый автоматизированный конвейер. Результат — единый ресурс-пак, авто‑выгрузка из Figma в репозиторий и чёткие критерии готовности, которые позволили выполнять кастомизацию за часы, а не недели.

Что изменилось: ручные правки и постоянные возвраты из‑за расхождений → предсказуемый процесс с единым источником правды, автоматической синхронизацией и визуальными эталонами.

Роль: Senior Product Designer
Платформы: iOS / Android (white‑label проекты)
Команда: PM, 2 iOS dev, 2 Android dev, backend dev, QA, аккаунт‑менеджеры
Срок: 3 месяца
Контекст: B2B / White‑Label / Mobile / Internal process improvement

Задача: устранить узкое место в бизнесе — кастомизация мобильных приложений под бренд клиента занимала 30−45 дней, вызывала постоянные возвраты и перегрузку команды.

Проблема: процесс был полностью ручным: дизайнер вручную правил палитру (около 300 переменных), пересобирал пакеты иконок и шрифтов, затем разработчики отдельно интегрировали ресурсы под iOS и Android, после чего начинались долгие циклы сверки и правок из‑за различий в рендеринге.

Что я сделал: проанализировал текущий процесс, выявил основные точки потерь, унифицировал цветовую систему (сократил с 300 до ~30 токенов), создал единый ресурс-пак, совместно с разработкой настроил автоматическую выгрузку значений из Figma в репозиторий, обновил библиотеку компонентов и внедрил чек‑листы приёмки.

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

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

Статус: решение внедрено в регулярный процесс. Метрики post‑launch подтвердили эффективность (см. раздел «Результат»).

Компания разрабатывает white‑label мобильные приложения для крупных заказчиков в сфере недвижимости. Каждый клиент получает приложение, стилизованное под его бренд: свои цвета, логотип, иконки, шрифты. Этих клиентов десятки, и количество растёт.

До оптимизации каждый новый проект означал ручную работу:

• дизайнер брал базовый шаблон и вручную перекраивал палитру (часто просто копировал значения из брендбука в переменные Figma);
• отдельно готовил набор иконок (перерисовывал или адаптировал);
• отдельно — файлы шрифтов;
• всё это выгружалось в виде разрозненных архивов и передавалось разработчикам;
• iOS и Android команды по‑разному интерпретировали цвета (из‑за разных цветовых пространств), иконки могли съезжать, шрифты — не совпадать.

Процесс превращался в бесконечные итерации «дизайн → разработка → сверка → правки». Сроки горели, команда работала на пределе, а новые заказы приходилось откладывать.

До оптимизации сценарий кастомизации выглядел так:

1. Менеджер получает бриф от клиента с брендбуком.
2. Дизайнер вручную создаёт новую ветку в Figma, копирует базовые компоненты, начинает подменять цвета — около 300 переменных (основной цвет, оттенки, состояния, градиенты). Часто ошибается или пропускает часть.
3. Параллельно готовит иконки (от 50 до 100 шт.) — либо перерисовывает, либо адаптирует имеющиеся.
4. Шрифты — загружает, конвертирует, подключает.
5. Все ресурсы выгружаются по отдельности: PDF с палитрой, архивы с иконками, файлы шрифтов, и передаются разработчикам через мессенджеры или почту.
6. Разработчики iOS и Android независимо друг от друга интегрируют ресурсы, используя свои инструменты. Из-за различий в цветовых профилях (sRGB, P3) и подходах к отрисовке иконок визуал на двух платформах начинает отличаться.
7. Собирается тестовая версия, проводится сверка. Обнаруживаются расхождения. Начинается цикл: дизайнер уточняет, разработчик правит, снова сверка.
8. Клиент принимает работу, но часто просит правки (например, «этот цвет на айфоне выглядит ярче, чем надо»).
9. Итоговое время — от 30 до 45 дней на одного клиента. Команда может вести не больше 2−3 таких проектов параллельно.

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

Бизнес рос, количество white‑label проектов увеличивалось, но процесс не масштабировался.

Ручная кастомизация стала бутылочным горлышком:

• падала пропускная способность команды;
• клиенты ждали дольше обещанного;
• росла себестоимость каждого проекта;
• страдало качество (из-за спешки допускали ошибки);
• разработчики выгорали от монотонной рутины.

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

Я выступил инициатором и владельцем этой внутренней оптимизации. Моя задача была не просто «нарисовать красиво», а перепроектировать процесс целиком, от брифа до релиза.

В моей зоне ответственности:

• картирование текущего процесса (совместно с дизайнерами, разработчиками, аккаунтами);
• выявление узких мест и потерь времени;
• унификация цветовой палитры (сведение 300 переменных к ~30 базовым токенам);
• разработка структуры единого ресурс-пака (цвета, иконки, графика, шрифты) в Figma;
• проектирование логики авто‑выгрузки (какие данные, в каком формате, как часто);
• координация с разработчиками по реализации скриптов выгрузки и интеграции;
• обновление библиотеки компонентов с учётом токенов;
• создание чек-листов и визуальных эталонов для приёмки;
• пилотное тестирование процесса на реальных проектах;
• документирование нового процесса и обучение команды.

Я начал с погружения в существующий процесс: опросил всех участников (дизайнеров, iOS/Android разработчиков, QA, аккаунт-менеджеров), собрал хронику нескольких последних проектов, замерил фактические затраты времени.

Методы

• Интервью с 8 участниками команды.
• Анализ тайм-трекинга по 5 завершённым проектам.
• Сравнение артефактов (переданные дизайнерами файлы и то, что в итоге попало в код).
• Визуальный аудит расхождений между iOS и Android сборками.
• Бенчмарк аналогичных процессов в других компаниях (через профессиональные сообщества).

Ключевые выводы
1. Ручная правка палитры занимала 40% времени дизайнера
300 переменных — это много. Дизайнер тратил 2−3 дня только на то, чтобы перебить все цветовые значения из брендбука в Figma, часто допуская опечатки и пропуски.
2. Различия в рендеринге цветов на iOS и Android — главная причина возвратов
iOS использует цветовое пространство P3 (широкий охват), Android — sRGB. Один и тот же hex‑код выглядит по‑разному. Разработчики не синхронизировали цветовые профили, и клиенты видели расхождения.
3. Передача ресурсов частями создавала хаос
Цвета могли быть в одном файле, иконки — в другом, шрифты — в третьем. Разработчики не всегда получали актуальные версии, возникали коллизии.
4. Не было единого стандарта «готово»
Каждый дизайнер по-своему понимал, что значит «кастомизация завершена». Разработчики тоже имели разные представления о том, как должны выглядеть компоненты. Из-за этого правки тянулись бесконечно.

Что было сделано

1. Унификация цветовой системы
Я проанализировал все используемые в проектах цвета и выделил базовые токены:

• primary / secondary / accent
• background / surface
• text (primary, secondary, disabled)
• status (success, warning, error, info)
• borders, dividers, overlays

Вместо 300 произвольных переменных получилось около 30 токенов, которые покрывали 95% всех случаев. Каждый токен имел описание и пример использования.

2. Создание единого ресурс-пака в Figma
Все необходимые для кастомизации элементы были собраны в одном файле-шаблоне:

• страница с цветовыми токенами (каждый токен — отдельный компонент со значением);
• страница с иконками (всё как векторы, сгруппированы по категориям);
• страница с графикой (иллюстрации, паттерны);
• страница со шрифтами (стили текста с подключением шрифтов через web-ссылки или локальные файлы).

3. Автоматическая выгрузка в репозиторий
Совместно с разработчиками мы написали скрипт (на Python), который:

• через Figma API получает значения цветовых токенов;
• конвертирует их в нужные форматы (UIColor+extension для iOS, ресурсы для Android);
• загружает SVG-иконки и оптимизирует их;
• коммитит изменения в репозиторий, откуда мобильные сборки автоматически подхватывают их (через CI/CD).

Теперь дизайнер меняет цвет токена в Figma, нажимает кнопку — и через 5 минут новая сборка приложения уже использует этот цвет.

4. Правила и чек-листы
Я разработал:

• чек-лист для дизайнера перед передачей (все ли токены заполнены, все ли иконки на месте);
• визуальные эталоны — скриншоты ключевых экранов с подписями, как должно выглядеть в идеале;
• правила приёмки для QA (что проверять, с чем сравнивать).

5. Обновление библиотеки компонентов
В дизайн-систему были добавлены компоненты, которые используют цветовые токены. Теперь при смене палитры все компоненты автоматически перекрашиваются.

После внедрения нового процесса мы замерили эффект на трёх пилотных проектах, а затем и на всех последующих.

Ключевые метрики

• Цикл кастомизации сократился с 30−45 дней до 4−8 часов (время, которое дизайнер тратит на настройку токенов и иконок).
• Time‑to‑Market кастомных релизов ускорился на 25% (за счёт исключения длительных циклов правок).
• Доля релизов, принятых с первого раза, выросла на 20−35 п.п. (с 50% до 70−85%).
• Количество правок после приёмки снизилось примерно на 30%.
• Команда дизайна теперь обрабатывает в 2 раза больше заказов без увеличения штата.

Что изменилось для команды

• Дизайнеры перестали выполнять рутинную работу, сосредоточились на улучшении продукта.
• Разработчики больше не тратят время на «подгонку цветов» и синхронизацию платформ.
• QA проверяет только сложные сценарии, базовая кастомизация работает стабильно.
• Аккаунт-менеджеры могут называть клиентам реальные сроки и не бояться срывов.

Что изменилось для бизнеса

• Выросла пропускная способность: теперь можно брать больше white‑label проектов.
• Улучшилось качество продуктов, меньше негатива от клиентов.
• Снизились издержки на поддержку и доработки.

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

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

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

4. Не пытайтесь автоматизировать всё сразу
Лучше сделать 80% работы, которая приносит 95% пользы, чем потратить уйму времени на оставшиеся 20%.

5. Документация и чек-листы — тоже часть дизайна
Без чётких критериев «готово» даже самая лучшая автоматизация не спасёт от возвратов.