Отношения между программистами и проектировщиками

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

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

Большинство программ проектируются случайным образом

Глиняные лачуги и подземные норы проектируются, пусть зачастую неосознанно, в рамках возможностей камня и тростника. Аналогичным образом все программы проектируются в рамках таинственных потребностей языков программирования и баз данных. Самое сильное влияние на проектирование во всех перечисленных материалах оказывает традиция. Разница, и большая, в том, что строитель, проектирующий лачугу, так же является и её основным жильцом, тогда как программисты обычно не используют спроектированные ими приложения.
В большинстве фирм, занимающихся разработкой программного обеспечения, просто нет людей, имеющих представление о проектировании для конечного пользователя. Но есть люди, имеющие более чем серьёзное представление о проектировании программ, имеющие своё собственное мнение и личные предпочтения. И потому они делают то, что делают, - проектируют взаимодействие с программой, как для самих себя, выбирая функциональность, которую проще всего и интереснее всего реализовывать, и при этом воображают, что на самом деле проектируют для пользователей. И хотя программисту кажется, что объём выполяемого проектирования очень велик, на деле много всего лишь проектирования программного, а проектирование для конечного пользователя почти отсутствует.
Недостаточное проектирование - тоже вид проектирования, поэтому когда кто-либо принимает решения о поведении программы, он принимает на себя роль проектировщика взаимодействия. Когда маркетолог настаивает на включении привлекательной функции в продукт он проектирует. Когда программист реализует в продукте излюбленный способ поведения, он проектирует.
Разница между проектированием хорошим и непроизвольным - в стиле клиняных домиков - не в применяемых инструментах и приспособлениях, но в мотивации. Настоящий проектировщик взаимодействия принимает решения, исходя из задач пользователя. Эрзац-проектировщики принимают решения, исходя из произвольного числа случайных соображений. Личные предпочтения, знакомство с предметом, страх перед неизвестностью, указания от Microsoft, ошибочные замечания коллег - все эти факторы играют на удивление серьёзную роль. Впрочем, чаще всего решения эрзац-проектировщиков склоняются в сторону пути наименьшего сопротивления.

--
Алан Купер, "Психбольница в руках пациентов"

Sincerelly, NunDesign