Общая психология: usability

То есть как — психология?

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

Корень юзабилити

Человеческие возможности обработки информации ограничены. Рабочая память, «область ясного сознания» не может вместить больше 5-9 элементов, если заниматься только припоминанием, и больше 3-5 – если параллельно заниматься чем-то ещё, например, конструировать модель системы, формулировать мысль, каждую секунду отнимать от сотни по три в уме и так далее. Причём пропускная способность человека как системы переработки информации динамична и напрямую зависит от структуры данных, с которыми человек взаимодействует. То есть одна и та же задача может оказаться для абстрактного пользователя как лёгкой, так и сложной — в зависимости от того, как она представлена интерфейсом. Задачи, которые решает пользователь с помощью программного продукта, обладают внутренней сложностью, и для их решения необходимо некоторое умственное усилие. Избежать внутренней сложности невозможно. Главная задача интерфейса — свести к минимуму сложность внешнюю, единственным источником которой он сам и является.

Цель юзабилити-проектирования

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

Принцип минимизации усилий

Основными показателями удобства интерфейса являются сложность выполнения необходимых пользователю задач и время, затрачиваемое на каждую из них. Именно эти показатели определяют объём усилий, которые, по ощущению пользователя, расходуются на выполнение действия. Показатели имеют разные приоритеты в зависимости от обслуживаемой интерфейсом деятельности.
Сложность. Любое действие имеет свою, внутреннюю, сложность, от которой невозможно избавиться, не сделав это действие бессмысленным. Например, если Вы хотите совершить покупку, Вам не избежать финансовых операций, как и принятия решения по поводу этих операций. Эти два действия обеспечат внутреннюю сложность Вашей деятельности. Вы примете решение, вероятнее всего, без внешних посредников. Однако на этапе произведения финансовых расчётов Вы будете применять различные средства, созданные внутри сообщества. Пусть это будут бумажные деньги. В этом случае процедура финансовых расчётов будет разложена на последовательность движений, простой арифметики и познавательных действий (позволяющих Вам отличать купюры и монеты друг от друга), поддержанную петлёй обратной связи, которая корректирует движения на основе опознания и арифметики. Все эти действия предъявляют к Вам требования и являются внешней сложностью задачи, созданной несовершенством интерфейса «деньги-покупатель».
Таким образом, внешняя сложность задачи всегда является разницей между актуальной сложностью задачи и минимальной возможной сложностью задачи. Минимальная сложность умственной задачи достигается в утопическом случае: любое действие осуществляется в один психологический квант, «одну мысль», без необходимости внешних действий и, тем более, коррекций. «Мысль» как единица измерения никуда не годится, но пафос прост: минимизируем количество действий, а особенно – действий, требовательных к характеристикам их исполнения. Так, попасть курсором в кнопку 10*10 требует гораздо более точных сенсомоторных координаций, чем в кнопку 100*100 – значит, требует большего усилия (пресловутый закон Фиттса учитывает время, но не усилия, и игнорирует контекст. Однако лучше, чем ничего). Оценка сложности каждого поведенческого действия опирается на психофизиологические и – широко – эргономические знания; оценка действий умственных гораздо сложнее и пока, в основном, происходит на базе экспериментальных данных о разнообразных ограничениях человека как системы переработки информации и результатов популяционных исследований.
Основной способ снизить нагрузку на пользователя – организовать информацию так, чтобы в фокусе внимания располагались 1-5 элементов, которые:

1. Имеют одинаковую или схожие функции;
2. При взаимодействии с ними приводят к схожим результатам;
3. Сообщают своими сенсорными свойствами о всех действиях, которые можно с ними совершить (принцип экономичной ментальной модели – ниже);
4. Для взаимодействия с ними не требуют помнить ничего, кроме собственного намерения.

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

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

Принцип экономичной ментальной модели

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

Экономичная ментальная модель:

1. Организована просто и иерархично: использует как можно меньшее количество объектов и правил, не содержит исключений, использует знания из повседневной жизни (например, аналогии элементов интерфейса реальным вещам: элемент, который выглядит, как тумблер, не может иметь активными оба состояния одновременно; зона, реагирующая на наведение курсора, не может быть больше зоны, реагирующей на клик – иначе возникают противоречия);
2. Вынесена вовне: если Ваш продукт устроен (с точки зрения пользователя!) слоями, визуализируйте эти слои. Если это среда с событиями – обеспечьте фон и хорошую различимость событий на нём;
3. Однозначна: если элемент сообщает о себе что-то, то он сообщает только это и ничего другого или противоречивого (!);
4. Внутренне связна: дополнительные связи между структурными единицами приложения снижают итоговую сложность ментальной модели, отображение одной и той же связи несколькими способами позволяет пользователям с разными стилями деятельности одинаково эффективно работать с продуктом.

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

1. Элемент (кнопка, ссылка, скролл-бар, текстовое поле…), атом юзабилити. На этом уровне ментальная модель должна показывать пользователю три свойства:
   • является ли элемент интерактивным;
   • какие взаимодействия с элементом возможны;
   • к чему приведёт каждое из этих взаимодействий.
2. Блок (навигационная панель, список, текстовое поле с принадлежащими ему кнопками и подсказками…). Блок состоит из элементов, и дополнительным требованием ментальной модели к нему является цельность: блоки отграничены друг от друга пространственно и с помощью обратной связи, взаимодействие между ними минимизировано. Количество элементов в блоке, как правило, соответствует среднему объёму внимания человека, поэтому именно блок является основной единицей взаимодействия «пользователь-приложение», и понимание этого предоставляет нам множество возможностей разгрузить пользователя.
3. Страница состоит из блоков. Дополнительных требований к странице (относительно первых двух уровней) два. Первое из них – указание на положение в структуре сайта/приложения. Страница чаще всего моделируется как пространство, экран, разворот книги и так далее: система блоков, встроенная в пространство всего приложения, имеющая свой уникальный адрес (в понимании пользователя! Не путь в сайте, а некое место, в которое можно пройти с помощью определённой последовательности внутренних ссылок и из которого можно этим же образом выйти. Узел в сети приложения). Положение страницы в сети приложения, количество «входов» и «выходов» определяют её оформление. Второе требование к странице – функциональное единство. Каждая страница создана для какой-то определённой цели, и эта цель отражается в атрибутике (стиле) страницы, выборке блоков и их взаимном расположении.
4. Приложение состоит из страниц. Ментальная модель приложения – это его глобальная функция (что делает этот сайт?) и структура (как он организован? Из чего состоит? Как с ним работать?). Дополнительное требование к ментальной модели сайта: прозрачность его внутреннего устройства, сети переходов между страницами.

Как создать ментальную модель?

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

Скрытые правила – законы организации приложения любого уровня, выраженные невербально. Часто они носят внешний относительно приложения характер, то есть наследуются из более широкого контекста. Прямоугольник высотой чуть больше строки с высветленным текстом, обращающимся к пользователю («Чем Вы заняты?», «Что нового?», «Введите описание задачи…»), считается полем ввода текста. Его функция никак не следует из формы или других характеристик, однако с развитием Интернет-технологий значение закрепилось в культуре, и теперь сделать, например, кнопку с таким внешним видом означает запутать подавляющее большинство пользователей. Это скрытое правило базируется на аналогии.
Аналогии – перенос некоторых свойств объекта на другой объект, используя совпадающие характеристики образов восприятия этих объектов или способов взаимодействия с ними. Поле текстового ввода на разнообразных стенах в соцсетях аналогично уже написанным сообщениям по пространственным характеристикам (размер и положение), а также аналогично полям ввода и вывода некоторых технических устройств (строке калькулятора и счётных приборов в автомобиле, телеграфной ленте, рукописной строке в тексте). Наиболее выгодные аналогии – со знакомыми пользователю в реальной жизни предметами. Типичные примеры – это инструмент «вырезать» (уничтожает содержание в одном месте, предоставляя возможность восстановить его в другом), предметные иконки (приоткрытая дверь – выход, шестерёнка – механическое устройство, настройки; динамик с волнами около него – звук), постраничный вид документа в текстовых редакторах, файловые системы всех популярных операционных систем (и само слово «файл»). Найти продукт с графическим интерфейсом, не использующий аналогии, практически невозможно. Именно аналогии Д.Норман положил в основу принципа естественного соответствия, подчёркивая этим названием необходимую интуитивность аналогий, их понятность без размышлений.

Принцип безошибочности

Все пользователи совершают ошибки. Как и в случае сложности, задача идеального юзабилити-инженера – избавить пользователя от ошибок по вине программы и позволить ему исправить ошибки, допущенные по его собственной вине. В первом приближении что-то может идти не так на двух уровнях: моторном и смысловом. Типичные ошибки моторного уровня – неточное позиционирование курсора при клике, промах по клавише, неверное опознание буквы. Ошибки смыслового уровня – это неверное опознание слова, совершение ненамеренного действия, забывание намерения… В большинстве случаев уровень ошибки не имеет особого значения, однако есть ситуации, в которых защита именно от определённого типа ошибок в корне изменяет диалог человека с программой.
Возможные ошибки пользователя зачастую невозможно моделировать без учёта его состояния, а этот фактор определяет многое во взаимодействии потребителя с продуктом. Утомлённый, задумавшийся или взволнованный (тонизированный) пользователь вероятнее допускает ошибки обоих уровней, невозможные для пользователя в оптимальном рабочем состоянии.
Защита от моторных ошибок — ограничения на минимальный размер шрифта и кнопки, на минимальное расстояние между границами соседних кнопок.
Защита от смысловых ошибок — максимальная различимость функциональных элементов, их разумная группировка (экономизация ментальной модели) и самое главное – очевидные защиты от деструктивных действий, особенно если такие действия необратимы. Возможные способы защиты от фатальных ошибок:

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

Как снизить нагрузку?

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

1. Напоминания и внешняя память: чем меньше нужно помнить пользователю, тем лучше. Даже собственное намерение он может забыть, если на пути к его реализации встанут несколько перегруженных экранов или хотя бы одно непредсказуемое событие;
2. Непрерывность деятельности и защита от прерываний: давайте пользователю возможность закончить начатое, прежде чем отвлекать его. После каждого отвлечения ему понадобится время, чтобы вспомнить, чем он занимался, и вработаться в прерванную деятельность – и ответственность за это потраченное впустую время лежит на разработчике. Но пока софт мало знает о пользователе. Полноценные сенсоры ещё не стали непременным атрибутом рабочего места, но они смогут значительно облегчить нам жизнь.

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

Автор: 2cun

Источник