Войти в систему
Войти с помощью соц. сетей:
В технологическом мире инженеров главная роль была отдана проектированию архитектуры программного продукта, а о проектировании взаимодействия на благо конечного пользователя вспоминали лишь постфактум, когда оставалось время. Одна из целей, которую я преследую в этой книге, – обозначить преимущества от смены приоритетов и добиться того, чтобы проектирование взаимодействия начали считать первоочередной задачей в процессе создания программных продуктов.
Проектирование тростниковых хижин и подземных ходов происходит не всегда осознанно, исходя из возможностей камня и тростника. То же можно сказать и о программном обеспечении – его устройство подчинено неведомым законам языков программирования и баз данных. Значительное влияние на все перечисленные способы проектирования оказывают сложившиеся устои. С той лишь разницей, что строитель-проектировщик хижины сам будет в ней жить, в то время как программисты обычно не являются теми, кто использует спроектированное ими ПО.
Реальное положение дел состоит в том, что компании, которые ведут разработку программ, не содержат в штате людей, хоть что-то понимающих в проектировании пользовательского взаимодействия. Однако те же самые несведущие люди весьма неплохо разбираются в проектировании программных продуктов и имеют собственное сложившееся представление о том, что нравится лично им. В итоге получается то, что получается: дизайн, спроектированный под них самих, при этом они выбирают лишь те аспекты, которые легко и приятно реализовать в коде, и воображают, будто на самом деле все это создается для пользователя. И хотя разработчики пребывают в уверенности, что в отношении дизайна и проектирования проделан большой пласт работы, речь здесь в большей степени идет только о проектировании программного продукта, и совсем немного выполняется для проектирования пользовательского взаимодействия.
Поскольку несовершенное проектирование – это тоже проектирование, получается, что тот, кто берет на себя принятие решений о поведении программы, выполняет роль проектировщика пользовательского взаимодействия. Маркетолог ли это, настаивающий на добавлении привлекательной для него функции, или программист, пытающийся реализовать в программе удобные для него опции, – все они «проектируют».
Отличие хорошего проектирования от того, что похоже на постройку тростниковых хижин, вовсе не в инструментах или приспособлениях, которые для этого применяются, а в тех побуждениях, что им движут. Для настоящего проектировщика взаимодействия важны те цели, которых пытается достичь пользователь. Мнимые проектировщики руководствуются широким кругом любых других случайных доводов в процессе принятия решения. Просто поразительно, что к ним могут относиться персональные предпочтения, мнение близких, боязнь неизвестности, рекомендации Microsoft, промахи коллег – все может сыграть решающую роль. Но чаще всего их решения основаны на том, что будет самым простым в реализации.
Я предпочитаю говорить проектирование взаимодействия, а не проектирование интерфейса, потому что термин «интерфейс» предполагает, что код находится по одну сторону, а люди – по другую. А посредине есть некая прослойка, которая передает сигналы между ними. Это выглядит так, будто только интерфейс отвечает за нужды пользователя. В результате подобного отделения дизайна на уровне интерфейса программисты начинают справедливо мыслить приблизительно так: «Я могу кодить как моей душе угодно, ведь все равно интерфейс будет прикручен в самом конце». Процесс дизайна и проектирования откладывается напоследок, когда становится совсем поздно.
С помощью дизайна и проектирования интерфейса можно только «приукрасить» то поведение, которое уже заложено в программе, – это все равно что одеть в костюм от Armani Атиллу, предводителя гуннов. Так, интерфейс программы для создания отчетов позволит убрать ненужные границы таблиц с рядами цифр или устранить иные мешающие восприятию помехи, обозначить цветом важные показатели, дать визуально богатую обратную связь, когда пользователь будет щелкать по различным элементам. Несомненно, лучше такое поведение, чем вообще никакого, но для качественной системы этого отнюдь не достаточно. Microsoft затрачивает миллионы долларов на дизайн и проектирование интерфейсов, но их программные продукты так и не заслужили любви пользователей.
Поведенческое проектирование определяет, как должны себя вести и как взаимодействовать с пользователем элементы программного продукта. Если применить эту концепцию к тому же примеру с отчетными таблицами, то мы увидим, что поведенческое проектирование показывает, какими инструментами можно воспользоваться для работы с отчетом и как отразить в отчете средние и итоговые значения. Проектировщики взаимодействия начинают свою работу вовне, изучая цели, которые требуется достичь пользователю, но при этом постоянно контролируют, чтобы эти цели коррелировались с глобальными потребностями бизнеса, техническими возможностями системы и сопутствующими задачами.
Можно пойти еще дальше и затронуть область концептуального проектирования, которая исследует, что для пользователя является по-настоящему ценным и выходит на первый план. В примере с нашими таблицами концептуальное проектирование может показать, что работа над таблицей с цифрами лишь второстепенная задача для пользователя, – на самом же деле его целью является выявить тенденции и закономерности. Это означает, что вам следует задуматься не о создании инструмента формирования отчетности, а о проектировании средства отслеживания тенденций. Чтобы одновременно дать пользователям ощущение силы и удовольствия, проектировщикам взаимодействия следует изначально думать в концептуальном ключе, затем в поведенческом ключе и только потом задумываться об интерфейсе.
Войти с помощью соц. сетей: