Пересмотр процессов
Год работы. 8 дизайнеров. -34% доработок. MVP дизайн-системы. Налаженная коммуникация с разработкой и аналитикой. Повышение самостоятельности и осознанности в отделе.
Проблемы
-
1
Не было дизайн-системы в продукте, который выпускает около 100 фич за год. Можно представить, что происходило в макетах.
-
2
Мнение дизайнеров не учитывалось в продуктовых решениях. Не было общего языка между разработкой и дизайном.
-
3
Работа часто строилась только на ТЗ, без подключения критического мышления. Дизайнер = оператор Figma.
Шаг 1. Единый источник правды
Итак, у нас не было дизайн-системы. К чему это привело:
30% времени уходило на уточнение актуальности макетов. В каждой задаче приходилось перепроверять каждый пиксель и оттенок.
Новым дизайнерам негде было взять информацию о процессах и правилах. Их бросали в задачи без адаптации.
Разные стримы делали одни и те же элементы по-разному. Даже внутри одного отдела не было единства.
Решения
-
1
Приоритет дизайн-системы снижали по инерции, поэтому я взяла ответственность на себя. За 3 дня собрала MVP ДС. Про это писала в отдельном кейсе тут
-
2
Создала библиотеку пустых состояний, чтобы по всему приложению соблюдался общий tone of voice
-
3
Собрала онбординг-файл со всей информацией по работе с задачей: правила описания, нейминг, структура, воркфлоу
-
4
Написала гайд для проверки макетов, чтобы дизайнеры могли сами проверять свои макеты перед сдачей
-
5
Протолкнула дизайн-ревью как обязательный этап воркфлоу.
Бизнес-ценность
12>18+
Задач за спринт
-60%
Доработок после просмотра готовой верстки. Дизайн-ревью дополнительно привило разработке ответственность: теперь работа тщательно проверяется
100+
Компонентов в модерируемой дизайн-системе. Библиотеки в коде и в Figma идентичны
Шаг 2. Ритм работы
Параллельно работала над отношением к задачам. В небольших командах мнение каждого важно. Если мнение дизайнеров не слушают, фича получается сырой и плохо масштабируется. Разделила проблему на части:
Дизайнеров подключали к фиче только после того, как аналитик пропишет ТЗ. Дизайнер ничего не решал, он просто рисовал макет по запросу
Не было общего языка между разработкой и дизайном. Возникали проблемы на уровне: «я верстал макет на глаз, так как не знал, как в фигме отступы смотреть»
Решения
-
1
Перед началом работы исследуем задачу, смотрим разные подходы к решению и консультируем авторов задач по своим наработкам. Перешли от слепого выполнения ТЗ к партнёрству с продактами
-
2
Начала вести еженедельную защиту прогресса перед CTO, Head of Mobile, Product Owner и Analyst. На этих встречах мы в формате дискуссии принимаем стратегические решения по задачам на основе фактов
-
3
Провела опрос среди разработки о взаимодействии с макетами, выявила проблемные места, собрала гайд по Figma для разработки и паттерны передачи макетов.
Бизнес-ценность
80%
Задач аналитики и разработки приходят обсуждать с нами на раннем этапе
10%
Задач мы отменили на старте, просто объяснив, что решение уже существует и его можно адаптировать, вместо того чтобы кодить с нуля
Шаг 3. Делегирование и автономия
У нас есть ДС, у нас есть авторитет, что дальше? Закрепляем результат. Делим проблему:
Дизайнеры выполняли задачу на основе ТЗ, не подключая критическое мышление.
Решения не аргументировались, а после заворачивались из-за слабой защиты.
Не было списка навыков, требуемых для продвижения.
Решения
-
1
Распределила потоки задач между дизайнерами с учетом их сильных сторон и интересов. Получились мини-зоны ответственности
-
2
Продвинула воркфлоу, где дизайнер сначала анализирует проблему, ищет подходы, предлагает варианты и только потом согласовывает решение
-
3
Ввела регулярные 1-1 с дизайнерами для сбора обратной связи и оптимизации процессов.
Бизнес-ценность
+40%
Инициативных предложений по улучшению продукта от членов команды
100%
Задачи дизайнеры решают без микроменеджмента. Потоки распределены по интересам, люди делают то, что им нравится
ура
