Заноза в ж*** разработчика или необходимость?

Поговорим про design review.

У разработчиков к нему вполне могут быть смешанные чувства. Ты закончил задачу, всё работает, собираешься закрыть тикет. И тут приходит дизайнер:

Тут на 4 пикселя выше. Тут кнопка не там. Тут текст переносится не как в макете. А вот здесь вообще всё поехало.

И вполне логично возникает вопрос: «Зачем мне ещё один человек, который будет ходить за мной с линейкой?» И я разработчиков понимаю. Особенно если весь review сводится к комментариям про пиксели без контекста.

Но между Figma и реальным продуктом постоянно что-то происходит. Мы стараемся продумать права, статусы, адаптивы, разные сценарии. Но в сложном продукте всё равно что-нибудь всплывёт.

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

Такое нормально. Невозможно заранее прожить в Figma вообще все варианты использования продукта. Поэтому на review я в первую очередь хочу понять:

То, что получилось в коде, всё ещё работает так, как мы задумывали?

Иногда проблема вообще оказывается в дизайне. Разработчик спрашивает: «А что должно произойти вот здесь?»

Открываешь макет и понимаешь: хороший вопрос. Потому что про этот случай ты сам забыл)

Возвращаемся, разбираемся, доделываем.

С технической реализацией я стараюсь разбираться раньше. Если предлагаю новое поведение, созваниваюсь с разработчиком и прогоняю сценарий: «Мы вообще можем так сделать? Как это работает под капотом? Насколько дорого это будет?» Иногда после десяти минут разговора решение уже другое. И хорошо, что это случилось до разработки. Но даже после этого review всё равно нужен.

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

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

Design review нужен по очень простой причине: проверить, что по дороге от макета до production мы ничего важного не потеряли. Иногда ошибся разработчик. Иногда что-то забыл дизайнер. Иногда проблема вообще появляется только в коде.

Главное, чтобы после review продукт стал лучше, а не просто появился ещё один список комментариев про отступы.

А что думаете вы?

Заноза в ж* разработчика или необходимость? | Сетка — социальная сеть от hh.ru