Часто заповнені жаргоном, акронімами та напрямками, які вимагають від Ph.D зрозуміти, посібники користувача програмного забезпечення іноді пишуться з точки зору розробника, а не користувача. Як результат, керівництво може робити припущення щодо рівня кваліфікації читача, який часто є неправильним. Перший крок у написанні хорошого керівництва користувача полягає в тому, щоб отримати реальний процес написання якнайдалі від інженерів.
Розробник програмного забезпечення знає більше, ніж хто завгодно, що робить програмне забезпечення робочим, але це не означає, що розробник повинен написати керівництво. Навпаки, це виразний недолік. Більш важливим, ніж глибоке розуміння внутрішньої роботи програмного забезпечення, є розуміння того, хто буде кінцевим користувачем, який його рівень освіти і як цей кінцевий користувач буде використовувати програмне забезпечення. У більшості випадків кінцевим користувачам не потрібно знати точніші моменти програмування та зворотні роботи програмного забезпечення - вони просто повинні знати, як його використовувати, щоб полегшити роботу.
Тестування користувачів
Посібник користувача повинен бути в значній мірі орієнтованим на завдання, а не дуже описовим. Оскільки посібник написано для того, щоб допомогти користувачам зрозуміти, як виконувати конкретні завдання, письменник повинен мати розуміння цих завдань, і, як наслідок, перехід через кожний дискретний крок кожної функції є абсолютно необхідним. Не обов'язково письменник обов'язково знати, як програма була створена з точки зору дизайну або розвитку, але важливо мати сильне знання всіх її можливостей. Під час виконання кожного завдання потрібно час, щоб записати кожен крок, включаючи кліки, випадаючі меню та інші дії.
Процес інтерв'ю
Хоча розробник не повинен писати посібник, вона все одно буде цінним ресурсом для письменника, і перед початком написання плануйте зустріч письменника, розробника і інженерів, а також потенційних кінцевих користувачів, щоб допомогти інформувати творчість письменника з самого початку. Необхідно записати інтерв'ю з фахівцями та інженерами за тематикою, з розшифровкою для подальшого використання.
Зображення
Посібник користувача не повинен бути занадто важким для тексту. Скоріше, включати ліберальне використання графіки і екрану кліпів. Опис дії набагато чіткіше з текстовими напрямками, що супроводжується екраном, який чітко ілюструє цей напрямок. Включіть як до, так і після переглядів, щоб показати, як виглядає екран, перш ніж робити кожну дію, і що відбувається після того, як дія була вжита. Простий утиліти для захоплення екрану, такі як Snipping Tool, що входить до складу Microsoft Windows, добре підходить для зйомки цих зображень. Обов'язково вкажіть кожне зображення і вкажіть його заголовок. Розташуйте його безпосередньо під абзацом, який вперше вводить поняття, зображене на зображенні.
Форматування
Чітке спілкування в технічному документі вимагає планування та ретельного дотримання стандартів у всьому посібнику. Стандарти як у презентації, так і в мові та номенклатурі допомагають уникнути плутанини. Шаблони доступні і можуть бути гарною відправною точкою для однорідності, хоча вони, безумовно, можуть бути пристосовані до кожної ситуації. Використання одного дюймового поля з одним стовпцем найкраще відповідає потребі додавати графіку; установка з двома стовпцями може здатися надто переповненою і може призвести до заплутаного розміщення зображень.
Версії та відстеження
Більш ніж будь-який інший тип документа, посібник користувача програмного забезпечення, ймовірно, пройде через кілька ітерацій, перш ніж він буде завершений, і він, ймовірно, буде проходити процес перевірки кількома зацікавленими сторонами. Використання функції відстеження змін у Microsoft Word - це простий спосіб відстежувати коментарі та зміни кожної особи. Створення декількох версій після кожного циклу огляду, кожен з різними іменами файлів, також допомагає процесу і гарантує, що всі зацікавлені сторони задоволені кінцевим результатом.
