Eine interne oder externe Technische Redaktion bekommt den Auftrag für eine neue Technische Dokumentation. Über den Ausgangspunkt ist man jedoch nicht orientiert. Manchmal fehlen Informationen, und die Redaktion fängt auf der grünen Wiese an. Doch ab und zu sind bereits Informationen oder auch Schaubilder vorhanden. Daraus soll die Redakteurin oder der Redakteur möglichst ohne großen Aufwand ein benutzerfreundliches Informationsprodukt erstellen. In diesem Artikel möchte ich Ihnen zeigen, was wir als Dienstleister aus unseren letzten Projekten als „lessons learned“ mitgenommen haben, um in Zukunft schneller und zielgerichteter den Input unserer Kunden in eine gute Technische Doku zu wandeln. Bestimmt helfen Ihnen unsere Erfahrungen auch dann weiter, wenn Sie in einer Inhouse-Redaktion arbeiten.
Gleich am Anfang
Oft ist bei einem neuen Projekt nicht klar, wo die Fallstricke liegen. Deswegen möchte ich zunächst ein bisschen aus dem Nähkästchen plaudern, was wir als Dienstleister bei neuen Projekten manchmal erleben, was wir daraus lernen und versuchen, künftig besser zu machen. Denn einige Projekte sehen überschaubar und schnell durchführbar aus und ziehen sich dann wie Kaugummi. Oder ein Projekt, das ursprünglich sehr komplex wirkte, flutscht von Anfang bis Ende durch. Auch daraus kann man lernen.
Gerade wenn genau geschaut wird, wie viel Zeit man in einzelne Projekte steckt, wird schnell klar: Ein systematisches Vorgehen bringt Vorteile. Doch wichtig ist auch, dass man flexibel genug bleibt, um eben dieses Vorgehen fallspezifisch anzupassen.
Besser mit Checkliste
Oftmals wird einem in der Redaktion zugerufen, dass es ein neues Projekt gibt. Für diesen Fall haben wir uns eine Checkliste erarbeitet, die wichtige Infos für den Projektstart enthält. Beispielhafte Punkte aus der Checkliste finden Sie in Abbildung 01.
Abb. 01 Checkliste für den Projektstart. Quelle Anna Lehmann
Die Checkliste füllen wir vor dem Kickoff-Meeting aus und senden sie an unsere Ansprechpartner. So wissen diese vorab, welche Informationen wir dringend benötigen, welche wir mit der Info zum neuen Projekt erhalten haben oder welche wir aus anderen Projekten übernehmen können. Damit lässt sich zum einen das Meeting zielführend lenken. Zum anderen sind wir damit meist in einer bis zwei Stunden Besprechungsdauer mit den wichtigsten Informationen versorgt. Falls nötig, kommt die Produktbesichtigung vor Ort hinzu, bei der man typische Fragen „abklappern“ kann:
- Wo sind kritische Bereiche für den Nutzer?
- Wie bedient er das Produkt genau?
- Gibt es Unterschiede in der Bedienung, je nach Nutzergruppe? Braucht es dazu spezielle Informationen?
- Gibt es sogar Gefahrenbereiche bei Hardware-Produkten – oder zu erwartende Datenverluste bei Software?
- Müssen regelmäßige Updates oder Wartungsarbeiten durchgeführt werden?
Übrigens ist auch für Doku-Projekte der klassische „PDCA-Prozess“ hilfreich. Wir haben ihn nur um einen Punkt erweitert. Bei uns lautet er Plan, Do, Check, Act und zusätzlich Monitor (Abb. 02).
Abb. 02 Doku-Projekte werden mit Hilfe von PDCA bearbeitet. Quelle Anna Lehmann
Zudem kann jedes Topic oder Kapitel nach diesem Verfahren erstellt werden. Also ein eigener kleiner Teilprozess, der für die Informationen immer vergleichbar abläuft. Unsere Redaktion hat festgestellt, dass sie den Prozess schon so verinnerlicht hat, dass er von jedem abgenickt wird – ohne jegliche Korrekturschleife. Wer den Schritt „Check“ mit der Entwicklung/Konstruktion schon mal durchgeführt hat, wird wissen, wie besonders das ist (zumindest, wenn die Ansprechpartner Zeit für die Prüfung hatten).
Zusammengefasst sollten die Informationen also für ein neues Doku-Projekt erst geplant werden (Plan), dann erstellt die Technische Redaktion den Entwurf (Do), im Anschluss wird das Erstellte inhaltlich und bei Text auch sprachlich geprüft (Check). Falls Unstimmigkeiten auftreten, werden diese angepasst (Act) – und zum Schluss sollte die Anleitung im Rahmen der Marktbeobachtung oder von Produktänderungen geprüft werden, ob alle Anforderungen ausreichend erfüllt sind (Monitor). Falls Anpassungen an der Anleitung durchgeführt werden, fängt der Prozess von vorne an.
Relevantes zusammentragen
Gehen wir davon aus, dass die Ansprechpartner klar sind, und um das Beispiel abzukürzen, gehen wir von einem bekannten Kunden aus, der das Layout bereits freigegeben hat. Auch die Gliederung kann bleiben, weil das Produktspektrum sich nicht ändert. Dann bekommen wir für ein neues Projekt immer noch einige Daten.
Die Formen, in denen wir Informationen zum Produkt erhalten, sind vielfältig. Die häufigsten Informationsquellen sind:
- technische Daten
- Zeichnungen (aus CAD, per Hand oder als Flussdiagramme)
- bestehende Dokumente
- manchmal auch Lasten- oder Pflichtenhefte
- teilweise eine Risikobeurteilung oder FMEA (oder wie auch immer der Kunde das nennt)
- rechtliche oder vertragliche Anforderungen
- vorhandene Anleitungen mit handschriftlichen Kommentaren oder Zeichnungen
- bereits durch die Entwicklungs- und Konstruktionsabteilung erstellte Teil-Anleitungen.
Wenn das nicht reicht, führen wir mit den betreffenden Ansprechpartnern Interviews oder erhalten eine Online-Schulung zum Produkt. Damit haben wir eine Menge an Informationen, die wir sichten können und die uns einen Eindruck in unterschiedlichem Detaillierungsgrad über das Produkt geben.
Analysieren und Vorsortieren: Da kommen wir zu einem Wort, dass in der Technischen Redaktion häufig die Runde macht – die Zielgruppe. Wer soll was mit der Doku tun? Was braucht derjenige dazu? Unter diesem Aspekt müssen die erhaltenen Informationen betrachtet werden. Als Redakteur oder Redakteurin sitzt man dazu eine ganze Weile, um die einzelnen Informationen zunächst zu prüfen und in zwei große Stapel zu sortieren: Erstens brauchbare und für den Anwender nützliche Informationen und zweitens Informationen, die zu tief ins Detail gehen, und damit nicht zielgruppengerecht sind.
Sortieren und Gliedern: Sobald der erste Stapel feststeht, geht es darum, die Informationen geeignet zu sortieren und zu gliedern. Das sollte einerseits anhand der Zielgruppe geschehen. Andererseits hilft es, sich an übliche Standards oder Normen zu halten, wie beispielsweise die DIN EN IEC/IEEE 82079-1: Gliederung nach dem Lebenszyklus.
Wenn es sich um Software handelt, ist der Lebenszyklus möglicherweise nur für die grobe Gliederung hilfreich. Denn die meisten Informationen für den Anwender finden im Bereich „Bedienung“ statt, sind möglicherweise im Vorfeld vom Administrator schon über Rechte- und Rollenvergabe ausgewählt und brauchen tiefere Details. Hier bietet es sich an, logische Vorgänge einzuhalten, beispielsweise in einzelne Screenshots, Menüpunkte oder Untermenüpunkte zu gliedern.
Jetzt hat die Technische Redaktion schon einen großen Teil der Arbeit geschafft: aus einem Wald an Informationen die relevanten herausgesucht und diese zielgruppenkonform den einzelnen Abschnitten zugeordnet. Die Schritte sind alle als Vorarbeit nötig, um die vorhandenen Daten in benutzerfreundliche Abschnitte zu verwandeln. Einige Stapel, die wir fürs Sortieren der Informationen nutzen und natürlich nach Zielgruppe und Thema sortiert, zeigt Abbildung 03. Je nach Produkt sollten diese Stapel (ob tatsächlich aus Papier auf dem Tisch oder digital oder nur gedanklich ist Geschmacksache) angepasst werden.
Nebenbei bemerkt, ist das eine Aufgabe, die ich bisher von einer künstlichen Intelligenz noch nicht gut erledigt gesehen habe. Denn das richtige Augenmaß beim Zusammenfassen von Informationen oder Ausweiten der Detailtiefe, weil es für die Zielgruppe wichtig ist, funktioniert bisher bei erfahrenen Menschen besonders gut. Vorausgesetzt, man kann sich ausreichend in eben diese Zielgruppe hineinversetzen und von deren Kenntnis- und Erfahrungsstand ausgehen.
Abb. 03 Übersicht über die einzelnen Informationen. Quelle Anna Lehmann
Das richtige Format wählen
Leider ist mit der Sortierung und Gliederung noch nicht der schwierigste Teil erledigt. Denn wenn ich weiß, was ich meiner Zielgruppe präsentieren möchte, muss ich dann noch entscheiden: In welcher Form geschieht das am besten? Hierfür möchte ich ein paar grobe Anhaltspunkte anbieten, die nicht nur klassische Elemente einer Anleitung enthalten, sondern auch die Gliederung beeinflussen können.
Quickstart: Als Schnelleinstieg mit üblichen Situationen ist der Quickstart besonders gut geeignet, wenn es sich um Software mit üblichen Funktionen handelt oder einige Tätigkeiten mit einem Hardware-Produkt routinemäßig durchgeführt werden. Die Frage der Fragen, die sich hierbei stellt: Wie viel sicherheitsrelevante Information muss rein, und wird der Quickstart separat oder als eigenes Kapitel einer Gesamtanleitung betrachtet? Unsere Erfahrung hat gezeigt, dass der Quickstart tatsächlich das Kapitel ist, das bei einer Gesamtanleitung weit vorne steht oder dem Nutzer als Erstes ins Auge springt. Trotzdem erstellen wir es erst am Ende des Projekts. Denn dann sind alle Schritte klar und deutlich, schon irgendwo beschrieben, und man kann sie geeignet kurz und knapp zusammenfassen.
Handlungsanweisungen: Alle Informationen, die aktives Handeln durch den Anwender erfordern, sollten als Handlungsanweisungen ausgeführt werden. Dabei muss es aber nicht immer nur durchgängig nummeriert zugehen. Es kann auch über Konzepte erklärt werden, was zu tun ist und wo weitere Schritte zu finden sind. Das kommt immer auf Produkt und … richtig! … die Zielgruppe an. Manchmal lassen sich Handlungsanweisungen auch im nummerierten Stil deutlich verschlanken, wenn man einige Dinge als Voraussetzungen aufführt, die man sonst umständlich in vielen Schritten beschreiben müsste. Oder wenn man die Handlungen in kompakte Segmente aufsplittet. Teilweise lassen sich auch grafische Abläufe schneller und kompakter erklären, entweder wie ein Flussdiagramm oder ein Organigramm (vgl. abb. 03), welche Funktionen wo zu finden sind. Oder die Handlung wird grafisch dargestellt – das behandeln wir später unter „Grafik“ genauer.
Piktogramme für die eindeutige Zuordnung: Wenn es etwa Bedienelemente oder Knöpfe gibt, auf die der Benutzer drücken muss, kann es eine gute Hilfe sein, diese als einzelne Piktogramme oder Tasten mit aufzunehmen. Damit der Text nicht unterbrochen wird, ist das auch in einer Randnotiz gut untergebracht. Und selbstverständlich können Piktogramme in Form von bekannten Warnhinweisen eine Gefahr oder ein Gebot verdeutlichen.
Wir versuchen, bei Piktogrammen hauptsächlich mit den aus Normen stammenden Symbolen zu arbeiten oder die Bedienelemente zu nutzen. Allerdings kann es sehr zeitaufwändig werden, wenn es eine Vielzahl an Bedienelementen gibt, die zu jedem Schritt integriert werden. Daher ist das Kosten-Nutzen-Verhältnis ein Punkt, den es bei dieser Entscheidung zu berücksichtigen gilt.
Liste: Lange Fließtexte schrecken ungeübte Leser schneller ab als zwischendurch aufgelockerte Texte mit Aufzählungen. Je nach Lesetyp bevorzugen einige Stichpunkte, andere mögen lieber eingebettete Hinweise im laufenden Text. Listen können ungeordnet sein, wenn bei der Auflistung die Reihenfolge keine oder nur eine geringe Rolle spielt. Das ist beispielsweise der Fall, wenn verschiedene Bestandteile oder Optionen aufgelistet werden. Wenn die Reihenfolge wichtig ist, so wie bei Handlungen, sollten die Listen nummeriert sein. Bitte beachten Sie aber immer, dass sich Ihre Listen nicht zu sehr verschachteln. Wir wenden nur eine Listenebene an, in seltenen Fällen eine zweite Ebene. Falls einzelne Punkte nochmals aufgeteilt werden müssen.
Tabelle: Enge Zusammenhänge zwischen einzelnen Informationen können hierarchisch nicht nur als Liste oder Handlung gegliedert werden, sondern auch als Tabelle. Das bietet sich besonders für technische Daten an, möglicherweise aber auch für einzelne Funktionen, die voneinander abhängen. Wenn sich Informationen aus Tabellen schnell vergleichen lassen sollen, sind Diagramme eine gute Möglichkeit, die Werte daraus optisch darzulegen. Doch achten Sie im Fall von Diagrammen darauf, dass Ihre Zielgruppe in der Lage ist, die eingesetzten Diagramme richtig zu lesen. Ein Hindernis bei der Diagramm-Verständlichkeit kann schnell eine fehlende oder zu klein geratene Beschriftung sein.
Grafik: Diagramme lassen mich direkt an Grafiken im Allgemeinen denken. Nicht umsonst heißt es, dass ein Bild mehr als tausend Worte sagen kann. Doch gerade in der Technischen Dokumentation sollte der Fokus darauf liegen, eindeutige Aussagen zu machen und die Inhalte möglichst unmissverständlich darzustellen. Wir nutzen gerne Grafiken für den Lieferumfang oder um den Zusammenhang zwischen Funktionen zu erklären, wenn sie einander bedingen. Oder um einen Zusammenhang zu beschreiben. Teilweise können auch einzelne Handlungsschritte grafisch entweder komplett dargestellt werden oder zumindest unterstützt werden. Das ist besonders hilfreich, wenn etwas um bestimmte Umdrehungszahlen in eine bestimmte Richtung gedreht werden oder an fest definierten Stellen angebracht werden muss, die sich verbal nur schwer beschreiben lassen. Besonders zu beachten gilt dabei: Machen Sie sich vor der grafischen Aufbereitung Gedanken dazu, in welcher Form die Information prägnant, präzise genug und eindeutig dargestellt werden kann.
Multimediale und interaktive Inhalte: Wenn man nicht an Papier gebunden ist, sind multimediale und interaktive Inhalte eine auch für Marketingzwecke oder Verkaufsargumente nutzbare Möglichkeit, Informationen für die Zielgruppe ansprechender oder moderner zu liefern. Dabei denke ich spontan an einzelne Umfragen, Feedback-Aussagen, Checklisten oder Audio- und Videoinhalte, nur um ein paar Möglichkeiten zu nennen. Doch bei allen technischen Möglichkeiten ist auch hier wichtig, dass sich der Redakteur bzw. die Redakteurin überlegt: „Was braucht meine Zielgruppe?“ Und: „Wie gut hilft es, diese Informationen multimedial oder interaktiv zu gestalten?“ Doch besonders im Hinblick auf immer schlechtere Fähigkeiten beim Leseverständnis können zusätzliche Videos schnell und ansprechend die richtige Vorgehensweise für eine Handlung zeigen.
Das lässt sich übertragen
Zusammengefasst haben wir aus unseren Projekten mit verschiedenen Kunden, Ansprechpartnern und Produkten gelernt, dass besonders die technischen Ansprechpartner Schwierigkeiten damit haben, die Informationen für die Zielgruppe im geeigneten Detaillierungsgrad zu liefern. Daher lassen wir uns lieber alle vorhandenen Informationen zum Produkt/Projekt geben und splitten diese dann relativ schnell in die zwei Stapel auf „Brauchbar und nützlich“ oder „zu tief ins Detail gehend“. Den ersten Stapel analysieren wir genauer und bringen ihn in eine geeignete Reihenfolge, bevor wir uns um das „Aussehen“ kümmern. Damit meine ich, ob wir Fließtexte, Aufzählungen, Tabellen, Grafiken oder spezifische Kapitel dafür erstellen.
Vielleicht hilft Ihnen das weiter, weil Sie selbst bei einem Dienstleister tätig sind. Oder wenn Sie bei einem Produkthersteller beschäftigt sind, könnten Sie annehmen, die Technische Redaktion wäre der Dienstleister für das Unternehmen.
Prüfen Sie beim nächsten Projekt Ihre Prozesse dahingehend, ob Sie mit Ihren Kollegen und Kolleginnen aus den anderen Abteilungen so umgehen wollen, wie es ein externer Dienstleister mit seinen Kunden tun würde. Schreiben Sie mir gerne, wenn Sie noch mehr Tipps für das Transformieren der Daten in benutzerfreundliche Inhalte haben – wer weiß, vielleicht gibt es dank Ihres Inputs einen Folgeartikel.
