Разрыв между устройствами и программами

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

Среди инженеров-разработчиков можно выделить две категории специалистов: первые являются разработчиками аппаратной части устройств и создают электронные платы и микрочипы, а вторые – программными разработчиками и пишут программный код. И хотя плоды их деятельности обретают единство в составных – гибридных – продуктах, обе эти отдельные фракции разработчиков, как правило, не взаимодействуют между собой. Иногда они даже не коммуницируют друг с другом, а просто «перекидывают» готовые модули через воздвигнутый между ними «забор».

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

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

По иронии судьбы у компаний, занимающихся разработкой аппаратных устройств, гораздо больше опыта в привлечении сторонних специалистов из области промышленного дизайна с целью сделать продукт более полезным и желанным для пользователя. Разработчики же программного обеспечения склонны предпринимать попытки справиться с проблемой самостоятельно. Любая компания – производитель гибридных продуктов, в которой нет проектировщиков, способных выступить посредниками между обеими сторонами, в результате выпустит продукт, не отвечающий потребностям пользователей. Такая ситуация абсолютно ясно видна в большинстве примеров из главы 1 «Загадки информационной эры».

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

Корпорация 3Сот – разработчик продукта PalmPilot – хороший пример компании с гибридным подходом, которой удалось оптимальным образом объединить разработку программной и аппаратной части посредством проектирования. Одно касание экрана – и устройство «просыпается» ровно в том же состоянии, в каком оно пребывало, когда выключилось. Когда устройство моментально откликается на действия пользователя, это явный признак того, что проектирование аппаратной части согласуется с потребностями программного обеспечения. Есть и обратный пример: моей фотокамере Nikon CoolPix 900 требуется долгих семь секунд для загрузки после каждого включения, и это при отсутствии жесткого диска. Когда устройство настолько инертно, становится очевидным, что бал правят разработчики аппаратной части.

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

Тем не менее при достаточном бюджете проекта проектировщикам не стоит отказываться давать советы относительно аппаратной части продукта. P@ssport – система развлечений в полете от корпорации Sony, описанная в главе 9 «Проектируем для удовольствия», функционировала на основе специализированных компьютеров, так что поставщик имел полную власть как над аппаратной, так и над программной частью всей системы. Проектировщики из моей команды дали корпорации Sony несколько рекомендаций по аппаратной части этого проекта.

Продукт Drumbeat от компании Elemental, процесс проектирования которого я описывал в главе 10 «Проектируем для результата», предназначался для запуска на стандартных настольных компьютерах на базе Wintel, так что в этом случае мои проектировщики даже не пытались давать рекомендации.

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

Меньше значит больше

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

Чем меньше подозревает пользователь об участии проектировщика в разработке продукта, тем больше это сигнализирует о том, что проектировщик справился со своей задачей на высочайшем уровне. Качественный интерфейс, как и обслуживание в ресторане высшего класса, должен быть ненавязчивым. Если какой-то аспект взаимодействия удался проектировщику особенно хорошо, пользователи даже не должны обратить на это внимания. В индустрии программного обеспечения, где целью проектирования провозглашаются «крутые» интерфейсы, бывает весьма трудно продираться сквозь тьму артефактов взаимодействия, на которые какой-нибудь несчастный программист, очевидно, потратил целую уйму времени. Как жаль, что он не потратил свои усилия на создание чего-либо более эффективного. Многим графическим дизайнерам свойственно полагать, что качественное проектирование означает «крутой дизайн». Отчасти это действительно бывает так, однако вне зависимости от того, насколько «крут» ваш интерфейс, чем он меньше заметен, тем лучше ^[36]. Еще раз: суть подхода заключается в том, что чем менее навязчив интерфейс для пользователя, тем качественнее справился проектировщик со своей работой. Представьте, что вы смотрите фильм, на границах кадра заметны яркие софиты, а после каждой сцены слышно, как режиссер кричит «Снято!». Только представьте, как навязчиво будут выглядеть подобные «спецэффекты» и как все волшебство кинофильма для зрителя враз будет разрушено.

Величайший программист и проектировщик программного обеспечения Кай Краузе (Kai Krause) известен своими неповторимыми интерфейсами. Кай разработал ряд программ для работы с графикой, которые считаются одними из самых мощных и интересных продуктов. Интерфейсам его продуктов свойственна необычайная ошеломительная красота и одновременно некая загадка, будто играешь в игру. В дополнение к своей специализации программиста Кай является также графическим дизайнером, поэтому его продукты отражают дизайнерское стремление добавлять своим творениям элемент неясности – словно в современном искусстве – с целью произвести впечатление. В отношении Кая такой подход работает «на ура», поскольку пользователями его продуктов являются такие же дизайнеры – как профессионалы, так и люди, увлеченные дизайном в качестве хобби. А вот за пределами этого мира продуктам Кая найти понимание нелегко.

* * *

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

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

Проектировщик, который мыслит в правильном направлении, будто бы вовсе исключает интерфейс из продукта. Он не станет проектировать экран за экраном, испещренный многочисленными кнопками и «примочками». Как-то к нам обратился менеджер по продукту одной из крупных компаний, допытываясь, можем ли мы перепроектировать его продукт. Далее мы выяснили, что в интерфейсе должно быть около десятка диалоговых окон. Тогда мы рассказали ему, как происходит наш рабочий процесс, а затем огласили предварительную стоимость работ. Если я правильно помню, цифра составляла приблизительно 60 000 долларов. Услышав это, менеджер пришел в ярость. «Возмутительно! – воскликнул он. – Пять тысяч долларов за один экран!» У меня тогда просто духу не хватило сказать, что когда мы урежем количество диалоговых окон, оставив всего одно или два, то цена даже возрастет, если использовать для ее вычисления подобный метод. Он бы просто не понял, о чем речь. Рассчитывать стоимость проектирования, исходя из стоимости каждого экрана, – это то же, что оплачивать счет в ресторане, прибавляя цену за каждый подход официанта к столику. Чем лучше работает официант, тем меньше он перемещается по залу, а чем лучше работает проектировщик, тем «меньше» интерфейса он создает.

Бывают в жизни проектировщиков взаимодействия и в некотором роде обидные моменты. Например, если вы в рабочем процессе нашли, как можно сделать что-то невероятно правильно, обстоятельно и до невозможности верно, то все, завидев это, восклицают: «Ну конечно! А разве это можно было сделать как-то по-другому?» Такое случается даже в тех ситуациях, когда клиент многие месяцы или годы безуспешно пытается найти решение проблемы, бездумно глядя на нее без малейшей идеи в голове. Такое бывает даже тогда, когда наше решение приносит компании миллионы долларов дохода.

Реализацию значительной части по-настоящему прорывных инновационных идей поначалу очень сложно даже вообразить, зато стоит ей появиться на свет, как всем сразу становится очевидно, что это нужно было делать именно так. Совершить такой прорыв в проектировании невероятно сложно. Можно потратить долгие часы на подготовку, обучение и исследование проблемной области и все равно не найти подходящего решения. А потом вдруг кто-то другой укажет на ключевой момент, и все сразу встает на свои места, столь же естественным образом, как и с изобретением колеса. Вы можете бить во все колокола, возвещая о своей находке, но найдутся те, кто ответит: «Конечно же, колесо круглое! А разве оно может быть каким-то другим?» Так что, как ни обидно это признавать, но похвастать оригинальной находкой в отношении проектирования бывает весьма затруднительно.

Алан Карп, ученый в области компьютерных наук, как-то поведал: «Почти все заявки на патент, которые я направлял, были отвергнуты по причине „очевидности“».

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

* * *

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