01
Разрозненные паттерны
Одинаковые сущности, статусы и действия решались по-разному в соседних частях продукта. Это ломало предсказуемость и для пользователей, и для команды.
Как я пересобрал разрозненную B2G-платформу через design system и lead-подход
Когда я пришёл на проект, продукт не устраивал заказчика ни по визуалу, ни по качеству решений. За короткий срок я пересобрал интерфейсный слой, собрал дизайн-систему с нуля на базе Ant Design и выстроил работу дизайнеров так, чтобы система наконец стала цельной и управляемой.
Из-за NDA я не раскрываю регион, бренд и часть предметных сущностей. Но здесь сохранены реальные задачи, моя зона ответственности, ход работы и то, как именно я влиял на качество продукта, команду дизайнеров и результат для заказчика.
Контекст
Сложная B2G-система для контроля строительных процессов, документов, согласований и статусов по нескольким ролям.
Моя роль
Lead designer: пересборка интерфейсного слоя, дизайн-система, выравнивание решений, ревью и обучение дизайнеров.
Результат
Заказчик начал принимать решения предметнее, продукт стал выглядеть и работать как единая система, а не набор разрозненных экранов.
Что было ключевым
Я чинил не отдельные экраны, а саму систему принятия решений
Проблема проекта была глубже визуала: разные сценарии жили по разным правилам, команда проектировала неравномерно, а заказчик не видел в продукте целостности.
Собрал design system с нуля на базе Ant Design и адаптировал её под B2G-контекст.
Выстроил единый стандарт качества для команды и регулярные дизайн-ревью.
Помог заказчику увидеть не хаос из экранов, а цельную платформу с понятной логикой.
Lead role
Системное выравнивание продукта, команды и качества решений.
Ant + custom
Надёжная база для enterprise-паттернов и скорость без хаоса.
Наконец устроило заказчика
Не только визуально, но и по самой логике интерфейсных решений.
Контекст продукта
Это была не просто “админка”, а большая система, где ошибка в интерфейсе стоила дорого
Платформа помогала контролирующим органам и участникам строительного процесса видеть, где тормозится услуга, на каком этапе завис документ, кто отвечает за следующий шаг и где уже появились проблемные зоны. Внутри было много ролей, много статусов, много документов и длинные сценарии с юридическим весом.
Почему продукт был сложным
В одном интерфейсе сходились контроль сроков, маршруты документов, замечания, возвраты на доработку, разрешительные сценарии и прозрачность для разных участников процесса. Пользователю нужно было не просто “заполнить форму”, а быстро понять, что происходит и где именно сломалось движение услуги.
Почему тут важно системное качество
Когда паттерны расходятся, пользователь дольше ищет нужное действие, команда каждый раз заново спорит о базовых решениях, а заказчик перестаёт доверять продукту как инструменту. В этом проекте качество интерфейса напрямую влияло на ощущение управляемости всей системы.
B2G платформа
контроль статусов, документов, исполнителей, проблемных зон и итоговых разрешений
Контролирующие органы
Подсветка проблем, этапов и задержек по процессу.
Организации
Проверка пакетов документов, возвраты на доработку, согласование решений.
Строительные компании
Подача документов, работа с замечаниями, получение разрешений.
Разрешения и печати
Финальные документы с юридически значимым статусом и маршрутом.
Проблемные зоны
Где именно остановился процесс и кто сейчас держит следующий шаг.
Статусы и этапы
Нужна была предсказуемая логика, а не набор разношёрстных решений.
Проблема до меня
На проекте уже работало несколько дизайнеров, но продукт всё ещё не складывался в систему
Снаружи это выглядело как вечные правки и недовольство заказчика. Но внутренняя причина была в другом: интерфейсный слой рос фрагментами, паттерны не держались, решения не повторялись, а одно и то же действие в разных местах продукта могло выглядеть и работать по-разному.
02
Нет общей базы
Без foundations, компонентов и правил продукт развивался через ручные исключения. Каждая новая задача тащила за собой новые визуальные и логические расхождения.
03
Команда работала неравномерно
Когда нет единого стандарта качества, сильные дизайнеры тянут уровень вручную, а слабые множат расхождения. На сложном B2G-проекте это чувствовалось особенно сильно.
04
Заказчик видел хаос
Даже хорошие точечные экраны не убеждали клиента, если рядом продукт выглядел и вёл себя по-другому. Требовалось не “подкрасить”, а стабилизировать продукт целиком.
Главный вывод
Я быстро понял, что точечные правки не спасут проект. Нужна была единая интерфейсная основа, набор повторяемых правил и понятный критерий качества, чтобы и заказчик, и команда наконец увидели в продукте систему.
Проблема была системной
Не отдельные “некрасивые” экраны, а отсутствие общей логики, единых паттернов и устойчивого качества.
Моя lead-роль
Я пришёл не как ещё один дизайнер экранов, а как человек, который должен был стабилизировать качество
За что я отвечал
Моя задача была не просто рисовать новые макеты. Я отвечал за то, чтобы пересобрать интерфейсный слой, создать систему, поднять качество решений внутри команды и привести продукт к состоянию, в котором его можно уверенно показывать и развивать дальше.
Провёл быстрый аудит текущих интерфейсов и нашёл повторяющиеся противоречия.
Собрал design system с нуля на базе Ant Design и зафиксировал единые правила.
Построил процесс дизайн-ревью и объяснял не только “как рисовать”, но и почему решение должно быть именно таким.
Помогал дизайнерам расти через разбор сценариев, паттернов, композиции и логики сложных enterprise-экранов.
Как я работал с командой
Для меня lead-роль здесь заключалась не в контроле ради контроля, а в том, чтобы команда перестала решать один и тот же класс проблем заново. Я старался переводить обсуждение из вкусовщины в понятные принципы: что у нас считается базовым паттерном, где нужно расширение, а где нельзя плодить новый компонент только потому, что “так сейчас удобнее”.
“Для меня эта работа была не про набор компонентов. Я фактически собирал общий язык, на котором продукт, команда и заказчик наконец начали понимать друг друга.”
Lead designer role / реальный NDA-проектПодход к пересборке
Я не начал с перерисовки десятков экранов. Сначала я собрал каркас, на котором продукт мог стать предсказуемым
В сложных B2G и enterprise-продуктах красивые фрагменты бесполезны, если в основе нет повторяемых решений. Поэтому первым шагом для меня была не гонка за новыми экранами, а быстрая стабилизация базового слоя: принципы, foundations, ключевые компоненты, правила применения и понятная точка контроля качества.
Собрал текущее состояние
Сверил существующие сценарии, таблицы, формы, статусы, действия и типовые ошибки.
Определил правила
Зафиксировал, где паттерны должны быть едиными и что нельзя решать по-разному.
Собрал дизайн-систему
Взял Ant Design как надёжную основу и адаптировал её под задачи реального продукта, а поверх собрал собственный слой сложных компонентов для сценариев, которые были схожи по сути, но заметно отличались по внутренней логике и статусам.
Выстроил ревью
Через регулярные разборы и обучение поднял качество решений внутри команды.
Вернул продукту цельность
Новые и переработанные интерфейсы начали говорить с пользователем на одном языке.
Design system
Ключевым решением стала дизайн-система: не как UI-kit, а как рабочая инфраструктура продукта
Я выбрал Ant Design как базу не ради “быстрой сборки из готового”. Для enterprise-среды он дал надёжный фундамент: предсказуемые паттерны, знакомую логику таблиц, форм и состояний. Дальше я адаптировал этот фундамент под задачи продукта и собрал поверх него свой слой правил, визуального языка и продуктовых сценариев.
Что вошло в систему
Foundations, типографика, цветовая семантика, сетка, отступы, таблицы, фильтры, формы, модалки, статусы, документные сценарии, правила действий и общие паттерны для перегруженных экранов. Отдельно проектировал сложные компоненты, которые позволяли закрывать несколько близких сценариев без потери предсказуемости.
foundations
components
patterns
states
governance
Почему это сработало
Команда перестала каждый раз придумывать заново базовые решения. У дизайнеров появилась опора, у продукта — единый визуальный и логический язык, а у заказчика — ощущение, что перед ним наконец не набор кусков, а взрослый управляемый сервис.
Что было для меня важно
Я собирал систему так, чтобы она помогала команде, а не усложняла ей жизнь. Хорошая design system в таком контексте должна ускорять работу, убирать лишние споры и давать устойчивое качество даже на сложных сценариях.
Работа с дизайнерами
Я усиливал проект не только системой, но и людьми: через ревью, объяснение решений и понятную планку качества
Для меня lead-дизайн здесь был не только про “самому сделать лучше всех”. Важнее было сделать так, чтобы команда в целом проектировала сильнее. Поэтому я не ограничивался правками макетов: разбирал сценарии, объяснял причинно-следственные связи, показывал, где решение ломает систему, и помогал дизайнерам видеть продукт шире одного экрана.
Что разбирали на ревью
Логику действий, читаемость перегруженных экранов, иерархию, паттерны таблиц и форм, семантику статусов, работу с edge cases и плотность интерфейса.
Как я обучал
Не просто правил за дизайнера, а объяснял принцип: почему решение слабое, чем оно ломает систему и как его улучшить так, чтобы в следующий раз человек сам принял более сильное решение.
Что это дало команде
Меньше повторяющихся ошибок, больше самостоятельности в типовых и сложных сценариях, более ровное качество и меньше ручных “спасательных операций” в конце.
Что это дало мне как lead
Я видел свою задачу не в том, чтобы держать всё на себе, а в том, чтобы команда могла развивать продукт системно и без постоянной потери качества.
Качественный сдвиг после пересборки
до / после
Предсказуемость интерфейсных решений
Самостоятельность дизайнеров в типовых сценариях
Количество ручных исключений и разнобоя
Предметность согласований с заказчиком
Ревью как инструмент роста
Я не просто вылавливал ошибки. Я старался собирать у дизайнеров более зрелое проектное мышление: видеть паттерн, оценивать влияние решения на систему и держать единый уровень качества без постоянного ручного контроля.
Результат
В результате удалось стабилизировать и продукт, и работу команды — именно это и почувствовал заказчик
Самым важным итогом для меня было не наличие библиотеки компонентов как таковой, а то, что проект перестал разваливаться на части. У продукта появился единый интерфейсный язык, команда начала работать ровнее, а заказчик наконец увидел в решениях последовательность, а не набор отдельных попыток попасть в ожидания.
Продукт начал восприниматься как единая система, а не как набор экранов, сделанных разными людьми в разное время.
Новые экраны стало проще собирать и согласовывать, потому что команда опиралась на общую основу, а не начинала с нуля.
Обучение и ревью дали более ровное качество: меньше случайных решений и больше самостоятельности у дизайнеров.
Клиент начал принимать решения предметнее, потому что видел не хаос, а систему с понятной логикой и устойчивым визуальным языком.
До пересборки
- Разрозненные сценарииОдинаковые действия и сущности решались по-разному в разных зонах продукта.
- Слабая база для ростаКаждое новое решение рождало новые исключения вместо предсказуемого развития.
- Неровное качество командыБез общего стандарта проект зависел от уровня конкретного дизайнера.
- Фрустрация заказчикаДаже хорошие точечные экраны не компенсировали общего ощущения нестабильности.
После пересборки
- Единый язык продуктаКомпоненты, статусы, таблицы и формы начали работать по понятным и повторяемым правилам.
- Design system как опораПродукт получил устойчивую основу, которую можно расширять без потери качества.
- Сильнее работает командаДизайнеры стали увереннее в типовых и сложных сценариях благодаря ревью и обучению.
- Заказчик увидел системуСогласования стали предметнее, потому что продукт начал выглядеть и работать как цельное решение.
Что этот кейс говорит обо мне
Для меня это один из самых показательных кейсов: здесь видно не только мой UI, но и мой способ влиять на продукт
Этот кейс хорошо показывает, что я умею работать не “на уровне экранов”, а на уровне системы, команды и качества продукта
Вижу, когда проблема лежит не в визуале, а в отсутствии общей логики и устойчивых паттернов.
Умею быстро наводить порядок в сложных, разрозненных и конфликтных интерфейсных средах.
Могу собирать design system не для галочки, а как рабочий инструмент для продукта и команды.
Работаю как lead: поднимаю планку качества, помогаю дизайнерам расти и перевожу хаос в систему.
Умею разговаривать с тяжёлым заказчиком через сильную структуру решений, а не только через красивый визуал.
Почему мне важен этот кейс
Он показывает меня не как человека, который просто делает хорошие макеты, а как дизайнера, который умеет стабилизировать сложный продукт и делать сильнее не только интерфейс, но и команду вокруг него.
