Заноза в ж*** разработчика или необходимость?
Поговорим про design review.
У разработчиков к нему вполне могут быть смешанные чувства. Ты закончил задачу, всё работает, собираешься закрыть тикет. И тут приходит дизайнер:
Тут на 4 пикселя выше. Тут кнопка не там. Тут текст переносится не как в макете. А вот здесь вообще всё поехало.
И вполне логично возникает вопрос: «Зачем мне ещё один человек, который будет ходить за мной с линейкой?» И я разработчиков понимаю. Особенно если весь review сводится к комментариям про пиксели без контекста.
Но между Figma и реальным продуктом постоянно что-то происходит. Мы стараемся продумать права, статусы, адаптивы, разные сценарии. Но в сложном продукте всё равно что-нибудь всплывёт.
Пришли реальные данные, и красивое имя из макета превратилось в строку на три этажа. С другим набором прав пользователь попал в состояние, которое мы не предусмотрели. Статус поменялся чуть иначе, и экран уже работает не так, как ожидалось.
Такое нормально. Невозможно заранее прожить в Figma вообще все варианты использования продукта. Поэтому на review я в первую очередь хочу понять:
То, что получилось в коде, всё ещё работает так, как мы задумывали?
Иногда проблема вообще оказывается в дизайне. Разработчик спрашивает: «А что должно произойти вот здесь?»
Открываешь макет и понимаешь: хороший вопрос. Потому что про этот случай ты сам забыл)
Возвращаемся, разбираемся, доделываем.
С технической реализацией я стараюсь разбираться раньше. Если предлагаю новое поведение, созваниваюсь с разработчиком и прогоняю сценарий: «Мы вообще можем так сделать? Как это работает под капотом? Насколько дорого это будет?» Иногда после десяти минут разговора решение уже другое. И хорошо, что это случилось до разработки. Но даже после этого review всё равно нужен.
И да, я всё-таки буду тем человеком, который придёт из-за нескольких пикселей.
Один кривой отступ ничего не сломает. Потом появляется второй, где-то кнопка уже другого размера, ещё где-то компонент немного уехал. Через несколько релизов каждый экран начинает жить своей жизнью. А иногда меняется не только внешний вид. Пользователь привык искать действие в одном месте, а на соседнем экране оно внезапно оказалось в другом просто потому, что при реализации что-то поменяли. Вот такие вещи и хочется поймать до релиза.
Design review нужен по очень простой причине: проверить, что по дороге от макета до production мы ничего важного не потеряли. Иногда ошибся разработчик. Иногда что-то забыл дизайнер. Иногда проблема вообще появляется только в коде.
Главное, чтобы после review продукт стал лучше, а не просто появился ещё один список комментариев про отступы.
А что думаете вы?