Бумажный экземпляр второго издания (справа) у меня был уже лет 6, но прочитать от корки до корки всё никак не доходили руки. Несколько лет назад начинал читать, уловил идею про то, что продукт должен подсказывать как им пользоваться и отложил. Но в декабре решил-таки прочитать полностью, тем более на Литресе как-то по акции покупал самое свежее, аж 2018 года, издание от МИФа (с очками на обложке, слева на картинке).

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

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

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

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

Вспоминается мысль, которую услышал у Дорофеева:

Большинство людей бОльшую часть времени иррациональны, импульсивны, действуют на автомате. При этом не считают такое поведение нормой и ожидают, что другие люди рациональные, действуют на основе конкретной целей и обдуманно.

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

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

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

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

Нужно делать хорошую коммуникацию — звучит хорошо. А делать-то что?

Семь концептов от Нормана

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

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

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

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

Фидбек
Когда всегда есть информация о результате действия пользователя и текущем состоянии системы. Сделал действие — легко понял новое состояние системы. Система дает понять, что обрабатывает запрос. Фидбек — информация, которая нужна, чтобы понять что произошло по результатам действия. Достигается за счет отображения на устройстве того, какой эффект этой действие вызвало (не всегда на экранах или текстом, но и звуком, каким-то ответным движением и пр. Например: звук заведенного мотора в автомобиле — если будет слишком хорошая звукоизоляция салона, его можно не услышать и подумать, что машина не завелась).

Пример системы с плохим фидбеком из моего опыта: дверной звонок — повесил у входной двери беспроводную кнопку (от умного дома Aqara). Курьеры нажимают на нее, не видят и не слышал фидбек (пальцем чувствуют, что кнопка щелкнула, но не слышат звук звонка в квартире, а кнопка не дает никакой информации о том, что она действительно сработала). Проходит 3-5 секунд, они думают, что ничего не произошло и начинают стучать по двери (а это жутко раздражающий громкий шум) — они получили фидбек и уверены что жильцы квартиры их услышат.

Другие примеры плохого фидбека:

• Пешеходный светофор и кнопка для пешеходов — замечал, что ожидающие зеленого света пешеходы нажимают ее по 10 раз. Даже если у нее загорается лампочка, что запрос принят. У них нет информации о том, через сколько секунд загорится зеленый свет (не на каждом пешеходном светофоре такое есть в связке с кнопкой), при долгом ожидании людям начинает казаться, что если они нажмут кнопку еще 10 раз, это ускорит включение зеленого света.
• Кнопка вызова официанта в кафешках (хочется 10 раз нажать потому что не знаешь — приняли вызов или нет, хотя лампочка на кнопке загорается).

Хороший фидбек — мгновенный и информативный. Он дает понять, если что-то пошло не так и что нужно делать. И его не слишком много (он уместный и по важным вещам, иначе отключат и пропустят важное).

Концептуальная модель
Модель того, как именно работает система. Хорошо, если внешний вид системы дает всю информацию, чтобы понять концептуальную модель (полезную для цели пользователя, но возможно упрощенную). Это дает понимание и ощущение контроля ситуации, по ней можно хоть как-то прогнозировать то, как будет вести себя система. Пример: руль колеса автомобиля. Концептуальная модель объяснит как работа элементов управления влияют на транспортное средство (руль через ряд механизмов связан с передними колесами и когда крутишь его влево — они поворачивают влево и при движении это приводит к повороту машины влево). Или педаль газа — нажал сильнее, двигатель увеличит обороты и это приведет к большему ускорению автомобиля.

В системном подходе концептуальной модели соответствует понятие функциональной схемы.

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

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

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

Ограничения
Когда система не дает просто так сделать то действие, которое делать в данный момент либо нельзя, либо нежелетально. Норман приводит пример полицейским мотоцикла из Лего — все детали спроектированы так, что любой поймет как их сопоставить друг с другом, даже без инструкции. За счет разных видов ограничений (физических, культурных, семантических). Физические ограничения: переднее колесо в несоответствующую ему заднюю вилку, рулевую колодку не в переднюю часть корпуса. Это упрощает использование, потому что снижает количество возможных комбинаций. Просто не получится сделать неподходящее действие. Пример культурного ограничеия: синюю фару физически можно поставить на место фары ближнего/дальнего света, но в культуре принято, что синий — это цвет проблескового маячка у полицейских, поэтому мы без проблем понимаем что ставить его надо на место мигалки. Пример семантического ограничения: человечка мы не посадим лицом назад, потому что понимаем — в этом нет смысла.

Еще примеры ограничений (не из книги):

• кнопка SOS в некоторых современных автомобилях (где есть ЭРА Глонасс): чтобы избежать ложных срабатываний (например, хочешь включить освещение в салоне, а попадаешь в кнопку SOS и вызываешь оператора 112), делают откидную кнопку-ограничитель, как в фильмах, где показывают пилотов истребителей, которые перед тем, как выпустить снаряд сначала должны открыть крышечку над кнопкой выпуска снаряда).
• вилка USB-A — вставить её неверно не получится, она и разьем имеют ограничители, но их невозможно заметить. Я постоянно путаю сторону, но придумал эвристику — если разьем, куда вставлять вилку расположен горизонтально, то вилку нужно вставлять стороной, где два квадратных отверстия наверху:

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

Если от пользователей продукта нет обратной связи про его неудобство — это не значит, что все хорошо

Заговор молчания — когда мы понимаем, что проблема в нас, но молчим, потому хотим скрыть чувство беспомощности и вины (и что люди о нас плохо подумают).

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

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

Напоминания как «потенциальная» память

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

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

Идеальное напоминание содержит и сигнал и сообщение (информацию о том, что нужно сделать). Записал на бумажку — есть только сообщение. Крестик ручкой на руке — напоминает, но не содержит сообщения (причем и напоминает не всегда в подходящий момнт). Приложение тудуйник — удачно объединяет и то, и другое. Я пользуюсь отечественным Singularity, до этого пользовался Todoist. В целом они оба вполне подходящие инструменты.

Но напоминалки — это не обязательно стикеры на бумажках или в тудуйнике. Можно использовать «естественные» напоминания. Обещал принести кому-то из друзей книгу? Положить ее у входной двери и перед выходом на работу не забыл взять с собой.

Просто короткие и прикольные тезисы в кучку:

• Хороший дизайн — незаметный. Просто делает свою работу и никого не раздражает.
• Дизайн системы, которой удобно пользоваться, начинается с того, что мы выявляем каким образом выполняются те задачи, которые эта система должна выполнять. А еще более правильно — когда мы понимаем сценарий использования и в зависимости от того, на каком этапе сценария находится пользователь — адаптируем всё под удобство выполнения этого сценария.
• Требования к продукту, которые люди нам прямо озвучивают часто ошибочны. Более точно их можно определить наблюдением за людьми в их естественной среде. Подробнее эта тема раскрывается у Фитцпатрика в «Спроси маму» и Риса в Lean Startup

В общем, рекомендовал бы эту книгу всем, кто связан с разработкой продуктов.