Оценка руководства пользователя

Как с помощью руководства пользователя повысить качество информационной системы +38

Тестирование IT-систем, Отладка, Анализ и проектирование систем, Блог компании ГК ЛАНИТ

---

Рекомендация: подборка платных и бесплатных курсов Java — https://katalog-kursov.ru/

Описание проблемы

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

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

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

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

3. Частые изменения.
Опять же следствие масштаба — постоянный поток изменений и доработок.

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

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

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

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

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

Поиск решения

Для каждой проблемы был разработан собственный подход. Рассмотрим каждую проблему и каждый подход более подробно.

Неактуальность документа

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

1. Составить описание модели «AS IS» (т.е. что у нас есть сейчас, какие функции и бизнес-процессы описаны).
2. Описать модель «TO BE» (в качестве консультантов привлекались ведущие аналитики по каждой подсистеме).
3. Сравнить «AS IS» и «TO BE» с помощью индикатора «Светофор» и составить план действий.

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

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

Далее наглядным индикатором «Светофор» были отмечены результаты сравнения:

1. Зеленый цвет – процесс есть в руководстве и нужен в бизнесе.
2. Красный – процесс есть, но не нужен (удалить!).
3. Желтый – процесс отсутствует, но нужен (добавить!).
4. Серый – процесс отсутствует и не нужен.

Использование цветовых индикаторов позволило выявить общую картину: руководство пользователя нужно править… и существенно.

Рисунок 1

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

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

Рисунок 2

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

Таблица соответствия в ходе работы над документом:

Рисунок 3

По завершении «покрасочных» работ обозначились приоритеты:

1. убрать оранжевый цвет – все должно быть описано корректно;
2. cделать светло-зеленые поля ярко-зелеными.

На этом моменте важно вспомнить про закон Парето (принцип 20/80): мы относительно быстро исправили наиболее проблемные оранжевые области и долго работали над светло-зелеными. Ведь в них, собственно, вся суть, если мы стремимся к тому, чтобы пользователь действительно мог работать с руководством.

Отсутствие единообразия

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

Рисунок 4

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

Принципиально важный момент: доступ к репозиторию должен быть обеспечен всем командам, работающим над проектом, согласно сформированному регламенту его использования.
Используя такой подход для актуализации и метод «строительных блоков» для сборки, документ удалось за короткий срок привести в надлежащее состояние. Трудозатраты сократились более чем на 30%, по сравнению с традиционным методом формирования документа. Казалось бы, на этом месте можно было бы обозначить happy end, но мне бы хотелось продолжить. Будет интересно.

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

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

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

Рисунок 5

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

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

Рисунок 6

Выводы

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

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

Использование описанных подходов при формировании руководства пользователя позволяет:

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

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

---

P.S. В статью не вошли вопросы содержательности элементов и разделов руководства пользователя. Подробно это рассмотрено и регламентировано подразделом 3.4 документа РД 50-34.698-9 и стандартом IEEE 1063-2001.

Структура и содержание документов Руководство оператора, Руководство программиста, Руководство системного программиста регламентированы ГОСТ 19.505-79, ГОСТ 19.504-79 и ГОСТ 19.503-79 соответственно.

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

Руководство пользователя – это основной документ в составе эксплуатационной документации на автоматизированную систему (ГОСТ 34). Очевидно ли это?

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

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

Состав типового руководства пользователя

Конкретный подход к написанию определяется многими факторами:

– назначением программы и областью ее применения;

– сложностью программы;

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

Принимая во внимание все различия и особенности, сложно привести структуру любого Руководства пользователя к одному виду. Тем не менее, РД 50-34.698 предлагает нам такой список разделов:

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

– Назначение и условия применения, где описывают виды деятельности и функции, которые автоматизированы и условия, при соблюдении которых автоматизация используется;

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

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

– Аварийные ситуации, где описывают действия в нештатных ситуациях – сбоях в программе, ошибок в данных и т.д.;

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

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

Стандарты для руководства пользователя

Наличие Руководства пользователя регламентируется ГОСТ 34.201, а структура и содержание – РД 50-34.698. Однако, в зависимости от сложности, назначения и области применения ПО, различные Руководства пользователя могут отличаться друг от друга по способу, методике и стилю изложения.

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

Наименование документа	Наименование стандарта	Стоимость разработки
РП на автоматизированную систему	РД 50-34.698	от 70 тыс. р.

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

Возможно, вас также заинтересует:

– разработка руководства администратора;
– создание руководства программиста;
– разработка руководства оператора.

---

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

Приятного чтения.

Если перед вами стоит вопрос – нужно ли вашему продукту пользовательское руководство, то отвечу сразу – да, нужно. Почему? На это есть две причины:

1. Качественная документация повышает лояльность клиента и ценность продукта в целом.

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

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

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

А теперь к советам!

Общие советы по созданию руководства пользователя

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

— Где скорее всего пользователи будут прибегать к документации? (дома, на работе, в машине)

— Насколько объективно сложен для понимания продукт и как часто пользователь будет обращаться к документации?

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

(Для изложения лучше всего выбрать нейтрально-формальный стиль)

Структура руководства пользователя

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

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

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

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

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

В любом руководстве желательны разделы «Частые вопросы» и «Устранение типовых проблем». Расскажите о проблемах, с которыми часто сталкиваются клиенты и о путях их решения.

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

И последний «обязательный» раздел, которой точно должен быть в любой документации – «контактная информация». Данный раздел даст пользователю возможность связаться с разработчиком. Если руководство вдруг не закрывает потребность читателя, то он может обратиться в поддержку. Кроме того, клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.

Профессиональный совет: если вы хотите максимально облегчить ношу клиента при чтении документации создайте контекстно-зависимую справку. Что это такое?

Представьте, что вы работаете в программе для создания пользовательской документации. Открываете меню основных настроек и видите раздел «аннотирование экрана» Заходите в него, там показаны разные стили аннотации, тени, фон и так далее. Но что такое аннотация? Допустим вы не знаете — нажимаете кнопку F1 и перед вами открывается руководство именно на той странице, где рассказано об «аннотировании экрана»

Как ее сделать? Смотрите ниже.

Контент

И так, мы создали «каркас» нашей документации, но чтобы руководство стало полезным нужно наполнить её компетентной информацией.

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

1. Понятность.

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

2. Наглядность.

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

3. Видео.

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

Но как добавить в документацию видео? Смотрите ниже.

Больше советов!

Когда документация будет готова, чтобы она стала «полноценной» её нужно опубликовать. Иначе какой от неё толк, если клиент не может её прочитать. У «юзера» всегда должен быть доступ к документации, и не важно где он. Такую потребность легко закрывают три формата: HTML, PDF и CHM.

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

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

И напоследок, переведите пользовательскую документацию в формат PDF, чтобы клиенты могли скачать и распечатать руководство.

Но помните, что после публикации документации, придется иногда её обновлять.

Инструменты

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

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

Dr.Explain – программа для создания руководств пользователя для ПО, web-сервисов и баз знаний.

Благодаря «доктору» вы сможете опубликовать и обновлять документацию в востребованных форматах (CHM; HTML; PDF; DOC), не выходя из программы.

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

Импортируйте в программу заранее написанные фрагменты документации.

Вы сможете создать контекстно-зависимую документацию, настроить визуальный стиль руководства, добавить в него видео и многое другое!

Какой можно сделать вывод

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

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

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

Спасибо за внимание!

Со всеми возможностями Dr.Explain можно ознакомиться здесь:

Ценность продукта для клиента – один из важных критериев для построения эффективного и успешного бизнеса. Но даже идеальный с точки зрения пользовательских характеристик продукт может провалиться на рынке, если у него нет качественной технической и сервисной поддержки. Один из ключевых элементов такой поддержки – грамотная справочная документация. О том, как повысить ценность IT-продукта с помощью руководства пользователя, в своей авторской статье для портала Biz360.ru рассказал основатель компании «Индиго Байт» Денис Журавлёв.

Узкие места сервисной поддержки

Сразу хочу задать несколько вопросов уважаемым читателям:

• Как вы считаете, что делает ваш продукт ценным в глазах клиента?

• За что пользователь ценит и любит ваш продукт?

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

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

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

Кроме того, большая загрузка техподдержки – это ещё и прямые затраты на оплату рабочих часов специалистов, оплату входящих звонков, если вы используете номер 8-800, оплату более дорогих планов helpdesk-систем.

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

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

И тут на помощь может прийти качественная пользовательская документация.

Помоги себе сам

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

1. Загуглить вопрос в открытых источниках – на профильных сайтах, в Youtube, на форумах;

2. Читать документацию – в самом программном продукте или на сайте;

3. Обратиться в поддержку – по email или телефону.

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

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

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

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

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

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

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

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

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

1. Структурированность.

2. Многоформатность и доступность.

3. Качество контента.

Фактически, дальнейший текст можно считать чек-листом для создания хорошей документации.

Фактор №1: структурированность

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

Наша задача – максимально облегчить людям доступ к вспомогательной информации и её усвоение.

Совет №1: структурируйте руководство пользователя под задачи пользователя

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

Совет №2: нарезайте контент на разделы

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

Совет №3: делайте помощь контекстно-зависимой

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

• Пример: если вы работаете в нашем продукте для создания пользовательской документации и зайдёте в настройках проекта в раздел «Аннотирование экрана», вы увидите там целый набор опций: стили аннотации, тени, фон, эффекты и так далее. Предположу, что вы можете не знать ничего об аннотации скриншотов вообще. Однако, при нажатии клавиши F1 или кнопки «Помощь» перед вами открывается руководство пользователя именно на том разделе, где рассказано об процессе аннотирования экранов приложения в документации.

Удобно, не правда ли?

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

Фактор №2: многоформатность и доступность

Совет №4: предоставьте пользовательскую документацию в различных форматах

Выложите инструкцию на сайт, интегрируйте её в продукт в виде файла помощи и создайте печатную PDF-версию, чтобы пользователь мог скачать её, переслать коллеге или распечатать.

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

Совет №5: сделайте информацию легко находимой и доступной

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

Фактор №3: качество контента

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

Совет №6: в документации должны быть описаны все элементы интерфейса и все типовые сценарии, с которыми может столкнуться пользователь

Разделы документации должны отвечать на два типа вопросов – «Что я сейчас вижу перед собой?» и «Как мне сделать…». Документация должна описывать и сам продукт, и задачи, которые с его помощью можно решить.
Очень часто разработчики забывают либо первую часть, либо вторую.

Совет №7: не допускайте ошибок и не нарушайте единства стиля

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

Совет №8: руководство должно быть максимально простым и ёмким

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

Совет №9: обязательно визуализируйте информацию

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

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

P.S.

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

Спасибо за внимание и удачи в бизнесе!

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в «ВКонтакте» и канал на «Яндекс.Дзен».