Профессия "Технический писатель", или "Рыцари клавиатуры" - [33]

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

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

Манера общения с пользователем также выбирается исходя из целевой аудитории:

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

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

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

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

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

В нашем примере лучше всего использовать форму «вы».

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

1. Для домашних пользователей нужно снабдить скриншотом каждое действие, а на самих скриншотах не помешает выделить нужные элементы с помощью графического редактора (например, обвести нужную кнопку и указать на неё стрелкой). То же касается и рисунков к статьям, предназначенным для этой ЦА — они должны присутствовать в достаточном количестве, «разбавляя текст». Здесь задача картинок буквально проиллюстрировать материал, чтобы пользователь увидел своими глазами всё, о чём говорится в документе.

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

3. Для администраторов снабжать рисунками нужно только те фрагменты инструкции, где есть значительное количество настроек, которые требуется менять при вводе программы в эксплуатацию или в процессе её использования. Если процесс настройки и базовой установки сложен, его можно «проскринить» полностью, опуская только очевидные моменты. Также нужно отметить, что если какой-то процесс содержит много ветвлений, то это повод изложить его в виде блок-схемы с комментариями, а не описывать всё словами. При написании статей для этой ЦА будет полезно использовать графики и схемы, поскольку одной из задач этих статей зачастую является сравнение и анализ каких-либо данных.

4. Для разработчиков не требуется ни скриншотов, ни картинок. При этом графики в документах для них может быть достаточно много — это и структурные схемы баз данных, и схемы алгоритмов (иногда имеют просто огромный размер и распечатать их очень затруднительно, картинка может иметь размер 2×5 метров в масштабе распечатки 100%). Какие именно схемы и блок-схемы изображать — нужно согласовывать с консультантами, которых выделит вам отдел разработки. Это связано с тем, что только сами разработчики могут сказать, какие графические пояснения будут полезны их коллегам, а какие будут ненужным отчётом Капитана Очевидности.

В описанном в начале темы примере удобно использовать второму варианту.

Шестым шагом будет определение последовательности описания элементов программы и действий с ними.

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