#frontend_post

Про Design review

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

Все мы привыкли (ну или большинство из нас) к code review. Сделали задачу, отправили на проверку, проверил QA и вперед в production.

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

Кто должен отвечать за то, что до production доедет то, что задумал дизайнер? Кто-то из нас забивает на отступы, кто-то на межстрочный интервал, а для кого-то не важно, какой шрифт юзать: Helvetica, Sans-Serif или Arial. Текст же можно прочитать? Значит сойдет 😃

Конечно, я утрирую и слишком драматизирую (или нет?), но контроль дизайнера в процессе разработки задачи очень нужен.

И вот тут подключается Design Review. То есть дизайнер смотрит то, что вы сделали и как нашкодившего кота тыкает вам в неверные border-radius и неправильные тени.

Помню, на прошлой работе я на первом Design Review получил около 30 правок. Почему? Я не настолько сильно парился с отступами и размерами. Конечно, работа была сделана не тяп-ляп, но многие моменты я упустил и дизайнер на это указал.

После этого я понял правила "игры" и сейчас еще тщательнее (хотя и раньше я всегда проверял свою работу вдоль и поперек) вылизываю визуал. Вот она еще одна точка роста, которую я взял не с первого раза, но все-таки взял.

На текущей работе дизайнер не смотрит Pixel Perfect, поэтому чуть легче, но все равно бывает что-то ускользает от взгляда разработчика и вот тут Design Review как никогда кстати приходится.

Какие плюсы и минусы у Design Review есть?

➕➕➕➕➕

Выявление проблем на раннем этапе
Иногда неверно сверстанный блок доставляет не просто визуально выглядит не так, но и ломает логику. QA может не заметить (или же для него/нее это не кажется чем-то критичным), но дизайнер обязательно подсветит то, что без правок тут никак. Иначе то, что задумывалось в будущем, в текущем вариант работать не будет.

Совместное творчество и улучшение идей
Бывает такое, что на этапе Design Review появляются споры и если дизайнер сговорчивый, то нередко frontend-разработчик успешно "защищает" свое решение (если может обосновать, почему он сделал не так, как было нарисовано)

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

➖➖➖➖➖

Затраты времени
Design Review - это нередко довольно долгий процесс. Одно дело вы кнопочку вставили в проект, другое - переделали целый раздел. Чем больше задача - тем больше правок и итераций может пройти.

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

Итог:
Design Review - это круто, но если в этом есть реальная необходимость. К примеру, если вы делаете MVP - излишний перфекционизм может стоит денег (ведь каждый час работы разработчика стоит немало). С другой стороны, если проект приносит прибыль - наплевательски к визуалу относиться никак нельзя.

А какие плюсы и минусы в Design Review вы можете отметить для себя?

Ну и по стандарту, давайте отмечаться 🙃

👍 - Design Review нужен
👎 - Design Review это лишняя трата времени
❤️ - Лайк в поддержку поста

Ну и пишите в комментариях свое мнение 🙃