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

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

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

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

Edge-кейс — непредвиденное поведение системы. Часто не закладывается сразу при разработке, т.к. является крайне неочевидным и проявляется уже только при реальном использовании продукта.Как не допускать ошибки?

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

Рассмотрим некоторые из них:

Установка ограничений ввода

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

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

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

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

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

В поле «дата» можно запретить ввод чисел свыше «31» для дней и свыше «12» для месяцев, чтобы снизить количество заполнений поля произвольными числами.

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

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

Подсказки и предложения

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

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

Правильные настройки по-умолчанию

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

Придерживайтесь распространенных паттернов

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

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

Используйте микрокопирайтинг или UX копирайтинг

Все кнопки, метки на полях и подсказки должны однозначно говорить, как работает интерфейс. Называйте кнопки по действиям, например, не просто «Отмена», а «Отменить», не «Регистрация» а «Создать аккаунт» или «Зарегистрироваться». В полях используйте четкие и однозначные названия. Добавляйте подсказки (placeholders) прямо в поле при клике на нем, чтобы пользователь видел, что мы от него ожидаем.

Предпросмотр

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

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

Проверка ввода в реальном времени

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

Как альтренативу лучше использовать проверку в реальном времени, после перехода в следующее поле (focus out).

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

Подтверждения действий

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

На примере вновь приведу рекламный кабинет Facebook. Чтобы создать рекламное объявление, пользователь готовит картинку, текст, загружает их в специальную форму, настраивает кому он будет показывать, сколько денег он будет платить. А потом случайно нажимает на кнопку «Закрыть» которая затирает всю его работу. Чтобы такого не было Facebook показывает окно с сообщением, что данные будут утеряны, но пользователь все еще может продолжить работу, нажав на кнопку «Отмена» или согласиться выйти, нажав кнопку «Да» (копирайтинг тут не блистательный, с ним можно было бы лучше поработать, если возвращаться к пункту про UX-тексты). Это и есть метод Подтверждения действий. Используйте его на важных действиях, которые приводят к серьезным потерям для пользователя.

К таким действиям чаще всего относятся:

  • Удаления банковских карт из системы, удаления результатов сложных многошаговых форм, удаление аккаунтов
  • Смена важных данных, влияющих на функциональность системы, например, пользовательского логина (тут правда чаще используется верификация через e-mail)

Этот метод не следует использовать на каждом действии. Он довольно раздражает.

Отмена предыдущих действий и редактирование

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

Как искать места гипотетических ошибок?

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

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