Как организовать и оптимизировать дизайн-ревью
Возможно вам, как и мне, не чуждо запариться за пиксели. После чего хочется, чтобы на проде всё выглядело как в макете. Но такое редко случается, обычно надо посмотреть вёрстку несколько раз и написать пару комментариев разработчику. В общем, в какой‑то момент ревью становится каждодневной рутиной, а рутину нужно что? Правильно — оптимизировать. Собственно именно этим я постоянно занимаюсь и хочу поделиться самыми интересными решениями.
Небольшой оргмомент:
Если вы уже прошарены в теме, и у вас выстроены процессы, смело листайте до: «Пути оптимизации».
Чтобы дальше говорить на одном языке, давайте разберёмся с неймингом. Дизайн‑ревью, ревью и авторский надзор — это всё разные названия одного процесса: приёмки готового продукта со стороны дизайна. Терминология часто меняется от команды к команде, так как в мире нет зафиксированного стандарта. Например, в Точке мы используем «авторский надзор», чтобы избежать путаницы с процессом дизайнерского ревью, когда дизайнеры проверяют макеты друг друга.
Как организовать дизайн-ревью
В рамках дизайн‑ревью дизайнер по факту становится тестировщиком, просто с упором не на логику, а на визуал. По этому я рассматриваю дизайн‑ревью, как один из этапов внутри глобального процесса тестирования, имеющего, на самом деле, огромное количество разветвлений. Правда их количество и качество тестирования, в целом, сильно зависит от уровня развития как команды, так и компании.
Тестирование? Нее, не слышали…
В худшем случае вы можете столкнуться с полным отсутствием процесса тестирования как такового (а значит и дизайн‑ревью). Условно у вас есть разработка, потом где‑то кто‑то не системно потыкался, и всё поехало в прод.
Плохой процесс разработки
И если в вашем проекте дела обстоят так, то дизайн‑ревью становится второстепенным. Визуальные баги — это мелочь по сравнению с высокой вероятностью наличия технических багов, мешающих клиентам полноценно пользоваться продуктом. Тут вашей главной задачей становится убедить бизнес в важности комплексного тестирования.
На первое время можно договориться на обязательную проверку перед релизом со стороны дизайнера и продакта/руководителя проекта. А найденные баги использовать как аргументы для найма профессионального тестировщика.
Тестирование есть, но вас туда не звали
К счастью, отсутствие тестирования — это уже достаточно редкий кейс, и бизнес понимает, что лучше проверить всё до релиза, чем потом разгребать негатив. Поэтому, скорее всего, процесс на старте будет такой: дизайн, разработка, тестирование и только затем релиз в прод.
Стандартный процесс разработки
Вроде бы всё хорошо, начало положено, и в эту схему легко добавить дизайн‑ревью. Но есть одна проблема — чаще всего такая ситуация полностью устраивает команду/бизнес. Поэтому всегда помните, что именно вы, как дизайнер, заинтересованы в организации ревью, и никто не принесёт вам готовый процесс. Это не потому что менеджеры/разработчики плохие, просто у них другой уровень восприятия качественно сделанного продукта. Он работает как описано в ТЗ? Не ломается и не порождает обращения? Супер! Мы сделали всё хорошо, кровь из глаз дизайнера — это уже детали.
Если это ваш случай, начните с того, чтобы донести команде последствия отсутствия дизайн-ревью. Например:
Дизайн — это лицо продукта, и клиенты часто делают выводы о его качестве исходя из внешнего вида. Как говорится, встречают по одёжке. Поэтому выпуск некачественно свёрстанного сайта/приложения может повлиять на доверие к продукту и его репутацию. Правда у меня была весёлая ситуация, когда клиент написал «у вас весь сайт поехал», а это была такая дизайн-концепция. К счастью это был единичный случай, так как если таких отзывов много, возможно, стоит задуматься о пересмотре концепта.
Визуальные баги могут ломать клиентский опыт так же, как и технические. Например, некорректные цвета или изменение размера могут помешать клиентам взаимодействовать с элементами интерфейса (они их не заметят или не смогут кликнуть), а разная механика одного и того же элемента на разных страницах сломает привычки пользователя. Причём, если у вас уже были такие ситуации в проекте, расскажите о них, аргументация всегда лучше работает на реальных примерах.
Дизайнер лучше понимает пользовательское поведение и может заметить неочевидные/плохие механики, которые, порой, появляются в ходе тернистого пути разработки. У нас был случай, когда заехало обновление лейаута без теста от дизайнера. В рамках доработки добавили возможность включать вторую колонку и, чтобы дать возможность скроллить их асинхронно, сделали механику скролла по наведению на колонку. Но вот беда — такая механика сохранилась и для ситуации с одной колонкой. Как следствие, держа курсор вне контентной зоны колонки пропала возможность скроллинга страницы целиком. Команда разработки решила, что это валидное поведение, а дизайнеры пришли слишком поздно. В итоге посыпались обращения от клиентов — как скроллить?
Дизайн состоит из огромного количества элементов, а разработчики — не роботы и могут ошибаться. Тестировщики не могут подметить все визуальные тонкости, поэтому дизайн должен принимать дизайнер.
После того как команда поймёт зачем и почему, вам будет проще добавить в процесс разработки этап дизайн-ревью.
Все согласны, погнали
Есть два типичных варианта «внедрения» дизайн-ревью в стандартный процесс, назовём их условно: каскадный и параллельный, и рассмотрим плюсы и минусы.
Каскадный процесс
Этот вариант подразумевает строгую очередность действий, и в нём дизайн-ревью начинается только после проверки и исправления замечаний тестировщика.
Схема каскадного процесса
Плюсом такого подхода является возможность дизайнера сфокусироваться на визуале, т. к. все механики уже отсмотрел тестировщик. Также к моменту ревью будут решены технические проблемы, которые могли мешать проверке и, возможно, даже очевидные визуальные баги, если ваш тестировщик умеет смотреть визуал.
Но при этом есть большой минус, который часто критичен для команды — это увеличение времени тестирования. Потому что сначала мы проходим раунды туда-сюда на этапе тестирования, и потом история повторяется на дизайн-ревью.
Параллельный процесс
Этот вариант подразумевает одновременное тестирование, т. е. дизайнер начинает вместе с тестировщиком или сразу после него, не дожидаясь исправления багов.
Схема паралельного процесса
Очевидный плюс — это уменьшение времени тестирования, и чаще всего это перекрывает минусы:
Наличие возможных функциональных/логических багов, которые всё ломают и мешают вам тестировать.
Двойная работа, так как вы можете одновременно с тестировщиком описывать одни и те же вещи. Но это легко решить: начинайте после тестировщика, предварительно сверившись с его замечаниями.
У нас в команде по умолчанию зафиксирован каскадный подход, но при горящих сроках я подключаюсь сразу после тестировщика. Поэтому рекомендую смотреть по текущей ситуации и оценивать, какой вариант вам сейчас больше подходит.
А можно скипнуть?
Даже если вы выстроите максимально лояльный процесс, к вам не раз придут с этим вопросом. И на самом деле ответ: да, можно! А порой даже нужно.
Чаще всего визуальные недочёты не влияют на продукт. Да, вёрстка не соответствует макету, и вам может не нравится, как это выглядит. Но если пользователь может использовать фичу и совершать все действия, которые вы для него запланировали, не стоит задерживать выкатку.
Ведь главное — доставить ценность до клиентов! Большинство из них может даже не заметить визуальные недочёты. Именно поэтому в определённых ситуациях и с оговоренным планом действий пропуск дизайн-ревью — это целесообразное решение.
К таким ситуациям относятся сжатые сроки реализации. Как я говорила ранее, команды не всегда понимают ценность исправления визуальных багов. И в разы сложнее донести эту ценность, когда пользователи заваливают техподдержку гневными обращениями, или начальство поджимает. Поэтому лучше сперва снять боль пользователя/бизнеса, а позже дотюнить визуал.
Вторая ситуация — это очень маленькая задача. Например, вы вносите какие-то незначительные изменения, в которых надо еще постараться что-то сломать, или добавляете какую-то стандартную модификацию из вашего ui-кита. Качество исполнения такой задачи может проверить тестировщик, а вы сэкономите свой ресурс и будете меньше переключаться.
Ну, а чтобы ничего не терялось, согласуйте с командой порядок действий после релиза, например:
что вы проводите ревью прода раз в N времени;
что все найденные в рамках ревью баги решаются в течение N времени.
Пути оптимизации
Маленький дисклеймер: в нашей команде дизайнер — узкое горлышко, и мы всячески пытаемся разгрузить моё время и сократить переключения. Поэтому некоторые нижеописанные способы оптимизации заключаются в гармоничном переключении отдельных процессов на тестировщиков/разработчиков. А если у вас в компании, наоборот, загружен отдел тестирования, вам, скорее всего, подойдет лишь часть пунктов. В общем, действуйте по ситуации.
1. Работа с процессом
Закрепите процесс в таск-менеджере
Добавьте дизайн-ревью как этап флоу задачи. Например, мы работаем в Jira, и после тестирования таска автоматически назначается на дизайнера, указанного в задаче, и переходит в статус «Ждёт авторского надзора».
Флоу задачи в Jira
Также создайте несколько типов задач, в зависимости от которого будет определяться обязательность прохождения дизайн-ревью. Например, мы с командой договорись о трех типах со следующим поведением:
Новая фича — для заезда чего-то нового и сложного, их дизайнер смотрит обязательно. Причём толкнуть ее дальше по флоу может только участник с ролью «Дизайнер».
Доработка и Баг — для незначительных изменений, их принимает только тестировщик.
Кроме того, рекомендую собирать отдельную доску, куда будут попадать все баги по вашему проекту. В чём профит? Так процесс сложнее пропустить или сломать, а задачи не будут теряться и будет проще контролировать их статус.
Передавайте баги «правильно»
Узнайте у разработки, где им удобнее работать с багами. Спойлер, скорее всего, ответом будет название вашего таск-менеджера, т.к. вся информация по задаче хранится в одном месте и с ней легко ознакомиться всем участникам команды, но пока не спросишь не узнаешь.
Кроме места так же важен формат передачи, вот несколько ключевых аспектов:
Описывайте в формате действия с параметрами что на что исправить. Например, вы заметили, что отступ после шапки сайта маленький. Можно написать коммент в формате констатации факта, но это неэффективно, т. к. у разработчика останется вопрос: «а какой отступ должен быть?», и это выльется в поиски на макете, дополнительную коммуникацию или неточное исправление.
При этом если описывать баг как инструкцию к исполнению, разработчику будет сразу понятно, что нужно сделать, и этих проблем не возникнет.
Сравнение двух путей описания бага
Если баг есть только при определённых условиях, опишите порядок действий для его воспроизведения. Добавьте платформу/браузер/тестовый аккаунт, если они влияют на проявление бага.
Прикладывайте скрины или видео для наглядности, а также ссылки на экраны в макетах, если исправления большие.
В итоге уменьшится объём коммуникаций с разработкой и повысится точность исправлений, а значит сократится количество возвратов и повторных проверок.
Расставляйте приоритеты
При проведении ревью вы можете найти большое количество багов. Тут важно понимать, какие из них реально блокируют выкатку, а какие нет. Поэтому всегда анализируйте критичность бага и давайте разработке отложить его исправление на потом, если он не блокирует работу с сервисом.
Такой подход поможет сократить общий Тime to market, при этом самостоятельно определяя приоритеты вы будете лучше контролировать итоговое качество продукта.
Зафиксируйте регламент
Как я говорила ранее, нужно иметь план после релиза, но можно зафиксировать с командой регламент — в какие сроки и с каким приоритетом будут решены визуальные баги. Это поможет вам легче отпускать на прод «неидеальные» задачи, так как вы будете понимать, что эта «какашка» тут лишь на пару спринтов. Например, у нас есть вот такой файлик в конфлю, где мы обо всём договорились:
Регламент по процессу разработки и тестирования
Предварительная подготовка задачи
Если у вас сложный интерфейс с большим количеством состояний, которые зависят от внешних условий или типов пользователя, попросите тестировщика формировать и оставлять в задаче тестовые аккаунты для их проверки.
Так задача будет сразу готова к тесту. Не придется чего-то ждать или искать, вдобавок сократится время тестирования.
Попросите прикладывать тестовые сборки
Приёмка задачи на правильной версии сборки — наиважнейший аспект при работе с приложениями. У меня не раз были ситуации когда смотришь — ничего нет. Начинаешь общаться, выяснять, и оказывается, что просто смотришь не там. Поэтому попросите разработчика добавлять конкретную сборку в задачу, так вы сократите коммуникации и ошибки по невнимательности.
2. Экономим свое время
Передайте повторную приёмку
После ревью должен остаться чёткий список что и на что исправить, по которому принять задачу сможет любой участник команды.
Поэтому полезно договориться с тестировщиками о проверке исполнения найденных вами багов. Так уменьшится время тестирования, тестировщик будет учиться смотреть визуал, а вы — меньше переключаться.
Принимайте по скринам
При проверке приложения достаточно много времени может занимать поиск тестового устройства, скачивание и установка нужной версии, а также поиск нужного экрана. Поэтому, если изменения сфокусированы на одном/двух экранах, можно попросить тестировщиков приложить к задаче скрины.
Например, после диалога с ребятами оказалось, что им несложно добавить в отчет скрин, и это несильно увеличивает время теста. Зато мне больше не надо тратить время на подготовку к тестированию. В итоге задачи проходят ревью за пять минут вместо тридцати, чему все очень рады.
Попробуйте использовать тест-кейсы в больших задачах
При заезде крупных задач легко запутаться в экранах, пропустить часть состояний или отсмотреть их по несколько раз. Чтобы этого не случилось, можете попросить у команды тестирования тест-кейсы или сформировать их самостоятельно и использовать при проверке как чек-лист.
3. Работа с командой
Проведите обучение с разработкой
Многие визуальные баги можно снять, повысив внимательность разработчиков. Проанализируйте, какие замечания чаще всего у вас встречаются, и попросите команду обращать на эти места больше внимания. Также можно подумать над форматом чек-листа по проверке до передачи на тест, чтобы у ребят ничего не забывалось.
Кроме невнимательности может быть банальное незнание, что можно сделать как-то иначе, или что какая-то инфа есть в Figma.
Например, у нас часто встречалась проблема со сборкой аватарки. Визуально она смотрится как шейп с иконкой, и именно так разработчики собирали её. Но на самом деле — это цельное изображение. Когда я спросила, почему ребята делают так, оказалось, что во-первых, им неочевидно, какой тип брать из кита — с иконкой или с изображением, а во-вторых, в самом ките неочевидно, что есть тип с изображением. В итоге одного объяснения, где смотреть тип в Figma и как это собрать правильно на ките, хватило, чтобы полностью снять эту проблему.
Пример аватарки
Научите тестировщика принимать дизайн
Ну и последний совет, правда не по лёгкости — научить вашего тестировщика проверять дизайн. Ребята проводят в проекте уйму времени, постоянно отсматривая кучу экранов и будет здорово, если в процессе они будут подмечать дизайн.
Для начала узнайте у команды, готова ли она к этому, а после проведите обучение, показав на практике как смотреть дизайн. Из основного что стоит затронуть:
расскажите с чем чаще бывают проблемы и на чём фокусировать внимание. Например, у нас часто путают наборы иконок или вёрстка сильно едет на адаптиве, поэтому я просила их в первую очередь проверять это;
посоветуйте плагины для ревью, которые помогут упростить процесс;
расскажите про скриншотное тестирование и как его легко провести.
Как итог ребята снимут с вас простые визуальные баги и вам будет проще проверять задачи.
Вот и все основные улучшайки, если вы тоже занимались оптимизацией процесса дизайн-ревью обязательно поделитесь в комментариях идеями, ведь это беспрерывный процесс и всегда есть, что подтюнить.
А в завершение хочется сказать: процессы — процессами, но старайтесь соблюдать баланс между клиентом и бизнесом, качеством и сроками. Не нужно всегда требовать сиюминутных исправлений, лучше подстраиваться под ситуацию. В долгосрочной перспективе гибкий подход и внимательность к нуждам бизнеса дадут вам большую отдачу от команды. Так вы покажете себя открытым к диалогу и болеющим за продукт, а не за пиксели. Да и будем откровенны, пиксель пёрфект — то ещё зло)
