Контекст
Кабинет для бизнеса растёт быстрее, чем дизайн-команда. Новые разделы рисуют восемь продуктовых дизайнеров из разных команд, часть из них вендоры. Корневые компоненты делает отдельная команда дизайн-системы, у неё свой бэклог и свои приоритеты.
Каждый экран собирался вручную по старым макетам. Вендоры ошибались в простом, разработка и тестирование приходили к дизайнерам с вопросами про каждое состояние, а ревью тонуло в замечаниях по каркасу вместо сути.
Нанять ещё людей было нельзя. Значит, нужно было сделать так, чтобы правильный экран было проще собрать, чем неправильный.
Второй слой
Моя команда не дизайн-система, и мы не пытались ей стать. Корневые компоненты мы заказываем у команды ДС, а сами отвечаем за второй слой: паттерны и продуктовые компоненты кабинета и документацию к ним.
Полтора года команда под моим руководством описывает, как устроен каждый паттерн: из чего состоит, какие у него состояния, где его использовать и где нельзя. Документацию читают не только дизайнеры: по ней работают разработка и тестирование.
Что описано
- Состав и анатомия
- Все состояния, включая пустые и ошибки
- Правила поведения данных
Кто пользуется
- Продуктовые дизайнеры и вендоры
- Разработка: реализует по описанию
- Тестирование: проверяет замысел
Что это дало
- Часть задач решается без дизайна
- Storybook собран по документации с помощью ИИ
Конструктор экранов
Когда паттерны были описаны, следующий шаг напрашивался сам. Я спроектировал Figma-компонент, в который зашит весь каркас экрана: шапка, навигация, сетка, уведомления, управляющие элементы. Дизайнер заполняет только слот с содержанием.
У конструктора два режима: реестр с вкладками и действиями над выборкой и деталка с шагами и нижней панелью. Во второй версии появились уведомления: закреплённая плашка и стек всплывающих сообщений, которые нельзя поставить не туда.
Моя роль
Обычно каркас и конструкторы это зона команды дизайн-системы. Но глубже всех в устройство кабинета погружена моя команда, поэтому задачу поставил я сам и сам же её довёл, работая через чужой бэклог.
- Сформулировал проблему не как «вендоры ошибаются», а как «правильный экран должен собираться быстрее неправильного».
- Выстроил процесс документации: команда пишет, я ревьюю и держу единый формат.
- Спроектировал обе версии конструктора и планировал нагрузку в спринтах команды ДС, тестировал сборки и выпускал вместе с ними.
- Переучил внешних дизайнеров на новый процесс и перевёл ревью всех новых макетов на конструктор.
Результат
Команда не выросла, а продукт стал проектироваться быстрее и ровнее.
Что бы сделал иначе
- Заложил бы уведомления сразу в первую версию конструктора: их добавление потребовало обновить все макеты.
- Выпустил бы гайды для вендоров до релиза, а не после первых вопросов.