Nicht lineare Dokumentation – was wird anders?

Früher haben wir Anleitungen geschrieben, bei denen der Inhalt für das (lineare) Buch gegliedert war:

  • alles steht hintereinander, vom Titelblatt bis zur letzten Seite
  • die Inhalte sind kapitelweise hierarchisch gegliedert

Diese Reihenfolge soll es dem Anwender ermöglichen seinen aktuellen Informationsbedarf zu decken, der inter- und intra-individuell durchaus unterschiedlich sein kann:

  • Einarbeiten: Bedienelemente kennen lernen, Grundbedienung erlernen, ausprobieren, anwenden …
  • Nachschlagen: Sehr unterschiedlicher Informationsbedarf in allen Phasen der Anwendung (vom „wie kann ich XY tun?“ bis „welches Drehmoment brauche ich bei …?“)
  • Weiter lernen: Ich gehe davon aus, dass ein Anwender zuerst die Grundfunktionen kennen lernen will und sich danach, vielleicht auch viel später, weitere Funktionen erschließt (bei Bedarf oder auch als „was gibt es sonst noch?“).

Heute nennen wir das gerne Use Cases. Die Anleitung muss geeignet sein, Antworten bei allen Use Cases zu geben (gemeint sind die Use Cases der Anleitung).

Punktuelle Informationsbereitstellung

Heute sehen wir mehr die punktuelle Informationsbereitstellung: Der Anwender hat ein Problem, sucht in der Anleitung (bzw. in der TD) und springt direkt zur Lösung seines Problems.
Dabei ist es egal, ob die Information in einem hierarchischen Inhaltsverzeichnis angeordnet ist, oder als Topic einzeln aus einer Datenbank kommt.

Use Cases

Wichtig bleiben weiterhin die Use Cases, zu denen die Anleitung Antworten liefern muss.

  • Einarbeitung: Hier sehe ich nach wie vor eine umfangreichere Information als nur ein Topic, ähnlich den ersten Kapiteln einer „alten Anleitung“.
    Das könnte aber auch als Video oder Tutorial ausgeführt sein.
  • Nachschlagen: Sehr unterschiedliche Fragestellungen, die mit spezifischer oder unspezifischer Information beantwortet werden können (siehe auch mein Blogbeitrag).
  • Weiterlernen: Wenn der Anwender eine bestimmte Handlung oder Funktion sucht, kann er via Nachschlagen zu einem geeigneten Topic finden.
    Wenn er sich anregen lassen will, braucht er irgendwelche Führung: z.B. eine Liste der Tätigkeiten oder Funktionen, vielleicht mit einer kleinen Leistungsbeschreibung jeweils und der Möglichkeit ins Topic zu springen.

Use Case „Nachschlagen“

Bei den meisten Diskussionen über „nicht lineare Dokumentation“ wird (leider) nur der Use Case „Nachschlagen“ betrachtet (der aber nicht der wichtigste ist!).
Trotzdem: Wir sind mittlerweile gewohnt mit Volltextsuche uns zu einer Problemlösung hin zu suchen.

  • Suchwort,
  • Suchwortkombinationen,
  • Trefferlisten mit Kurzfassung,
  • checken, ob das die gesuchte Information ist …
  • weitersuchen

Dabei hat uns Google mit gut gerankten Fundstellen häufig schnell geholfen.
Das Ranking ist also wichtig!

Ebenso gewohnt sind wir bereits die „kontextsensitive Suche“, bei der Hilfe zur aktuellen Umgebung (z.B. zur aktuellen Dialogbox) gegeben wird.
Eine Aufgabe des TRs wird es also sein, die Topics einem oder mehreren Kontexts zuzuordnen.

In diesem Zusammenhang sind technisch noch etliche weitere „Mechanismen“ denkbar:

  • Wichtig wäre zunächst, dass sich die TD nur auf die tatsächlich vorhandenen Features bezieht.
    (Wann bekomme ich endlich die PKW-Anleitung zu meinem PKW in meiner Ausstattung? 🙂 )
  • Denkbar wäre auch die Berücksichtigung des Ortes (wo an der Maschine steht der Anwender gerade?)
  • oder des Anwenders (welche Rolle hat der Aufrufer: Anwender, Service Techniker, Admin?)
  • oder wie lange hat der Anwender das Gerät schon?
  • Unser Ziel als Informationsbereitsteller müsste sein, möglichst wenig relevante Fundstellen zu präsentieren.

Qualität des Topics

Wenn der Anwender erstmal das richtig Topic gefunden hat, bleibt die Qualität des Topics wichtig:

  • kann er als Anwender seine Information im Topic schnell finden?
  • und kann er die Information schnell in Handlung umsetzen?
  • Hierfür müssen die Topics inhaltlich und darstellungstechnisch optimiert sein
    (z.B. Schritt-für-Schritt-Anleitung für Handlungen).

Das Topic steht nicht allein

Ein Topic enthält idealerweise die Informationen genau zu einem Punkt (z.B. einer Handlung oder einem Bauteil oder einer Funktion).
Dabei müssen fast immer Kenntnisse vorausgesetzt werden, z.B.:

  • Grundkenntnisse
  • Aufbau und Funktion
  • Bezeichnung der Bauteile/Module und Bedienelemente
  • Sicherheitshinweise

Eine Wiederholung dieser Kenntnisse widerspricht der Idee des Topics und würde den Umfang kolossal vergrößern.
So müssen wir auch bei Handlungsanweisungen m.E. die Kenntnis der Sicherheitshinweise voraussetzen (siehe auch mein Buch Warn Out).

Genau an dieser Stelle ergibt sich ein Problem der nicht linearen Dokumentation:
Wie können wir die Information auf einen Punkt beschränken und die Kenntnis der notwendigen Grundlagen voraussetzen?
Der Anwender soll ja „einfach in der TD suchen und seine (isolierte) Lösung finden und verstehen.

Meines Erachtens sind zwei Ansätze denkbar:

  1. Wir zählen bei jedem Topic die notwendigen Kenntnisse auf und verlinken jeweils.
  2. Wir schaffen in der jeweiligen TD ein System, bei dem wir die Grundkenntnisse voraussetzen können
    (d.h. es gibt Kapitel, die der Anwender gelesen und verstanden haben muss. Möglicherweise hat er das irgendwo bestätigt oder sogar ein Zertifikat erworben.)

Lösung 1. ist m.E. schwierig zu realisieren.
Es mag einfache Geräte geben, bei denen wenige Topics genügen und die Verbindung oder Voraussetzungen durch Links zu realisieren sind.
Bei den meisten Beispielen aus meiner Praxis ist das aber nicht der Fall, weil die Bezüge zu vielfältig sind.
Vielleicht bin ich auch nur zu altmodisch und glaube, dass ein systematischer Aufbau von Grundkenntnissen der bessere Weg ist.

Lösung 2. bietet sich m.E. an, weil in den meisten Fällen sowieso eine Einarbeitung und ein Lernen erforderlich ist.

(Exkurs: Ich bin mir bewusst, dass das modernem Produktdesign widerspricht, bei dem die Entwickler versuchen, das Gerät oder die Software so zu designen, dass intuitiv bedient werden kann und ein Lernen nicht erforderlich ist. Die Grundidee finde ich richtig. In vielen Fällen macht aber ein System mehr Sinn, wenn der Anwender etwas gelernt hat. Beispiel: MS Word ist intuitiv bedienbar; Formatvorlagen ermöglichen eine intelligentere Nutzung, müssen aber erlernt werden.)

Meines Erachtens wird hier schon deutlich, dass eine nicht-lineare-Dokumentation für das Nachschlagen ein Konzept zur Einbindung der Grundkenntnisse erfordert. Möglicherweise wird das viele stören, weil ja die Idee der nicht-linearen-Dokumentation damit um einen wichtigen Aspekt beschnitten wird: Der „einfache“ Zugriff auf nur die benötigte Information ist nicht ohne weiteres möglich.

Use Case „Einarbeitung“

Auch für den Use Case „Einarbeitung“ sehe ich im Moment keine nicht-lineare Lösung.
Meines Erachtens umfasst die Einarbeitung immer mehrere Inhalte, die sinnvoll in einer bestimmten (didaktischen) Reihenfolge vermittelt werden können (z.B. Leistungsbeschreibung, Sicherheitshinweise, Gerätebeschreibung, Tätigkeiten).

Use Case „weiter lernen“

Wahrscheinlich wissen Sie aus eigener Anwender- oder TR-Erfahrung, dass viele Anwender viele Features nicht nutzen. Die Gründe sind meistens Unkenntnis und eine gewisse Abneigung Anleitungen zu lesen.

Aus TR-Sicht können/müssen wir m.E. gerade im Punkt „weiter lernen“ verstärkt investieren.
Möglichkeiten den Anwender zum weiter lernen zu motivieren gibt es ausreichend, auch in der nicht-linearen-Dokumentation.

Am besten geht das über die Vermittlung von Nutzen. Dazu muss es uns gelingen die Aufmerksamkeit des Anwenders kurz zu erlangen und in dieser kurzen Zeit ihm den Nutzen so schmackhaft zu machen, dass er einem Link folgt.
Eine eigentlich gute Möglichkeit sind „Tipps“ wie sie z.B. jeweils beim Start der Software gegeben werden. („Eigentlich“ weil der Anwender in diesem Zeitpunkt nicht die Muße für Tipps hat. Ein anderer Zeitpunkt wäre besser …)

Diesen Punkt möchte ich hier aber nicht weiter ausführen.

Sonderfälle

In der Menge der Ausführungen von TD gibt es bestimmt Fälle, in denen sich die nicht lineare Dokumentation gut eignet.
Das sind entsprechend der obigen Betrachtungen vor allem TDs die speziell für das Nachschlagen benutzt werden und bei denen ein gewisses Grundwissen vorausgesetzt werden kann, z.B.:

  • Eine Serviceanleitung, die sich an ausgebildete Servicetechniker wendet, kann Wissen und Handlungswissen als Topics anbieten, weil  bei der Zielgruppe Grundwissen (auch zum Gerät?) vorausgesetzt werden kann.
  • Bei mancher Software (auch einem Betriebssystem eines Smartphones) kann viel Wissen und Handlungswissen in Topics vermittelt werden, wenn die systematische Einarbeitung und das Weiterlernen anderweitig abgedeckt sind.

Fazit

  • Die Idee Informationen als eine Topic-Antwort auf ein Anwender-Problem zu geben ist gut.
  • Technische Möglichkeiten des Information-Retrieval sind viele denkbar und realisierbar.
  • Die Anforderungen an die Qualität der Topics sind hoch.
  • Voraussetzungslose Topics sind m.E. nicht möglich.
    Hier muss im Einzelfall dringend eine Lösung konzipiert werden!
  • Einzelne nicht-lineare Lösungen sind gut denkbar, wenn sie in einem TD-System stehen, in dem die anderen Aspekte (vor allem die Einarbeitung) abgedeckt werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.