Мне все чаще приходится писать руководства пользователя как часть моей работы, и мне нужны маршруты, чтобы сделать это более интересным упражнением.
Следовательно, я на самом деле искал что-то совершенно другое, когда начал писать этот вопрос, например: «Могу ли я использовать юмор в техническом письме?» но обнаружил, что об этом уже спрашивали ( Насколько юмор эффективен в технической документации? ), и ответ был решительным нет (кроме книг X для чайников).
Тогда я подумал о том, чтобы задать вопрос вроде «Могу ли я сделать руководства пользователя более привлекательными ?». Я был поражен этим захватывающим вопросом: может ли техническое письмо быть менее отстойным ? На этот раз ответы были примерно такими: «да, но не с юмором».
И тут я увидел это (от Майкла ):
Одним из примеров, который пришел на ум, являются инструкции или «правила» для игр. Некоторые из этих книг могут быть настолько увлекательными, что многие фанаты просто читают своды правил, не играя в игры (я знаю, что играю, и я замечаю людей на дискуссионных форумах, например, по ролевым играм, которые сообщают о таком же увлечении).
И это заставило меня задуматься о написании сводов правил, которые настолько занимательны, что их можно читать почти так же, как рассказы. Итак, вот (наконец) мой вопрос: насколько сложно было бы переписать (случайное) руководство пользователя, превратив его в рассказ о безрассудстве и интригах? Другими словами, каков наилучший технический подход к переписыванию руководства пользователя в виде истории?
Да, это слишком широко, не так ли! В частности, как я могу обернуть сюжет вокруг чего-то бессюжетного? Или вставлять символы во что-то, у чего таких зверей нет? Хм.
Я полагаю, что мой вопрос сводится к следующему: «В чем разница между «техническим письмом» и «творческим письмом» и как я могу сократить этот разрыв с точки зрения преобразования одного в другое»?
(Отправляет вопрос, а затем бежит в Warhammer, чтобы посмотреть, как они там это делают.)
Как отмечено в этом ответе , вам нужно помнить, что для руководства пользователя целью вашего читателя является информация , а для свода правил это также может быть развлечением . Если развлечение мешает информации, читатель, который должен закончить свою задачу сегодня и застрял на том, как сделать следующий шаг, будет разочарован. В техническом письме есть место для развлечения (включая юмор), но оно не должно находиться на критическом пути .
Техника, которую я видел, заключается в использовании примеров «боковой панели» с общей нитью. Я говорю «боковая панель», потому что они заметно смещены в вашем макете (например, в полях), стиль, который также используется для правил игры. Также, как и в случае с правилами игры, вы устанавливаете сценарий, а затем постепенно строите его на протяжении всей книги. Основная часть текста никогда не должна зависетьна этих примерах, потому что в этой более ранней настройке есть контекст, который будет слишком трудоемким для того, кто просто пытается настроить свой frobbitz и ему нужно понять параметр thingy, но пример есть для тех, кто (когда нет времени) хочет чтобы увидеть полный сценарий. Следствием этого является то, что эти «боковые» примеры не должны быть единственными примерами в вашем руководстве пользователя; покажите основные примеры «встроенными», как обычно. «Встроенные» примеры демонстрируют конкретную функцию настолько подробно, насколько это необходимо; примеры «боковой панели» показывают , как все эти части подходят друг к другу.
Вы ссылаетесь на книги правил для ролевых игр, поэтому я собираюсь основывать свой ответ на них в качестве примеров, потому что я знаю, как увлекательно читать эти книги, не играя в соответствующие игры.
Есть несколько причин, по которым книги правил интересны для меня:
Вы можете применить это в определенных вариациях к руководствам пользователя. Просто замените «Изображение» на «Диаграмма». Убедитесь, что он соответствует текущей теме, а не просто бессмысленно отвлекает. Примеры не должны быть в повествовательной форме, которую вы видите в сводах правил, но вы можете использовать скриншоты, чтобы показать, как кто-то должен ориентироваться в программном обеспечении. Структура должна быть такой же, как и у других документов, над которыми вы работаете, чтобы вам было легче находить соответствующие части, когда вы привыкнете к ней.
Основная проблема в том, что слишком много творчества отвлекает от основного компонента: людям нужна информация. И им нужна эта информация сейчас , потому что каждая потерянная минута может стоить целое состояние.
Люди, читающие своды правил, редко испытывают такое давление при чтении книг. Во время сеанса редко, а лучше никогда не нужно что-то искать, потому что это отвлекает от главного — игры. Вот почему у вас обычно есть столько времени, сколько вам нужно, чтобы прочитать такую книгу.
Вы можете применять определенные вещи от творческого письма до технического письма. Но это должно иметь смысл и соответствовать общему стилю, которого ожидают люди. Даже если это скучно, вам платят не за то, чтобы вы развлекались созданием руководств пользователя — вам платят за создание руководств пользователя, которые помогут пользователям привыкнуть к программному обеспечению или найти важные настройки, когда они находятся под давлением. Ясность важнее в таких обстоятельствах, чем творчество.
Вы можете ввести символы, чтобы использовать эти символы в примерах. Посмотрите на Алису, Боба, Еву и Мэллори , чтобы узнать, как это сделать. Или, если вы идете в направлении X для чайников , вы можете взглянуть на такие вещи, как «Руководство по статистике манги» . Но это больше для другой целевой аудитории, чем обычное руководство пользователя.
кельчк
Робертсдей