Про важность дизайн-ревью в продуктовом процессе

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

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

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

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

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

Когда я пришел в sberdevices.ru, в процессах не было практики дизайн-ревью. И конечно же, макеты в деталях не соответствовали продакшену. Одной из моих основных задач было улучшение качества продукта, и пуш этой проблемы стал важным пунктом. Моя команда оказалась супер адекватной и понимающей, поэтому обосновав необходимость этого этапа в наших процессах, мы обсудили все нюансы и согласовали эту интеграцию. Особых трудностей все это не вызвало, скорее всего, потому что команда понимала, зачем я пришел в продукт. Возможно, когда вы работаете уже какое-то определенное время, то пуш таких нововведений может вызвать вопросы у команды (и так же все хорошо, зачем что-то менять). Отношение к дизайнеру в таком кейсе может быть другое.

Были кейсы, когда в виду моей загруженности, дизайном занимался подрядчик. Работа сделана, макеты переданы, а проводить ревью с их стороны никто не будет. Такой пункт, скорее всего, никто не будет учитывать в договоре. Я старался, по мере возможности, точно также ревьюить результат. Это гораздо сложнее, так как макет делает совсем другой дизайнер, который еще и не в контексте ваших гайдлайнов и прочего. Но как говориться, если хочешь сделать хорошо — сделай это сам.

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

На мой взгляд, абсолютно неважно где вы будете документировать все неточности. Главное, чтобы всем было удобно взаимодействовать с этим. Подстройтесь под команду, так как вы изначально инициатор всего этого. Чаще всего, это Notion, Figma или Google таблица.

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

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

Прикрепляю свой шаблон для визуализации несоответствий. Я делаю его в Notion и заполняю по следующим параметрам:

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

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

Дизайн-ревью — это скорее всего история либо для маленьких продуктов либо для больших, но с плохо выстроенными процессами.

Дизайнеру нужно пушить проблему отсутствия дизайн-ревью, минимум чтобы упростить себе жизнь, максимум, чтобы улучшить качество продукта.

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

Внедрение дизайн-ревью — долгосрочные инвестиции. Можно не предавать значение этому этапу, но какова будет цена потом?

Делитесь в комментариях своим мнением, опытом внедрения и проведения дизайн-ревью.

Подписывайтесь на мой телеграм. Я работаю продуктовым дизайнером в SberDevices и делюсь своим опытом.