Текст книги "Психбольница в руках пациентов. Алан Купер об интерфейсах"

На самом деле пользователи не слишком нуждаются в большом количестве опций, хотя часто кажется, что это не так. Такое утверждение неоднократно доказывают истории взлетов и падений различных программных продуктов. Пользователям важно лишь то, насколько удобно решать нужные им задачи с помощью конкретного продукта. В редких случаях опции тоже могут пригодиться при решении задач, но чаще случается так, что опции только затрудняют работу и запутывают пользователя. Более того, опции, польза которых неочевидна, заставляют пользователей чувствовать себя глупыми. Если рассмотреть предыдущий пример с компьютером PalmPilot, мы увидим, что этот продукт предлагал гораздо меньше опций, чем провальные Magic Link от General Magic, Newton от Apple и компьютер PenPoint. Продукт PalmPilot стал успешным благодаря участию в разработке проектировщиков, которые полностью сосредоточились на потребностях целевой аудитории.

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

В мире, помешанном на опциях, может показаться неожиданной мысль о том, что элементарно невозможно достичь каких-либо целей, используя набор опций в качестве инструмента решения задач. Даже если все опции из списка будут успешно реализованы, продукт в конечном счете все равно может оказаться провальным. Проектировщик взаимодействий Скотт Макгрегор в целях доказательства правомерности этого утверждения использует на своих занятиях восхитительный тест, который заключается в следующем: он просит слушателей угадать продукт по описанию списка опций и немедленно записать свои догадки. Затем он начинает перечислять: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми шинами; 3) трансмиссия, связующая двигатель и ведущие колеса; 4) двигатель и трансмиссия, установленные на металлическом шасси; 5) рулевое колесо. К этому моменту каждый слушатель уже с полной уверенностью записал, что продукт является автомобилем, но Скотт продолжает, заканчивая описывать опции, вместо этого упоминая две потребности пользователя: 6) позволяет быстро и легко срезать траву; 7) позволяет сидеть на нем с комфортом. Только лишь на основании описания пяти опций никто не может точно определить, что искомый продукт – это трактор-газонокосилка. Вы сами могли убедиться, насколько более наглядными являются потребности и цели пользователя, нежели опции.

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

В начале 1990-х годов мне довелось оказаться участником одного из таких провалов. Я помогал создавать компанию, запуск которой осуществлялся на деньги инвесторов, а основной ее целью было заявлено следующее: максимально упростить процесс объединения компьютеров в сеть[8]8
  Если быть точнее, мы утверждали, что хотим «сделать процесс объединения компьютеров на базе Intel/Windows таким же простым, как объединение компьютеров Macintosh». В те времена было до смешного просто сделать сеть из компьютеров Mac с помощью AppleTalk. И совсем не так просто сделать это с компьютерами Wintel, даже в настоящее время.


[Закрыть]. Продукт отлично функционировал и был легок в использовании, но ряд грубых маркетинговых ошибок сработал против него и, как это ни прискорбно, привел его к провалу. Недавно на одной из конференций я столкнулся с инвестором и бывшим членом совета директоров той злосчастной компании. Мы не виделись с тех самых пор, как проект провалился, и, подобно ветеранам, вместе прошедшим через поражение на поле боя и встретившимся спустя много лет, мы утешили друг друга тем, что получили печальный опыт, но зато стали мудрее. Однако, к моему неприкрытому удивлению, этот в других отношениях невероятно успешный и рассудительный человек вдруг заявил, что, окидывая взглядом прошлое, он вынес из него главный урок: несмотря на безупречный маркетинг, менеджмент и техническую реализацию проекта, покупатели «просто не были заинтересованы в легком создании локальных сетей». Я был парализован от его столь очевидно безумного заявления и попытался возразить, что, разумеется, дело было вовсе не в отсутствии потребности, а в том, что мы не смогли эту потребность должным образом удовлетворить. Он переформулировал свое высказывание, настойчиво убеждая меня в том, что мы наглядно доказали отсутствие у покупателей потребности в упрощенном создании сетей.

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

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

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

И напротив, если продукт терпит крах, никто не желает копаться в его останках и выявлять причины неудачи. Любое оправдание будет на руку игрокам, окажись у руководства и разработчиков возможность перекинуться на реализацию нового высокотехнологичного проекта, которых вокруг превеликое множество. Таким образом, повода расстраиваться из-за неудачи нет. Однако неприятная особенность нежелания разбираться в причинах неудач заключается в том, что все участники молча признают невозможность спрогнозировать успех, считая, что в индустрии высоких технологий все зависит лишь от удачи и случая. Это явление, в свою очередь, положило начало подходу к инвестированию, которое инвесторы называют spray-and-pray («стреляй куда придется и молись, чтобы попало»): небольшие суммы денежных средств вкладываются во множество предприятий, а затем остается лишь надеяться на то, что хотя бы одно из них окажется успешным.

* * *

Метод небольших итераций также характерен для сред быстрой разработки, к которым, например, относится Всемирная паутина, а до ее появления таким был Visual Basic. Согласно этому методу, нужно повторять итерации до тех пор, пока какая-то из них не приведет к успеху. Всемирная паутина стала новым средством рекламного продвижения и тем самым привлекла множество специалистов по маркетингу, которые невероятно восприимчивы к мифу о непредсказуемом рынке и вытекающей из этого необходимости к итерациям. Мир рекламы и медиа суров и своеволен, и маркетологи знают это не понаслышке. В конечном счете значительная часть рекламных кампаний – это в самом деле лишь случайные предположения. Например, в рекламном продвижении одним из самых эффективных приемов считается представление какого-либо продукта как «новинки», тем не менее, когда компания Coca-Cola в середине 1980-х годов вывела на рынок свою новинку New Coke, она потерпела поражение. Такой исход никто не мог спрогнозировать. Вкусовые предпочтения и поведение людей способны измениться самым непредсказуемым образом, оттого может казаться, что эффективность маркетинга также зависит от случая.

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

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

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

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

Многие в других отношениях разумные и высокопрофессиональные руководители отчего-то беззастенчиво гордятся таким подходом. От одного зрелого и опытного исполнительного директора (в прошлом работавшего в сфере маркетинга) я как-то услышал весьма самонадеянный вопрос: «Как может кто-либо осмеливаться утверждать, что знает, чего хотят пользователи?» Это просто поразительно. Каждый предприниматель осмеливается это утверждать. Тем и ценны многие руководители, что привносят в свою сферу подобные «предположения» о том, чего хотят потребители. Разумеется, в отношении некоторых пользователей эти предположения окажутся неверными, но полное отсутствие предположений приведет к тому, что продукт не оценит никто. Этот глупец полагал, что пользователи не станут возражать против того, чтобы с трудом продираться сквозь «непаханое поле» программы безо всяких предположений, таким образом выполняя за него его работу по проектированию. Сегодня в Кремниевой долине наверняка нашлось бы множество любящих гулять по сети апологетов, кто хотел бы помочь этому ленивому руководителю постичь сущность его бизнеса, но при этом скольких страдающих потерпевших он отвратил своим дурным отношением? Пока он выпускал все новые и новые зачатки своего сайта, реагируя лишь на тех, чья выдержка позволила им снова вернуться на сайт, скольких клиентов он потерял безвозвратно? Что было нужно им? Говорят, Сталин использовал для разминирования минных полей солдат-пехотинцев, которым приказывал по ним проходить. Эффективен ли такой способ? Да. Но можно ли считать его рациональным, гуманным, целесообразным, желанным? Нет.

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

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

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

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

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

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

Задайте вопрос любому из тех, кому довелось поработать в технической поддержке любой из компаний, занятой в сфере создания настольных программ, и он непременно ответит, что больше всего времени и сил он тратит на объяснение нюансов работы с файловой системой. Пользователи, так же как Джейн из главы 1, не разбираются в рекурсивной иерархии файловой системы, и не важно, будет ли это Finder или Explorer в операционной системе Windows, Мас или UNIX. Удивительно, но очень невелика доля тех компаний, которые тратят средства на проектирование и реализацию версий файловых систем, более дружественных пользователю. В большинстве своем компании предпочитают более дорогой путь в виде содержания службы технической поддержки для ответов на бесконечные вопросы пользователей.

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

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

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

Если же этап проектирования не выполняется прежде этапа программирования, то никакого толку от него не будет. Как-то от одного руководителя я услышал такую фразу: «Мы уже поручили нашим сотрудникам писать код, и я не собираюсь останавливать их». Посыл этого умника приблизительно такой: «Я успею соорудить парашют прежде, чем мы ударимся о землю». Звучит весьма смело, но я ни разу не видел, чтобы это сработало.

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

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