Пользовательская документация — не самая интересная тема для разработчиков. Однако важно убедиться, что продукт не причинит вреда пользователям — ни физически, ни в плане повреждения их собственности. Утрата данных, выход из строя оборудования и прочие проблемы могут привести к серьезным судебным претензиям.
Эта статья не сделает вас профессиональным техническим писателем, равно как не охватит всех законных требований к продукту. Тем не менее она даст примерное представление о том, как создавать полноценную документацию, которая поможет пользователям эффективно взаимодействовать с софтом.
Статья основана на почти десяти годах моего опыта в сфере технического писательства, а также включает материал, необходимый для не технических писателей.
Определить целевую группу
Прежде чем начать писать документацию, необходимо определить, для кого она будет предназначена? Кто будет использовать продукт?
Я не стану объяснять, как проводить анализ целевой группы, так как вы можете легко найти необходимую информацию в интернете. В целом, вам нужно просто представить потребности пользователей и понять, как они будут отражены в руководстве к продукту.
Для лучшего понимания приведу несколько примеров того, как целевая группа может повлиять на содержание руководства.
- Если аудитория состоит из людей старшего поколения, то используйте хорошо читаемый разборчивый шрифт.
- Если же она представлена разработчиками, то нет необходимости объяснять базовые шаги в ОС Windows.
- Если вы пишите для дислексиков, то делайте предложения короткими и используйте простые термины.
Этот список далеко не полон и показывает только то, что для написания понятного руководства необходимо понимать его будущих читателей.
Понять, как будет использоваться продукт
Когда с целевой группой пользователей вы определились, нужно понять, как именно они будут работать с продуктом. Хорошая документация всегда должна ориентироваться на пользователя, а не просто объяснять функционал. Технические писатели создают мануалы, ориентированные на задачи, а не на функционал.
Вот два примера, которые помогут выделить отличия этих двух принципов.
- Функционально-ориентированное название главы: “Использование мастера экспорта”.
- Задачно-ориентированное название главы: “Экспортирование данных проекта”.
В данном случае мастер экспорта — это просто инструмент для выполнения задачи, а именно экспорта данных. Пользователи не знают, что для экспорта данных им нужно использовать мастера экспорта. Они будут искать, ориентируясь на задачу, а не функцию.
Разработчики же работают с функционалом, поэтому переключение на восприятие с позиции выполнения задачи может вызывать трудности.
В этом случае рекомендуется спросить себя следующее.
- Что будут делать пользователи с продуктом?
- Почему они его используют? Какова их цель?
Лучше всего будет пригласить группу пользователей и провести с ними обсуждение. Целью будет определить их задачи и, в идеале, дать им название на языке пользователей. Если же возможности собрать группу реальных пользователей у вас нет, то есть еще одно решение: пригласить коллег, которые по своей работе близко с ними связаны (например, продакт-менеджеров, проектных менеджеров, маркетологов или специалистов поддержки).
Создайте список задач в том порядке, в каком пользователи будут их реализовывать. Если вы рассматриваете разные целевые группы с различными задачами, то создайте по одному списку для каждой группы.
Начните с инструкций
Возьмите созданные вами списки задач. Грубо говоря, каждая задача будет одной инструктивной главой руководства. Если список у вас не один, то лучше создать отдельную документацию для каждой целевой группы.
Инструктивная глава дает пользователю пошаговый алгоритм действий.
Советы по написанию инструктивных глав
Вот несколько советов, которые нужно учесть при написании инструктивных глав.
- Начинайте название главы с существительного. Пример: “Экспортирование данных проекта”.
- Структурируйте инструктивные главы в виде нумерованного списка. Каждый этап задачи должен представлять один пункт списка.
- Инструктивная глава не должна превышать 11 шагов. Большее число шагов излишне ее удлинит, снизив удобство чтения. Если в итоге у вас получается длинная глава, то поделите ее на подразделы.
- Описывайте шаги в императивной форме. Пример: чтобы экспортировать данные проекта, нажмите на значок “Экспорт”.
- Не предоставляйте подробной информации о возможности продукта или о том, как он работает. Вместо этого сосредоточьтесь на выполняемых пользователем шагах. Главы с сопутствующей информацией относятся к следующему этапу руководства.
Далее приводится пример того, как должна быть отформатирована и написана инструктивная глава.
Пример инструктивной главы
Добавление сопутствующей информации
После написания инструкций спросите себя: “Что нужно знать пользователям (чего они еще не знают) для выполнения всех этих инструкций?”
Перед каждой инструктивной главой добавляйте концептуальные. Они будут объяснять особенность ПО, необходимую для выполнения инструкций. В примере “Экспортирование данных проекта” одна глава может быть посвящена мастеру экспорта и поддерживаемым форматам данных.
Инструктивная и концептуальная информация строго разделяются, упрощая для пользователя поиск нужной информации. Помните, что большинство пользователей не читают все руководство, а ищут конкретную тему, используя функцию поиска или службу поддержки.
Советы по написанию сопутствующей информации
Вот несколько советов, актуальных при написании концептуальных глав.
- Не добавляйте в заголовках описательные приставки типа “О…” или “Сведения о…”. Называйте только сам принцип или функцию, которую хотите описать. Почему? Когда вы ищете что-либо по теме в интернете, то не вводите “Сведения о затмении”. С большей вероятностью вы будете искать по запросу “Затмение”. Когда пользователи ищут принципиальную информацию, они действуют аналогично, например пишут запрос “Мастер экспорта”.
- Добавляйте только такие концептуальные главы, которые помогут пользователям выполнить инструкцию. Вероятно, вы вложили немало усилий в разработку бэкенда, необходимого для работы конкретной функции. При этом сложности, связанные с ее реализацией, не должны отражаться в документации. Единственное исключение — когда пользователю нужно знать эти детали для выполнения инструкций. Перед написанием концептуальной главы всегда спрашивайте себя: “Зачем пользователю нужно это знать?”.
- Связывайте описательные главы с соответствующими инструктивными и наоборот.
Пример главы с сопроводительной информацией
Добавление справки
Последний компонент — это справка. Справочные главы содержат информацию для поиска в виде таблиц. В этих таблицах вы описываете графический интерфейс пользователя (GUI) и API.
Этот тип информации предназначен для пользователей, которые знакомы с принципом в общем, но хотят почитать о параметре, поле записи, выпадающем меню или других элементах GUI. В первую очередь такие справочные главы ориентированы на опытных пользователей, хотя иногда их читают и новички.
Советы по написанию справочной информации
- Заголовок справочной главы должен совпадать с элементом GUI или описываемой в ней функцией, например “Диалоговое окно мастера экспорта”.
- Обязательно называйте элементы GUI так же, как они названы в самом GUI. Пользователи зачастую копируют названия элементов и вставляют их в строку поиска.
- Подумайте, какая информация поможет пользователю, ищущему конкретный элемент GUI. Возможно, он как-то связан с другими элементами GUI или ограничениями. Задокументируйте их в справочной главе.
Примеры справочных глав
Вот и все — у вас получился мануал, ориентированный на нужды пользователей. Конечно же, для создания образцовых мануалов еще многое нужно изучить. Однако с помощью этих основ вы уже сможете выстроить неплохую документацию.
Я не стал детально объяснять, почему рекомендую структурировать и писать руководства именно так. Моей целью было научить вас делать это максимально быстро.
При этом нужно иметь в виду, что даже идеально структурированная документация ничего не стоит, если само содержание читать невозможно. Так что не забывайте основы.
- Используйте проверку орфографии.
- Пишите последовательно.
- Используйте короткие и понятные предложения.
- Используйте как можно меньше слов, только их необходимое количество.
Помните, что мануалы мы читаем не ради удовольствия, а от необходимости.
Читайте также:
- 5 вредных привычек неэффективных программистов
- Как написать хороший README: краткий курс
- Успешный релиз ПО: распространенные ошибки перед запуском продукта
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Andreas D.: How To Write Manuals as a Developer
Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение
Журавлев Денис
Что такое руководство пользователя и для чего его создавать
Ежедневно создаются новые продукты, программы, сервисы и часто пользователям приходится несладко при освоении какой-нибудь сложной программы, поэтому каждому новому продукту желательно собственное руководство. Для чего?
Большинство людей не хочет разбираться с чем-то незнакомым без персонального, всегда доступного и понятного помощника. А именно им и является хорошее руководство пользователя.
Общие советы по созданию пользовательской документации
Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.
После этого важно подумать о том:
- Где пользователь будет к нему обращаться: дома, на работе, в машине?
- Как часто он будет его просматривать?
- Насколько объективно сложен для понимания продукт?
Из этого можно сделать вывод, насколько интенсивно пользователь будет работать с документацией, а значит уже можно выбрать между сжатым «справочником» или объемным «путеводителем» Также важно, чтобы руководство писал профессионал, знающий продукт. Так что по возможности делегируйте написание техническому специалисту или аналитику, у которого есть полное представление о всех тонкостях продукта.
Определившись со всеми представленными пунктами, станет понятнее, какой нужно использовать стиль изложения, какого объема написать текст. Но помните, что излишне стилистически окрашенные слова мешают пользователю добраться до сути. Так что лучшим вариантом в большинстве случаев будет нейтрально-формальный стиль. Пишите так, чтобы пользователь вас понял. Постарайтесь по возможности избегать технических терминов, но проанализируйте — не сделает ли полное отсутствие терминов ваше руководство бесполезным?
Структура руководства пользователя
После того как вы ответили на предыдущие вопросы, создайте структуру руководства. У любого хорошего «путеводителя» хорошая и логичная структура. Начните с оглавления. Информативное содержание поможет читателю легко ориентироваться в документе.
В первом разделе желательно рассказать общую информацию о программе:
- Для чего создан продукт.
- Какие задачи он решает.
- Какие основные выгоды от использования для клиента.
В следующем разделе можно указать основные элементы пользовательского интерфейса. Пользователю будет трудно разобраться в софте, если он не поймёт для чего служат различные элементы интерфейса, или он не разберётся в основных режимах работы ПО. Опишите понятным языком предназначение экранов и окон.
Создайте раздел, где расскажете о наиболее эффективных способах применения продукта для решения типовых задач. Какие цели стоят перед клиентом, и как ваша программа/сервис помогает достичь их. Укажите информацию о том, как быстро и продуктивно пользоваться программой.
Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.
Иногда технические писатели забывают о важном моменте в руководстве пользователя — контактная информация. Этот раздел поможет пользователям связаться с вами, даже если у них нет никаких вопросов и руководство полностью закрывает все их потребности. Клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Инструменты для быстрого создания руководства пользователя
Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в MS Word.
Одним из популярных инструментов для создания качественного руководства является программа Dr. Explain (https://www.drexplain.ru), в которой уже есть готовые шаблоны руководств пользователя с готовой структурой разделов и в которой удобно обновлять документацию, как бы часто эти обновления не происходили.
Видео-обзор основных возможностей программы Dr.Explain
Удобной особенностью инструмента является возможность экспортировать один и тот же документ в форматы: HTML, CHM, PDF. Простой и понятный интерфейс сам подскажет, как быстро просмотреть документ в различных форматах и настроить его под вывод в эти форматы.
Любой проект в Dr.Explain вы можете создать с нуля или импортировать уже существующую документацию, например из формата MS Word, HTML или CHM-файла, и буквально за несколько минут создать из нее онлайн-помощь, файл справки в формате CHM, или документ в формате PDF.
При создании руководства важно опираться на заранее составленный план. Дерево проекта в Dr.Explain поможет структурировать документ по вашему усмотрению. Вы можете добавлять, удалять перемещать разделы и переименовывать их. Для каждого раздела вы можете определить, в какой формат он будет экспортироваться. Также в работе удобно использовать статусы готовности разделов.
У программы свой собственный редактор, оптимизированный под работу со сложной документацией. Основные функции редактора вынесены в компактный тулбар. Это — управление стилем текста, форматирование абзацев, вставка ссылок, изображений, видео, таблиц и списков, а также вставка специальных объектов. Dr. Explain экономит время и силы своих пользователей. Разработчики документации часто сталкиваются с проблемой многократного использования одного и того же фрагмента текста и прибегают к очевидным решениям — «Ctrl+c», Ctrl+v». Dr.Explain предлагает решение по повторному использованию контента — текстовые переменные. Это решение экономит время, когда нужно много раз использовать один и тот же текст, особенно, который может периодически изменяться — например, версия документируемой системы.
Многие российские компании сталкиваются с тем, что руководство пользователя нужно писать согласно ГОСТ 19 и ГОСТ 34. Dr.Explain активирует поддержку требований ГОСТ фактически одним кликом. Программа автоматически сформирует структуру обязательных разделов и установит требуемые параметры страницы, стили абзацев, списков и заголовков.
Часто техническим писателям при документировании пользовательского интерфейса приходится снабжать изображения пояснительными выносками. Для таких случаев программа поддерживает специальные графические объекты — аннотированные экраны. Чаще всего аннотируются скриншоты программ и страниц веб-сайтов. Уникальной особенностью Dr.Explain является автоматическая аннотация изображений, получаемых при захвате экранов с окнами программ или сайтов. Программа анализирует структуру окон и добавляет пояснительные выноски ко всем значимым элементам.
Кроме того, Dr.Explain позволяет нескольким авторам одновременно работать над проектом с использованием сервиса www.tiwri.com, учетную запись на котором можно создать бесплатно за пару минут. При внесении правок одним автором сервис блокирует редактируемые разделы проекта для изменения другими авторами. По окончании редактирования изменения отправляются на сервер, и блокировка снимается. Так несколько человек могут одновременно работать над различными разделами проекта без риска помешать друг другу.
Попробовать режим многопользовательской работы в Dr.Explain можно даже с бесплатной лицензией. Вы можете создать общий проект и полноценно работать с ним в многопользовательском режиме до семи дней.
Почему компании выбирают Dr.Explain для создания руководств пользователя
Павел Свиридов, профессиональный военный, полковник, создатель астрологической системы «Вега Матрица»
«Только программа Dr.Explain обладала всеми необходимыми возможностями. А главное — она давала простор для творчества. Можно было выбрать цветовую гамму, вид и форму служебных элементов, настраиваемые шаблоны. Это позволило мне сохранить стилевое единство документации и самой программы. Ну, и конечно, полуавтоматическая обработка материала существенно облегчает и ускоряет работу по созданию хелпа.
Обучение работе в Dr.Explain было наглядным и сделано возможностями самой программы, что безусловно повлияло на мой выбор в ее пользу».
Прочитать полный кейс компании «Вега Матрица вы можете перейдя по ссылке
Наталья Обухова, бизнес-аналитик компании CRM Expert
«По классике жанра был пилотный проект на двух фаворитах (Dr.Explain и HelpNDoc) и муки выбора.
Через неделю справка была полностью готова. Конечно, если мы набивали ее «с нуля», за это время мы бы не успели. Мы просто конвертировали все бумажные инструкции во внутренний формат программ, изменили каталогизацию и организовали систему гиперссылок.
Сначала фаворитом выбора была другая система, но решающим фактором в пользу Dr.Explain стал возглас человека, выполняющего основную часть работы по переносу текста: «Вжух! И вся структура документа перенеслась в файл справки». Функция импорта в Dr.Explain отработала на ура и сэкономила кучу времени.
Также очень подкупил дизайн веб-справки, который формируется Dr.Explain, и красивый способ организации подписей к окнам нашей системы. В Dr.Explain это называется «Аннотирование экрана».
Возможность установки статуса раздела тоже оказалась очень удобной, особенно, после импорта старой версии справки легко отслеживать, какие разделы требуют обновления, в каких еще ведутся изменения, а какие уже обновлены и актуальны».
Прочитать полный кейс компании CRM Expert
Николай Вальковец, разработчик компании 2V
«Мы значительно сократили время работы техподдержки с новыми клиентами на этапе подключения. Раньше требовалось проводить онлайн презентации и видео конференции для новых клиентов, объясняя особенности программы. Сейчас же, один раз постаравшись максимально подробно всё описать, мы избавили себя и нашу техподдержку от этой работы. Нам импонирует простота программы и скорость работы. Можно быстро редактировать, добавить новые пункты в документацию, сохранить в формате HTML и выложить на сайт».
Прочитать кейс компании V2
Подытожим
Создание и написание хорошей пользовательской документации — это труд, который требует много времени и усилий. Но если успешно справиться с задачей, можно навсегда получить лояльных и довольных клиентов. Не забывайте о том, что недовольство от некачественного руководства может быть спроецировано пользователем на сам продукт и повлиять на дальнейшие решения о его выборе. Пользовательская документация должна стать персональным и незаменимым помощником. Используя Dr. Explain, вы сможете быстро создать качественное руководство пользователя, которое будет помогать пользователям разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.
Скачать Dr.Explain с неограниченной по срокам возможностью бесплатной работы можно по адресу: https://www.drexplain.ru/download/
Успешных вам разработок!
Смотрите также
- Dr.Explain — инструмент для создания мобильной версии пользовательской документации к программным продуктам
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
Что такое хороший мануал к ПО?
Время на прочтение
1 мин
Количество просмотров 3.7K
Хотелось столько всего рассказать, столько всего написать, что теряешься от созерцания горизонтов тем, мыслей, соображений.
Наверно стоило бы рассказывать о компании и о ее проектах, но это может быстро ввести читателя в грусть-тоску. Поэтому первое, с чего мы решили начать, спросить совета.
С ростом проекта WELLtime команда наших разработчиков встала перед несколькими вопросами. Развивающийся программный продукт дал почву для реорганизации линейки предложений, изменения приоритетов между его модулями и подал много интересных идей.
Но это были одни из основных ожидаемых направлений деятельности.
Не думали не гадали мы, и, прямо таки, никак не ожидали мы, что продукт станет ожидать от нас координального обновления справочного материала.
Сделать продукт не просто, но написать к нему грамотный мануал не легче.
Возникло много интересных идей и рациональных предложений, но хотелось бы спросить у хабролюдей, что для них является показателем хорошего мануала к ПО?
Пользовательская документация — не самая интересная тема для разработчиков. Однако важно убедиться, что продукт не причинит вреда пользователям — ни физически, ни в плане повреждения их собственности. Утрата данных, выход из строя оборудования и прочие проблемы могут привести к серьезным судебным претензиям.
Эта статья не сделает вас профессиональным техническим писателем, равно как не охватит всех законных требований к продукту. Тем не менее она даст примерное представление о том, как создавать полноценную документацию, которая поможет пользователям эффективно взаимодействовать с софтом.
Статья основана на почти десяти годах моего опыта в сфере технического писательства, а также включает материал, необходимый для не технических писателей.
Определить целевую группу
Прежде чем начать писать документацию, необходимо определить, для кого она будет предназначена? Кто будет использовать продукт?
Я не стану объяснять, как проводить анализ целевой группы, так как вы можете легко найти необходимую информацию в интернете. В целом, вам нужно просто представить потребности пользователей и понять, как они будут отражены в руководстве к продукту.
Для лучшего понимания приведу несколько примеров того, как целевая группа может повлиять на содержание руководства.
- Если аудитория состоит из людей старшего поколения, то используйте хорошо читаемый разборчивый шрифт.
- Если же она представлена разработчиками, то нет необходимости объяснять базовые шаги в ОС Windows.
- Если вы пишите для дислексиков, то делайте предложения короткими и используйте простые термины.
Этот список далеко не полон и показывает только то, что для написания понятного руководства необходимо понимать его будущих читателей.
Понять, как будет использоваться продукт
Когда с целевой группой пользователей вы определились, нужно понять, как именно они будут работать с продуктом. Хорошая документация всегда должна ориентироваться на пользователя, а не просто объяснять функционал. Технические писатели создают мануалы, ориентированные на задачи, а не на функционал.
Вот два примера, которые помогут выделить отличия этих двух принципов.
- Функционально-ориентированное название главы: “Использование мастера экспорта”.
- Задачно-ориентированное название главы: “Экспортирование данных проекта”.
В данном случае мастер экспорта — это просто инструмент для выполнения задачи, а именно экспорта данных. Пользователи не знают, что для экспорта данных им нужно использовать мастера экспорта. Они будут искать, ориентируясь на задачу, а не функцию.
Разработчики же работают с функционалом, поэтому переключение на восприятие с позиции выполнения задачи может вызывать трудности.
В этом случае рекомендуется спросить себя следующее.
- Что будут делать пользователи с продуктом?
- Почему они его используют? Какова их цель?
Лучше всего будет пригласить группу пользователей и провести с ними обсуждение. Целью будет определить их задачи и, в идеале, дать им название на языке пользователей. Если же возможности собрать группу реальных пользователей у вас нет, то есть еще одно решение: пригласить коллег, которые по своей работе близко с ними связаны (например, продакт-менеджеров, проектных менеджеров, маркетологов или специалистов поддержки).
Создайте список задач в том порядке, в каком пользователи будут их реализовывать. Если вы рассматриваете разные целевые группы с различными задачами, то создайте по одному списку для каждой группы.
Начните с инструкций
Возьмите созданные вами списки задач. Грубо говоря, каждая задача будет одной инструктивной главой руководства. Если список у вас не один, то лучше создать отдельную документацию для каждой целевой группы.
Инструктивная глава дает пользователю пошаговый алгоритм действий.
Советы по написанию инструктивных глав
Вот несколько советов, которые нужно учесть при написании инструктивных глав.
- Начинайте название главы с существительного. Пример: “Экспортирование данных проекта”.
- Структурируйте инструктивные главы в виде нумерованного списка. Каждый этап задачи должен представлять один пункт списка.
- Инструктивная глава не должна превышать 11 шагов. Большее число шагов излишне ее удлинит, снизив удобство чтения. Если в итоге у вас получается длинная глава, то поделите ее на подразделы.
- Описывайте шаги в императивной форме. Пример: чтобы экспортировать данные проекта, нажмите на значок “Экспорт”.
- Не предоставляйте подробной информации о возможности продукта или о том, как он работает. Вместо этого сосредоточьтесь на выполняемых пользователем шагах. Главы с сопутствующей информацией относятся к следующему этапу руководства.
Далее приводится пример того, как должна быть отформатирована и написана инструктивная глава.
Пример инструктивной главы
Добавление сопутствующей информации
После написания инструкций спросите себя: “Что нужно знать пользователям (чего они еще не знают) для выполнения всех этих инструкций?”
Перед каждой инструктивной главой добавляйте концептуальные. Они будут объяснять особенность ПО, необходимую для выполнения инструкций. В примере “Экспортирование данных проекта” одна глава может быть посвящена мастеру экспорта и поддерживаемым форматам данных.
Инструктивная и концептуальная информация строго разделяются, упрощая для пользователя поиск нужной информации. Помните, что большинство пользователей не читают все руководство, а ищут конкретную тему, используя функцию поиска или службу поддержки.
Советы по написанию сопутствующей информации
Вот несколько советов, актуальных при написании концептуальных глав.
- Не добавляйте в заголовках описательные приставки типа “О…” или “Сведения о…”. Называйте только сам принцип или функцию, которую хотите описать. Почему? Когда вы ищете что-либо по теме в интернете, то не вводите “Сведения о затмении”. С большей вероятностью вы будете искать по запросу “Затмение”. Когда пользователи ищут принципиальную информацию, они действуют аналогично, например пишут запрос “Мастер экспорта”.
- Добавляйте только такие концептуальные главы, которые помогут пользователям выполнить инструкцию. Вероятно, вы вложили немало усилий в разработку бэкенда, необходимого для работы конкретной функции. При этом сложности, связанные с ее реализацией, не должны отражаться в документации. Единственное исключение — когда пользователю нужно знать эти детали для выполнения инструкций. Перед написанием концептуальной главы всегда спрашивайте себя: “Зачем пользователю нужно это знать?”.
- Связывайте описательные главы с соответствующими инструктивными и наоборот.
Пример главы с сопроводительной информацией
Добавление справки
Последний компонент — это справка. Справочные главы содержат информацию для поиска в виде таблиц. В этих таблицах вы описываете графический интерфейс пользователя (GUI) и API.
Этот тип информации предназначен для пользователей, которые знакомы с принципом в общем, но хотят почитать о параметре, поле записи, выпадающем меню или других элементах GUI. В первую очередь такие справочные главы ориентированы на опытных пользователей, хотя иногда их читают и новички.
Советы по написанию справочной информации
- Заголовок справочной главы должен совпадать с элементом GUI или описываемой в ней функцией, например “Диалоговое окно мастера экспорта”.
- Обязательно называйте элементы GUI так же, как они названы в самом GUI. Пользователи зачастую копируют названия элементов и вставляют их в строку поиска.
- Подумайте, какая информация поможет пользователю, ищущему конкретный элемент GUI. Возможно, он как-то связан с другими элементами GUI или ограничениями. Задокументируйте их в справочной главе.
Примеры справочных глав
Вот и все — у вас получился мануал, ориентированный на нужды пользователей. Конечно же, для создания образцовых мануалов еще многое нужно изучить. Однако с помощью этих основ вы уже сможете выстроить неплохую документацию.
Я не стал детально объяснять, почему рекомендую структурировать и писать руководства именно так. Моей целью было научить вас делать это максимально быстро.
При этом нужно иметь в виду, что даже идеально структурированная документация ничего не стоит, если само содержание читать невозможно. Так что не забывайте основы.
- Используйте проверку орфографии.
- Пишите последовательно.
- Используйте короткие и понятные предложения.
- Используйте как можно меньше слов, только их необходимое количество.
Помните, что мануалы мы читаем не ради удовольствия, а от необходимости.
Разработка мануалов
«Написание мануалов, это вам не мануальная терапия!» – пробормотал специалист
и пошагал наискось от компьютера куда-то в тень в полусогнутом состоянии.
Качественные услуги по написанию мануалов готова предложить наша команда
копирайтеров имени Комаренко. Мы ходим в полусогнутом состоянии не потому что
привыкли, а потому что пишем много манов.
Имеющий опыт и страсть к техническим объяснениям позволяет нам быть
ненормальными людьми, но очень полезными и незаменимыми при написании
качественного мануала.
Но давайте не будем рассматривать наши прелести и меряться дырками в
клавиатурах с другими студиями, а рассмотрим подробнее особенности, которые мы
применяем, когда происходит написание мануалов.
Мануал, с английского
переводится, как помощь, помощь в виде инструкции к определенным программам
или сервисам. Правильное составление мануала позволяет серьёзно упростить
жизнь для технической поддержки вашего проекта, потому что большинство
вопросов можно отнести к часто задаваемым. Это первое, чему уделяется
внимание, когда происходит составление мануалов.
Написание хелпов, коим является мануал, позволит ответить на важные вопросы
для пользователей, увеличить доверие к проекту и самое главное – упростить
всем жизнь. И поверьте, даже нам, ведь мы любим написание инструкции.
Насколько важно составление мануалов?
Вспомните, что когда что-нибудь не работает, вы начинаете сразу винить
разработчика или владельца сервиса в том, что он не качественно реализовал
свой проект. Ведь, в «кривых руках» мы себя никогда не виним, нет-нет, ни в
коем случае! 
Не понимая особенностей проекта, юзеры считают его неисправным. И чаще всего,
пользователь не обращается в техническую поддержку, потому что верит, что это
баг системы. Имея хорошо написанный мануал, эта проблема решается.
Не забывайте, что так же очень важна структура и подача информации в мануале.
Об этом можете не беспокоиться, мы на этих структурах «собаку съели» и знаем
все «фишечки» и мудрости подготовки.
Специалисты дают совет, что лучше, чтобы составление хелпа выполнял
тестировщик, который непосредственно работал с этой функциональностью. В этом
случае нам стоит напомнить, что тестирование и написание хелпов, это две
разные специальности, и как в одной, так и в другой необходим свой хороший
скилл. Мы опытные технические писатели, которые быстро вникают в суть, и с
небольшой помощью мы не упустим ни одной значимой детали.
Мануал +на русском, гремучая смесь. Напишите в «обратную связь», чтобы
поговорить о деталях.
Без лишнего пафоса – мануалы, 24/7 в любой праздничный день, потому что для
нас праздничный день, это очередной мануал. Верите? Ждем!
Наши средние возможности на выполнение объема, конкретно на этот вид услуги: небольшие задания – 4 суток; большие и оптовые – неделя-месяц.
80% успеха — качественно составленный бриф. Пожалуйста, скачайте и заполните соответствующий услуге бриф. Помогите нам лучше понять вашу задачу.