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

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

Такой разрыв между образом пользователей, сложившимся у разработчиков, и действительной природой пользователей создает дополнительное когнитивное сопротивление. Вы легко увидите это в большинстве внутренних корпоративных приложений и в большинстве массовых продуктов, основанных на программном обеспечении. Чтобы успешно применять эти продукты, необходимо быть программистом, но в то же время эти продукты изобилуют артефактами вроде мастеров и оперативной справки для начинающих. Эти возможности и есть дополнительно приделанные средства обучения. Мастеры и справка, как правило, выручают пользователей в определенных ситуациях, не обучая тому, как в будущем не попадать в неприятные ситуации. Специалисты мастерами и справкой никогда не пользуются, а новички стремятся побыстрее избавиться от этих оскорбительных напоминаний о невежестве. Однако вечные середняки навсегда остаются в компании этих артефактов.

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

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

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

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

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

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