Inhaltsverzeichnis
Bis vor kurzem habe ich für doctima in einem großen Softwareunternehmen gearbeitet. In dieser Zeit habe ich Software-Anleitungen in einem CMS geschrieben und gepflegt, an Konzepten gefeilt und mein Augenmerk auf Verständlichkeit gelegt. Deshalb machte mich der Titel des neuen Buchs von Dietrich Juhl sofort neugierig: „Software-Anleitungen verständlich schreiben. Konzepte, Strukturen, Beispiele“. Ich fragte mich: Welche Herangehensweisen zeigt dieses Buch auf, an die ich noch gar nicht gedacht habe? Inwiefern deckt meine Praxiserfahrung sich mit der des Autors?
Top-down oder Bottom-up?
Herkömmlich gliedern Technische Redakteure Inhalte Top-down, also von Hintergrundinformationen zu Handlungsanweisungen, vom Allgemeinen zum Besonderen. Auch Juhl geht in seinem neuen Buch so vor und macht sich zunächst Gedanken über die Grobgliederung einer Software-Anleitung. Gleichzeitig hinterfragt er das Top-down-Prinzip. Seit der Generation „Google-Anwender“ nehme beständig die Geduld dafür ab, eine große Menge an Informationen linear bis zur gewünschten Information durchzuarbeiten, so der Autor (später mehr dazu).
Durch ihre Systematik bietet die Publikation dennoch mehrere Lesemöglichkeiten: Vom Anfang bis zum Ende zu lesen ist sinnvoll – man kann aber auch mittendrin einsteigen. Oder man widmet sich gleich den abgeschlossenen Kapiteln am Ende des Buchs, zu Themen wie App-Anleitungen, Anleitungen für displaygeführte Software (z. B. die Anzeige im Auto) oder Anleitungen in Form von Screencasts.
Eine Systematik der Gliederungsarten
Dietrich Juhl stellt Systematisierungsmöglichkeiten speziell von Software-Anleitungen vor. Die meisten dieser Anleitungen sind entweder vorwiegend zum Nachschlagen oder zum Lernen gedacht. Der Autor weiß jedoch aus der Praxis, dass am häufigsten Kombinationen aus Lern-Gliederung und Nachschlage-Gliederung im Einsatz sind. Üblicherweise wird dabei wie folgt systematisiert:
- Gliederungsteile, die vorwiegend zum Lernen genutzt werden:
- Leistungsbeschreibung
- Fachliche Grundlagen
- Benutzeroberfläche
- Einführung in die Bedienung
- Gliederungsteile, die vorwiegend zum Nachschlagen genutzt werden:
- Tätigkeiten
- Funktionen
Die Gliederung solle sich idealerweise für alle möglichen Use Cases eigenen, sagt Juhl. Bei mehreren Zielgruppen mit unterschiedlichem Wissensstand empfiehlt er eine stufenweise Vermittlung. Um Klarheit über eine geeignete Struktur zu gewinnen, könne eine „Wer macht was?“-Matrix helfen, aus der der Technische Redakteur auf den Aufbau der benötigten Anleitungen schließe. Ein Beispiel: Während ein Administrator sowohl die Software installieren als auch administrieren müsse, habe der Software-Administrator zwar auch eine administrative Aufgabe, sei gleichzeitig aber auch noch für die Grundkonfiguration zuständig. Die verschiedenen Anwendergruppen bräuchten also auf ihre jeweilige Rolle abgestimmte Anleitungsteile.
Neben Möglichkeiten zur Grobgliederung einer ganzen Anleitung zeigt Juhl die Vorteile und Nachteile auf, die Formate wie Kurzanleitungen mit sich bringen. Und vermittelt, was man beherzigen sollte, wenn man eine Anleitung zum Beispiel durch ein Video-Tutorial ergänzen oder gar ersetzen möchte.
Handlungsanweisungen: Nicht die herkömmliche Lösung entscheidet, sondern der Einzelfall
Für eine Software-Anleitung wählt der Redakteur die Strukturelemente, die zu Software, Kontext und Zielgruppe passen
Innerhalb einer gewählten Grobstruktur muss weiter untergegliedert werden. Um beispielsweise Handlungen zu vermitteln, sieht Juhl bis zu zwölf Strukturelemente vor. Je nach zu beschreibender Software und Handlung und abhängig von der Zielgruppe könnten Strukturelemente eingesetzt oder weggelassen werden. Dazu bietet der Autor für konkrete Szenarien Vorschläge an, die beim Zusammenstellen helfen sollen. Wenn man für jeden Kontext dieselben Elemente nutze, sei das Ergebnis selten bedarfsgerecht, so Dietrich Juhl. Das ist eine Haltung, mit der ich als Redakteurin auch nur gute Erfahrungen gemacht habe.
Das Buch möchte zum verständlichen Schreiben anregen. Es liest sich selbst so, dass es als gutes Beispiel seines Ansatzes gelten kann. Juhl lädt dazu ein, Redakteursgewohnheiten zu hinterfragen und in bestimmten Fällen Handlungsschritte einer Anleitung auch mal wegzulassen oder zumindest zu kürzen. So könne es ausreichend sein, lediglich ein Handlungsziel zu nennen und dazu einen Screenshot zu zeigen. Bei der Vermittlung von Software derart zurückzuschrauben sei möglich, weil die Anwender von heute sich an Elemente von Bedienoberflächen gewöhnt hätten und diese Oberflächen besser aufbereitet seien als früher. Auch Regeln oder Strategien an die Stelle einer Schritt-für-Schritt-Anleitung zu setzen, könne dem Anwender Handeln ermöglichen. Darüber müsse der Redakteur im Einzelfall entscheiden.
Während ich im Kapitel „Handlungen“ blättere, entdecke ich Elemente, die ich von Vorgängerpublikationen des Autors schon kenne: Die Empfehlung zu didaktischer Vorarbeit mit Fokus auf die Leserschaft, einen Wechsel aus Wiederholungen von Basics der (Software-)Dokumentation und aus Anregungen zum redaktionellen Tapetenwechsel, alles mit zahlreichen Bildern versehen sowie mit praktischen, einfachen Beispielen.
Nicht bloß graue Theorie
Viele Thesen gründen auf Juhls beruflichen Erfahrungen als Technischer Redakteur und als Leiter von Workshops. Die Abhandlung ist daher nicht voll von Quellenangaben, Fußnoten etc. und bezüglich Lesefluss angenehm zu verdauen. Zwei Quellen aus der Literatur gibt Juhl im Anhang an, „Every Page is Page One“ von Mark Baker und „Software-Dokumentation“ von Getrud Grünwied. Insgesamt kommt der Stand der Forschung seltener zu Wort als in anderen Fachbüchern. Doch stark wissenschaftlich gehaltene Fachbücher zum Thema existieren bereits mehrfach. Dietrich Juhls Werk macht mit seinem anwendungsnahen Stil die oft graue Theorie greifbar, schenkt damit wertvolle Einblicke und macht dazu noch Laune (das Buch enthält viele Comics…).
Geänderte Anwenderkompetenzen, geänderte Erwartungen
Geänderte Lese- und Suchgewohnheiten der Google-Anwender bewirken, dass heutige Leser von Software-Anleitungen immer weniger Top-down vorgehen und immer mehr Bottom-up („Anwender lernen auch verkehrt herum“). Meine Praxiserfahrung deckt sich damit. Aus Sicht von Dietrich Juhl ist die Bereitstellung und die Bottom-up-Konstruktion von Inhalten allerdings noch nicht zu Ende gedacht.
Juhl empfiehlt, Mark Bakers Ideen aus „Every Page is Page One“ in der Praxis stärker miteinzubeziehen. Die damit meistens verbundene Haltung von Topics mit Metadaten mache allerdings immer ein Content-Management-System erforderlich. Eine bessere Suche und die Auslieferung von bedarfsgerecht zusammengestellten Inhalten erfordere darüber hinaus noch die dynamische Anbindung des Anwenders an das CMS. Erst mit solchen Systemen, mit gut gemachten (!) Inhalten und mit den richtigen Metadaten seien Hilfesysteme denkbar, die beim Verstehen von Software ganz gezielt Unterstützung anböten. Mithilfe von Technik (CMS, Content Delivery) könne man im Vergleich zu herkömmlichen Gliederungen bessere, topicorientierte Systeme verwirklichen.
Für wen eignet sich das Buch?
Die Veröffentlichung richtet sich an Technische Redakteur:innen mit Erfahrung in der Softwaredokumentation. Die Perspektive wegzulenken von dem, was oder wie man etwas üblicherweise an seine Anwender heranträgt, sorgt für frischen Wind. Und diesen Effekt halte ich für sehr wichtig. Trotzdem eignet sich das Buch auch für Neulinge oder Studenten. Denn die praxisnahen Überlegungen können dabei helfen, einen Zugang zum Thema Verständlichkeit in der Technischen Kommunikation zu finden.
Literatur:
Juhl, Dietrich: Software-Anleitungen verständlich schreiben. Konzepte, Strukturen, Beispiele.
BoD – Books on Demand, Norderstedt 2018.
268 Seiten, Hardcover.
Buch: 89,90 EUR | ISBN-13: 978-3-7528-1552-8
Hinweis: Das hier besprochene Buch wurde uns vom Autor kostenfrei als Rezensionsexemplar zur Verfügung gestellt. Der Autor hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.
Sie erstellen Software-Dokumentation?
Sie erstellen Software-Dokumentation und möchten wissen, welches Redaktionskonzept oder welche Anbindung an ein CMS sich für Sie eignet? Dann melden Sie sich bei Benjamin Rauschenberger benjamin.rauschenberger@doctima.de. Er stellt Ihnen gerne unsere Lösungen vor – entweder bei Ihnen vor Ort oder per Web-Meeting.
