Mit „Use Cases“ zur optimalen Anleitungen

Wenn ein Anwender eine Anleitung zur Hand nimmt, erwartet er schnelle Hilfe zu genau seiner Frage oder seinem Problem.
Die Betrachtung dieser Use Cases ist der Schlüssel für die Entwicklung effizienter Technischer Dokumentation auf Papier, Online oder als App.

Was sind Use Cases?

Um es noch mal deutlich zu sagen: Ich spreche hier über Use Cases der Anleitung, also die Situationen, in denen der Anwender Hilfe benötigt. Zunächst auch unabhängig davon, ob er die Anleitung zur Hand nimmt oder nicht.
Zur Abgrenzung: Use Cases werden bei der Produktentwicklung betrachtet, dabei geht es um Anwendungen des Produkts und Optimierung des Produkts.
Unser Produkt heißt „Anleitung“ (oder andere Technische Dokumentation).

Mehr lesen

Zielgruppenanalyse und wie wir uns auf die Zielgruppe einstellen können

Zielgruppenanalyse, Zielgruppe, Technische Dokumentation

Wer eine Anleitung schreibt, MUSS über die Zielgruppe nachdenken, um sich in Sprache und Stil auf die potentiellen Anwender einzustellen.
Dabei gibt es mehrere Möglichkeiten die Zielgruppe einzuschätzen. Meistens sprechen wir von einer „Zielgruppenanalyse“, was aber nicht so ganz stimmt, wie der folgende Beitrag zeigt.
Das obige Bild soll deutlich machen, wie umfangreich und unterschiedlich Fachwissen sein kann und wie wichtig es folglich ist, dieses Fachwissen zu kennen und zu berücksichtigen.

Welche Eigenschaften der Zielgruppe interessieren uns?

Wir schreiben Anleitungen für Anwender, die schon etwas wissen und können.
Um uns beim Schreiben auf diese Anwender einzustellen, interessiert uns besonders:

  • Welche Fachkenntnisse hat der Anwender? (Grundwissen, Fachtermini, Handlungswissen, Sicherheitsbewusstsein).
  • Welche Erfahrung hat er mit ähnlicher Technik bereits gemacht?

Mehr lesen

Voraussetzungen in Handlungsanweisungen

Der Punkt „Voraussetzungen“ in Handlungsanweisungen führt immer wieder zu Fragen. Deswegen möchte ich ein paar Gedanken hier näher ausführen.
Dabei beziehe ich mich auf die Struktur der Handlungsanweisung (Juhl’sche Handlungsanweisung).

Unter Voraussetzungen verstehe ich Zustände, die bereits vorhanden sein müssen,  damit die Handlung (sinnvoll) durchgeführt werden kann, z.B.:

  • Es müssen mindestens zwei Benutzer angelegt sein (bei Windows, um einen Benutzer ohne Adminrechte zu definieren)
  • Das Bild muss im Format RGB vorliegen (bei Photoshop, um die Filter zu benutzen)
  • Der Pfad muss geschlossen sein (bei Photoshop, um die Pfadfläche zu füllen)
  • Sie müssen über ein Bankkonto verfügen und VR-Net-Key und Passwort vorliegen haben.

Mehr lesen

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).

Mehr lesen

Gehört Fachwissen in eine Anleitung?

Fachwissen gehört eigentlich nicht in eine Anleitung!
Eine Anleitung vermittelt das notwendige Geräte- und Handlungswissen zu einem Gerät / zu einer Maschine / zu einer Software.
Als Anleitungsschreiber kann und muss man davon ausgehen, dass der Anwender das notwendige Fachwissen bereits mitbringt, oder falls er es nicht hat, sich anderweitig besorgt.
Grundsätzlich steht es Ihnen als TR aber frei, Fachwissen in die Anleitung aufzunehmen.

Mehr lesen

Spezifische, unspezifische Information

***  Dieser Beitrag ist noch nicht ganz fertig, ***
*** ich stelle ihn trotzdem schon mal zur Diskussion ***

In letzter Zeit betrachte ich häufiger, wie wir als Technische Redakteure Informationen für unsere Anwender aufbereiten. Dabei differenziere ich momentan gerne „spezifische“ und „unspezifische“ Information. Wahrscheinlich kommt Ihnen das zunächst etwas akademisch vor, ich meine aber, es lohnt sich, sich mit dieser Unterscheidung zu befassen.

Spezifische Information

Spezifische Information nenne ich solche, die eine konkrete Antwort auf eine Frage gibt. Z.B. „Wie kann ich das Gerät einschalten?“ wird durch ein Kapitel „Einschalten“ beantwortet. Weitere Beispiele:

Mehr lesen

Terminologiearbeit (Überblick)

Der folgende kurze Abriss soll nur einen Überblick über die Terminologiearbeit geben.
Zu jedem Punkt könnte man noch viel schreiben.

  • Sensibilisierung, dass bei der Benennung von Teilen nicht immer die gleichen Termini benutzt werden.
  • Beispiele aus der aktuellen Praxis
  • Entschluss Terminologiearbeit einzuführen
  • Extraktion aller Benennungen
    (z.B. aus allen Dokumenten im Unternehmen)
  • Erkennung von Dubletten (welche Benennungen meinen das Gleiche?)
  • Gründung eines Terminologie-Arbeitskreises
  • Festlegen auf eine Benennung (im Arbeitskreis)
  • Festhalten der gewünschten und der nicht gewünschten Benennungen
    (in einer Datenbank, Excelliste … ggf. mit Definition und Übersetzungen)
  • Publizieren (die Datenbank muss für alle zugänglich sein)
  • Verpflichtend! (Die Einhaltung muss von der Geschäftsleitung gefordert werden).