Применением каких методов можно сократить ошибки пользователей

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

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

• Секреты юзабилити: почему пользователи винят себя в ошибках дизайнеров?

Два типа пользовательских ошибок

Как правило, посетители ресурсов совершают ошибки двух типов: промахи и просчеты.

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

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

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

Общие рекомендации по предотвращению ошибок

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

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

1. Вспомогательные ограничения

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

К примеру, бронирование рейсов обычно включает в себя выбор даты поездки, и авиакомпании предлагают клиентам несколько подсказок, позволяющих указать подходящий день для перелета. Одно из основных правил заключается в том, что обратный рейс не может произойти до отъезда. Если пользователи не ограничены по дате, они могут случайно указать неверный временной отрезок. В данном случае, вспомогательное ограничение позволяет им выбрать правильный диапазон дат:

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

• Микро-контент: как повысить UX с помощью нескольких слов?

2. Подсказки в строке поиска

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

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

Пользователям, которые ищут наушники, может быть трудно вспомнить, как пишется, например, «Etymotic Research», да и с набором самой фразы могут возникнуть проблемы. Кликабельные подсказки в поисковой строке Amazon.com позволяют найти искомое, введя несколько первых букв, благодаря чему количество ошибок сводится к минимуму

3. Установите правильные исходные настройки

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

Приложение Inbox для iOS от компании Google позволяет вам «отложить» письмо на потом. Здесь используются удобные стандартные настройки, которые предотвращают ошибки путем предоставления самых распространенных выборов

4. Используйте щадящее форматирование

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

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

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

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

• 4 ошибки веб-дизайна, убивающие конверсию

Вместо заключения

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

Высоких вам конверсий!

По материалам: nngroup.com, image source: Sharon Wish 

25-12-2015

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

Природа
существования ошибок.

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

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

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

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

Типы ошибок

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

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

Опечатки
происходят
в двух случаях:

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

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

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

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

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

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

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

Суммируя, при
борьбе с ошибками нужно направлять
усилия на:

—
плавное
обучение пользователей в
процессе работы

—
снижение
требований к бдительности

—
повышение
разборчивости и заметности индикаторов.

— снижение
чувствительности системы к ошибкам.

Для этого есть три
основных способа, а именно:

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

—
проверка
системой всех действий пользователя
перед их принятием

—
самостоятельный
выбор системой необходимых команд или
параметров, при этом от пользователя
требуется только проверка.

Самым
эффективным является третий способ. К
сожалению, этот способ наиболее труден
в реализации. Разберем эти три способа
подробнее.

Блокировка
потенциально опасных действий до
получения подтверждения

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

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

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

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

Не
делайте опасные для пользователя кнопки
кнопками по умолчанию

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

Проверка действий
пользователя перед их принятием

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

Всегда
показывайте границы диапазона во
всплывающей подсказке

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

Рис. 3. Ползунок.

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

Самостоятельный
выбор команд

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

Проиллюстрировать
сферу применения данного метода удобно
на примере печати. MS Windows User Experience
заставляет использовать только один
способ что-либо напечатать. Существует
две команды меню Файл,
а именно Печать
и
Параметры
печати.
Обе команды вызывают одноименные
диалоговые окна. Проблема заключается
в том, что обилие элементов управления
замедляет восприятие этих окон и
увеличивает вероятность ошибки.

Рис. 4. Диалоговое
окно печати в MS Word. © Microsoft.

Разберём
это подробнее. Итак, чем меньше элементов
управления, тем меньше вероятность
ошибки. Система может уменьшить число
элементов, если она знает сама, какими
именно параметрами она должна
руководствоваться. Главной причиной
появления этих диалоговых окон является
печать нескольких копий. Причем есть
простая зависимость – «количество
копий обратно пропорционально частоте
печати такого количества», т.е. сто копий
печатают примерно в сто раз реже, чем
печатают одну копию. Стандартное
диалоговое окно печати содержит также
область выбора принтера из числа
установленных в системе. Большинство
же пользователей имеет только один
принтер. Так зачем заставлять это
большинство каждый раз вдумчиво
воспринимать совершенно не нужные им
элементы интерфейса?

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

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

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

—
здравый
смысл разработчика системы

—
предыдущие
установленные параметры

—
наиболее
часто устанавливаемые параметры.

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

Два уровня ошибок
и обратная связь

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

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

С
ошибками из четвертого пункта всё ясно.
Всякий раз, когда мы теряем возможность,
по крайней мере, проверить корректность
данных или самой системы, мы вступаем
на слишком уж скользкий путь. Межпланетные
зонды, из-за ошибок в ПО улетают не туда
куда надо, коммерческие договоры, в
которых обнаруживаются ошибки приносят
много неприятностей, ошибочные номера
телефонов в записной книжке не дают
возможности найти абонента – всё это
примеры неисправляемых ошибок. Разумеется,
такие ошибки всегда обнаруживаются,
проблема в том, что к моменту их обнаружения
становится поздно их исправлять. Именно
поэтому такие ошибки гораздо хуже
ошибок, которые исправить трудно, но
которые, по крайней мере, сразу видны.
Единственной индустрией, научившейся
получать пользу от необнаруженных
ошибок, является производство почтовых
марок – марки с опечатками стоят у
филателистов многократно дороже марок
без них. Это было знание программистов.
Теперь пора перейти к интерфейсу и
определить, почему ошибки первого типа
(«исправляемые во время») гораздо лучше
ошибок второго типа («исправляемых
после»).

Вообще
говоря, объяснение этого факта двояко.
Объяснение есть как субъективное, так
и объективное, сказать, какое сильнее,
затруднительно. При этом объяснения
еще и складываются.

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

—
понять,
что ошибка совершена

—
понять,
как её исправить

—
потратить
время на исправление ошибки.

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

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

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

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

К
сожалению, это простое соображение
имеет существенный недостаток: вводить
в систему обратную связь получается не
всегда. Дело в том, что её ненавидят
программисты. Мотивируют они своё
отношение тем, что она плохо влияет на
производительность системы. Обычно они
обманывают. На самом деле им просто лень
её реализовывать. Иногда, впрочем,
соображения о производительности
системы и вправду имеют место. Так что
если вы чувствуете, что программисты
правы, когда говорят о том, что система
«будет тормозить», вспомните, что
производительность связки
«система-пользователь» всегда важнее
производительности системы просто.
Если же и это не помогает, попробуйте
спроектировать обратную связь иначе,
более скромно. Иногда так получается
даже лучше. Например, с помощью ползунков
на линейке в MS Word можно менять абзацные
отступы, при этом обратная связь есть,
но не полная: вместо перманентного
переформатирования документа по экрану
двигается полоска, показывающая, куда
передвинется текст. Благодаря этому
изображение на экране особенно не
перерисовывается, что хорошо, поскольку
такое «дрыганье» раздражает.

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

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

Как это делается? Рассмотрим типичный пример.

При входе в личный кабинет Invision сообщение об ошибке выводится выше полей формы. Предполагается, что пользователь прочтет фразу «Упс. Логин или пароль неправильные» и проверит, правильно ли введены логин и пароль.

Однако на самом деле происходит нечто иное. Статистика показывает, что зачастую пользователь вновь и вновь пытается ввести пароль, прежде чем догадается проверить логин.

Такое поведение легко объяснимо. В случае ошибки логин остается на месте, а поле пароля очищается. Это изменение привлекает больше внимания, чем текст, выделенный красным. Когда пользователь нажимает на кнопку входа, он сконцентрирован на зоне ввода пароля.

Эта область называется фокусом внимания.

Следите за фокусом внимания.

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

Часто, чтобы решить проблему, достаточно разместить сообщение об ошибке там, где пользователь точно заметит его.

Само по себе это правило достаточно простое, и бо́льшая часть сервисов уже не нарушают его.

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

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

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

Рассмотрим на примере. В последнее время наблюдается тенденция «дизейблить» недоступные действия. Например, пока пользователь не заполнит все поля на сайте «Госуслуги», кнопка «Сохранить» не станет активной.

Человек может просто не догадаться, почему кнопка серая и неактивная. Он наверняка попытается нажать на нее, даже если где-то на странице написано «заполните все поля». Настроив аналитику, вы можете выяснить, как часто люди кликают на серую кнопку. А исходя из полученных данных, уже можно принять решение, надо ли дезактивировать кнопку в вашем случае.

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

Про тексты в таких сообщениях поговорим ниже.

Не заставляйте пользователя самому искать ошибки. Сообщения об ошибках должны помогать ему быстрее разобраться с интерфейсом.

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

Каковы самые частые проблемы интерфейсных текстов?

Текст не должен быть слишком длинным. Вряд ли пользователи будут вникать в такие пассажи. Пишите как можно короче.

В приложении Xiaomi mi fit на вопрос «Отменить изменения?» предлагается два ответа «отмена» и «отменить». Подобные формулировки ставят пользователя в тупик.

Эта проблема широко распространена. Посмотрите на пример ниже.

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

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

Сообщение об ошибке должно помогать решить проблему, а не приводить в ступор.

Следующий уровень, повышающий качество сообщения об ошибке, — это подсказки. Объясню на примере, подсмотренном на этом курсе.

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

Сканируешь товар и кладешь его на весы с другой стороны. На первый взгляд всё просто.

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

Решить проблему помогло одно маленькое сообщение об ошибке, которое подсказывало пользователям, как исправить дело.

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

Поэтому появление окна с сообщением об ошибке сопровождалось звуком «би-би-би», который заставлял покупателя прервать монотонное сканирование и поднять глаза на экран. Он видел, что нужно сделать, и ставил бутылку воды на весы.

Таким образом, в 90% случаев люди стали обходиться без вызова помощника. Подсказывая пользователю, как исправить ошибку самому, можно сэкономить время обслуживающего персонала.

Позаботьтесь о том, чтобы пользователю не приходилось повторять свои действия из-за ошибки.

Запоминайте данные, если пользователь случайно закрыл поп-ап или обновил страницу. Сохраняйте все, что можно сохранить. Не очищайте поля, заполненные без ошибок. И так далее. Без примеров эти рекомендации бесполезны, поэтому давайте рассмотрим два кейса.

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

Обратите внимание, что сервис автоматически подставил в номер телефона код России +7. После подтверждения номера телефона кодом из СМС следует заполнить профиль: ввести имя, фамилию и год рождения.

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

Далее нужно заполнить адресную информацию. При этом страна определилась автоматически и написана кириллицей. Но я-то знаю, что надо вводить латиницей!

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

Отличный дизайн — незаметен. Semrush — один из немногих сервисов, которые запоминают ваш логин и не заставляют вводить его заново, если вы пытаетесь восстановить пароль.

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

Перевод материала Эммануэля Сербонуа о том, как анализировать действия пользователей и сделать дизайн, который не заведёт их в тупик.

Материал подготовлен командой онлайн-школы английского языка Skyeng.

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

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

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

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

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

Я использую термин «система» в широком смысле — для описания цифровых продуктов, потоков, реальных систем.

Сколько типов ошибок существует

Джеймс Ризон, заслуженный профессор Манчестерского университета, подробно исследовавший эту тему, выделяет две категории: промахи и ошибки.

О чём нужно помнить

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

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

Когда я искал материал для этой статьи, я наткнулся на PDF с большим количеством примеров, опубликованный на сайте Управления по охране труда Великобритании.

Почему случаются ошибки

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

Кратко рассмотрим каждую из этих причин.

Предвзятость при принятии решений

Я выбрал три наиболее распространённых фактора ошибок. Это поможет понять, к чему они приводят.

Люди в принципе предрасположены ко множеству ошибок. В «Википедии» есть список с большим количеством примеров.

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

Работа в условиях стресса (закон Йеркса — Додсона)

Ещё в 1908 году психологи Роберт Йеркс и Джон Додсон обнаружили связь между стрессом (называемым в психологии возбуждением) и производительностью.

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

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

Работа в неестественных условиях

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

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

Как люди решают проблемы

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

Вот самые важные из них, которые следует принимать во внимание при моделировании поведения пользователя.

Систематическое исследование

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

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

Метод проб и ошибок

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

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

Упрямство

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

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

Материал по теме: статья Амстердамского университета.

Дизайн с учётом человеческого фактора

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

Рассмотрим несколько приёмов проектирования, которые можно использовать в ходе разработки для снижения влияния человеческого фактора.

1. Предотвращать ошибки

Это хороший вариант, потому что он позволяет предотвращать ошибки ещё до того, как человек их допустит. Так у пользователя появляется ощущение безопасности и стабильности.

Методы:

2. Прощать ошибки

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

Методы:

3. Объяснять

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

Методы:

Дополнительные техники

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

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

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

1. Четко выделяйте обязательные для заполнения поля

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

На форме регистрации Zappos.com обязательные поля выделены звездочкой (*). Необязательные поля так же явно обозначены.

2. Используйте удобные и подробные сообщения об ошибках

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

Форма регистрации на Yahoo! предоставляет информацию об ошибках в реальном времени.

Читайте о лучших методах использования подсказок и проверок на ошибки в веб-формах.

3. Используйте проверку формата данных на стороне клиента (JavaScript)

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

Форма регистрации на SurveyGizmo дает знать, если формат введенного вами адреса электронной почты неверный.

4. Визуально выделяйте заполняемые поля, чтобы пользователь не потерялся

Убедитесь в том, что визуально можно определить какое именно поле пользователь заполняет в данный момент. Это можно реализовать с помощью селектора псевдо-класса focus: в CSS.

Веб-форма на Wufoo визуально выделяет активные элементы цветом фона.

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

Google Chrome выделяет активный элемент желтой рамкой. Firefox светло голубой.

5. Показывайте результаты прогресса

Если ваша веб-форма объемная и состоит из нескольких страниц (или имеет несколько шагов), убедитесь что пользователь постоянно получает сведения о ходе выполняемых действий, о том, сколько еще времени может ему понадобиться для заполнения. Такое часто встречается в случаях онлайн-опроса (исследования) с множеством вопросов или в процессе оформления заказа в интернет магазине.
Все что нужно, это писать “Шаг 4 из 5” или что-то в этом роде. Если пользователи будут продолжают нажимать кнопку “продолжить”, четко не понимая когда будет последний шаг, то они прекратят заполнение формы раньше, чем вы можете предположить.

Оформление заказа на Amazon имеет 4 страницы. Форма сообщает где вы сейчас и сколько еще осталось до завершения.

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

6. Периодически сохраняйте (кешируйте) данные формы

На формах с несколькими страницами или шагами часто можно допустить ошибку. Для избежания потери данных необходимо реализовать способ сохранения введенной пользователем информации для каждой сессии. Это повышает надежность и процент того, что форма будет заполнена даже после таких ситуаций, когда пользователь уходит с данной страницы (например нажимает кнопку назад в браузере). Необходимость заново заполнять все поля формы может заставить пользователя уйти.

7. Не используйте стандартный текст “Submit” (отправить)

Вместо того, чтобы ваша кнопка на форме называлась “Submit” (отправить), используйте такой текст, чтобы он напоминал пользователю о его действиях. Например “Зарегистрироваться”, или еще лучше — дайте пользователю узнать о преимуществах после заполнения формы.

На форме регистрации Basecamp текст «Submit» заменили на более полезный.

8. Кнопка “Отменить” заставляет колебаться

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

9. Показывайте пользователям поля в правильном формате

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

Форма регистрации Geico предоставляет однозначные инструкции о том, в каком формате ожидаются вводимые данные.

10. Одноколоночная форма — лучшее решение

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

Одноколоночная форма

Форма регистрации Backpack имеет одноколоночную форму.

Форма с несколькими колонками

Для сравнения на форме регистрации eBay пользователю нужно заполнять форму как снизу вверх, так и слева направо.

Примеры отличных веб-форм

Вот несколько превосходно разработанных форм для вдохновения.

Alexandru Cohaniuc

Grip’d Custom Facebook Tab Creator

Groupon

KISSMetrics

MobileMe Sign In

Baymard Institute провел исследование, как сайты сообщают пользователям об ошибках в заполнении полей форм. Только 9% компаний используют адаптивные сообщения об ошибках. Остальные 91% сайтов выдает стандартные сообщения.

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

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

15 ошибок лид-форм, убивающих конверсию

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

Универсальные сообщения об ошибках

Анализ оформления и оплаты заказов на 100 сайтах показал, что большинство сообщений об ошибках заполнения формы шаблонны и непонятны пользователю. Стандартные сообщения никак не помогает пользователю понять, где допущена ошибка и как ее исправить. Универсальные сообщения об ошибках варьируются от просто бесполезных до сбивающих пользователя с толку.

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

Исправляем:

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

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

Затем пользователь добавил код страны в международном формате, а сообщение о неверном формате номера телефона осталось прежним.

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

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

Если пользователь не понимает, где допущена ошибка, он может пойти двумя путями:

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

Адаптивные сообщения об ошибках

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

Рассмотрим пример. Пользователь вводит адрес электронной почты «snezhcka@gmail», тогда адаптивное сообщение прозвучит следующим образом:

Вы не указали домен высшего уровня, такой как .com, .ru, .net

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

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

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

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

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

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

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

Вы ввели дату, которая уже прошла. Пожалуйста, укажите заново все данные карты: номер, дату окончания действия карты и код безопасности.

Адаптивные сообщения об ошибках: есть ли альтернативы?

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

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

Какие есть альтернативы:

• распознание и прием всех возможных форматов ввода данных, а затем применение алгоритмов стандартизации данных (приведения данных к единому формату)
• четкое объяснение, в каком формате данные должны быть введены в поле
• встроенная валидация — проверка данных в момент введения.

Ни один из этих методов не исключает ошибок, допускаемых пользователями каждый раз при заполнении форм. Люк Вроблевкски (Luke Wroblewski), юзабилити-эксперт, автор книг Mobile First и Web Form Design, провел исследование встроенной валидации в сравнении с обычным методом проверки. Результаты исследований показали:

• количество успешно заполненных форм возросло на 22%
• количество допущенных ошибок уменьшилось на 22%
• оценочный коэффициент удовлетворенности увеличился на 31%
• время заполнения формы сократилось на 42%
• количество зрительных фиксаций сократилось на 47%

Якоб Нильсен, юзабилити эксперт, разработал рекомендации, каким должно быть сообщение об ошибке:

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

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

«Вы использовали один из недопустимых символов в пароле «!;№%:?*()@#$&. Попробуйте еще раз. Мы в Вас верим!»

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

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

Советы по исправлению — вместо того, чтобы указывать только на ошибку, объясните пользователю, как ее исправить. Сравним:

Неверный формат ввода телефона

ИЛИ

Вы ввели номер телефона в неверном формате. Не используйте пробелы. Укажите номер без дефисов/скобок/пробелов.

Рекомендации GetGoodRank по повышению эффективности лид-форм:

разрешите введение данных в разных форматах — пусть пользователь имеет возможность вводить номер телефона в привычном формате. Вы сможете легко привести данные к единому формату при помощи автоматических сервисов.

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

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

По материалам Baymard

«Неиспользуемые» перенаправляются сюда. Информацию о непригодной к использованию электронике см. Кирпич (электроника). О немецком немом фильме 1917 года см. Неиспользуемый (фильм).

Удобство использования можно описать как способность системы предоставлять пользователям условия для безопасного, эффективного и результативного выполнения задач, одновременно наслаждаясь опытом.^[1] В программная инженерия юзабилити — это степень, в которой программное обеспечение может использоваться определенными потребителями для достижения определенных целей с эффективностью, действенностью и удовлетворенностью в определенном контексте использования.^[2]

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

Юзабилити включает в себя методы измерение удобство использования, например требуется анализ^[3] и изучение принципов, лежащих в основе воспринимаемой эффективности или элегантности объекта. В взаимодействие человека с компьютером и Информатика, юзабилити изучает элегантность и ясность, с которой взаимодействие с помощью компьютерной программы или веб-сайта (удобство использования в Интернете ) разработан. Юзабилити учитывает удовлетворенность пользователей и полезность в качестве качественных компонентов и направлена ​​на улучшение Пользовательский опыт через итеративный дизайн.^[4]

Вступление

Основное понятие юзабилити состоит в том, что объект, созданный с учетом обобщенных пользовательских психология и физиология Имеется в виду, например:

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

Сложные компьютерные системы находят свое применение в повседневной жизни, и в то же время рынок насыщен конкурирующими бренды. Это сделало удобство использования более популярным и широко признанным в последние годы, поскольку компании видят преимущества исследования и разработки своих продуктов с помощью ориентированных на пользователя методов, а не технологии -ориентированные методы. Понимая и исследуя взаимодействие между продуктом и пользователем, эксперт по юзабилити может также дать понимание, недостижимое для традиционных компаний, ориентированных на исследования рынка. Например, после наблюдения и опроса пользователей эксперт по удобству использования может определить необходимые функциональные возможности или недостатки дизайна, которые не были предвидены. Метод под названием контекстный запрос делает это в естественном контексте собственной среды пользователя. в ориентированный на пользователя дизайн парадигма, продукт всегда разрабатывался с учетом его предполагаемых пользователей. В управляемом пользователем или совместный дизайн парадигма, некоторые пользователи становятся актуальными или де-факто члены дизайнерской группы.^[5]

Период, термин удобный часто используется как синоним пригодный к употреблению, хотя это может также относиться к доступность. Юзабилити описывает качество взаимодействия с пользователем на веб-сайтах, в программном обеспечении, продуктах и ​​средах. Нет единого мнения о соотношении терминов эргономика (или же человеческие факторы ) и удобство использования. Некоторые считают удобство использования программного обеспечения специализация более широкой темы эргономики. Другие считают эти темы второстепенными: эргономика сосредоточена на физиологических вопросах (например, поворот дверной ручки), а удобство использования — на психологических вопросах (например, признание того, что дверь можно открыть, повернув ручку). Удобство использования также важно при разработке веб-сайтов (удобство использования в Интернете ). В соответствии с Якоб Нильсен, «Исследования поведения пользователей в Интернете показывают, что они плохо переносят сложный дизайн или медленные сайты. Люди не хотят ждать. И они не хотят учиться пользоваться домашней страницей. Нет такой вещи, как обучение или руководство для веб-сайта. Люди должны быть в состоянии понять функционирование сайта сразу после сканирования домашней страницы — самое большее в течение нескольких секунд ».^[6] В противном случае большинство обычных пользователей просто покидают сайт и просматривают или делают покупки в другом месте.

Юзабилити также может включать концепцию прототипичности, то есть насколько конкретная вещь соответствует ожидаемой общей норме, например, в дизайне веб-сайтов пользователи предпочитают сайты, соответствующие признанным нормам дизайна.^[7]

Определение

ISO определяет удобство использования как «степень, в которой продукт может использоваться определенными пользователями для достижения определенных целей с эффективностью, действенностью и удовлетворенностью в определенном контексте использования». Слово «удобство использования» также относится к методам повышения простоты использования в процессе проектирования. Консультант по юзабилити Якоб Нильсен и профессор информатики Бен Шнейдерман написали (отдельно) о структуре приемлемости системы, где удобство использования является частью «полезности» и состоит из:^[8]

• Обучаемость: Насколько легко пользователям выполнять базовые задачи при первом знакомстве с дизайном?
• Эффективность: как быстро пользователи смогут выполнять задачи после изучения дизайна?
• Запоминаемость: когда пользователи возвращаются к дизайну после периода, когда он не используется, насколько легко они могут восстановить свои навыки?
• Ошибки: сколько ошибок делают пользователи, насколько серьезны эти ошибки и насколько легко они могут исправить ошибки?
• Удовлетворение: Насколько приятно пользоваться дизайном?

Удобство использования часто связано с функциональностью продукта (см. ISO определение, ниже), помимо того, что они являются исключительно характеристикой пользовательского интерфейса (см. структуру приемлемости системы, также ниже, которая разделяет полезность в удобство использования и полезность). Например, в контексте обычных потребительских товаров автомобиль без задней передачи можно рассматривать непригодный для использования согласно предыдущему мнению, и лишенный полезности согласно последней точке зрения. При оценке пользовательских интерфейсов на предмет удобства использования определение может быть таким простым, как «восприятие целевым пользователем эффективности (соответствия цели) и эффективности (работы или времени, необходимого для использования) интерфейса».^{[нужна цитата ]}. Каждый компонент может быть измерен субъективно по критериям, например, Принципам проектирования пользовательского интерфейса, чтобы обеспечить показатель, часто выражаемый в процентах. Важно различать юзабилити-тестирование и юзабилити-инжиниринг. Юзабилити-тестирование это мера простоты использования продукта или программного обеспечения. В отличие, юзабилити-инжиниринг (UE) — это процесс исследования и проектирования, обеспечивающий удобство использования продукта. Юзабилити — это нефункциональное требование. Как и в случае с другими нефункциональными требованиями, удобство использования не может быть измерено напрямую, но должно быть определено количественно с помощью косвенных мер или атрибутов, таких как, например, количество сообщенных проблем с простотой использования системы.

Интуитивно понятный интерфейс

Период, термин интуитивно понятный часто указывается как желательная черта в используемых интерфейсах, часто используется как синоним обучаемый. Некоторые эксперты, такие как Джеф Раскин не рекомендовали использовать этот термин в дизайне пользовательского интерфейса, утверждая, что простые в использовании интерфейсы часто оказываются легкими из-за того, что пользователь знаком с предыдущими подобными системами, поэтому следует отдавать предпочтение термину «знакомый».^[9] Например: две вертикальные линии «||» кнопки на медиаплеере интуитивно не означают «пауза» — они делают это условно. Стремление к «интуитивно понятным» интерфейсам (основанное на повторном использовании существующих навыков с системами взаимодействия) может привести к тому, что дизайнеры откажутся от лучшего дизайнерского решения только потому, что для этого потребуется новый подход. Эта позиция иногда иллюстрируется замечанием, что «Единственный интуитивно понятный интерфейс — это сосок; все остальное можно изучить».^[10] Брюс Тоньяццини даже отрицает существование «интуитивных» интерфейсов, поскольку такие интерфейсы должны быть способны интуитивно, то есть «воспринимать шаблоны поведения пользователя и делать выводы».^[11] Вместо этого он отстаивает термин «интуитивно понятный», то есть «чтобы пользователи могли интуитивно понять работу приложения, увидев его и используя». Однако он продолжает: «Но даже это бесполезная цель, поскольку только 25 процентов населения полагается на интуицию, чтобы что-либо воспринимать».

Стандарты ISO

Стандарт ISO / TR 16982: 2002

ISO / TR 16982: 2002 («Эргономика взаимодействия человека с системой — методы удобства использования, поддерживающие проектирование, ориентированное на человека «) Международная организация по стандартизации (ISO) стандарт, который предоставляет информацию о методах удобства использования, ориентированных на человека, которые могут использоваться для проектирования и оценки. В нем подробно описаны преимущества, недостатки и другие факторы, относящиеся к использованию каждого метода удобства использования. В нем объясняется значение стадии жизненного цикла и индивидуальных характеристик проекта для выбора методов удобства использования и приводятся примеры методов удобства использования в контексте. Основными пользователями ISO / TR 16982: 2002 являются: Менеджеры проекта. Таким образом, в нем рассматриваются технические аспекты человеческого фактора и вопросы эргономики только в той степени, в которой это необходимо, чтобы менеджеры могли понять их актуальность и важность для процесса проектирования в целом. Руководство в ISO / TR 16982: 2002 может быть адаптировано для конкретных проектных ситуаций с использованием списков проблем, характеризующих контекст использования продукта, который должен быть доставлен. При выборе подходящих методов удобства использования следует также учитывать соответствующий процесс жизненного цикла. ISO / TR 16982: 2002 ограничен методами, которые широко используются специалистами по юзабилити и руководителями проектов. Оно делает нет укажите детали того, как реализовать или реализовать описанные методы удобства использования.

Стандарт ISO 9241

ISO 9241 — это стандарт, состоящий из нескольких частей, который охватывает ряд аспектов людей, работающих с компьютерами. Хотя первоначально назывался Эргономические требования к офисной работе с терминалами визуального отображения (ВДТ), он был переименован в более общий Эргономика взаимодействия человека с системой.^[12] В рамках этого изменения ISO изменяет нумерацию некоторых частей стандарта, чтобы он мог охватывать больше тем, например тактильное и тактильное взаимодействие. Первой была перенумерована часть 10 в 2006 году, теперь часть 110.^[13]

Дизайн для удобства использования

Любая система или устройство, предназначенные для использования людьми, должны быть простыми в использовании, легкими в освоении, легкими для запоминания (инструкции) и полезными для пользователей. Джон Гулд и Клейтон Льюис рекомендуют дизайнерам, стремящимся к удобству использования, следовать этим трем принципам дизайна.^[14]

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

Сосредоточьтесь на пользователях и задачах

Команда разработчиков должна руководствоваться принципами работы пользователей и находиться в прямом контакте с потенциальными пользователями. Несколько методы оценки, включая персонажи, когнитивное моделирование, проверка, запрос, прототипирование, а методы тестирования могут способствовать пониманию потенциальных пользователей и их представлений о том, насколько хорошо работает продукт или процесс. Соображения удобства использования, такие как пользователи и их опыт работы с аналогичными системами, должны быть изучены. Как часть понимания пользователей, эти знания должны «… противопоставляться задачам, которые пользователи должны будут выполнять».^[14] Сюда входит анализ того, какие задачи будут выполнять пользователи, какие из них наиболее важны, и какие решения будут принимать пользователи при использовании вашей системы. Дизайнеры должны понимать, как когнитивные и эмоциональные характеристики пользователей будут связаны с предлагаемой системой. Один из способов подчеркнуть важность этих вопросов в сознании дизайнеров — использовать образы, которые представляют собой выдуманных репрезентативных пользователей. См. Ниже дальнейшее обсуждение персонажей. Еще один более дорогой, но более информативный метод — заставить группу потенциальных пользователей тесно сотрудничать с командой дизайнеров на ранних этапах.^[15]

Эмпирическое измерение

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

Итерационный дизайн

Итерационный дизайн — это методология проектирования, основанная на циклическом процессе прототипирования, тестирования, анализа и усовершенствования продукта или процесса. По результатам тестирования последней итерации дизайна вносятся изменения и уточнения. Этот процесс призван в конечном итоге улучшить качество и функциональность дизайна. В итеративном дизайне взаимодействие с разработанной системой используется как форма исследования для информирования и развития проекта по мере того, как реализуются последовательные версии или итерации дизайна. Ключевыми требованиями к итеративному дизайну являются: определение необходимых изменений, способность вносить изменения и готовность вносить изменения. Когда возникает проблема, не существует установленного метода определения правильного решения. Скорее, существуют эмпирические методы, которые можно использовать во время разработки системы или после того, как система поставлена, обычно в более неподходящее время. В конечном итоге итеративный дизайн направлен на достижение таких целей, как создание удобной для пользователя, простой в использовании, простой в эксплуатации, простой и т. Д.^[15]

Методы оценки

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

Когнитивные методы моделирования

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

Параллельный дизайн

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

GOMS

Основная статья: GOMS

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

Модель человеческого процессора

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

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

Считается, что долговременная память имеет бесконечную емкость и время распада.^[16]

Моделирование уровня нажатия клавиш

Моделирование на уровне нажатия клавиш — это, по сути, менее полная версия GOMS, которая делает упрощающие предположения, чтобы сократить время и сложность вычислений.

Методы проверки

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

Сорта карт

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

Древовидные тесты

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

Этнография

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

Эвристическая оценка

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

• Видимость состояния системы: Система всегда должна информировать пользователей о том, что происходит, посредством соответствующей обратной связи в разумные сроки.
• Соответствие системы и реального мира: Система должна говорить на языке пользователей, используя слова, фразы и концепции, знакомые пользователю, а не системные термины. Следуйте обычным правилам, чтобы информация отображалась в естественном и логическом порядке.
• Пользовательский контроль и свобода: Пользователи часто выбирают системные функции по ошибке, и им потребуется четко обозначенный «аварийный выход», чтобы выйти из нежелательного состояния без необходимости проходить расширенный диалог. Поддержка отмены и повтора.
• Последовательность и стандарты: Пользователи не должны задаваться вопросом, означают ли разные слова, ситуации или действия одно и то же. Соблюдайте соглашения о платформе.
• Предотвращение ошибок: Даже лучше, чем хорошие сообщения об ошибках, — это тщательный дизайн, который в первую очередь предотвращает возникновение проблемы. Либо устраните условия, подверженные ошибкам, либо проверьте их и предоставьте пользователям вариант подтверждения, прежде чем они совершат действие.
• Признание скорее, чем отзывать:^[17] Сведите к минимуму нагрузку на память пользователя, сделав видимыми объекты, действия и параметры. Пользователь не должен запоминать информацию из одной части диалога в другую. Инструкции по использованию системы должны быть видимыми или легко извлекаемыми при необходимости.
• Гибкость и эффективность использования: Ускорители — невидимые для начинающего пользователя — часто могут ускорить взаимодействие для опытного пользователя, так что система может обслуживать как неопытных, так и опытных пользователей. Разрешите пользователям настраивать частые действия.
• Эстетичный и минималистичный дизайн: Диалоги не должны содержать неактуальной или редко необходимой информации. Каждая дополнительная единица информации в диалоге конкурирует с соответствующими единицами информации и снижает их относительную видимость.
• Помогите пользователям распознавать, диагностировать и устранять ошибки: Сообщения об ошибках должны быть изложены простым языком (без кодов), точно указывать на проблему и конструктивно предлагать решение.
• Помощь и документация: Даже если систему можно использовать без документации, может потребоваться помощь и документация. Любая такая информация должна быть удобной для поиска, ориентированной на задачу пользователя, содержать список конкретных шагов, которые необходимо выполнить, и не должна быть слишком большой.

Таким образом, определяя, какие правила нарушаются, можно определить удобство использования устройства.

Проверка удобства использования

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

Плюралистическая проверка

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

Проверка согласованности

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

Анализ деятельности

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

Способы запроса

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

Анализ задачи

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

Фокус группы

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

Анкеты / опросы

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

Методы прототипирования

Дизайнерам часто бывает очень сложно провести тесты на удобство использования с конкретной разрабатываемой системой. Ограничения по стоимости, размеру и конструкции обычно побуждают проектировщика создавать прототип системы.Вместо того, чтобы создавать полную окончательную систему, разработчик может протестировать различные разделы системы, создав таким образом несколько небольших моделей каждого компонента системы. Прототипирование — это установка и результат, так как это процесс генерации и осмысления осязаемых идей, позволяя неудачам произойти раньше. ^[18] Создание прототипов помогает людям увидеть, что могло бы способствовать передаче общего видения и формированию будущего. Типы прототипов удобства использования могут отличаться от использования бумажных моделей, каталожных карточек, рисованных моделей или раскадровок.^[19] Прототипы можно быстро модифицировать, зачастую их проще и быстрее создавать, затрачивая меньше времени дизайнерами, и они более склонны к изменению дизайна; хотя иногда они не являются адекватным представлением всей системы, часто они недолговечны, и результаты тестирования могут не совпадать с результатами тестирования реальной системы.

Подход с использованием набора инструментов

Этот набор инструментов представляет собой обширную библиотеку методов, использующих традиционный язык программирования, и в первую очередь разработан для компьютерных программистов. Код, созданный для тестирования с использованием набора инструментов, может быть использован в конечном продукте. Однако, чтобы получить максимальную пользу от инструмента, пользователь должен быть опытным программистом.^[20]

Подход с использованием комплектов деталей

Два элемента этого подхода включают библиотеку деталей и метод, используемый для определения соединения между деталями. Этот подход может использоваться практически кем угодно, и он является отличным преимуществом для дизайнеров, выполняющих повторяющиеся задачи.^[21]

Метафора языка анимации

Этот подход представляет собой комбинацию подхода с использованием набора инструментов и подхода к комплекту деталей. И дизайнеры диалогов, и программисты могут взаимодействовать с этим инструментом для создания прототипов.^[22]

Быстрое прототипирование

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

Методы тестирования

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

Метрики

При проведении тестов юзабилити дизайнеры должны использовать метрики юзабилити, чтобы определить, что они собираются измерять, или метрики юзабилити. Эти показатели часто изменчивы и меняются в зависимости от масштабов и целей проекта. Количество тестируемых предметов также может повлиять на показатели юзабилити, так как часто легче сосредоточиться на определенных демографических характеристиках. Фазы качественного проектирования, такие как общее удобство использования (можно ли выполнить задачу?) И удовлетворенность пользователей, также обычно выполняются с небольшими группами субъектов.^[23] Использование недорогих прототипов для небольших групп пользователей позволяет получить более подробную информацию из-за более интерактивной атмосферы и способности дизайнера сосредоточиться на отдельном пользователе.

По мере того, как проекты становятся более сложными, тестирование должно становиться более формализованным. Оборудование для тестирования станет более сложным, а показатели тестирования — более количественными. В случае более совершенного прототипа дизайнеры часто проверяют эффективность, результативность и субъективное удовлетворение, прося пользователя выполнить различные задачи. Эти категории измеряются процентом выполнения задачи, продолжительностью выполнения задач, отношениями успеха к неудачам для выполнения задачи, временем, потраченным на ошибки, количеством ошибок, оценочной шкалой удовлетворенности, количеством раз, когда пользователь кажется разочарованным и т. д.^[24] Дополнительные наблюдения за пользователями дают дизайнерам представление о трудностях навигации, элементах управления, концептуальных моделях и т. Д. Конечная цель анализа этих показателей — найти / создать прототип дизайна, который понравится пользователям, и использовать его для успешного выполнения поставленных задач.^[19] После проведения тестов юзабилити проектировщику важно записать то, что наблюдалось, помимо того, почему произошло такое поведение, и изменить модель в соответствии с результатами. Часто бывает довольно сложно отличить источник ошибок дизайна от того, что сделал неправильно пользователь. Однако эффективные тесты юзабилити не помогут решить проблемы, а предоставят измененные рекомендации по проектированию для продолжения тестирования.

Удаленное тестирование юзабилити

Удаленное тестирование юзабилити (также известное как немодерируемое или асинхронное юзабилити-тестирование) включает использование специально модифицированного онлайн-опроса, позволяющего количественно оценить исследования пользовательского тестирования, предоставляя возможность генерировать большие размеры выборки или глубокий качественный анализ без необходимости специального удобства. Кроме того, этот стиль пользовательского тестирования также дает возможность сегментировать отзывы по демографическим, оценочным и поведенческим типам. Тесты проводятся в собственной среде пользователя (а не в лабораторных условиях), помогая в дальнейшем моделировать тестирование реальных сценариев. Этот подход также позволяет легко запрашивать обратную связь от пользователей в удаленных районах. Есть два типа: количественный и качественный. Для количественного анализа используются опросы большого размера и опросы, основанные на задачах. Эти типы исследований полезны для проверки предполагаемых проблем с удобством использования. Качественные исследования лучше всего использовать в качестве исследовательских, с небольшими объемами выборки, но частыми, даже ежедневными итерациями. Качественный метод обычно позволяет наблюдать за экранами респондента и озвучивать устные комментарии (видео с экрана, SRV), а для более глубокого понимания также включает изображение респондента с веб-камеры (Video-in-Video, ViV, иногда называемое Picture- в картинке, PiP)

Удаленное тестирование юзабилити мобильных устройств

Рост числа мобильных и связанных с ними платформ и услуг (например, рост мобильных игр в 2010-2012 гг. Увеличился в 20 раз) вызвал потребность в немодерируемом удаленном тестировании юзабилити на мобильных устройствах как для веб-сайтов, так и особенно для взаимодействия с приложениями. Одна из методологий заключается в доставке камер и специальных креплений для камер специализированным тестерам и их записи с экрана мобильного смартфона или планшетного устройства, обычно с использованием HD-камеры. Недостатком этого подхода является то, что движения пальца респондента могут скрывать обзор экрана, в дополнение к предвзятости и логистическим проблемам, связанным с доставкой специального оборудования выбранным респондентам. В более новом подходе используется беспроводная проекция экрана мобильного устройства на экран рабочего стола компьютера респондента, который затем может быть записан через его веб-камеру, и, таким образом, комбинированный просмотр видео-в-видео участника и взаимодействия с экраном просматриваются одновременно, пока включение словесных мыслей и комментариев респондентов вслух.

Мысли вслух

В Продумайте протокол вслух — это метод сбора данных, который используется как в исследованиях юзабилити, так и в психологии. Он включает в себя побуждение пользователя озвучивать свои мыслительные процессы (т.е. выражать свое мнение, мысли, ожидания и действия).^[25] как они выполняют задачу или набор задач. Как широко распространенный метод юзабилити-тестирования, «думай вслух» дает исследователям возможность узнать, что на самом деле думает пользователь во время выполнения и завершения задачи.^[25]

Часто присутствует инструктор, который побуждает пользователя говорить больше во время работы. Подобно методу «Субъекты в тандеме», он полезен для точного определения проблем и относительно прост в настройке. Кроме того, он может дать представление об отношении пользователя, которое обычно невозможно определить из опроса или анкеты.

RITE метод

Быстрое итеративное тестирование и оценка (RITE)^[26] представляет собой итеративный метод юзабилити, аналогичный традиционному «дисконтному» юзабилити-тестированию. Тестировщик и команда должны определить целевую группу для тестирования, запланировать вход участников в лабораторию, решить, как будет измеряться поведение пользователей, составить сценарий тестирования и предложить участникам устный протокол (например, подумать вслух). Однако он отличается от этих методов тем, что рекомендует вносить изменения в пользовательский интерфейс сразу после выявления проблемы и определения решения. Иногда это может произойти после наблюдения всего за 1 участником. После того, как данные для участника собраны, инженер по удобству использования и команда решают, будут ли они вносить какие-либо изменения в прототип до следующего участника. Затем измененный интерфейс тестируется с остальными пользователями.

Объекты в тандеме или со-открытие

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

Тестирование юзабилити на основе компонентов

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

Другие методы

Познавательная прогулка

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

Сравнительный анализ

Сравнительный анализ создает стандартизированные тестовые материалы для конкретного типа дизайна. При установлении эталона учитываются четыре ключевые характеристики: время для выполнения основной задачи, время для исправления ошибок, время для изучения приложений и функциональность системы. Когда есть эталон, с ним можно сравнить другие проекты, чтобы определить удобство использования системы. Многие общие цели исследований удобства использования, такие как попытка понять поведение пользователей или изучение альтернативных дизайнов, должны быть отложены. В отличие от многих других методов или типов лабораторных исследований, сравнительные исследования больше напоминают настоящие лабораторные исследования экспериментальной психологии, с большим вниманием к деталям методологии, протоколу исследования и анализу данных.^[27]

Мета-анализ

Мета-анализ представляет собой статистическую процедуру для объединения результатов различных исследований для интеграции результатов. Эта фраза была придумана в 1976 году как количественный литературный обзор. Этот тип оценки очень эффективен для определения удобства использования устройства, поскольку он объединяет несколько исследований для обеспечения очень точной количественной поддержки.

Персона

Персоны представляют собой вымышленные персонажи, созданные для представления различных типов пользователей сайта или продукта и связанных с ними демографических и технических характеристик. Алан Купер представил концепцию использования персонажей как части интерактивного дизайна в 1998 году в своей книге Заключенные управляют приютом,^[28] но использовал эту концепцию с 1975 года. Персонажи — это метод оценки юзабилити, который можно использовать на различных этапах проектирования. Наиболее типичное время для создания персонажей — это начало проектирования, чтобы дизайнеры имели четкое представление о том, кто будет пользователями их продукта. Персонажи — это архетипы которые представляют фактические группы пользователей и их потребности, которые могут быть общим описанием человека, контекста или сценария использования. Этот метод превращает маркетинговые данные о целевой группе пользователей в несколько физических представлений о пользователях, чтобы вызвать сочувствие среди команды дизайнеров, с конечной целью более точно адаптировать продукт к тому, как персонажи будут его использовать. Чтобы собрать маркетинг данные, которые требуются пользователям, можно использовать несколько инструментов, в том числе онлайн-опросы, веб-аналитика, формы обратной связи с клиентами, юзабилити-тесты и интервью с представителями службы поддержки.^[29]

Преимущества

Ключевые преимущества удобства использования:

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

Корпоративная интеграция

Повышение удобства использования обычно положительно влияет на несколько аспектов качества продукции компании. В частности, преимущества делятся на несколько общих областей:^[30]

• Повышенная продуктивность
• Снижение затрат на обучение и поддержку
• Увеличение продаж и доходов
• Сокращение времени и затрат на разработку
• Снижение затрат на обслуживание
• Повышение удовлетворенности клиентов

Повышенное удобство использования на рабочем месте вызывает несколько откликов со стороны сотрудников: «Работники, которым нравится их работа, делают ее лучше, дольше остаются перед лицом соблазнов и вносят идеи и энтузиазм в эволюцию повышения производительности».^[31] Для создания стандартов компании часто применяют методы экспериментального проектирования, которые создают базовые уровни. Проблемы, вызывающие озабоченность в офисной среде, включают (но не обязательно ограничиваются ими):^[32]

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

Работая над улучшением указанных факторов, корпорации могут достичь своих целей по увеличению выпуска продукции при меньших затратах, потенциально создавая оптимальный уровень удовлетворенности клиентов. Существует множество причин, по которым каждый из этих факторов коррелирует с общим улучшением. Например, упрощение понимания пользовательских интерфейсов программного обеспечения снижает потребность в обширном обучении. Усовершенствованный интерфейс имеет тенденцию сокращать время, необходимое для выполнения задач, и, таким образом, одновременно повышает уровень продуктивности сотрудников и сокращает время разработки (и, следовательно, затраты). Каждый из вышеупомянутых факторов не исключает друг друга; скорее, следует понимать, что они работают вместе, чтобы сформировать общую рабочую среду. В 2010-х удобство использования признано важным атрибутом качества программного обеспечения, заняв свое место среди более традиционных атрибутов, таких как спектакль, надежность и эстетичный вид. Различные академические программы ориентированы на удобство использования.^[33] Несколько юзабилити консультирование появились компании, и традиционные консалтинговые и дизайнерские фирмы предлагают аналогичные услуги.

Существует некоторое сопротивление интеграции работы по удобству использования в организациях. Юзабилити рассматривается как расплывчатое понятие, его трудно измерить, и другие области становятся приоритетными, когда у ИТ-проектов заканчивается время или деньги.^[34]

Профессиональное развитие

Практикующие юзабилити иногда проходят обучение на промышленных инженеров, психологов, кинезиологи, инженеров-проектировщиков систем или со степенью в области информационной архитектуры, информации или библиотечного дела, или Человеко-компьютерное взаимодействие (HCI). Чаще всего это люди, прошедшие подготовку в конкретных прикладных областях, которые в своей организации сосредоточили внимание на удобстве использования. Любой, кто стремится сделать инструменты более простыми в использовании и более эффективными для выполнения желаемых функций в контексте работы или повседневной жизни, может извлечь пользу из изучения принципов и рекомендаций по удобству использования. Для тех, кто хочет продлить свое обучение, Ассоциация профессионалов юзабилити предлагает онлайн-ресурсы, списки литературы, курсы, конференции и собрания местных отделений. УПА также спонсирует Всемирный день юзабилити каждый ноябрь.^[35] Связанные профессиональные организации включают Общество человеческого фактора и эргономики (HFES) и Ассоциация вычислительной техники группы, заинтересованные в компьютерном взаимодействии с человеком (СИГЧИ ), Дизайн коммуникаций (SIGDOC ) и компьютерная графика и интерактивные методы (СИГГРАФ ). В Общество технической коммуникации также есть группа специальных интересов по удобству использования и пользовательскому опыту (UUX). Они издают ежеквартальный информационный бюллетень под названием Юзабилити Интерфейс.^[36]

Смотрите также

Рекомендации

дальнейшее чтение

• Р. Г. Биас и Д. Дж. Мэйхью (редакторы) (2005), Экономичность и удобство использования: обновление для эпохи Интернета, Морган Кауфманн
• Дональд А. Норман (2013), Дизайн повседневных вещей, Базовые книги, ISBN  0-465-07299-2
• Дональд А. Норман (2004), Эмоциональный дизайн: почему мы любим (или ненавидим) повседневные вещи, Базовые книги, ISBN  0-465-05136-7
• Якоб Нильсен (1994), Юзабилити-инженерия, Издательство Morgan Kaufmann, ISBN  0-12-518406-9
• Якоб Нильсен (1994), Методы проверки юзабилити, Джон Уайли и сыновья, ISBN  0-471-01877-5
• Бен Шнейдерман, Психология программного обеспечения, 1980, ISBN  0-87626-816-5

внешняя ссылка

• Usability.gov