Я уже двадцать лет проектирую интерфейсы. Делаю интерактивные прототипы, готовлю проектную документацию, вот это всё. Получается я сочетаю в себе компетенции системного аналитика, UX-дизайнера и ещё всякого по мелочи. Раньше это всё называлось проектированием.
Итак.
Правда №1: я не знаю объективного способа подтвердить, что с проектированием продукты делаются быстрее и дешевле, чем без него.
То есть, для меня это очевидно. Это логично и рационально. Но не проверить.
Я не могу взять две разных команды и дать им две одинаковые задачи, только одна будет в виде устной постановки и заметок на салфетке, а другая — в виде прототипа, сопровождённого проектной документацией. Потому что это две разных команды и результаты могут зависеть именно от участников, а не от постановки задачи.
Я также не могу взять команду и дать ей одну и ту же задачу. Сначала на салфетке, а потом с полной проектной документацией. Потому что после того, как они выполнят первую, они выполнят вторую гораздо быстрее, т.к. будут знать, как.
Правда №2: никто не читает функциональных спецификаций (и прочих объёмных текстовых документов).
Если прототип на сто экранов сопровождён документацией на семьдесят страниц — будут смотреть исключительно в прототип. И клиенты, и руководители проектов, и даже разработчики.
Это происходит и при оценке разработки, и во время работы над проектом. Многим будет проще обратиться к проектировщику с вопросом, чем поискать ответ в документации.
Зачем же тогда их вообще писать?
Ну, во-первых, это в разы повышает качество проектирования. Пока я пишу документацию, приходится вносить много правок и улучшений в прототип.
Во-вторых, к документации всё-таки, возможно, будут обращаться позже. Либо через пару-тройку лет, когда уже забыли, как что работает под капотом и почему приняли то или иное интерфейсное решение. Либо когда проектировщика уже нет под рукой. Разработчики сначала поищут ответы в прототипе, затем поищут глазами, есть ли рядом тот, кому можно задать вопрос, и вот в конце уже пойдут читать.
Правда №3: не существует официального стандарта, по которому можно было бы однозначно оценивать свою работу и выстраивать процесс.
Мой «пробег» за 20 лет — 350+ проектов разной масти и размеров. В студии, на подряде, на фрилансе. В каждом коллективе, в каждом проекте, в каждой компании — свой набор практик и методик. Я не встречал двух команд с совершенно одинаковыми подходами к работе.
Поэтому любой коллектив может внезапно начать затирать о том, что их методы — самые правильные и свято верить в это. Особенно, если этот коллектив не посмотрел на сотню-другую соседних коллективов с точно такими же позициями.
Например, арт-директора Яндекса в своё время считали, что все дизайнеры обязаны уметь верстать и показывать свою работу уже в виде свёрстанных макетов (не знаю, как там сейчас). Кто-то дробит профессию проектировщика на десять разных подпрофессий (UX-писатель, UX-редактор, бизнес-аналитик, системный аналитик и т.п.). Кто-то рассказывает о разнице между UX и CX. И так далее и тому подобное.
Это не плохо, таков рынок, все методы хороши в своих контекстах. Но может сбить с толку человека, который поработал лишь с одной-двумя командами и верит, что его методы — самые правильные. Это может либо замедлить развитие специалиста, либо развернуть его не в ту сторону.
Полезные ссылки
Статья на Хабре с рассказом о функциональных спецификациях в моём исполнении и видеодемонстрацией одной из них
Статья на Хабре о том, как я проектирую интерфейсы на фрилансе. Подробное описание всего бизнес-процесса: от заявки до сдачи проектной документации
Мой Телеграм-канал о проектировании интерфейсов и работе на фрилансе
