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

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

Проблема №1 — time to market

На этапе дизайн-ревью, когда оно проводится после тестирования или во время, дизайнер может найти мелочные несоответствия макетам. Мелочные по меркам бизнеса. Защитить исправление таких несоответствий довольно сложно — с одной стороны стоит вопрос о деньгах и сроках, с другой — об управлении вниманием, красоте, соответствии UI kit'у, ToV и о прочем важном. Дизайнер, имеющий высокий уровень влияния, может заблокировать выкатку такой фичи до момента исправления, однако такая ситуация — исключение из правил. Зачастую фича катится с визуальными расхождениями, и дополнительно заводятся баги, которые по той же причине могут иметь низкий приоритет — всегда найдется что-то поважнее отступов между блоками. Круг замыкается, дизайн-долг разрастается.

Проблема №2

Если до момента внедрения дизайн-ревью разработка не пыталась соблюдать пиксель перфект и ToV, значит, она не заинтересована или не понимает ценность. Продать, объяснить и научить – это тот еще челлендж. Недовольство разработчиков дизайнерами и без этого частое явление, которое негативно влияет на работу, поэтому раз 3 месяца мы проводим опрос удовлетворённости. На пункт «Какие вопросы вас беспокоят в процессах между разработкой и дизайном» 90% разработчиков ответили «я не понимаю, почему я должен соблюдать пиксель перфект». Уровень осведомленности может быть разный от команды к команде, но очень советую провести такой опрос — быть может, и к вам есть вопросы.

Что делать?

Для первой проблемы мы внедрили процесс «предревью» – это максимально быстрая проверка верстки на этапе, когда фича ещё в разработке. Проверяется не весь флоу и логика, а компоненты и верстка экранов и блоков. Здесь не нужны шаблоны для заполнения, отдельные задачи и так далее – процесс проходит в личке или в треде между дизайнером и разработчиком. Для этого мы создали канал «Спроси дизайнера» в Mattermost. По опыту такой процесс занимает не более 15 минут, но сокращает процесс дизайн ревью на 50% процентов, а ещё позволяет тестировщикам немного расслабиться. В итоге пользователь видит тот самый текст с тем самым переносом, который задумал дизайнер, фича не задерживается и в целом все довольны.

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

Завершая — дизайн-ревью нужно, важно и имеет высокий value, но оно не должно превращаться в узкое горлышко. Каждый процесс нужно оптимизировать под команду, своевременно реагируя на проблемы. И спасибо Александру за статью.