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

Оглавление:

Anonim

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

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

Тестирование пользователя

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

Процесс интервью

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

образность

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

форматирование

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

Управление версиями и отслеживание

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