«В теории разницы между практикой и теорией нет. На практике есть»
«Ничто так не стимулирует творческих людей к тому, чтобы найти решение проблемы, как твердый дедлайн»
Как главный конструктор, я в некотором роде и главный дизайнер. В конечном итоге моя задача — делать продукт, который будет удовлетворять потребностям пользователей. Имея в виду эту точку зрения, я и читал эту классическую книжку, первое издание которой было в 1987 году. Поскольку дизайну, как и многому другому, я систематически не учился, то мне важно было узнать о базовых понятиях, таких как «означающее», «возможность», «проекция», «ограничение».
Книгу написал Дон Норман, эксперт в области когнитивистики, дизайна и UX, работавший в Гарварде, Кембридже, Университете Сан-Диего и в Apple.
Будем для простоты уравнивать понятия «дизайн», «конструирование» и «проектирование».
В нашей сфере автоматизации неразрушающего контроля пример «возможности» это конструкция сканера, который устанавливается на трек из металлической полосы и поджимается к ней мощной пружиной на полтонны. «Означающее» это рукоятки, за которые сканер можно схватить и перенести, а вот понятного «означающего», которое бы показало, что пружина для установки ослаблена, выполненного в духе «проекции» нет. Поэтому можно уже схватить сканер, попытаться его приладить на трек и внезапно понять, что пружину надо ослабить. Что могло бы послужить означающим? Пока я не придумал. Наверное, какой-то видимый зазор или флажок, который бы показывал что пружина зажата. Пока это можно увидеть по положению рукоятки, но не всегда и с любого ракурса ее хорошо видно. А, кроме того, это старая история о том, что человеческий глаз хорошо различает длины отрезков, но отвратительно меряет углы.
Фидбек — очень важная штука, показывающая что система начала реагировать на запрос пользователя. Но только фидбек должен быть мгновенным. Поэтому мы все время добавляем прогресс-бары, «ромашки» и прочие индикаторы, показывающие, что программа приняла данные и выполняет команду. Характерное время для эффективного фидбека порядка 0.1 с. Именно это я стараюсь объяснять нашим программистам.
Однако фидбек может быть и чрезмерным. Дон приводит в пример посудомоечную машину которая радостно сигнализирует о завершении работы писком в 3 часа ночи.
Парадокс технологий — вводится все больше новых функций облегчающих жизнь людей, но часто они вводятся так, что управлении ими довольно сложно и неинтуитивно.
По мнению Нормана (про это есть отдельная книжка («Things That Make Us Smarter») сверхспособности человека достижимы лишь при сочетании осознанной деятельности и продвинутых технологий. Зависимость от технологий огромна, но надо же иметь план Б на тот случай если сядут батарейки в смартфоне.
Одна из основных мыслей в том, что если пользователь совершает ошибки —скорее всего это проблема дизайна. Пример из личного опыта автора — по результатам расследования аварии в Три-майл-айленд: неудачное проектирование пульта управления.
Инженерам нельзя поручать делать дизайн целиком, если только они не подключают к логике использования знание психологии пользователей. Об этом же и известная книга «Психбольница в руках пациентов».
Много места в книге уделяется попытке систематично описать порядок выполнения действий человеком: от постановки цели, через планирование к исполнению и анализу близости достижения цели. Именно с точки зрения проектирования. И здесь дьявольски много деталей.
Потому что не все действия имеют цель, многие имеют неосознанную цель или цель анализируется неверно. Например: зачем я пишу этот обзор? Чтобы рассказать о книжке вам или для того, чтобы самому разобраться в прочитанном?
Действия могут побуждаться внешним миром, так полезной практикой может быть просьба о постановки дедлайна для важных дел со стороны.
Уровни человеческого сознания, которые должны учитываться при проектировании:
- рептильный — интуитивный: автоматические реакции на стимулы, почти не программируются обучением. Пример: распознавание лица по трем темным пятнам
- собачий — поведенческий : тут важно замыкание действия и сверка результата с ожиданием. Пример: вождение машины
- человеческий — аналитический: самый медленный — это осознанное познание.
Проектировщики редко думают о рептильных реакциях пользователя. И не всегда то, что красиво— удобно и вызывает нужные эмоции.
Наблюдение: отдых часто вспоминают с восторгом, несмотря на то, что дневниковые записи, сделанные например в ходе похода или путешествия, говорят о сплошном дискомфорте и проблемах.
Привычка повторять действие, если первая попытка провалилась — очень опасна и может привести к катастрофам. Например при пожаре или при управлении сложными механизмами. Сколько раз мы остервенело жмем на кнопку, если действие не происходит мгновенно. А между прочим, не исключено, что система сработает на каждое из нажатий, но с задержкой.
Наблюдение: Людям свойственно винить в своих неудачах других людей их самих, а в своих удачах самих себя, а не окружение. Это можно проиллюстрировать очередной матрицей 2х2. И по мнению автора это как раз нормально.
И ненормально, если свои ошибки в обращении с программами или системами человек приписывает исключительно себе. В результате может возникнуть выученная беспомощность. Отсюда идея о том, что потерпеть неудачу — это значит приобрести опыт.
Еще одна проблема с ложным самообвинением — когда человек даже и не жалуется на неудобства, считая, что проблема в нем самом.
Как рекомендуется при этом действовать при проектировании интерфейсов: минимизировать число сообщений об ошибках, стараясь делать интерфейс, чтобы он подсказывал движение в правильном направлении, не заставлять делать работу сначала (например, заполнять заново анкету на получение загранпаспорта на госуслугах, если случайно нажал на кнопочку back, автоматически подсказывать в случае опечаток).
Обязательно нужно учитывать что люди все время отвлекаются и надо давать возможность быстро вернуться в контекст выполняемой задачи.
Пример, который сейчас уже может показаться очевидным: интерфейс, который позволяет указать дату в любом формате, включая — «завтра», «через неделю» или распознает телефонный номер, как бы его не вводили — с пробелами, тире или хоть запятыми.
А мне стоило большого труда в свое время убедить наших программистов распознавать и точку и запятую как десятичный разделитель в нашем софте.
Пример — краткосрочная память имеет, как известно, малую емкость. И если система выдает какое-то важное сообщение, которое потом быстро скрывается или на него некогда среагировать, при этом не сразу ясно как его заново активировать — вызывает фрустрацию пользователя. Поэтому надо добавлять световой или звуковой идентификатор в фоне, к которому можно обратиться, когда есть возможность, и разобраться — что пошло не так. В целом проектировщик всегда должен помнить, что пользователя могут отвлечь о работы в любой момент и нужно помогать им вернуться к работе.
Хотя со звуком в качестве какого-либо индикатора нужно быть очень осторожными. Необдуманное применение быстро вызовет желание пользователя отключить его совсем.
Типы ограничений:
- Физические — пресловутый пример — пальчиковые батарейки, у которых не явны физические ограничения и поэтому ты никогда не уверен — правильно ли вставлена батарейка
- Культурные (социальные сценарии, правила), они со временем меняются и отличаются в разных странах (например, моргание фарами автомобиля в разных странах имеет разное значение)
- Семантические (основаны на знаниях) — они меняются еще быстрее
- Логические (тут подумать надо)
Большой раздел книги посвящен анализу типов человеческих ошибок
Джеймс Ризон разрабатывал такой классификатор, разделяя сбои (errors) на промахи (slips) и ошибки (mistakes).
Промахи характеризуются правильно поставленной целью, но проблемами в ее достижении:
- из-за неправильного действия вместо правильного — пример — пытаться пройти на работу по проездному в метро
- из-за сбоя памяти — просто забыть выключить газ
Ошибки же связаны или с неправильным планом или с неверным планом действий:
- из-за нарушения правил — ну тут все понятно — проехать на красный свет
- из-за незнания — например, используются неверные единицы расчета
- из-за сбоя памяти — когда отвлекают на этапе планирования работы
С точки зрения проектирования, как можно уменьшать вероятность ошибки пользователя:
- не допускать сценариев, которые длительное время развиваются одинаково, а потом начинают отличаться. Пользователь просто может не вовремя понять, по какому варианту развиваются события
- использование принуждения: классический пример — при снятии наличных в банкомате сначала нужно забрать карточку и лишь потом выдаются деньги. Так нивелируется огромное количество забытых в банкомате карточек, когда получивший кэш клиент радостно убегает. В производственной системе Тойота это называется poka-yoke.
- минимизировать количество «режимов», когда одни и те же кнопки приводят в зависимости от режима/контекста к разным действиям. Об этом же писал Джефф Раскин в своей книжке «Интерфейс«
- помогать пользователю превратить ошибку в правильное действие — направлять его
- опять же идея за которую был Раскин — поддержать в интерфейсах неограниченное число отмен выполненных действий (там где это возможно, конечно)
- делать более заметным тот элемент, с которым выполняется действие (подсвечивать)
- не надеяться на то что пользователь будет помнить все нюансы, когда выполняет действия
Хороший образ приводит автор — о том, как некоторые устройства дома странно себя ведут, например лампа, которая работает только если ее стукнуть. Но это дома, а что говорить о подобных проблемах на большом предприятии типа АЭС или НПЗ. Огромная проблема — как распознать действительно важные сигналы о неисправностях и при этом неизбежно игнорировать не столь важные сигналы. Автор признаёт что очевидного решения у этой задачи нет.
Рекомендация по выполнению чек-листов: делать работу сообща, а не последовательно. Потому что если один человек выполняет проверки, а второй типа проверяет первого, то каждый может понадеяться на другого и в итоге оба прошляпят беду.
Важный психологический момент — люди боятся сообщать об ошибках. В NASA эту проблему решают путем анонимизиации сообщений об ошибках. При этом если пилот самолета передал сообщение об ошибке в NASA, а затем эту же ошибку нашел контролирующий орган — пилот в ряде случае освобождается от наказания.
Подобную практику неплохо бы ввести и в медицину и в область неразрушающего контроля и диагностики.
Для вдохновения проектировщиков предлагается модель «Двойного бриллианта», когда процесс дивергентного поиска и сужения решения применяется два раза: чтобы найти проблему и придумать ее решение.
Это великолепная идея, напоминающая о том, что прежде чем предлагать решение надо понять, а в чем, собственно, проблема.
Предлагается концепция, которая должна подружить дизайнеров и маркетологов. В идеале дизайнеры знают, что на самом деле нужно людям, а маркетологи знают, что люди на самом деле покупают. Это взаимодополняющая информация.
Я взял на себя труд сделать поясняющую диаграмму:
То же касается и «улучшизмов» чтобы догонять конкурентов. Хорошо звучит в теории, но рекомендуется «сконцентрироваться на тех областях где ваш продукт сильнее, и еще больше укрепить их».
Это было бы здорово, но в области промышленности улучшизм неизбежен, потому что принимаются новые стандарты, меняются характеристики продукта и если хочешь выигрывать конкурсы, никуда не денешься, придется один за другим разбивать ограничительные барьеры, которые ставят конкуренты.
Мысль о том, что собирать требования с пользователей и аналитиков в общем не то, что позволяет правильно спроектировать. Требуется обязательно наблюдение за пользователями. Причем неоднократное.
На своей практике осознанно я делал это всего пару раз и то 10 лет назад, когда говорил пользователю: «вот откалибруй ПЭП» и наблюдал за тем куда он кликает и что при этом говорит.
Один из секретов хорошего дизайна — ориентация не на задачи (частные), а на деятельность, включающую в себя сценарии, наборы задач, чтобы добивать целей высокого уровня. В пример приводится IPad — как изделие отвечающее целиком за деятельность «прослушивание музыки», включающее поиск, выбор, хранение, расшаривание и как таковое прослушивание.
Еще одна проблема, которую так и непонятно как решить —«неявное знание», когда та информация о продукте, которая на самом деле важна, нигде не зафиксирована, кроме как в голове у разработчиков, и при смене команды очень сложно потом раскопать — что, как и почему все-таки было сделано.
В конце книги описана концепция «восстания мелюзги», когда каждый получил в руки инструменты для создания дизайна и контента, а также пути для публичной демонстрации достигнутых результатов. Сначала я подумал, что автор скорее негативно относится к этой ситуации с мамкиными дизайнерами, но понял, что он видит в это скорее потенциал для развития.
В общем книжка скорее полезна как артефакт, оставленный экспертом и повод для размышлений, извлечь из нее вот прямо хорошие кейсы и неочевидные правила, которые стоило бы выбить в камне, я пожалуй не смог.
#дизайн #юзабилити #книга