Найти в Дзене
Павел Шерер

Авторский надзор в дизайне

Оглавление

Всем знаком термин “авторский надзор”, да? Это когда ты что-то придумал, а потом следишь, чтобы это “что-то” создавалось именно так, как ты придумал.

Довольно распространена (особенно в больших компаниях) ситуация, когда результат работы дизайнера просто отправляется разработчикам, а сам дизайнер тут же приступает к новому проекту. Эта схема стала настолько привычной, что никто уже не обращает внимание на её явные негативные последствия.

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

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

Причины, по которым авторский надзор - мастхэв

Трактуемость

-2

Во-первых, так не бывает. Не бывает однозначно трактуемой документации. А иногда даже более того: бывают люди, которые из самых однозначных формулировок соберут добрый десяток версий.

Впрочем, если вы пилите лендинг, то никаких вопросов. Но чем сложнее проект, тем больше в нем мест, которые иногда просто невозможно однозначно описать. Например, вы делаете интеграцию с партнёром, он должен передавать вам какую-то информацию - список товаров, а забирает, например, данные об активности пользователей. А если таких партнеров пять? Со своей стороны вы можете описать всю логику, но когда дело дойдет до реализации, стопудов вылезет какая-нибудь гадость, вроде недостаточных данных для отображения.

Все мы люди

-3

Во-вторых, человеческий фактор. Некоторые люди не очень умны. Некоторые - высокомерны. А если уж в вашей команде разработки или в менеджерской прослойке есть высокомерный идиот, то я вам вообще не завидую. Тогда авторский надзор становится той подпоркой, которая не даёт скатиться в ад всему проекту.

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

Рынок изменчив

-4

Ну и в третьих, реалии бизнеса.

Пока вы пилите продукт, рынок может поменяться. Чаще всего несильно, но все же. И вам придется чуть-чуть, но изменить продукт. Доверять это разработчикам точно не стоит. Например, когда мы пилили проект по “защите интеллектуальной собственности онлайн”, вышла новая поправка к закону об авторском праве и пользовательских данных. Срочно пришлось придумывать механизм удаления информации, которой раньше не было предусмотрено.

И это ещё не всё

-5

Причин, на самом деле, ещё много. Тут и необходимость “ручного” погружения в проект всех его участников. И гарантия того, что во время разработки проект не обрастет новыми фичами (или, по крайней мере, это "обрастание" будет дружественным для пользователя и бизнеса). И много чего еще. Какие-то причины достаточно важны, чтобы предъявлять их руководству в качестве аргумента за авторский надзор, а какие-то стоит учитывать только для собственной мотивации.

Способы ведения авторского надзора

А вот о том, как осуществлять этот самый надзор, мы поговорим отдельно, хотя это всегда очень индивидуальная штука. Она зависит от особенностей компании, от личных качеств дизайнера, от его опыта и даже от отношений в команде.

Однако кое-какие советы я, всё же, могу дать.

Инфополе

-6

Держите всех в едином информационном поле.

Вы должны быть уверены, что каждый из разработчиков обладает той картиной, которой должен. И обладает ею в полной мере. Иногда, если повезет, часть этой работы можно перекинуть на техлида. Но везти будет не всегда.

Документация

-7

Поддерживайте документацию актуальной.

Это важно, за вас этого никто не сделает. Иногда, даже если поменялось что-то незначительное, приходится вносить изменения в два десятка мест документации. Делайте это сразу, уведомляйте всех заинтересованных (или убедитесь, что они в курсе).

Слежка

-8

Следите за промежуточными результатами.

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

Подставь другую щёку (нет)

-9

Не бойтесь конфликтов, но не будьте токсичными.

Это напоследок. Продуктовый дизайнер должен иметь стальные яйца и непробиваемую харизму. Иногда конфликт - единственный способ подружиться. И заодно добиться выполнения требований документации.

Однако этим пунктом не стоит злоупотреблять.

Напоследок

Если хотите, чтобы я рассказал про авторский надзор поподробнее - пишите об этом в комментариях.