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

Эх… вот она «жизнь»!

На личном примере убедилась, что писать руководства пользователя – не такая уж и простая задача… Особенно если не знаешь программный продукт по которому его нужно составить!

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

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

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

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

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

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

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

Еще есть такой хороший момент –  это ГОСТы! Для описания руководств пользователя существует такой замечательный ГОСТ, как ГОСТ 19.505-79 (описание см. в разделе сайта).

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

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

• назначение программы (зачем она вообще нужна, на кого ориентирована и т.п.);

• сообщения оператору (описание возможных ошибок, сообщений пользователей и т.п.).

• условия выполнения программы (min и max аппаратные и программные требования);

• выполнение программы (описание функционала программы, последовательность действий оператора и т.п.);

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

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

Далее формируем следующую структуру:

1.Краткое описание

2.Модуль А

• Подмодуль А.1
• Подмодуль А.2

3.Модуль В

• Подмодуль В.1
• Подмодуль В.2

В раздел «Краткое описание» помещается краткое описание модулей А и В, а также описываются те повторяющиеся пункты меню, наименования полей и т.п., характерные для обоих модулей. Далее в описании самого модуля/подмодуля описывается краткий алгоритм работы с модулем/подмодулем (загрузка, просмотр, добавление, редактирование, удаление, формирование отчетов и т.д), после чего осуществляется более подробное описание всего функционала и всех имеющихся полей.. Иными словами все в деталях!

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

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

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

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

Но как говорится, на вкус и цвет товарища нет! Остается пожелать успешных разработок!

————

Автор: Рожкова Елена

---

См. похожие статьи по теме:

Как определить роли пользователей в системе

Разработка технического задания на систему

ГОСТ 19.505-79. Руководство оператора

---

GD Star Rating
loading…

Как написать руководство пользователя, 4.3 out of 5 based on 6 ratings

Писать руководство пользователя по шаблону. Удобно? Удобно

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

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

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

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

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

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

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

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

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

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

• Руководство пользователя web-сервиса.

• Корпоративная база знаний компании.

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

Вы бережете своё время.

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

Вы сосредотачиваете внимание на вашей программе, а не на создании файл-справки

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

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

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

 Адаптация шаблонов и образцов под ваш проект.

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

О шаблонах

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

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

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

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

Особые случаи. Здесь нужно рассказать пользователю про то, какие трудности могут возникнуть и как их решить, выделить часто задаваемые вопросы и дать на них самый доступный ответ. Подразделы: «FAQ» и «Устранение типовых проблем»

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

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

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

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

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

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

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

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

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

Данная статья предлагает правила написания и проверки технической документации, а также инструменты, для упрощения работы «технического писателя».

Советы по созданию пользовательской документации

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

Правила качественной документации, описанные в этой статье, основываются на десяти основных принципах юзабилити в дизайне, разработанных Jakob Nielsen и Rolf Molich в 1990 году. Однако — мне пришлось переработать многие из них на основе собственного опыта по оценке качества документации.

1.  Поиск и навигация

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

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

2. Ориентирование

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

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

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

3. Решение задач

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

4. Обобщение задач

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

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

5. Диагностика ошибок и устранение их последствий.

Пользователя надо научить не бояться проблем и решать их.

Говорить о своих проблемах – лучше, чем умалчивать…

В каждой программы возможны баги… Вы знаете о них, но пока нет времени исправлять? Лучше напишите и предупредите пользователя. Следуя моему опыту, лучше «признать» ошибку и показать себя, возможно, не с лучшей стороны, чем промолчать и потом терять клиентов из-за их неоправданных ожиданий. Если у пользователя будет инструкция по ликвидации проблем – он вряд ли задумается о смене программы.

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

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

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

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

7. Писательский минимализм

Следует избегать ненужной и иррелевантной информации. Каждый дополнительный блок информации в документации будет конкурировать за пользовательское внимание. Это осложнит пользователю поиск нужной информации.

8. Согласованность и стандарты.

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

Если что-то принято называть «разделом», то надо придерживаться этого термина, и не использовать альтернативы — «секция, топик, тема».

9. Интеграция с программным продуктом.

Пользователю грустно видеть программу, в которой он не может открыть «файл-помощник»!

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

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

Мини-итог

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

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

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

Используя вышеперечисленные советы, думаю вам станет проще писать документацию, но кроме вопроса КАК писать документацию еще важен вопрос ГДЕ.

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

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

Далее вы ознакомитесь с некоторыми возможностями программы для создания руководства пользователя – Dr.Explain.

1. Аннотирование

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

2. Шаблоны

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

3. Многоформатность.

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

В Dr.Explain, имея текстовый документ, вы сможете:

— экспортировать его на сайт продукта в формате HTML, тем самым создать online-справку;

— сделать контекстно-зависимую справку в формате CHM для интеграции с ПО;

— экспортировать текст в формат PDF для создания «печатной» документации;

В программе множество функций для облегчения работы по написанию документации. Вы можете ознакомиться с ними по адресу: https://www.drexplain.ru/features/

Скачать Dr.Explain бесплатно можно по адресу: https://www.drexplain.ru/download/

Подытожим

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

Успешных вам разработок!

Обсудить в форуме