Про важность дизайн-ревью в продуктовом процессе
Расскажу про важнейший этап в процессе релиза, который отсутствует у многих продуктовых команд. Подсвечу, какие проблемы это решает. Дам рекомендации, как интегрировать этот этап в процесс. Поделюсь своим опытом и бонусом приложу пример шаблона оформления итогов дизайн-ревью.
Дизайн-ревью — это когда дизайнер проверяет результат верстки своего макета разработчиком и фиксирует, что не так.
Какие проблемы решает?
Дизайнер не в курсе, что уже в продакшене, а что нет. Для дальнейшего успешного развития продукта, дизайнер должен быть в курсе актуальных статусов, чтобы закладывать новую логику.
Дизайнер может выгореть, если конечный результат будет совсем не такой, какой был задуман изначально. Качество его работы может сильно упасть из-за отсутствия смысла. Он перестанет чувствовать важность своей роли в команде.
Отсутствие командного взаимодействия максимально важной связки дизайнер-разработчик. Две эти роли не будут плотно взаимодействовать — потеряется командное стремление развивать продукт.
Трата ресурсов на разработку и релиз. Без привлечения дизайнера на дальнейшие итерации релиза, команда затратит больше времени, пытаясь разгадать, что дизайнер имел ввиду.
Низкое качество интерфейса продукта. Не вовлечение дизайнера в другие процессы, помимо отрисовки макетов, может повлечь за собой неконсистентность и отстуствие унифицированных решений, разрушение дизайн-системы, разрушение tone of voice продукта и пр.
Отсутствие продуктовой культуры в решении задач. Каждый отдельный сотрудник мало вкладывает в общий результат и просто действует по инструкции. Чтобы создавать продукт, ответственность должна быть распределена. Это первый принцип продуктовой культуры.
Как внедрить?
Начну с того, что пока дизайнер не будет уважать свою работу и сам не придет с предложением внедрения дизайн-ревью, то скорее всего никто выше не созреет на такое нововведение. Важно донести до команды, зачем это нужно и какие проблемы решит. Несомненно, тут будут важны ваши софт скилы, чтобы договориться об изменениях.
На самом деле, тут не обязательно уделять супер много времени и переделывать весь ваш процесс. Достаточно верхнеуровнего просмотреть результат и проверить, все ли так, как вы (дизайнер) задумывали. Делать это можно параллельно с этапом тестирования, если ваше руководство боится срыва сроков релиза. Дизайнер проверит результат со своей профессиональной колокольни, а тестировщик со своей (досконально до мелочей).
Подсвечу одну проблему возможного конфликта и недопонимания. Важно, чтобы тестировщик не думал, что дизайнер отнимает его работу. У этих ролей абсолютно разный сет навыков. Дизайнер только разгрузит тестировщика, и это может точно также положительно сыграть на командном взаимодействии.
Маленький нюанс — нужно понимать, чтобы эффективно ревьюить результат, дизайнер должен уметь взаимодействовать с браузерными инструментами разработчика, плагинами и прочим.
Мой опыт
Когда я пришел в SberDevices, в процессах не было практики дизайн-ревью. И конечно же, макеты в деталях не соответствовали продакшену. Одной из моих основных задач было улучшение качества продукта, и пуш этой проблемы стал важным пунктом. Моя команда оказалась супер адекватной и понимающей, поэтому обосновав необходимость этого этапа в наших процессах, мы обсудили все нюансы и согласовали эту интеграцию. Особых трудностей все это не вызвало, скорее всего, потому что команда понимала, зачем я пришел в продукт. Возможно, когда вы работаете уже какое-то определенное время, то пуш таких нововведений может вызвать вопросы у команды (и так же все хорошо, зачем что-то менять). Отношение к дизайнеру в таком кейсе может быть другое.
Были кейсы, когда в виду моей загруженности, дизайном занимался подрядчик. Работа сделана, макеты переданы, а проводить ревью с их стороны никто не будет. Такой пункт, скорее всего, никто не будет учитывать в договоре. Я старался, по мере возможности, точно также ревьюить результат. Это гораздо сложнее, так как макет делает совсем другой дизайнер, который еще и не в контексте ваших гайдлайнов и прочего. Но как говориться, если хочешь сделать хорошо — сделай это сам.
Что из этого вышло?
Спустя 3 месяца на очередном ретро с командой, обсуждая внедрение дизайн-ревью, мы утвердили факт того, что качество последующих релизов действительно улучшилось, время на выкатку сократилось, работа тестировщика стала немного проще, а разработчики стали погружаться в концептуальную часть и идею, а не просто бездумно писать код. Ну и в целом, командное взаимодействие, за счет более частных коммуникаций друг с другом стало заметно лучше. Я же, со своей стороны, стал чувствовать себя более значимым и исключил вероятность выгорания на продукте.
Как оформлять итоги проведения дизайн-ревью
На мой взгляд, абсолютно неважно где вы будете документировать все неточности. Главное, чтобы всем было удобно взаимодействовать с этим. Подстройтесь под команду, так как вы изначально инициатор всего этого. Чаще всего, это Notion, Figma или Google таблица.
Важно донести каждый пункт максимально понятно, чтобы исключить лишних коммуникаций, которые могут тормозить процесс внесения доработок.
Описывайте каждый пункт единообразно, чтобы сформировать паттерн у разрабочиков и ускорить их взаимодействия с файлом.
Прикрепляю свой шаблон для визуализации несоответствий. Я делаю его в Notion и заполняю по следующим параметрам:
Номер
Несоответствие
Подробное описание несоответствия
Тип устройства (desktop/mobile)
Критичность несоответствия
Скриншот / запись экрана
Ссылка на верстку
Ссылка на макет
Вы можете воспользоваться моим шаблоном или подстроить порядок столбцов, их необходимость и прочее под ваш кейс. При желании можно улучшить шаблон для еще более эффективного внесения доработок.
Пример заполненного шаблона
Итоги
Опционально, дизайн-ревью необходимый этап в успешном развитии продукта. Опционально, потому что нужно понимать, что у вас за продукт и какие есть особенности (смысл проведения, ограниченные ресурсы и пр.)
Дизайн-ревью — это скорее всего история либо для маленьких продуктов либо для больших, но с плохо выстроенными процессами.
Дизайнеру нужно пушить проблему отсутствия дизайн-ревью, минимум чтобы упростить себе жизнь, максимум, чтобы улучшить качество продукта.
Пуште проблемы вашего продукта, даже если это не ваша зона ответственности. Не ждите пока кто-то другой заметит эту проблему и попросит вас ее решить.
Внедрение дизайн-ревью — долгосрочные инвестиции. Можно не предавать значение этому этапу, но какова будет цена потом?
Делитесь в комментариях своим мнением, опытом внедрения и проведения дизайн-ревью.
Подписывайтесь на мой телеграм. Я работаю продуктовым дизайнером в SberDevices и делюсь своим опытом.
