Как поможет руководство пользователя

Существует множество видов предоставления справочной информации пользователю – это и FAQ (frequently asked questions, часто задаваемые вопросы) и онлайн справка и руководство пользователя (user guide) и популярные сегодня подсказки (coachmarks, см. пример ниже), обучающие видео и другие.

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

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

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

 1. Стандарты

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

• IEEE Std 1063-2001, «IEEE Standard for Software User Documentation»;
• ГОСТ 19:
  • ГОСТ 19.402-78 ЕСПД. Описание программы;
  • ГОСТ 19.502-78 ЕСПД. Общее описание. Требования к содержанию и оформлению;
  • ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению;
  • ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению;
  • ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

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

Также может оказаться полезной книга Юрия Кагарлицкого MetaGuide. Руководство для разработчиков технической документации к программному обеспечению.

2. Структура

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

Хорошее руководство пользователя должно содержать:

• Аннотацию, в которой приводится краткое изложение содержимого документа и его назначение. Также рекомендуется писать краткую аннотацию в начале каждого крупного раздела.
• Введение, содержащее информацию о том, как лучше всего использовать данное руководство
• Содержание
• Главы, описывающие, как использовать ПО
• Глоссарий и
• Предметный указатель

Также руководство пользователя может содержать:

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

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

3. Пользователи

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

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

Уважайте пользователей системы, не пишите инструкции в пренебрежительном стиле.

4. Особенности изложения

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

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

Для составления хорошего документа пригодятся знания грамматики и немного психологии.

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

Хорошо: In File menu, select Save item.
Хуже: Select Save item from File menu.

4.2 Используйте повелительное наклонение, не употребляйте вежливые обороты (please, could и т.д.) — излишняя вежливость именно здесь будет помехой.

Хорошо: Click Logout to log out current user account from the system.

Хуже: It is needed to click Logout to log out current user account from the system.

Хуже: If user wants to log out current user account from the system (s)he needs to click Logout. 

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

Хорошо:
To create project:

1. Click the Create button on toolbar.
2. On the Create Project overlay fill in all mandatory fields.
3. Click the Save button to save the project.

Хуже: To create project click the Create button on toolbar, on the Create Project overlay fill in all mandatory fields, click the Save button to save the project.

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

Хорошо: When user clicks the Start button, the program starts the process.

Хуже: When user clicks the Start button, the program will start the process.

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

Например, глагол «press» означает нажатие клавиши на клавиатуре, а «click» – нажатие кнопки или значка в окне программы при помощи мыши, а «hit» вообще является жаргонным словом.

Разумеется, орфографические ошибки недопустимы.

4.6 Не используйте синонимы для одного и того же термина. В IT литературе на английском (или любом другом) языке есть стандартный набор глаголов, обозначающих действия (click, double-click, select, type, press и т.д.) и такой же стандартный набор названий элементов управления. Определитесь с терминологией и придерживайтесь ее в рамках всего документа.

Например, не допускайте, чтобы в одной части документа выпадающий список назывался dropdown, а в другой точно такой же элемент – combobox или dropdown list. Это путает пользователя.

4.7 Разумно используйте сокращения и исключите жаргон.

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

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

5. Внешний вид

5.1 Продумайте стиль документа. Это может быть корпоративный шаблон или цветовая схема ПО или специально сделанный для документа дизайн.

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

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

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

6. Поддержка

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

Заключение

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

Помните главное: документ должен помогать пользователям.

Статью подготовила

Тарасюк Надежда, участник сообщества analyst.by,

аналитик с 6-летним опытом в сфере.

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

В действительности все совершенно иначе, чем на самом деле.
Антуан де Сент-Экзюпери

Многое в разработке руководства пользователя регламентировано и описано ГОСТами. Но при создании больших гетерогенных систем могут возникать вопросы, не до конца освещенные этими документами.

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

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

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

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

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

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 соответственно.

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

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

Руководство пользователя, это что такое

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

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

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

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

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

к оглавлению ↑

Что это за программа drexplain.ru

Программа drexplain.ru представляет собой комплексную утилиту, которая создаёт руководство пользователя по ГОСТУ и собственным шаблонам.

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

Рассмотрим список возможностей программы ДрексПлейн:

1. Есть шаблоны файлов помощи.
2. Можно редактировать шаблоны и создавать новые.
3. Возможность скачивать документ на компьютер в формате PDF, RTF и другие форматы.
4. Есть просмотр результата в разных форматах, например, ПДФ, CHM и т.д.
5. Редактирование разделов и добавление новых категорий.
6. Вставка текстов, ссылок и картинок.
7. Документ загружается на сервер программы и сохраняется.

Далее покажем вам на практике, как пользоваться программой.

к оглавлению ↑

Как скачать и установить drexplain.ru 

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

Затем кликните пару раз по установщику программы, чтобы её установить.

Мастер установки потребует выбрать язык, например, мы выбираем русский и нажимаем «OK».

На следующем шаге нажимаете «Далее» и принимаете условия соглашения.

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

Программа будет запущена по умолчанию или нажмите по её ярлыку на рабочем столе компьютера.

к оглавлению ↑

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

В окне программы drexplain.ru можно выбрать руководство пользователя или другие шаблоны.

Был выбран вариант – «Создать локальный проект – руководство пользователя». После чего открылся редактор вместе с шаблоном.

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

Когда ваша инструкция будет готова, её можно скачать на компьютер. Нажимаете по кнопке вверху, например PDF (есть и другие форматы) и далее «Начать экспорт».

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

к оглавлению ↑

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

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

1. Выполнение заказов на фрилансе. Суть работы в том, чтобы находить заказы через биржи фриланса и выполнять работу. После выполнения заказа вы зарабатываете деньги и получаете отзыв о своей работе. В статье что такое фриланс мы рассказали, как биржи выбирать и начинать заработок.
2. Продвижение своего бизнеса. Допустим у вас есть онлайн бизнес и вы не хотите по много раз рассказывать что-то аудитории. Руководство пользователя поможет удержать целевых клиентов и увеличить продажи в бизнесе.
3. Заработок посредством партнерских программ. С помощью руководств вы можете собрать аудиторию и подписчиков за подписку. Затем предлагаете им партнерские товары. Если будут продажи партнерских товаров, заработаете комиссионные с продаж.

к оглавлению ↑

Отзывы о работе в программе. Руководство пользователя

В основном пользователи довольны работой утилиты drexplain.ru. Отзывы показывают, как преимущества, так и недостатки программы:

• otzovik.com/review_3268829.html;
• protext.su/pro/dr-explain-kak-instrument-tehnicheskogo-pisate/…

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

к оглавлению ↑

Заключение

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

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

С уважением, Иван Кунпан.

Просмотров: 46

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

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

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

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 можно ознакомиться здесь:

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

В этой статье я поделюсь опытом написания инструкций на проекте внедрения 1С. Расскажу, как писать ПОНЯТНЫЕ руководства пользователей, и главное – как внедрить в компании регламент для сотрудников.

Руководство пользователя – это технический документ, который предназначен для оказания поддержки пользователям конкретной системы. В этом смысле используется и слово «мануал» (manual).

Рассмотрим основной алгоритм написания инструкций для пользователей программы 1С.

1. ОПРЕДЕЛЯЕМ ТЕМУ И ЦЕЛЕВУЮ АУДИТОРИЮ

Для чего мы пишем инструкцию? Самый важный вопрос, на который нужно ответить. Я выделила несколько основных вариантов:

• Инструкция для конкретного блока учета в программе, например, «Инструкция по блоку Продажи»,

• Инструкция для определенной должности сотрудника, например, «Инструкция для менеджера по оптовым продажам»,

• Инструкция по конкретной функции или процессу, например, «Инструкция по маркировке товаров».

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

Эти вопросы стоит обсудить с заказчиком, ведь от них зависит основной принцип разработки инструкций.

2. ПРОДУМЫВАЕМ СТРУКТУРУ СОДЕРЖАНИЯ

Для выстраивания взаимосвязи разделов важно знать и понимать набор процессов и последовательность их действий. Разобраться в этом помогут:

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

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

• Встречи с заказчиком.

Инструкция по блоку. Заголовок раздела – объект программы.

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

Инструкция для должности. Заголовок раздела – название процесса.

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

Инструкция по процессу. Заголовок раздела – название процесса, объекта программы, должности.

Пример: процесс – реализация маркированных товаров. Менеджер по продажам создает реализацию товаров, выгружает данные на терминал сбора данных, затем кладовщик на складе считывает товары на терминал сбора данных и заносит их в 1С. Тогда структура содержания может выглядеть следующим образом:

3. ПИШЕМ ИНСТРУКЦИЮ

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

Содержательность. Опишите функционал программы, расскажите в деталях обо всех этапах, нюансах и распространённых ошибках.

Подробная или не очень

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

Если пользователь ранее работал в подобных программах, например, менеджер по продажам имеет опыт работы с программой 1С: Управление торговлей 11, тогда ему будет не сложно заполнить нормативно-справочную информацию и создать документы «Заказ клиента» и «Реализация товаров и услуг». Такая инструкция будет содержать меньше конкретики.

Полнота изложения

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

Ветвления

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

Если вы ссылаетесь на рисунок или таблицу, то воспользуйтесь механизмом «Перекрестная ссылка».

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

Заголовки – это обязательно.

Позволяют «просканировать» ваш текст и остановиться сразу на нужной части. Но главное – не нарушать их иерархию.

Абзацы – это не так просто.

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

Списки – это удобно и понятно.

Маркированный список – это обычный список перечисления с маркерами, точками. В перечне элементы не упорядочены между собой. От их перестановки местами смысл не поменяется.

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

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

1) Перейдите в раздел Закупки – Документы закупки (все).

2) Нажмите кнопку «Создать – Приобретение товаров и услуг – Закупка через подотчетное лицо».

3) Укажите на вкладке «Основное» следующие данные:

•  Организация,

•  Поставщик,

•  Контрагент,

•  Договор,

•  Склад.

4) Заполните вкладку «Товары».

5) Укажите на вкладке «Доставка» способ доставки.

6) Нажмите кнопку «Провести и закрыть».

Наглядность. Японское правило: «Одна картинка стоит тысячу слов».

Скриншоты 

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

Пример: чтобы установить значение цены номенклатуры в документе «Установка цен номенклатуры», необходимо выбрать подразделение, все влияющие и зависимые виды цен, затем перейти к установке:

Делюсь удобными и бесплатными инструментами для создания скриншотов:

• Lightshot. Скачать можно тут.

• Яндекс.Скриншот, входит в состав утилиты Яндекс.Диск. Посмотреть можно тут.

Важные фрагменты текста

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

Пример: Обратите внимание!!! Обычный менеджер не сможет отредактировать график оплаты в соглашении c клиентом. Для этого предусмотрена отдельная роль. Если данный функционал не доступен, то необходимо обратиться в ИТ-отдел.

Экспертность. Автор обязан хорошо разбираться в теме.

Если так вышло, что описываемый блок программы – новая тема для аналитика, тогда за основу типового функционала рекомендую взять инструкции с официального сайта 1С: ИТС.

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

Актуальность.
Инструкцию придется периодически обновлять.

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

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

4. ПРОВЕРЯЕМ, ПРОВЕРЯЕМ И ЕЩЕ РАЗ ПРОВЕРЯЕМ

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

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

КАК ВНЕДРИТЬ ИНСТРУКЦИИ ДЛЯ СОТРУДНИКОВ

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

Правило №1. Должностные папки

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

Правило №2. Проверка знаний

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

Правило №3. Контроль выполнения

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

ПОДЫТОЖИМ. Для того, чтобы написать качественную инструкцию нам нужно:

1. Определить тему и целевую аудиторию.

2. Продумать структуру содержания.

3. Написать инструкцию, соблюдая следующие критерии:

• Содержательность,

• Структурированность,

• Наглядность,

• Экспертность,

• Актуальность.

4. Проверить инструкцию под правами пользователя.

Чтобы правильно внедрить регламент, необходимо соблюдать три правила:

1. Регламент попал к сотрудникам, и вы в этом убедились.

2. Сотрудник его прочитал, понял и прошел проверку знаний. 

3. Соблюдение регламента контролируется. 

Ценность продукта для клиента – один из важных критериев для построения эффективного и успешного бизнеса. Но даже идеальный с точки зрения пользовательских характеристик продукт может провалиться на рынке, если у него нет качественной технической и сервисной поддержки. Один из ключевых элементов такой поддержки – грамотная справочная документация. О том, как повысить ценность 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-канал, страницу в «ВКонтакте» и канал на «Яндекс.Дзен».

Руководства пользователя прошли долгий путь. Сначала это были информационные справочники с пошаговыми инструкциями, напечатанными на нескольких языках, и шрифтами небольшого размера. Эти руководства были сделаны, чтобы помочь, в тот момент, когда у нас возникли проблемы с использованием продукта. Будь то стиральная машина или телевизор. Но, на практике, редко использовались и были неэффективны.

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

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

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

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

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

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

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

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

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

Как это может помочь моему бизнесу?

Снизить расходы на поддержку

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

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

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

Получить квалифицированных клиентов

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

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

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

Всё ограничивается только вашей фантазией.

Удерживать больше пользователей на сайте

«В мире обслуживания клиентов через Интернет важно помнить, что ваш конкурент находится всего в одном щелчке мыши», — Даг Уорнер

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

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

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

Упростить и автоматизировать адаптацию и обучение сотрудников

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

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

Как это работает?

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

Чтобы интегрировать Delta17 в приложение, нужно вставить короткий фрагмент кода <head> секцию вашего сервиса. С помощью удобного редактора вы сможете создавать интерактивные руководства пользователя за несколько минут.

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

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