Как и зачем растить процент дизайн-ревью?
Всем привет! На связи лид продуктового веб-дизайна Илона, лид дизайна мобильных приложений Полина и менеджер по развитию цифровых проектов Настя из T2. Сегодня мы расскажем про то, зачем проводить дизайн-ревью, как мы в компании растим процент задач, которые проходят дизайн-ревью перед релизом и наши первые результаты.
В целом дизайн-ревью, то есть проверка сверстанного дизайна на тестовом стенде или сборке, считается довольно базовой активностью и в некотором роде «гигиеной» при работе над задачами. Но, к сожалению, когда продуктов, проектов и команд много, а времени на запуск часто мало, дизайн-ревью становится той самой частью, которой начинают пренебрегать команды. В этой статье расскажем про то, почему делать этого не стоит и на своем примере покажем «до» и «после» и расскажем про наши шаги на пути к эталону, когда 100% задач проходят через этап дизайн-ревью.
Можно подумать, что мы рассказываем про дизайн-ревью в парадигме «у нас его не было, но сейчас появился», но это совсем не так. Процесс дизайн-ревью живет с нами уже очень давно. Сейчас, полечив более важные процессы, мы решили, что нужно взяться за систематизацию дизайн-ревью, сфокусироваться на нем и постараться максимизировать процент задач, которые проходят через данный этап.
Зачем вообще проводить дизайн-ревью?
Дизайн-ревью – это активность, которая требует затраты какого-то количества ресурса тестировщиков, руководителя группы разработки и, конечно, дизайнеров, а потому должны быть четкие причины его проводить. Можно ответить и просто «потому что так надо», но таким сложно замотивировать всех участников процесса, а еще это будет говорить о нерациональном использовании ресурса. А мы себе такого позволить не можем.
Для себя мы выделяем такие цели проведения дизайн-ревью:
- Влияние на метрику CSI. К сожалению, не всегда финальный сверстанный дизайн выглядит или работает так, как было задумано на этапе проектирования макетов, поэтому дизайн-ревью – отличный шанс отловить все недочеты и сгрузить их в разработку для правок, чтобы конечные пользователи увидели продукт таким, каким он был задуман.
- Снижение рисков ошибок (влияем на метрику «количество дизайн-багов на проде»). Конечно, обнаружением критических ошибок, которые блокируют работу функционала занимаются тестировщики, но и дизайнеры должны смотреть не только на UI-элементы, но и на то, корректно ли работает сам сценарий.
- Управление ожиданиями и согласование. Именно на этом этапе все циклы разработки продукта могут свериться, посмотреть на результат и дать обратную связь.
- Экономия ресурсов. Если в прод попадает то, что можно было бы найти и скорректировать на этапе дизайн-ревью относительно безболезненно, то на исправление уже зарелиженного уйдет больше ресурсов, так как команды не простаивают, и после старой задачи идет новая, а в таком случае новую придется отложить. А если функционал и вовсе как-то не так работает, то это может привести к снижению количества подключений и продаж, а значит компания теряет деньги.
Как у нас устроен процесс дизайн-ревью?
Когда мы планировали внедрение дизайн-ревью, нашей задачей было сформировать процесс, который будет занимать минимум ресурса команды разработки или не будет вообще (за исключением исправления багов), а также он должен выглядеть бесшовно для команды разработки.
Ключевые участники процесса - это дизайнер, проджект-менеджер и руководитель группы разработки. Задача дизайнера - провести ревью, найти ошибки, описать их и отдать их в команду разработки. Задача руководителя разработки – сигнализировать дизайнеру о том, когда и где можно проверять задачу, обеспечить дизайнера доступами. Задача проджекта – проконтролировать и убедиться, что дизайн-ревью случилось. Решение найденных ошибок вписывается в обыденный процесс работы с ошибками у команды разработки, поэтому на этом процесс дизайн-ревью заканчивается.
Таким образом, получилась следующая схема:
- На этапе финализации тестирования руководитель группы разработки заводит задачку в таск-менеджер на дизайн ревью к родительскому “эпику”. Его задача – указать в требовании, на каком стенде (если веб) или в какой тестовой сборке (если мп) смотреть задачу и какие тестовые доступы можно использовать. Такое требование назначается на дизайнера.
- Дизайнер сам реагирует на требование и проходит по сценарию, используя доступы, которые ему приложили. Проводит проверку и формирует документ в figma с описанием ошибок и уровнем их критичности. Получившийся документ дизайнер прикладывает в требование.
- На найденные баги заводится отдельная ошибка в нашем таск-менеджере, которая сразу назначается на разработчика.
Стоит также уточнить, как мы определяем критичность багов. Мы делим их на три уровня: низкий, средний и высокий.
- Низкий уровень — это минорные недочёты, которые не влияют на функциональность, но задевают тонкие струны души дизайнера или UX-редактора: например, неправильные переносы текста, смещение картинки на пару пикселей и тому подобное.
- Средний уровень — ошибки, которые выглядят как заметная глазу обычного пользователя некорректная вёрстка макета. Это, например, слишком большие или маленькие отступы между блоками, изображения низкого качества и прочие визуальные несоответствия.
- Высокий уровень присваивается тем багам, которые действительно «бросаются в глаза». Это неверные тексты, отсутствие элемента, предусмотренного дизайном, неправильные переходы или анимации, сильная деформация графики, а также любые отклонения от исходного макета, которые будут заметны даже недизайнеру.
Вот как выглядит образец таблички с комментариями для разработчиков. Такой формат уже проверен временем и с момента начала систематизации процесса ревью пункты таблицы остаются неизменными — в ней нет воды, а только все самое нужное. В мобильном приложении на каждую платформу (iOS и Android) своя таблица — баги не всегда одни и те же, а иногда на одной из платформ их вообще может не быть.
При этом мы понимаем, что описывать дизайн текстом не всегда хорошая идея, так что каждому пункту таблицы соответствует один или несколько скриншотов, где цифра на картинке соответствует пункту комментария. Рядом дизайнер также прикладывает макет, чтобы сразу была видна не только ошибка в дизайне, но и образ идеального результата.
Со стороны может показаться, что мы слишком дотошно подходим к описанию багов, мол чего там расписывать и ставить кучу цифр. Но такой уровень подробностей позволяет нам избежать длинных переписок в личных сообщениях со множеством уточнений и перекидыванием скриншотов. Этот этап мы проходили до систематизации процесса, и поверьте, он был длиннее и неудобнее.
У дизайнера также есть фиксированный срок, за который он должен провести ревью — три рабочих дня с момента назначения задачи на исполнителя. Это нужно, чтобы разработчики успели исправить максимум багов до релиза. В противном случае смысл наших усилий теряется, и если ревью будет растягиваться до бесконечности, то все баги окажутся на проде. Конечно, всегда есть исключения — дизайнер может быть в отпуске или на больничном, тогда к процессу подключается лид и делает ревью за дизайнера.
Сложности, как всегда, возникают там, где сохраняется «человеческий фактор». Ниже мы рассказываем, как боремся с этой проблемой. Одно из решений, которое помогло бы совсем избавиться от человеческого фактора, - это создание автотестов на соответствие макетам. Но это могло бы помочь нам закрыть только одну из целей, перечисленных выше, (отлавливание багов), поэтому не является «таблеткой», но может быть усилением этого процесса.
Как мы считаем общее количество задач, прошедших ревью?
Чтобы оценить эффективность, любой процесс должен быть оцифрован. Ключевая метрика, которая могла бы нам ответить на вопрос, как хорошо работает процесс, - это количество дизайн-багов на проде. При работе с процессом мы столкнулись с тем, что он плохо соблюдается, отсюда и эффект был не таким выраженным. Поэтому целевой метрикой на первый год применения процесса мы поставили именно процент покрытия задач проведенными дизайн-ревью. Это помогает нам видеть, насколько соблюдается процесс.
% покрытия задач проведенным дизайн-ревью мы считаем так:
Именно за этим показателем мы сейчас и наблюдаем пристальнее всего.
Как мы растим процент задач, прошедших дизайн-ревью?
Если искать в интернете способы роста процента задач на дизайн-ревью, то будут перечислены: регулярные встречи, чек-лист для работы над задачей, использование таск-трекеров для фиксации задач на разных этапах, плагины и отчеты, фиксирующие итоги ревью.
Мы решили, что бездумно брать все эти пункты – не для нас, поэтому что-то мы отмели, а что-то кастомизировали и докрутили под себя.
У нас есть очень важная автоматизированная вещь для контроля – (1) запрос, который по определенному признаку показывает все продуктовые задачи (уровень эпика) и на которые уже должно быть требование на дизайн-ревью; (2) запрос, который агрегирует и выводит все требования (уровень тасок) на дизайн-ревью. Из этих запросов формируется отчет - какие задачи требуют дизайн-ревью, по каким он был, а по каким еще нет. Это помогает понять, где должно было быть дизайн-ревью и где было проведено.
Помимо автоматизированного запроса, некоторые части все же держатся на «ручнике», то есть периодически лид команды дизайна должен проводить следующие ритуалы:
- Мониторинг досок стримов
В нашем таск-трекере есть возможность заходить на доски разработки разных продуктов. Там есть колонка UAT/IT, нахождение задач на которых говорит о том, что разработка завершена и сейчас проводится тестирование. Как раз этот столбец мы и мониторим и отлавливаем вручную задачи примерно раз в 1-2 недели, чтобы понять, что никакая задача не пройдет мимо дизайн-ревью. - Коммуникация с ответственными за дизайн-ревью
Да, мы говорим о том, что за дизайн-ревью ответственность лежит на дизайнерах, но не только на них. Руководитель группы разработки (иногда также аналитики или тестировщики) или проджект-менеджеры должны со своей стороны также следить за дизайн-ревью и создавать требования на дизайнеров. После того, как стало известно, по каким задачам не хватает таски на ревью, лид дизайна совершает обход руководителей группы разработки или проджектов и просит создать ее по процессу. Как правило в ответ мы либо получаем ссылку на ревью со всеми деталями, либо ответ со сроками его проведения (когда задача еще не до конца готова к нашей приемке). - Регулярный мониторинг процента дизайн-ревью
Раз в месяц лидами дизайна и ответственным проджектом проводится срез состояния – насколько хорошо мы движемся, какие есть затыки, требуются ли какие-то корректировки в процесс. Также мы смотрим, есть ли команды, в которых дизайн-ревью проводят реже — в таких случаях инициируем точечные встречи и пытаемся понять, в чем проблема. У нас есть две точки контроля:
1) % дизайн-ревью по задачам в проде. Это наша целевая метрика, мы ее растим.
2) % дизайн-ревью по задачам в тестировании, используется как контрольная метрика, которая помогает нам стабилизироваться и посмотреть, какую работу нам нужно проделать, чтобы поднять этот % и метрика 1 была выше при закрытии этих задач.
Какие могут быть исключения из правил и что можно не ревьюить (или просто не получится)?
Несмотря на то, что мы говорим, что мы стремимся к 100% задач, которые проходят через дизайн-ревью, это не совсем так. Мы говорим не про все-все задачи, а только про те, для которых проведение ревью в принципе возможно. Давайте посмотрим на то, какие мы делаем исключения:
- задачи, которые затрагивают персональные данные, интеграции, например, с Госуслугами или другими сервисами, для которых довольно тяжело раздобыть тестовые номера. В них мы проверяем верстку только до этапа перехода в контур другого сайта/приложения;
- задачи, которые визуализируют персональные офферы для абонентов и настраиваются другими функциями. У нас в компании есть центры компетенций, которые занимаются настройкой таргетированных предложений для пользователей в зависимости от их интересов, купленных услуг и других параметров. Так вот даже когда к нам на дизайн приходит задача на проектирование опыта таких абонентов, не всегда получается провести ревью, так как сымитировать такой тестовый номер довольно тяжело технически. Поэтому в таких задачах мы либо обходимся ревью прода (и приходим к разработке в случае проблем), либо проводим ревью по скриншотам;
- мелкие багфиксы или задачи со сменой буквально пары пикселей. Такие задачи мы также осознанно не ревьюим, так как это уже исправление чего-то мелкого и к тому же, как правило, строится на компонентах дизайн-системы, которая в коде у нас полностью готова. Ревью таких задач, возможно даже займет больше времени, чем их дизайн, поэтому и в нашей статистике мы такие задачи не учитываем, ставим для них тег “исключение”.
Поэтому важно помнить и понимать, что дизайн-ревью – не панацея, и надо относиться к ресурсу на него осознанно. Мы гонимся не за количеством ревью, а за их качеством.
Результаты и потенциал развития процесса
По результатам проведенной работы в командах веб-разработки количество задач, которые проходят через дизайн-ревью, выросло примерно на 30 п.п. Это мы дружно считаем отличным результатом (но все еще не идеальным). Начинали мы не с 0%, так что итоговая цифра нас вполне устраивает, но, как говорится, бесконечность – не предел, и мы продолжаем стремиться к максимальному результату.
В командах разработки мобильного приложения мы мониторим эту метрику уже второй год. Существенный рост задач, проходящих через дизайн-ревью, у нас случился ещё в прошлом году, но в этом мы продолжаем эту динамику и наблюдаем +15 п.п. разницы с прошлым годом.
Наша задача на будущее – посмотреть корреляцию этого показателя с общим количеством дизайн багов на проде, чтобы оценить эффективность процесса. Опираясь на тот результат, мы сможем построить дальнейший план развития этого процесса.