Оффлайн
- Регистрация
- 21.07.20
- Сообщения
- 40.408
- Реакции
- 1
- Репутация
- 0
Все мы рано или поздно оказываемся один на один со сложной информационной системой, а ведь далеко не каждый интерфейс позволяют нам быстро найти и выполнить нужную процедуру. В такой ситуации события могут развиваться по одному из двух сценариев:
Первый. Перед вами система и 5 минут на то, чтобы выполнить в ней необходимую процедуру. Первым делом вы ищете нужную кнопку или пункт меню, не находите и начинаете нервничать, ведь время идёт, а хочется быть эффективным в любой своей деятельности. Напряжение делает вас расфокусированным, в этом состоянии вы продолжаете искать и в какой-то момент понимаете, что не сможете сами разобраться. Обращаетесь в техподдержку: набираете номер, играет приятная музыка и отрешённый голос сообщает вам, что вы пятнадцатый в очереди, напряжение растёт. Через какое-то время отвечает сотрудник техподдержки, он объясняет вам, что надо делать. Вы успокаиваетесь и выполняете свою задачу.
Второй. Перед вами та же система и те же 5 минут. Вы открываете руководство пользователя, находите нужный раздел, читаете его и делаете всё, как там написано. Прошло несколько минут, вы спокойно разобрались и выполнили свою задачу.
Меня как пользователя больше бы устроил второй сценарий, в нём очень важную роль играет руководство пользователя. Но далеко не каждое руководство поможет вам быстро разобраться в чем-то, есть ряд требований, которым оно должно соответствовать.
В этой статье мы разберём требования, которые относятся к названию разделов в руководстве или названиям инструкций. Также мы обсудим, какой должна быть навигация в пользовательской документации.
Хочешь, чтобы никто не нашел, назови не думая
Название инструкции — это не название статьи в интернете. Ему не надо привлекать внимание и вызывать какие-то эмоции. Пользователь по названию должен понять, какая процедура описана в инструкции. Инструкцию надо называть так, чтобы её было несложно найти в интернете. Давайте более подробно разберёмся с этим.
Название инструкции не должно вызывать эмоции
Я использую два вида названий:
- название-проблема;
- название-процесс.
У каждого вида своя цель, и при выборе названия стоит учитывать один важный момент — психологическое состояние пользователя, а именно, состояние, в котором он находится в тот момент, когда начинает искать эту инструкцию.
Что такое «название-процесс»
Цель инструкции с таким названием — объяснить какой-то процесс.
Пример ситуации: пользователю надо в чём-то разобраться, у него есть достаточное количество времени и более менее спокойное состояние. По факту, его задача — понять как что-то работает. Для инструкции, которая будет решать такую задачу я использую — название-процесс.
Если это руководство пользователя, то в нём таких процессов может быть много. В этом случае мы уже говорим не про название инструкции, а про название раздела руководства.
Поисковый запрос может начинаться со слов “как работает” или “как сделать”. Это явно запросы про описание процесса, про ошибки и проблемы пользователь будет спрашивать иначе.
Пример названия-процесса:
You must be registered for see links
.Ситуация, когда будут искать эту инструкцию: пользователь купил устройство Рутокен с программой Рутокен Диск и хочет разобраться, как сохранить файл в защищённой флеш-памяти.
Его поисковый запрос: “как сохранить файл в защищённом разделе” или “как работать с Рутокен Диском”.
Он открывает инструкцию, выбирает свою операционную систему и раздел с названием “Работа с защищённым разделом”. Такой поиск у него займёт несколько секунд. Дальше он выполнит все действия этой процедуры и поймёт процесс.
Ещё один пример названия-процесса:
You must be registered for see links
.Ситуация, когда будут искать эту инструкцию: пользователь купил Рутокен с сертификатом КриптоПро и ему надо, чтобы всё это заработало на макбуке.
Его поисковый запрос: “Рутокен КриптоПро macOS”.
Он открывает инструкцию и выполняет последовательно все шаги из неё.
Пример плохого названия инструкции:
You must be registered for see links
.Ситуация, когда будут искать эту инструкцию: пользователю необходимо отформатировать токен перед тем как использовать его в другой системе или ему просто надо сменить PIN-код.
Мне это название не нравится по трём причинам:
- Оно слишком длинное.
- В нём фигурирует две процедуры: форматирование токена и смена PIN-кода.
- Название сформулировано не так, как его будет искать пользователь.
И получается, что его может найти не только пользователь, который хочет отформатировать токен, но и тот, кто хочет сменить PIN-код. Пользователь откроет эту инструкцию, начнёт форматировать токен, а это приведёт к тому, что удалятся все сертификаты, которые стоят денег. Он хотел просто сменить PIN-код, а это надо было сделать иначе. Также у пользователя мог быть изначально пустой токен, тогда форматировать его не надо. На этом примере мы видим, что плохое название инструкции может привести даже к финансовым потерям. Эта инструкция подошла бы только в том случае, если пользователю надо было отформатировать Рутокен.
Плохое название может привести к финансовым потерям
Сейчас по запросу “как изменить PIN-код Рутокена” пользователь найдёт нашу инструкцию.
Что такое “название-проблема»
Цель инструкции с таким названием — помочь решить проблему.
Пользователь работал в системе и в ней что-то произошло. Например, отобразилось сообщение с каким-то предупреждением или ошибкой, и он не знает, как правильно поступить. Он оказывается в стрессовой ситуации, от того, что он будет делать дальше зависит результат. Для описания таких случаев я использую — название-проблему.
Поисковый запрос может начинаться со слов “что делать, если” или “отобразилась ошибка”. Здесь пользователю надо максимально быстро получить ответ.
Также в такой ситуации его поисковый запрос может дублировать название ошибки или текст предупреждения.
Пример такого названия:
You must be registered for see links
.Ситуация, когда будут искать эту инструкцию: пользователь подключает смарт-карту Рутокен, а она не работает в системе, и он хочет разобраться, почему она не работает и, что сделать, чтобы заработала.
Его поисковый запрос: “токены или смарт-карты недоступны”. Он описывает проблему так, как она сформулирована в окне с ошибкой.
Он находит эту инструкцию и выполняет необходимые действия в системе.
Второй пример названия, но теперь уже раздела:
You must be registered for see links
Ситуация, когда будут искать эту инструкцию: пользователь ввёл несколько раз неправильный PIN-код, на экране отобразилось сообщение о том, что он заблокирован.
Самая эмоциональная реакция может возникнуть, когда с этим сталкиваются первый раз. Чаще всего пользователю кажется, что всё, доступ к Рутокену уже не вернуть, но это не так.
Его поисковый запрос будет таким: “что делать, если PIN-код Пользователя заблокирован”.
Он откроет эту инструкцию, найдёт нужный раздел и разблокирует PIN-код.
Пример плохого названия инструкции:
You must be registered for see links
Что мне не нравится в этом названии:
- Оно слишком длинное, в нём указаны лишние подробности, а именно то, что Рутокен вставлен. За счёт этого можно было сократить название.
- Я бы заменила слово “диод”, не каждый пользователь его знает.
Давайте сделаем общие выводы:
- Прежде чем придумывать название для инструкции необходимо понять — для кого эта инструкция и в какой ситуации пользователь будет её искать.
- При составлении названий используйте слова из мира пользователей.
- Подумайте о том, какой запрос пользователь введёт, когда будет искать инструкцию.
- Перед публикацией инструкции ещё раз прочитайте название и подумайте, может быть вы указали какие-то лишние подробности.
Хочешь, чтобы никто не нашёл, забудь про навигацию
После того, как пользователь прочитает название инструкции, поймёт насколько она подходит для его задачи, он попадёт на страницу с содержанием. Так вот оно тоже должно быть составлено определённым образом. Правда есть случай, когда его не должно быть. Давайте разбираться, надеюсь вы ещё не устали.
Содержание как карта
Главное требования к содержанию инструкции — оно должно быть логичным.
Цель содержания, как и у любой карты — ускорить процесс поиска. Помочь пользователю быстро найти нужный раздел. Да, кто-то скажет, что в инструкции всегда можно воспользоваться внутренним поиском, нажав Ctrl+F, но это не всегда удобно. Если страниц в инструкции много, то внутренний поиск может только запутать пользователя.
Содержание должно быть логичным
Здесь тоже не обойтись без примеров. Давайте посмотрим на навигацию в одной из моих инструкций.
Самый простой случай, когда описана программа, которая работает в одной операционной системе. В нашем случае это программа
You must be registered for see links
. Посмотрим на то, как устроена навигация в
You must be registered for see links
для неё.
Как видите, это просто последовательность процедур. Они выстроены по определённой логике, которая отражает то, как пользователь будет взаимодействовать с этой программой. Получается, что перед тем, как разместить содержание инструкции необходимо понять, что пользователь будет делать в этой программе, осознать его логику.
Простая последовательность изложения может выглядеть так:
Установка -> Запуск -> Настройка -> Процесс работы -> Удаление
В таком содержании пользователь просто находит нужный раздел и выполняет описанную в нём процедуру.
Второй случай, когда есть программа, которая работает в нескольких операционных системах.
Ранее мы рассматривали
You must be registered for see links
про
You must be registered for see links
, она как раз была с таким содержанием. В ней пользователь находит раздел со своей операционной системой и подраздел с необходимой процедурой.Такая последовательность изложения выглядит так:
Выбор операционной системы -> Запуск -> Настройка -> Процесс работы -> Удаление
Здесь просто добавилось название операционной системы, их в одной инструкции может быть много.
Пользователь должен находить название нужного раздела меньше чем за полминуты, иначе можно сделать вывод, что содержание не работает и его можно смело удалить.
У пользователя полминуты на то, чтобы найти нужный раздел
Я ещё очень люблю делать навигацию внутри разделов, это для тех пользователей, которые автоматически пропускают содержание.
Вот пример такой
You must be registered for see links
. Она написана для пользователей
You must be registered for see links
.
Здесь, если пользователь пропустит содержание, то он увидит в заголовке раздела название необходимого сервиса и уже внутри этого раздела найдёт необходимый подраздел, при этом в содержании названия этих подразделов тоже остаются, для тех кто всё-таки его читает.
Содержание может всё испортить
Есть случай, когда содержание может действительно всё испортить. Его проще всего описать так: если пользователь пропустит любой шаг, то ничего работать не будет. Дорожная карта нужна в том случае, если дорог много. Но когда дорога одна и надо двигаться по ней не пропуская ни одного пункта, карта не нужна. Пользователь просто выполняет все шаги один за другим. Да, у меня таких инструкций немало, и они чаще всего про настройку чего-либо. Чтобы минимизировать стресс пользователя, в начале такой инструкции я объясняю ему, что необходимо последовательно выполнить все шаги этой инструкции, тогда у него сформируется определённый настрой.
Последний пример в этой статье как раз будет про это. Инструкция о том, как удалить сертификат. В самом её начале я объясняю пользователю, что прежде чем удалить сертификат, надо определить криптопровайдера или формат сертификата и записать имя контейнера. Это важно, так как можно удалить не тот сертификат, а вернуть его будет уже невозможно.
Поэтому у пользователя в начале инструкции нет возможности сразу перейти к какому-то разделу. Он открывает инструкцию и на первой странице читает предупреждение и последовательность действий. Здесь моя роль — предупредить его о возможных рисках. Дальше он конечно выбирает сам, как ему действовать.
Давайте сделаем общие выводы:
- При составлении содержания учитывайте логику взаимодействия пользователя с тем, что вы описываете.
- Если пользователь пропустил содержание, то ему может помочь навигация в разделе.
- Если пропускать шаги в инструкции нельзя, то навигация не нужна.
Казалось бы все эти выводы простые и логичные, но я часто вижу, что про это забывают. Давайте всё-таки осознаем всё, что написано в этой статье и начнём писать так, чтобы минимизировать стресс пользователя. Ведь тогда мы сможем изменить его состояние, а также улучшить глобальное отношение к пользовательской документации.