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


Существует множество видов предоставления справочной информации пользователю – это и 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. Структура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошо : Click Logout .

Хуже : 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. Поддержка

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.Модуль А

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

3.Модуль В

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

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

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

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

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

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

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

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

Программный компонент комплекса или системы

Цели и задачи

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

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

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

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

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

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

Методика и стиль изложения

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

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

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

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

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

Типовая структура

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

  1. Общие сведения.
  2. Установка и первоначальная настройка.
  3. Основные понятия и определения.
  4. Интерфейс пользователя.
  5. Работа с программой.
  6. Пользовательская настройка.
  7. Сообщения об ошибках.

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

Особенности

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

@ Журавлев Денис

Многие IT-компании, которые занимаются разработкой и сопровождением программного обеспечения и автоматизированных комплексов, сталкиваются с задачей создания пользовательской документации для своих продуктов в соответствии с требованиями ГОСТ.

Как правило, необходимость в наличии документации по ГОСТ возникает при сотрудничестве с государственными организациями, крупными производствами и компаниями, при заказной разработке программного обеспечения по тендерам и госзаказам или при необходимости добавить программный продукт в "Единый реестр российских программ для электронных вычислительных машин и баз данных (реестр отечественного ПО)".

Существует две серии (набора) стандартов, которые регламентируют набор создаваемых документов и правила их оформления при разработке автоматизированных систем, комплексов и программного обеспечения:

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

Если говорить именно о документации для конечного пользователя системы, то из перечня описываемых в ГОСТ 34 документов нас интересует "Руководство пользователя". В ГОСТ 19 аналогичный по смыслу документ называется "Руководство оператора", но для программного обеспечения чаще используется именно первый вариант.

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

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

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

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

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

Dr.Explain упрощает создание руководства пользователя по ГОСТ

Начиная с версии 5.5.1100 программа для создания пользовательской документации Dr.Explain предлагает функцию автоматизированной поддержки ГОСТ в проектах. Эта функция призвана значительно облегчить жизнь пользователям, перед которыми стоит задача создания руководства пользователя в соответствии с требованиями государственных стандартов.

В частности программа Dr.Explain контролирует и автоматизирует поддержку следующих требований стандартов:

  • Наличие обязательных разделов документа “Руководство пользователя” [ГОСТ 34 РД 50-34.698-90]. Все разделы снабжаются пояснениями по их содержанию.
  • Оформление титульных листов, аннотации и содержания [ГОСТ 19.105-78, 19.104-78].
  • Параметры печатных страниц документа и расположение основных элементов на них [ГОСТ 19.106-78].
  • Структуру и оформление колонтитулов [ГОСТ 19.106-78].
  • Оформление текстовой части документа: стили шрифтов, абзацные отступы, межстрочные интервалы [ГОСТ 19.106-78].
  • Формирование и оформление заголовков, разделов, перечислений (списков) [ГОСТ 19.106-78].

Управление функцией поддержки ГОСТ для проекта доступно в Настройках проекта в разделе Общие .

При включенном режиме поддержки ГОСТ для проекта соответствующие пользовательские настройки для печатаемых форматов RTF\DOC и PDF автоматически перекрываются программой, что гарантирует полное соответствие параметров выходных документов требованиям стандартов.

Для выходных форматов HTML и CHM будут использоваться пользовательские настройки вне зависимости от активности режима поддержки ГОСТ. Это снимает ограничение на свободную стилизацию этих форматов и позволяет, например, оформить онлайн-справку полностью в корпоративном или тематическом стиле.

Важно:

Важно: Функция поддержки ГОСТ доступна в Dr.Explain только в русскоязычной версии интерфейса. Язык интерфейса программы выбирается в меню Настройки\Выбор языка программы (Options\Application language ).

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

Для создания нового руководства пользователя по требованиям ГОСТ 34 в программе Dr.Explain можно использовать команды меню Файл \ Создать локальный проект - Руководство пользователя по ГОСТ 34 или Файл \ Создать общий проект на tiwri.com - Руководство пользователя по ГОСТ 34

или аналогичные кнопки на стартовом экране приложения.

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

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

Настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.

Приведение существующей пользовательской документации в соответствие с требованиями ГОСТ

Также программа Dr.Explain позволяет привести существующую пользовательскую документацию в соответствии с требованиями ГОСТ.

Важно: Перед включением режима поддержки ГОСТ для уже существующих в формате Dr.Explain проектов необходимо сделать резервную копию gui-файла проекта.

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

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

Пользователь должен будет перенести содержимое этих разделов или разделы целиком методом drag-n-drop в основное дерево проекта и отредактировать их по необходимости.

Как и в первом случае настройки оформления для печатных форматов RTF/DOC и PDF будут выставлены в соответствии с требованиям ГОСТ 19.


Вам понадобится

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

Инструкция

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

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

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

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


2024 © gtavrl.ru.