Как мы внедрили дизайн-ревью и повысили качество разработки

Мы в Lamoda Tech запустили дизайн-ревью в клиентской разработке и теперь экономим в среднем до 20% времени работы команды тестирования.

Привет! Меня зовут Наташа Филиппова, я руководитель группы разработки в Lamoda Tech. В этой статье расскажу, как реализовать этот процесс в своем флоу и настроить его этапы так, чтобы они не мешали, а дополняли и улучшали общую работу.

Однажды, еще до пандемии, мы работали над добавлением на платформу фотоотзывов. Тестирование только одного из десятка макетов шло больше трех часов. Наконец тестировщик позвал на помощь дизайнера. Тот попросил тестовый телефон, протестировал всю функциональность за 10 минут и нашел 5 недочетов.

Тестировщику, чтобы сравнить сборку с макетом, надо вручную проверять каждый пиксель, учитывая их плотность. Особенно это актуально в мобильных приложениях. Например, на Android есть приложение Window VQA, с помощью которого можно протестировать размеры кнопок, отступы. На iOS таких приложений нет.

Наметанный глаз дизайнера способен заметить тончайшие детали, которые могут быть упущены при ручном тестировании. Способность специалистов к визуальному восприятию можно сравнить с тем, как быстрее и эффективнее понять и проанализировать текст на английском может тот, для кого этот язык родной. Аналогично опытный взгляд дизайнера может сделать процесс разработки более глубоким, качественным и быстрым.

Раньше дизайнеры обычно видели результаты своей работы лишь на собственном устройстве, когда функционал уже выходил в продакшн. Из-за этого сильно страдало качество.

Если возникали какие-то ошибки, фикс занимал значительное время из-за долгого цикла развертывания на Android и особенно на iOS. Раньше мы выпускали релизы каждые 2 недели. Если вдруг какой-то баг, который не заметили QA, попадал на прод, то исправление — от постановки задачи до новой раскатки на пользователей — занимало минимум 3 недели.

Кроме всего прочего, дизайнеру в такой системе могло показаться, что он работает в стол. Делаешь, отрисовываешь, отдаешь, а потом не попадаешь в выборку A/B-тестирования и просто не видишь результатов своего труда. А фича показала не очень хорошие результаты, и ее решили не раскатывать на пользователей.

Поэтому внедрение нового этапа тестирования UI, предложенное дизайн-командой, показалось нам необходимым шагом, особенно учитывая быстрые темпы разработки и релизов в нашей компании.

Наши QA проверяют все — цвета, расположение элементов, анимации. Еще пару лет назад это требовало тщательной работы, включающей, например, замеры отступов в пикселях с помощью GIMP. Сегодня недочеты и ошибки в визуальной части дополнительно проверяют те, кто создает дизайн. Такой этап проверки существенно увеличил качество выпускаемых в прод релизов. Мы перестали копить низкоприоритетные баги, а QA меньше времени тратят на тестирование UI.

Сначала мы решили, что будем передавать дизайнерам на проверку фичи, которые хоть как-то затрагивают визуальную часть продукта, сразу после разработки. Они смотрели их на устройствах QA или своих личных либо получали в виде скриншотов, задач и комментариев.

Адаптация к изменяющимся условиям, вызванным COVID-19, требовала изменения подхода к процессу — просто показать сборку на тестовом устройстве стало невозможно из-за удаленки. Мы стали прикладывать к отчетам скриншоты и видео, писать комментарии с запросами на проверку и тегать дизайнеров. Это позволило эффективнее контролировать качество, даже несмотря на отсутствие возможности передавать устройства дизайнерам для быстрой оценки.

Однако мы понимали, что проверка на реальных устройствах является несомненным преимуществом, так как позволяет увидеть работу анимаций и другие детали, которые могут быть упущены при тестировании по скриншотам и видео.

Мы выдали каждому дизайнеру по одному тестовому девайсу. Научили устанавливать сборки, раскатывать на себя различные переменные и теперь они могли самостоятельно тестировать дизайн и анимации. Такая практика не только ускорила процесс тестирования, но и улучшила эффективность, обеспечивая более детальную оценку дизайна и более активное выявление потенциальных проблем.

Теперь QA брали задачи, проводили тестирование и затем передавали дизайнерам для дополнительной проверки. Так в итерации появилось два этапа взаимодействия.

Подход с перераспределением ролей и упором на основные задачи дизайнеров оказался более эффективным. Это позволило QA тратить меньше времени на тестирование дизайна и сфокусироваться на других видах тестирования.

Эти изменения сократили общее время тестирования UI в среднем на 20%

Между тем, такая перестройка процессов была сопряжена с двумя трудностями:

1. В первые месяцы мы выдали дизайнерам по одному устройству. Однако, когда переход к новому флоу показал результаты, всем, кому требовалось, выдали и по второму, на другой операционной системе.

2. Необходимость улучшения коммуникации в процессе. Недостаток прозрачности и связи между QA, дизайнерами и продактами создавал сложности в передаче задач, отслеживании их статусов и реагировании.

В рабочем мессенджере мы создали отдельный чат для координации и отслеживания процесса дизайн-ревью. Дизайнеры сами предложили использовать эмодзи для обозначения статусов задач. Например, 👀 — означает «задачу увидел, смотрю». Такие внутренние «ритуалы» сделали процесс наглядным и понятным для всех участников.

Самое главное — мы добавили в воркфлоу новый статус дизайн-ревью для прозрачности. После тестирования задача может уйти либо на ожидании релиза либо на дизайн-ревью, если были изменения в дизайне. Если дизайнер замечал недочеты, то отдавал сразу на фикс разработчикам, если замечаний не было, то возвращал обратно на тестирование, так как QA принимает окончательное решение о качестве продукта и отдает в релиз.

Мы поняли, что тестировать дизайн руками QA сложно с точки зрения тестирования, но просто с точки зрения процесса. Однако тестировать руками дизайнеров — наоборот, просто с точки зрения тестирования, но сложно с точки зрения процесса.

Поэтому, потратив около года на доработку флоу и на техническое дооснащение дизайнеров, мы на выходе получили более легкую и эффективную систему, а главное — повысили качество конечного продукта.

Примерно через полгода после внедрения в мобильные приложения систему раскатали и на Web. Теперь вся клиентская разработка в Lamoda Tech проходит тестирование в новом воркфлоу. Этот подход дает значительно большую эффективность при экономии времени команды в среднем до 20% и вообще считается стандартом на рынке.

Теперь наши дизайнеры сами проверяют реализацию своих макетов, QA не пытаются считать пиксели и сравнивать шрифты «на глазок», а в разработке значительно снизилось количество багрепортов.