Ich muss im Rahmen meiner Arbeit zunehmend Benutzerhandbücher schreiben, und ich brauche Routen, um dies zu einer interessanteren Übung zu machen.
Daher suchte ich eigentlich nach etwas ganz anderem, als ich anfing, diese Frage zu schreiben, wie z. B. „Kann ich Humor in der technischen Redaktion verwenden?“. aber festgestellt, dass dies bereits gefragt wurde ( Wie viel Humor wirkt in der Technischen Dokumentation? ) mit einem klaren Nein (abgesehen von X wie Dummies-Büchern).
Also dachte ich darüber nach, eine Frage zu stellen wie „Kann ich Benutzerhandbücher ansprechender gestalten ?“. Diese fesselnde Frage hat mich umgehauen: Kann technisches Schreiben weniger scheiße sein ? Die Antworten fielen diesmal in die Richtung „ja, aber nicht mit Humor“.
Und dann sah ich das (von Michael ):
Ein Beispiel, das mir in den Sinn kam, sind die Anweisungen oder "Regeln" für Spiele. Einige dieser Bücher können so fesselnd sein, dass viele Fans nur die Regelbücher lesen, ohne die Spiele tatsächlich zu spielen (ich weiß, dass ich das getan habe, und ich bemerke, dass Leute in Diskussionsforen für zB Rollenspiele von der gleichen Faszination berichten).
Und das brachte mich dazu, darüber nachzudenken, ob man Regelbücher schreiben sollte, die so unterhaltsam sind, dass man sie ähnlich wie Geschichten lesen kann. Hier also (endlich) meine Frage: Wie herausfordernd wäre es, ein (zufälliges) Benutzerhandbuch als eine Geschichte von Eskapaden und Intrigen umzuschreiben? Mit anderen Worten – was wäre der beste technische Ansatz, um ein Benutzerhandbuch als Story umzuschreiben?
Ja, es ist zu breit, innit! Genauer gesagt - wie kann ich eine Handlung um etwas wickeln, das handlungslos ist? Oder Zeichen in etwas einfügen, das keine solchen Bestien hat? Hmm.
Ich nehme an, meine Frage läuft darauf hinaus: „Was ist der Unterschied zwischen „technischem Schreiben“ und „kreativem Schreiben“ und wie kann ich diese Lücke schließen, um das eine in das andere umzuwandeln“?
(Stellt eine Frage und geht dann zu Warhammer, um zu sehen, wie sie es dort machen.)
Wie in dieser Antwort erwähnt , müssen Sie bedenken, dass das Ziel Ihres Lesers bei einem Benutzerhandbuch Information ist , während es bei einem Regelbuch auch Unterhaltung sein kann . Wenn die Unterhaltung der Information im Wege steht, wird der Leser, der seine Aufgabe heute erledigen muss und nicht weiß, wie er den nächsten Schritt machen soll, frustriert sein. Unterhaltung (auch Humor) ist in der Technischen Redaktion möglich, darf aber nicht auf dem kritischen Pfad liegen .
Eine Technik, die ich gesehen habe, ist die Verwendung von "Sidebar"-Beispielen mit einem gemeinsamen Faden. Ich sage "Seitenleiste", weil sie in Ihrem Layout sichtbar versetzt sind (wie in Boxen), ein Stil, der auch für Spielregeln verwendet wird. Auch wie bei den Spielregeln legen Sie das Szenario fest und bauen es dann im Laufe des Buches schrittweise auf. Der Hauptteil des Textes darf niemals davon abhängenauf diese Beispiele, weil es in diesem früheren Setup einen Kontext gibt, der zu viel Arbeit für jemanden wäre, der nur versucht, seinen frobbitz zu konfigurieren und den Ding-Parameter verstehen muss, aber das Beispiel ist für jemanden da, der es will (wenn er nicht unter Zeitdruck steht). um ein komplettes Szenario zu sehen. Eine logische Folge davon ist, dass diese "Sidebar"-Beispiele nicht die einzigen Beispiele in Ihrem Benutzerhandbuch sein sollten; Zeigen Sie wichtige Beispiele "inline", wie Sie es normalerweise tun würden. Die "Inline"-Beispiele demonstrieren die jeweilige Funktion so detailliert wie nötig; Die "Seitenleisten"-Beispiele zeigen eine Möglichkeit, wie all diese Teile zusammenpassen.
Sie beziehen sich auf Regelbücher für RPGs, daher werde ich meine Antwort auf diese Beispiele stützen, da ich die Faszination kenne, diese Bücher zu lesen, ohne die entsprechenden Spiele zu spielen.
Es gibt ein paar Gründe, die Regelbücher für mich interessant machen:
Sie könnten dies in bestimmten Variationen auf Benutzerhandbücher anwenden. Ersetzen Sie einfach "Artwork" durch "Diagram". Achten Sie darauf, dass es zum aktuellen Thema passt und nicht nur sinnlos ablenkt. Die Beispiele sollten nicht in der narrativen Form vorliegen, die Sie in Regelbüchern sehen, aber Sie können Screenshots verwenden, um zu zeigen, wie jemand mit Software navigieren sollte. Die Struktur sollte dieselbe sein wie in anderen Dokumenten, an denen Sie arbeiten, damit Sie die relevanten Teile leichter finden können, sobald Sie sich daran gewöhnt haben.
Das Hauptproblem ist, dass zu viel Kreativität von der Kernkomponente ablenkt: Menschen wollen Informationen. Und sie wollen diese Informationen jetzt , denn jede verlorene Minute könnte ein kleines Vermögen kosten.
Menschen, die Regelbücher lesen, stehen selten unter einem solchen Druck, wenn sie die Bücher lesen. Während einer Session sollte man selten oder besser nie etwas nachschlagen, da es von der Hauptsache, dem Spiel, ablenkt. Deshalb hat man normalerweise alle Zeit, die man braucht, um ein solches Buch zu lesen.
Sie können bestimmte Dinge vom kreativen Schreiben bis zum technischen Schreiben anwenden. Aber es muss Sinn machen und zum allgemeinen Stil passen, den die Leute erwarten. Auch wenn es langweilig ist, Sie werden nicht dafür bezahlt, Spaß am Erstellen von Benutzerhandbüchern zu haben – Sie werden dafür bezahlt, Benutzerhandbücher zu erstellen, die Benutzern helfen, sich an Software zu gewöhnen oder wichtige Einstellungen zu finden, wenn sie unter Druck stehen. Klarheit ist in solchen Situationen wichtiger als Kreativität.
Sie könnten Zeichen einführen, um diese Zeichen in Beispielen zu verwenden. Sehen Sie sich Alice, Bob, Eve und Mallory an, um zu sehen, wie das geht. Oder wenn Sie in die Richtung von X for Dummies gehen, sollten Sie sich Dinge wie The Manga Guide to Statistics ansehen . Aber diese sind eher für eine andere Zielgruppe als ein durchschnittliches Benutzerhandbuch.
celtschk
Robertcday