Как я улучшила процесс и сделала его более удобным для команды
Почему возникла потребность в изменениях
В ДЛЕ ТЕХ не было устоявшегося процесса дизайн-ревью, поэтому я взяла инициативу на себя и выстроила процесс с нуля, создав таблицу в Figma, где можно было фиксировать правки, оставлять комментарии и прикреплять ссылки на макеты.
Со временем я решила обновить процесс. Собрала обратную связь с разработчиков и выстроила систему с учётом всех прошлых недостатков и сделала её удобнее, гибче и нагляднее.
Что было и как работало раньше
Старая система — это таблица в Figma, где:
- Разработчики самостоятельно отмечали выполненные правки.
- Были колонки для скриншота сборки, дизайна и ссылки на макет.
- Для разделения багов и обычных правок использовались теги.
- Всё было функционально, но требовало дополнительных пояснений — не всегда было понятно, о чём идёт речь.
Пример старой таблицы
Рядом с таблицей я расположила небольшую инструкцию для разработчиков о том, как отметить выполненную правку.
Как я улучшила процесс
Что изменилось:
- Теперь проблемные места выделяются прямо на скриншотах.
- Я подписываю исправления, показываю расстояния, сравниваю "как сейчас" и "как должно быть".
- Форма стала более гибкой и её проще заполнять.
- Теперь не разработчики, а дизайнер меняет статус правки, что помогает контролировать соответствие дизайну.
Пример нового процесса
Какие плюсы дал новый процесс
✅ Больше наглядности — разработчики сразу видят, что и где исправлять.
✅ Проще заполнять — гибкая система позволяет быстрее вносить правки.
✅ Контроль за статусами — дизайнер управляет процессом, а не разработчики.
✅ Меньше недопонимания — каждое исправление сопровождается чётким визуальным пояснением.
Вывод
Благодаря обновлённому процессу дизайн-ревью, команда стала тратить меньше времени на разбор правок, а работа над исправлениями стала более прозрачной. Теперь ни одна важная деталь не теряется, а итоговый результат ближе к задуманному дизайну.