Мы в Точке делаем эквайринг, онлайн-бухгалтерию и много других полезных продуктов для бизнеса. Все они постоянно дорабатываются, поэтому нам нужно непрерывно работать с дизайном и выпускать новые фичи.
Недавно мы заметили, что каждый раз исправляем в вёрстке одни и те же ошибки. Решили оптимизировать процесс дизайн-ревью и ввели чек-листы, благодаря которым количество правок сократилось в три раза.
Меня зовут Евгений Ерёмин, я продуктовый дизайнер в Точке уже более пяти лет. Расскажу подробнее о процессе оптимизации дизайн-ревью в этой статье.
Как мы работаем с дизайном
Сейчас наш флоу работы с дизайном выглядит так:
Идея: её может предложить продакт или сам дизайнер. После этого вместе обсуждаем, какие ресурсы нужны для выполнения задачи.
Проектирование: создаём первый макет и вносим правки. Сначала — с продактом, затем — с командой, которая будет работать с фичей. После этого делаем чистовой вариант с использованием дизайн-системы.
Груминг с командой: ещё раз обсуждаем, чтобы убедиться, что движемся в правильном направлении и на выходе не нужно будет всё переделывать.
Редактура: отправляем макеты редакторам и меняем тексты.
Дизайн-ревью с командой: коллеги проверяют макеты и оставляют стикеры с комментариями. Иногда можем созвониться, чтобы обсудить что-то подробнее.
Финальный груминг: разбиваем дизайн на итерации, составляем общий флоу (работа с бэком, фронтом, релиз и т.д.)
Разработка: отправляем дизайн программистам, а сами становимся саппортами — объясняем сложные моменты, уточняем детали.
Тестирование: отдаём фичу тестировщикам, чтобы они проверили и исправили баги.
Дизайн-ревью: смотрим вёрстку и исправляем ошибки.
Как проходит дизайн-ревью
Во время ревью мы проверяем все основные моменты: отступы, тексты, шрифты, размерности, анимацию, клиентские сценарии. Правки и комментарии для разработчиков прикрепляем в Jira: делаем скриншоты макета и дизайна, указываем несоответствия, подробно описываем, в чём проблема, и что нужно исправить. Это помогает:
Экономить ресурсы на исправлении багов в проде.
Уменьшить количество ошибок в интерфейсе и поддерживать качество клиентского опыта.
Очевидные минусы авторского ревью, которые мы выявили:
Может занимать много времени.
Сложно планировать работу — не знаешь, когда разработчик отправит тебе фичу на проверку.
Приходится часто переключаться между задачами и отвлекаться от текущих дел, чтобы снова вникнуть в контекст и дать обратную связь программистам.
Почему мы решились на изменения
В какой-то момент мы поняли, что каждый раз во время дизайн-ревью исправляем одни и те же ошибки. Чаще всего это:
Отступы — внешние и внутренние.
Текст и шрифт — не та размерность, толщина, кегль.
Лейаут — неправильная ширина страницы, размерности элементов внутри интерфейса.
Иконки — не тот размер или состояние.
Цвета — отличающиеся от макета.
Реже встречаются:
Неактуальные компоненты и устаревшие версии элементов.
Посторонние компоненты, которые разработчик сделал вручную, а не взял из UI-кита.
Неработающие переходы или кнопки, которые ведут не туда.
Элементы, которые ведут себя не так, как задумывалось — например, анимация.
Мы в команде любим своих разработчиков — это наши бадди, которые могут дать много крутых советов по технической части. И прекрасно понимаем, что иногда они ошибаются по объективным причинам — из-за ускорения разработки или нехватки времени. Но в то же время нам важно научить их следить за деталями, чтобы на выходе получать более качественный продукт. Поэтому стало очевидно, что процесс ревью надо менять.
Поиск решения
Первое, что мы сделали — попробовали ImageMagick, чтобы мэтчить скриншоты вёрстки и дизайна. Но уже после первого фронта отказались от этой идеи — было неудобно и сильно отрывало от контекста.
В итоге мы пришли к тому, что нужно:
Научить разработчиков пользоваться Figma, чтобы они могли смотреть на дизайн нашими глазами, видеть отступы в макетах и оценивать параметры.
Прийти к единому описанию ошибок, т.к. у нас масштабный продукт с большим количеством команд, среди которых периодически происходит ротация. Иногда мы работаем с новыми разработчиками и нам приходится заново подстраиваться друг под друга.
Сделать чек-лист с самыми распространёнными ошибками и встраивать его во все фронтовые задачи. Чтобы перед тем, как отправить работу на проверку, разработчик мог сам пробежаться по списку и посмотреть, всё ли соответствует макету.
Заводить мелкие правки в отдельные подзадачи и ставить их в приоритет на следующий спринт, чтобы не задерживать релиз.
Просто быть внимательнее, потому что это ещё никому никогда не мешало :)
Наши итоги
Команда поддержала нашу инициативу, и почти сразу после введения чек-листа мы получили отличный результат:
Улучшилось качество работы. Ребята начали обращать внимание на детали, которые не замечали раньше.
Время на авторский надзор уменьшалось с каждым ревью.
Мы стали меньше выпадать из процесса, так как исправленная работа приходит быстрее.
Уменьшилось количество ошибок. Если раньше в среднем было от пяти до десяти на одну задачу, то после введения чек-листов — не больше трёх. А некоторые задачи вообще не надо править.
Привели в порядок time-to-market и значительно скоратили время выкатки фичи на клиента.
Что ещё мы хотим поправить
Чек-листы дали отличный результат, но есть моменты, над которыми надо работать:
Сейчас разработчик может передвинуть задачу дальше по флоу, даже если не поставит галочки на все пункты чек-листа.
Мелкие правки мы начали выносить в отдельные подзадачи, но по ним не приходят уведомления, поэтому трудно среагировать, когда началась работа, и когда она завершилась.
Хотим сделать так, чтобы чек-листы автоматически добавлялись к любой задаче, у которой есть статус «ждёт дизайн-ревью».
А ещё было бы круто задействовать в этом AI. Уже есть несколько идей, как это можно реализовать, но пока не будем раскрывать карты 🙂
