Проектирование интерфейса для идиотов

Когда о человеке говорят, что он "раб вещей", подразумевается, что этот человек слишком много внимания уделяет материальной стороне бытия, а о душе думает изредка и через силу. Однако если посмотреть со стороны, то каждый из нас - такой же раб, если не хуже. С выходом новой программы, с выходом новой электронной игрушки, с выходом нового автомобиля счастливым владельцам приходится переучиваться, перестраивать себя под жесткие и не всегда логичные ограничения, наложенные разработчиками на свои продукты. Вспомните середину 90-х, время расцвета курсов "по работе с компьютером", когда взрослым и вполне состоявшимся, казалось бы, людям пришлось все бросить и бежать учиться работе на ПК, потому что появился новый класс устройств, с которыми кровь из носу нужно было уметь обращаться. И кто из нас раб - человек или машина?

- Владимир Гуриев

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

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

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

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

В заголовок раздела вынесено название книги Алана Купера [При подготовке статьи использовалась оригинальная версия книги, однако в 2005 году в издательстве "Символ-Пресс" вышел русский перевод. У нас не было возможности сверить эти два издания, поэтому в цитатах из Купера могут быть незначительные отличия от "книжного" перевода. - Прим. ред], одного из самых известных экспертов по проектированию интерфейсов. Купер примечателен еще и тем, что не является "чистокровным" специалистом по юзабилити - он пришел в эту сферу из софтверного бизнеса, и если имя Купера вам незнакомо, то уж о его детище вы точно наслышаны. В бытность свою программистом Алан Купер создал среду проектирования Ruby, которая после некоторой доработки превратилась в первую версию Microsoft Visual Basic.

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

Одна из главных причин заключается в том, что софтверный бизнес построен вокруг дедлайнов. У разработчиков есть дата, к которой они обязаны закончить продукт, и частенько случается так, что к этой дате разработчики выдают не то, что нужно, а то, что написалось. Любой человек с первого взгляда может определить, что дом не достроен, а автомобилю не хватает колес, однако с программами или электроникой все далеко не так просто - недостаток функциональности или надежности при желании можно легко замаскировать. И если сроки поджимают, то почему бы не выдать пользователю полуфабрикат? А потом, - говорят себе разработчики, - мы выпустим патч или даже сервис-пак, где все исправим.

Разработчиков трудно винить, они люди подневольные - на них давит менеджер проекта, который отвечает за соблюдение сроков. Ведь компании нужно безотлагательно занять рынок, пока на него еще кто-нибудь не пришел[Купер отмечает, что ранний приход на рынок с плохим, не готовым продуктом скорее навредит изготовителю, и вспоминает, что компания Palm, перевернувшая рынок КПК, вовсе не была первопроходцем. Больше того, к моменту появления Palm Pilot венчурные капиталисты были уверены, что рынок наладонников абсолютно бесперспективен. - Здесь и далее прим. автора]. Так что выпуск продукта откладывается лишь в самом крайнем случае.

Но и у разработчиков есть свои слабости. Одна из них заключается в том, что разработчики, в общем-то, не настоящие люди, а Homo Logicus.

Homo Logicus против Homo Sapiens

Чтобы определить, к какому виду - Homo Logicus или Homo Sapiens - вы относитесь, Купер предлагает пройти небольшой тест.

Представьте, что вы находитесь в самолете и можете выбрать, куда отправиться: в нашпигованную ручками, рычагами и приборами кабину пилота, где, потратив некоторое время на обучение, вы сможете контролировать полет, или в комфортабельный салон, где вы сможете расслабиться вплоть до момента приземления. Homo Logicus - по Куперу - отправляются в кабину пилота, поскольку им важно отслеживать ситуацию, им важно знать, как это работает, чтобы быть уверенными, что это работает. Homo Sapiens, отправившегося в салон, эти мелкие подробности нисколько не интересуют - ему гораздо важнее вовремя долететь до места, а потом отправиться по своим делам. Ради собственного спокойствия он готов пожертвовать контролем над ситуацией. Хотя, скорее всего, ему даже в голову не придет, что он, отправившись в салон, что-то потерял.

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

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

Для Homo Logicus наличие дополнительных возможностей очень важно, но для большинства пользователей огромные списки реализованных функций абсолютно бесполезны. Программа может быть сколь угодно сложно устроена, однако недостаточное внимание к простейшим пользовательским нуждам может привести ее производителя к фиаско. Примеров тому не счесть. Один из самых ярких - провал электронных таблиц Lotus Improv.

История Lotus Improv, которая была лучше всех

Благими намерениями вымощена дорога к банкротству. Когда в 1986 году в компании Lotus была образована специальная исследовательская группа, в чью задачу входило создание новой парадигмы электронных таблиц, вряд ли кто-то мог предположить, что выпущенный продукт станет одним из последних самостоятельных проектов Lotus.

Напомню, что на рубеже 80-х и 90-х годов прошлого века компания Lotus была главным разработчиком электронных таблиц, а ее программа Lotus 1-2-3 - образцом, который нещадно копировали конкуренты. Впрочем, первопроходцами лотусовцы не были - Lotus 1-2-3 эксплуатировал идею электронных таблиц, найденную авторами более раннего продукта, VisiCalc.

Считается, что от добра добра не ищут, но в Lotus предположили, что двухмерные таблицы (когда пользователь может оперировать только вертикальными столбцами и горизонтальными строками) не оптимальны и современным финансистам гораздо нужнее трехмерная модель данных. Кроме того, было очевидно, что ссылочная система адресации, стандартная для электронных таблиц, слишком сложна и неудобна. С какой это, простите, стати пользователь должен складывать ячейку B1 с ячейкой B2, чтобы получить сумму в ячейке B3? Зачем все усложнять? Давайте сделаем проще (см. таблицу).

В любой электронной таблице сумма стоимости билетов в кино и расходы на попкорн описывались бы следующим образом (c поправкой на различия в нотации): B1+B2. Однако в Lotus Improv от ссылочности отказались, поэтому формула получалась куда нагляднее: Tickets+Popcorn.

Для своего времени Lotus Improv был очень продвинутым продуктом с дружелюбным пользовательским интерфейсом. И тем не менее он потерпел поражение, проиграв более примитивным конкурентам. Почему?

Процитируем Джоэла Сполски (Joel Spolsky), автора цикла статей "Дизайн пользовательских интерфейсов для программистов"[Joel Spolsky, User Interface Design for Programmers. Chapter 9: The Process of Designing a Product]: Во время разработки с первой по четвертую версию Excel большинство сотрудников Microsoft пребывало в уверенности, что юзеры используют эту программу для отработки сценариев "а что если…" - вы легко можете менять значения в ячейках, а потом смотреть, что у вас получилось.

Однако корпя над Microsoft Excel 5.0, разработчики решили поинтересоваться, какие функции имеют для пользователей наибольший приоритет, и выяснили, что невероятное количество людей применяло Excel исключительно для ведения списков: Они не писали формул, они вообще ничего не считали! И пользователи намного чаще составляют в Excel списки, чем делают что-либо еще. Это вынудило нас создавать целый ряд новых возможностей, которые бы облегчали составление списков: упрощенная сортировка, автоматический ввод данных, автофильтр плюс многопользовательские возможности, позволявшие редактировать списки сразу нескольким людям.

Вышедший в это время Lotus Improv - превосходно подходивший для финансовых расчетов - со списками работал из рук вон плохо. И пользователю было наплевать на то, что все остальное он делал лучше всех. Improv, вероятно, был идеальным продуктом для Homo Logicus, однако для Homo Sapiens он оказался неудобен[Lotus Improv не канул в Лету. Идеи, заложенные в него, были позднее реализованы в пакете Quantrix].