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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О шаблонах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Еще есть такой хороший момент –  это ГОСТы! Для описания руководств пользователя существует такой замечательный ГОСТ, как ГОСТ 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

РД
50-34.698-90 Руководство пользователя (пример
оформления)

Ниже
представлен пример (образец) документа
«Руководство
пользователя«,
разработанного на основании методических
указаний РД
50-34.698-90.

Данный
документ формируется IT-специалистом,
или функциональным специалистом, или
техническим писателем в ходе разработки
рабочей документации на систему и её
части на стадии «Рабочая документация».

Для
формирования руководства пользователя
в качестве примера был взят инструмент
Oracle
Discoverer
информационно-аналитической системы
«Корпоративное хранилище данных».

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

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

1. Введение.

2. Назначение
   и условия применения.

3. Подготовка
   к работе.

4. Описание
   операций.

5. Аварийные
   ситуации.

6. Рекомендации
   по освоению.

В
разделе «Введение» указывают:

1. область
   применения;

2. краткое
   описание возможностей;

3. уровень
   подготовки пользователя;

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

1.1. Область применения

Требования
настоящего документа применяются при:

• предварительных
  комплексных испытаниях;

• опытной
  эксплуатации;

• приемочных
  испытаниях;

• промышленной
  эксплуатации.

1.2. Краткое описание возможностей

Информационно-аналитическая
система Корпоративное Хранилище Данных
(ИАС КХД) предназначена для оптимизации
технологии принятия тактических и
стратегических управленческих решений
конечными бизнес-пользователями на
основе информации о всех аспектах
финансово-хозяйственной деятельности
Компании.

ИАС
КХД предоставляет возможность работы
с регламентированной и нерегламентированной
отчетностью.

При
работе с отчетностью используется
инструмент пользователя Oracle Discoverer Plus,
который предоставляет следующие
возможности:

• формирование
  табличных и кросс-табличных отчетов;

• построение
  различных диаграмм;

• экспорт
  и импорт результатов анализа;

• печать
  результатов анализа;

• распространение
  результатов анализа.

1.3. Уровень подготовки пользователя

Пользователь
ИАС КХД должен иметь опыт работы с ОС
MS Windows (95/98/NT/2000/XP), навык работы с ПО
Internet Explorer, Oracle Discoverer, а также обладать
следующими знаниями:

• знать
  соответствующую предметную область;

• знать
  основы многомерного анализа;

• понимать
  многомерную модель соответствующей
  предметной области;

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

Квалификация
пользователя должна позволять:

• формировать
  отчеты в Oracle Discoverer Plus;

• осуществлять
  анализ данных.

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

• Информационно-аналитическая
  система «Корпоративное хранилище
  данных». ПАСПОРТ;

• Информационно-аналитическая
  система «Корпоративное хранилище
  данных». ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ.

2. Назначение и условия применения Oracle Discoverer Plus

В
разделе «Назначение и условия
применения» указывают:

1. виды
   деятельности, функции, для автоматизации
   которых предназначено данное средство
   автоматизации;

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

Oracle
Discoverer Plus в составе ИАС КХД предназначен
для автоматизации подготовки, настройки
отчетных форм по показателям деятельности,
а также для углубленного исследования
данных на основе корпоративной информации
хранилища данных.

Работа
с Oracle Discoverer Plus в составе ИАС КХД возможна
всегда, когда есть необходимость в
получении информации для анализа,
контроля, мониторинга и принятия решений
на ее основе.

Работа
с Oracle Discoverer Plus в составе ИАС КХД доступна
всем пользователям с установленными
правами доступа.

Соседние файлы в папке TZ

• #
• #
• #
• #
• #
• #
• #

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

Итак, начнем с того, что условно гайды делятся на два типа:

Определитесь с ЦА

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

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

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

Отжимайте лишнюю воду

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

Вот пример неудачного вступления:

У всех, кто работает в «Фотошопе», рано или поздно возникает потребность нарисовать круг. Именно для таких пользователей и написано это руководство.

Надо вот так:

В гайде я собрал 11 способов, как нарисовать круг в «Фотошопе». Руководство подходит для версии СС 2015 и выше.

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

Очень много вступлений, речевых оборотов и т.д.

Кратко или подробно: ищите баланс

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

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

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

Для сравнения:

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

И вот так:

Нарушите инструкцию — песец всему.

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

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

Помните о структуре

«Нет» длинным абзацам. Абзацы больше 6 строк лучше разбивать на две части — так текст читается легче.

Используйте списки. Надо что-то перечислить — делайте список, даже короткий, даже всего из трех пунктов.

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

Чтобы что-то сравнить, создавайте таблицы.

Без картинок никуда

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

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

Нет фотографий — есть YouTube. Найдите видео по теме, сделайте скриншот нужного кадра. Другой вариант — нарисуйте схему в графическом редакторе. Так, если вы пишете гайд по работе с компьютером, делайте много скриншотов. Удалить лишние скрины проще, чем обнаружить, что не хватает какого-то шага, и начинать все сначала.

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

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

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

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

Ссылки

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

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

Этот рецепт работает и с полными руководствами. Не размещайте огромное текстовое полотно на одной странице, а разбивайте его на разделы с грамотной перелинковкой. Google и Яндекс именно так и устроили гайды для своих сервисов.

Заключение

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

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