«Психбольница в руках пациентов». Как правильно проектировать интерфейсы
2026-02-21 19:24 Diff
https://skillbox.ru/media/design/book-about-face-3/

#статьи

  • 16 авг 2022
  • 0

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

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

Иллюстрация: Colowgee для Skillbox Media

Редактор. Пишет про дизайн, редактирует книги, шутит шутки, смотрит аниме.

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

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

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

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

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

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

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

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

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

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

Алан Купер

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

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

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

Алан Купер

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

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

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

PalmPilot, который опоздал на рынок на шесть лет. Но при этом стал хитом
Фото: Wikimedia Commons

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

Алан Купер

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

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

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

Photoshop предлагает сохранять изображения там, откуда вы взяли источник. Он не знает, что обычно вы складываете все файлы в отдельную папку
Скриншот: Skillbox Media

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

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

Алан Купер

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

Я только что купил для спальни новые дорогие часы со встроенным радиоприёмником — JVC FS-2000. <…> Очень сложно определить, когда будильник включён, поэтому время от времени он пропускает побудку в понедельник и выдёргивает меня из кровати рано утром в субботу. Разумеется, в этих часах есть индикатор активности будильника, однако это не означает, что его можно использовать.

Алан Купер

Будильник JVC FS-2000, который похож на музыкальный центр
Фото: Shopozz

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

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

Алан Купер

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

Скриншот: Skillbox Media

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

Окно подтверждения Windows 10. Даже если пользователь не хочет запустить непроверенную программу, он всё равно это сделает, нажав не глядя на кнопку Yes
Скриншот: Skillbox Media

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

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

Цели ― не то же самое, что задачи. Цель ― это конечное состояние, тогда как задача ― переходный процесс, необходимый для достижения цели. Очень важно различать задачи и цели, ведь их так легко спутать. <…> Задачи меняются вместе с технологией, тогда как цели обладают приятной особенностью ― они очень стабильны. <…> Если моя цель ― побездельничать в гамаке, почитывая воскресную газету, то придётся мне сначала подстричь лужайку. Моя задача ― подстричь газон, тогда как моя цель — отдых. Если бы я мог нанять кого-то для стрижки газона, то достиг бы цели, не прикасаясь к газонокосилке.

Алан Купер

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

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

Алан Купер

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

  • Не чувствовать себя глупо.
  • Не совершать ошибок.
  • Выполнить адекватный объём работы.
  • Развлечься (или хотя бы не страдать от скуки).

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

  • Увеличить прибыль.
  • Увеличить рыночную долю.
  • Победить конкурентов.
  • Нанять больше сотрудников.
  • Предложить новые продукты и услуги.
  • Выпустить акции компании в свободное обращение.

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

  • Сократить количество собраний.
  • Удовлетворять требованиям клиента.
  • Сохранять информацию о заказах клиента.
  • Создавать математические модели бизнеса.

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

Если программа игнорирует практические цели и служит только целям пользователя, это означает, что вы спроектировали компьютерную игру.

Алан Купер

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

  • Экономия памяти.
  • Уменьшение потребности в клавиатурном вводе.
  • Поддержка работы в браузере.
  • Простота в освоении.
  • Обеспечение целостности данных.
  • Ускорение ввода данных.
  • Увеличение скорости исполнения программы.
  • Применение супертехнологии или супервозможностей.
  • Улучшение внешнего вида.
  • Сохранение единообразия интерфейса на различных платформах.

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

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

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

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

Алан Купер

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

Программист: «Что если пользователь захочет вывести это на печать?»

Дизайнер: «Не думаю, что печать в первой версии так уж необходима».

Программист: «Кому-то может понадобиться печать».

Дизайнер: «Вероятно, да, но не могли бы мы отложить пока эту функцию?»

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

Программист: «Что если пользователь захочет вывести это на печать?»

Дизайнер: «Марии печать не нужна».

Программист: «Кому-то может понадобиться печать».

Дизайнер: «Но мы проектируем для Марии, а не для кого-то».

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

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

Пример разработки портретов персон для сервиса по продаже автомобилей av.by
Изображение: av.by

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

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

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

Алан Купер

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

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

Алан Купер

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

Изображение: SoleilC / Shutterstock / Skillbox Media

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

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

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

Алан Купер

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

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

Алан Купер

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

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

Алан Купер

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

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

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

Алан Купер

Больше о дизайне интерфейсов

Попробуйте бесплатно 4 топовые профессии в дизайне
Пройдите бесплатный курс по дизайну. Добавьте 4 крутых кейса в портфолио и решите, в каком направлении развиваться дальше. Пройти курс→