Всем знаком термин “авторский надзор”, да? Это когда ты что-то придумал, а потом следишь, чтобы это “что-то” создавалось именно так, как ты придумал.
Довольно распространена (особенно в больших компаниях) ситуация, когда результат работы дизайнера просто отправляется разработчикам, а сам дизайнер тут же приступает к новому проекту. Эта схема стала настолько привычной, что никто уже не обращает внимание на её явные негативные последствия.
И я не говорю о том, что всё равно разработчики будут дёргать дизайнера, равно как не говорю и о последствиях такого вырывания из контекста нового проекта.
Давайте обсудим лишь то, что происходит с самим проектом без авторского надзора со стороны дизайна - даже если его документация максимально подробна, однозначно трактуема и исчерпывающа.
Причины, по которым авторский надзор - мастхэв
Трактуемость
Во-первых, так не бывает. Не бывает однозначно трактуемой документации. А иногда даже более того: бывают люди, которые из самых однозначных формулировок соберут добрый десяток версий.
Впрочем, если вы пилите лендинг, то никаких вопросов. Но чем сложнее проект, тем больше в нем мест, которые иногда просто невозможно однозначно описать. Например, вы делаете интеграцию с партнёром, он должен передавать вам какую-то информацию - список товаров, а забирает, например, данные об активности пользователей. А если таких партнеров пять? Со своей стороны вы можете описать всю логику, но когда дело дойдет до реализации, стопудов вылезет какая-нибудь гадость, вроде недостаточных данных для отображения.
Все мы люди
Во-вторых, человеческий фактор. Некоторые люди не очень умны. Некоторые - высокомерны. А если уж в вашей команде разработки или в менеджерской прослойке есть высокомерный идиот, то я вам вообще не завидую. Тогда авторский надзор становится той подпоркой, которая не даёт скатиться в ад всему проекту.
Кроме того, никто не застрахован от банальной лени или невнимательности разработчиков. Может случиться так, что для валидации полей формы они решат заюзать либу с прошлого проекта - и тогда прощай ваша "идеальная форма регистрации".
Рынок изменчив
Ну и в третьих, реалии бизнеса.
Пока вы пилите продукт, рынок может поменяться. Чаще всего несильно, но все же. И вам придется чуть-чуть, но изменить продукт. Доверять это разработчикам точно не стоит. Например, когда мы пилили проект по “защите интеллектуальной собственности онлайн”, вышла новая поправка к закону об авторском праве и пользовательских данных. Срочно пришлось придумывать механизм удаления информации, которой раньше не было предусмотрено.
И это ещё не всё
Причин, на самом деле, ещё много. Тут и необходимость “ручного” погружения в проект всех его участников. И гарантия того, что во время разработки проект не обрастет новыми фичами (или, по крайней мере, это "обрастание" будет дружественным для пользователя и бизнеса). И много чего еще. Какие-то причины достаточно важны, чтобы предъявлять их руководству в качестве аргумента за авторский надзор, а какие-то стоит учитывать только для собственной мотивации.
Способы ведения авторского надзора
А вот о том, как осуществлять этот самый надзор, мы поговорим отдельно, хотя это всегда очень индивидуальная штука. Она зависит от особенностей компании, от личных качеств дизайнера, от его опыта и даже от отношений в команде.
Однако кое-какие советы я, всё же, могу дать.
Инфополе
Держите всех в едином информационном поле.
Вы должны быть уверены, что каждый из разработчиков обладает той картиной, которой должен. И обладает ею в полной мере. Иногда, если повезет, часть этой работы можно перекинуть на техлида. Но везти будет не всегда.
Документация
Поддерживайте документацию актуальной.
Это важно, за вас этого никто не сделает. Иногда, даже если поменялось что-то незначительное, приходится вносить изменения в два десятка мест документации. Делайте это сразу, уведомляйте всех заинтересованных (или убедитесь, что они в курсе).
Слежка
Следите за промежуточными результатами.
Всегда просите включить вас в список тестеров, следите за каждым внутренним обновлением продукта. И еще нюанс - каждый раз проверяйте проект целиком, а не только обновленную часть. Потому что на странице регистрации, которую вы проверяли неделю назад, кнопочки могут разъехаться, а валидация сломаться только из-за того, что программисты поправили границы окна редактирования аватара в профиле. В идеале, конечно, предупреждать такие штуки нужно на архитектурном уровне, но для этого нужен определённый технический бэкграунд.
Подставь другую щёку (нет)
Не бойтесь конфликтов, но не будьте токсичными.
Это напоследок. Продуктовый дизайнер должен иметь стальные яйца и непробиваемую харизму. Иногда конфликт - единственный способ подружиться. И заодно добиться выполнения требований документации.
Однако этим пунктом не стоит злоупотреблять.
Напоследок
Если хотите, чтобы я рассказал про авторский надзор поподробнее - пишите об этом в комментариях.