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