Черная пятница в UPROCK! 2 дня до конца распродажи!

Помощь и документация: десятая эвристика юзабилити

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

Десятая эвристика юзабилити гласит: 

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

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

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

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

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

  • документация;
  • видео;
  • обучающие материалы. 

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

Есть два типа помощи в интерфейсе: проактивная и реактивная. Проактивную помощь можно далее разделить на push- и pull-сообщения.

1. Проактивная помощь

Цель проактивной помощи — познакомить пользователей с интерфейсом. Проактивная помощь часто возникает в следующих трех сценариях:

  1. Новые пользователи при первом запуске интерфейса
  2. Начинающие пользователи по мере освоения интерфейса (это происходит со временем и наиболее актуально для сложных приложений)
  3. Существующие пользователи сталкиваются с новым или переработанным интерфейсом

Проактивная помощь может быть реализована посредством:

Asana предлагает несколько шаблонов, чтобы помочь пользователям начать работать с распространенными типами проектов. Шаблоны могут быть полезны как для новых, так и для существующих пользователей.
Push- и pull-уведомления: два типа проактивной помощи

Проактивная помощь бывает двух видов: push- и pull-уведомления. Чтобы понять разницу между ними, следует ответить на следующие вопросы:

  • являются ли они индивидуализированными для контекста пользователя? 
  • связаны ли они с его текущей целью?

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

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

При входе в цифровую библиотеку O’Reilly система выдавала проактивную помощь в форме оверлея с инструкциями с выделением элементов интерфейса.

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

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

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

  • когда курсор мыши находится рядом с соответствующими элементами управления;
  • когда пользователь запустил определенный сценарий взаимодействия.

Pull-уведомления могут быть реализованы при помощи следующих средств:

  • всплывающими подсказками;
  • контекстными оверлеями;
  • мастер-формами. 

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

Microsoft Word распознал, что пользователь работал над резюме, и предоставил совет “Посмотреть предложения по резюме от LinkedIn”. Это пример pull-сообщения, поскольку оно запускается поведением конкретного пользователя, а не выдается всем пользователям.
Руководство по предоставлению проактивной помощи

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

  • своевременной;
  • информативной;
  • актуальной. 

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

Предпочтите pull-уведомления push-уведомлениям. Сделайте справочный контент доступным, но не навязывайте его пользователям. Используйте push-уведомления для информации, которая может потребоваться независимо от текущей задачи пользователя, а pull-уведомления для своевременного предоставления справочного контента, который имеет отношение к выполняемой задаче.

Dovetail, платформа для пользовательских исследований, своевременно посредством pull-сообщения предоставляла справочный контент, когда пользователи открывали страницу с данными. Такой вариант лучше, чем предоставление этого контента в виде push-сообщения (например, при входе в систему).

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

MindNode, мобильное приложение для визуализации, запустило обучение для новых пользователей (push-сообщение) и предоставило возможность пропустить его.

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

IOS предоставляла справочную информацию (помеченную как “Советы”) по вопросам изменений интерфейса и системы. Эти советы были представлены в качестве проактивной помощи (и push-, и pull-сообщения, в зависимости от контекста), но они также доступны в приложении IOS “Советы”, которое предварительно установлено на iPhone).

2. Реактивная помощь

Реактивная помощь предоставляется в ответ на столкновение пользователя с проблемой. Цели реактивной помощи:

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

Реактивная помощь предоставляется в следующем виде:

  • часто задаваемые вопросы; 
  • техническая документация; 
  • руководства или учебные модули.
Руководство по предоставлению реактивной помощи

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

Material Design предоставил обширную техническую документацию, в которой содержалась информация о различных компонентах, что они из себя представляют и как они используются.
Документация Microsoft Mixed Reality Toolkit иногда была неясной и не содержала описаний упомянутых дизайнов. В указанном случае в документации содержались визуальные подсказки, например, “ближний свет” и “сжимающаяся клетка”, но не были определены сами шаблоны, способы их реализации и отсутствовали ссылки на дополнительную информацию.

Обеспечьте возможность “сканирования” материала взглядом, используя правила написания текстов для веба:

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

Страницы поддержки Figma, инструмента для создания прототипов, было легко сканировать: у них были четкие заголовки и нумерованные списки.
Страницы поддержки IOS-приложения “Птицы Северной Европы” было трудно сканировать. Инструкции были написаны в форме абзацев, а не нумерованных списков.

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

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

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

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

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

Xbox предоставил категории (разделы) справочной информации на своей странице поддержки.
AirBrush, IOS-приложение для редактирования фото, предлагало обучающие материалы в GIF-формате, но не разбивало их на категории. Приложение предоставило более 20 GIF-руководств на одной прокручиваемой странице без заголовков или группировки.

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

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

Заключение

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

Действуйте по следующему алгоритму:

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

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

Источник
и
:
arrow