«Психбольница в руках пациентов». Как правильно проектировать интерфейсы

Алан Купер считает, что люди — безумцы, которые сами себе усложняют жизнь через неудобные интерфейсы.

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

Хотя эта книга изначально ориентировалась на программистов и менеджеров, она подойдёт и дизайнерам, которые работают над взаимодействием человека с программами.

Издательство — «Питер».

Алан Купер — американский дизайнер и программист. Известен как отец языка программирования Visual Basic, за что в 2017 году включён в зал славы Музея компьютерной истории. Разработал метод создания систем Goal-Directed, ориентированный на пользовательские цели, и одним из первых начал использовать портреты персон при проектировании продуктов.

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

Из статьи вы узнаете:

• почему количество функций не влияет на успех продукта;
• какие проблемы встречаются в современных системах;
• зачем нужны персонажи при проектировании системы.

Танцующий медведь

Вы наверняка видели этот видеоролик, где офисный рабочий сильно разозлился на свой компьютер:

Алан называет это «технояростью» или «компьютерным синдромом Туретта» — когда пользователь впадает в неконтролируемую агрессию, начинает громко ругаться и бить своё устройство. Если вы работали в офисе, то сами наблюдали, как в целом нормальные люди начинают вести себя неадекватно при работе за компьютером.

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

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

Посмотрите на этот интерфейс ТВ-приставки Xfinity X1. Она позволяет сохранять расписание просмотра программ в подменю Schedule. Это подменю находится во вкладке Save — и об этом просто невозможно догадаться без инструкции:

Это и есть пример «танцующего медведя» — функция с сохранением расписания есть, работает она очень плохо, но ведь работает!

Дедлайны и функции

В 1990 году компания GO разработала PenPoint — он должен был стать прототипом карманных персональных компьютеров, но в 1992 году потерпел крах. Следующую попытку предприняла Apple со своим Newton, а затем — General Magic со своим Magic Link в 1994 году. Все эти продукты оказались провальными, и инвесторы называли рынок КПК бесперспективным. Но в 1996 году появляется PalmPilot — он опоздал на шесть лет, но благодаря своей привлекательности смог захватить рынок.

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

Алан считает, что функции — причина одной из серьёзных проблем проектирования. Когда их очень много, они начинают сильно путать пользователя. Более того — их реализация делает продукт дороже и усложняет его: мало того, что для каждой новой фичи нужно написать код, их принцип работы придётся как-то объяснить пользователю.

Проблемы современных систем

Программы забывают

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

Программы ленивы

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

Программы скупы на информацию

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

Программы негибки

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

Программы возлагают вину на пользователей

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

Программы не несут ответственности

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

Проектирование ради результата

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

Очень часто разработчики не понимают разницы между целями и задачами. Алан считает, что это одна из главных причин, почему в мире всё ещё существуют неудобные системы:

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

Цели при разработке программ

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

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

Практические цели помогают достичь личных или корпоративных.

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

Ложные цели — ловушка для тех, кто хочет сам себе облегчить проектирование программы:

На самом деле всё это — лишь средства достижения цели, которые сами по себе не приведут ни к какому результату.

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

Персонажи для проектирования

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

Обычно диалог дизайнера и разработчика, которые не используют персонажей, выглядит вот так:

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

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

Общий подход к созданию персонажа — он должен быть максимально конкретным, чтобы вам было легко его представить перед собой. Например, некая Мария не просто использует какие-то приложения, а пишет рецепты в Google Docs. Она не просто ездит на работу, а на подержанной Toyota Camry 2016 года выпуска с синим детским сиденьем. У Марии не просто «есть какая-то работа», она — аптекарь в «Бюджетной аптеке», которая находится по конкретному адресу в Калининграде. Такая детализация поможет точнее и лучше спроектировать интерфейс и представить, как человек будет использовать ваш продукт.

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

Кажется, что вместо персонажа можно использовать и реального пользователя. Опыт рядового пользователя поможет вам определить задачу программы, но Алан предупреждает, что не нужно относиться к такому человеку как к эксперту по взаимодействию:

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

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

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

Проработка сценариев

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

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

Обязательные сценарии — те, которые пользователь выполняет нечасто, но неукоснительно. Например, в том же приложении с подсчётом калорий — это составление ежемесячного отчёта. Пользователь будет возвращаться к этой задаче всего раз в месяц, поэтому детально прорабатывать его необязательно.

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

Например, если пользователю нужно, чтобы калории считались в каких-то редких единицах, то в первой версии приложения это можно просто не делать — потому что это может понадобиться лишь 1–2% от потенциальной аудитории. Ради них не стоит задерживать выпуск продукта и усложнять интерфейс.