Изменение дизайн-процесса
Lead time −40%, ревью с 2 недель до 2–3 дней, покрытие процессом 92%.
Сейчас бы я сделала это так
Переделка дизайн-процесса на 15 команд в 2024 заняла у меня 9 месяцев. Сегодня я бы решала это иначе: skill `process-audit` мапит as-is процесс команды за день, выдаёт diff с target state и план перехода в виде списка конкретных skills, которые нужно написать или подключить.
process-audit
СкороАудит дизайн-процесса команды по 8 параметрам, diff к target state.
- Опросник для дизайнеров и продактов: где боль, где hand-off ломается
- Авто-сборка диаграммы as-is и сравнение с эталоном
- План миграции в формате backlog'а на 6 недель
Как это было сделано тогда
Контекст
15 продуктовых команд + ~20 распределённых проектных. Группа ревьюеров не справлялась — на одно ревью уходило по две недели, потому что человек впервые видел контекст задачи. Не все дизайн-задачи заводились в Jira отдельным тикетом, поэтому невозможно было отследить, что прошло ревью и почему столько дизайн-багов уходит в прод.
Цель и требования TO BE
- Сократить lead time дизайн-задачи
- Поднять процент задач, прошедших ревью
- Снизить количество дизайн-багов в проде
Решение
Выделила дизайн-направления — кластеры из нескольких продуктовых команд. Внутри каждого — погружённый лид-дизайнер, который заходит в задачу на этапе проектирования. К моменту ревью он уже знает контекст — ревью занимает дни, а не недели.
Все дизайн-задачи попадают в Jira отдельным тикетом. Создала новый тип задачи с прописанным бизнес-процессом и борд для отслеживания лидами и центром экспертизы.
Перенесла ревью на этап тестирования — дизайнеры работают в паре с QA. Тестировщики заводят баги с меткой design-bug — так появились метрики сгораемости и качества дизайна.
Pre-review в Gitlab — дизайнер смотрит фичу до того, как разработчик раскатает в CI/CD. Это ловит расхождение макет/реализация ещё до прода.
План внедрения
Презентация процесса → знакомство направлений → настройка коммуникации лида с командами → обучение лидов → процесс работы с дизайн-багами → пилот → метрики → масштабирование на всех.
Результат пилота
- Lead time дизайн-задачи: −40%
- Срок дизайн-ревью: 2 недели → 2–3 дня
- Покрытие задач ревью: 92%
- +70% к исправлениям дизайн-багов внутри спринта
- Научились измерять количество и сгораемость дизайн-багов
Итог
Процесс перешёл от хаотичного «тушения пожаров» к предсказуемому циклу. Дизайн стал партнёром продукта и разработки, а не узким горлышком в конце.
Что бы я сделала иначе сегодня
Сегодня я бы добавила в этот процесс AI-дизайн-ревью первым слоем — до человеческого. Skill, который проверяет соответствие дизайн-системе, базовую accessibility, иерархию, выравнивание по сетке — за минуты, а не дни. Лид-дизайнер тратит время только на смысловую часть: бизнес-логика, UX-решение, продуктовые компромиссы.