Wer sich in welchem Umfeld auch immer als Technikredakteur geoutet hat, kennt die Aussagen: „Hä? Anleitungen? Das lese ich nie! Da steht doch sowieso nie das drin, was ich wissen möchte.“ – Stimmt. Ich lese sie auch nie und verzweifle oft daran, was die Kollegen erstellt haben (oder erstellen mussten). Oft habe ich den Eindruck, dass keiner der Kollegen jemals das Produkt gesehen oder bedient hat.
Um die provokative Einleitung gleich wieder abzuschwächen: mir geht es häufig auch so, dass das Ergebnis meiner Tätigkeit nicht ganz meinen eigenen Ansprüchen genügt.1 Dasselbe gilt übrigens auch für Kochrezepte, denn selbst wer sich akribisch an die Rezeptvorgaben hält, endet mit einem anderen Kuchen als angegeben.2 Und so sieht es bei Dokumentationen auch aus: Die abgebildete Software hat den Button nicht da, wo er angeblich stehen sollte (und falls doch, dann heißt er anders), für das Verständnis des Anleitungstexts braucht man ein Informatikstudium – und um ein Fahrradrücklicht anzuklemmen ist ein Spezialwerkzeug erforderlich.
Wie kommt es dazu?
Dokumentationen dieser Art sind Trauerspiel, bei dem beim Anwender die Frustrationsgrenze schnell überschritten ist, selbst wenn es der Technikredakteur noch so gut meinte. Er kann ja nichts dafür, wenn der Produktmanager kurz vor der Auslieferung noch das Interface umstellt, weil ihm das besser gefällt, wenn die Programmierer den Button nach der Mittagspause anders nennen als davor oder es überhaupt keine Festlegung gibt, wie das Bauteil heißt, das beschrieben werden soll. Aber wie geht es dann erst dem Kunden? Wen soll er fragen? Den Support?
Vor diesem Szenario schrecken auch viele Technikredakteure zurück und wurschteln sich halt irgendwie durch. Dann werden die Seitenzahlen eben von Hand auf jede Seite gesetzt, der Kunde nimmt statt des Spezialwerkzeugs ein Taschenmesser und das Rücklicht muss bis zur Verschrottung des Rads am Rahmen bleiben…
Aber warum? Warum haben die Leute, die das herstellen und beschreiben, so wenig Vorstellung von der Verwendung und dem Gebrauchsnutzen des Produkts?
Haben sie. Nur eine ganz andere Vorstellung.
Konstrukteure, Entwickler und Produktverantwortliche haben nämlich (verständlicherweise) jeweils eine ganz andere Sicht auf das Produkt und müssen sich während der Herstellung einander annähern, um möglichst viele der jeweiligen Vorstellungen zu berücksichtigen. Dummerweise taucht der Anwender in dieser Konstellation gar nicht auf – außer der Produktleiter ist selbst Anwender.3 Wie aber kommt der Anwender ins Spiel? Man kann dem Kunden ja schlecht noch vor dem Produktionsstart ein paar Skizzen eines Staubsaugers vorlegen und dann von ihm verlangen, dass er daran erkennt, wie man den Beutel wechselt. Und selbst Usability-Studien helfen hier nicht unbedingt weiter, denn erstens sind sie aufwändig und zweitens benötigt man dazu bereits funktionierende Prototypen – ein immenser Kostenfaktor.
Es geht manchmal mit noch weniger Aufwand: Man benötigt Anwendungsfälle – oder neudeutsch: „Use cases“.
Ein Anwendungsfall (engl. use case) bündelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes fachliches Ziel zu erreichen. Er beschreibt, was inhaltlich beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen. Das Ergebnis des Anwendungsfalls kann ein Erfolg oder Fehlschlag/Abbruch sein. (Wikipedia)
OMG!
Das klingt wesentlich komplizierter als es ist: Man stellt sich die Frage, was ein Anwender tun muss, um ein bestimmtes Ziel zu erreichen und welche Voraussetzungen erfüllt sein müssen.
Mehr nicht? – Nein, mehr nicht.
Die Kunst besteht nun darin, die Prozesse (beispielsweise den Einbau eines Fahrradrücklichts) so zu beschreiben, dass die Tätigkeit (das „Was tun?“) im Mittelpunkt steht – und nicht die Art und Weise (das „Wie macht man das?“).
Auftritt: Technikredakteur
Eigentlich sind Anwendungsfälle unser Alltag, denn egal, ob wir in der Fertigungshalle stehen und eine Waschmaschine inspizieren oder ob wir die Beta-Version einer Software bekommen: Wir spielen daran herum und versuchen uns vorzustellen, was man damit eigentlich macht und was man tun muss, dass es das tut, was wir erreichen wollen. Wir machen uns Gedanken darüber, was der Anwender tun muss, um das Ergebnis zu erzielen, für das er das Produkt gekauft hat.
Bei Hardware ist das ja noch einfach: Bei einem Dieselaggregat sind die Anwendungsfälle noch vergleichsweise überschaubar. Ebenso bei einer elektrischen Zahnbürste oder einem Staubsauger. Schwieriger wird es mit Software – und es ist erstaunlich, zu welchen intellektuellen Sprüngen manche Anwender in der Lage sind, um eine Software so zu verwenden, wie sich das ein Entwickler nie hätte vorstellen können…
Wir brauchen also einen neuen Blickwinkel: den des Anwenders
Eingenordet
Im Use case steht die Sicht Anwenders („Actor“) im Mittelpunkt. Er interagiert mit dem System, um ein bestimmtes Ziel zu erreichen. Dazu führt er eindeutige Schritte durch und erhält mitunter Rückmeldung vom System. Ein Anwendungsfall ist also eine Handlungskette, die vom Anwender durchgeführt wird und auf die das System reagiert – am besten erfolgreich. Dazu müssen gegebenenfalls bestimmte Startkriterien erfüllt sein. Unterwegs gibt es möglicherweise Abbruchkriterien oder Optionen, die auch zum Ziel führen. Und zum Schluss wird ein Zielzustand erreicht, an den ein neuer Use case anschließen kann.4
Wie erstellt man denn nun einen Use case?
Die einschlägige Literatur macht einem unbedarften Technikredakteur dazu das Leben mit Visualisierungen und Beschreibungen nicht gerade einfach, da sie sich meist auf Geschäftsprozesse und Softwareprozesse bezieht, die der Technikredakteur normalerweise immer nur als fertiges Ergebnis zu sehen bekommt. Hat er sich allerdings selbst bereits eine Vorlage angelegt, ist auch der Technikredakteur in der Lage, Schwachstellen in den Prozessen zu entdecken, bevor er sie wortreich kaschieren muss.
Eine Vorlage besteht aus einer Gliederung:
- Titel des Anwendungsfalls. Kann dieser nicht eindeutig beschrieben werden, ist er zu weit gefasst und man muss einen neuen Anwendungsfall daraus machen.
- Zusammenfassung („Summary“). In höchstens zwei Sätzen wird das der Prozess beschrieben, um den es nun geht.
- Normaler Ablauf („Basic course of events“). Dies ist die Reihenfolge der Schritte , die vom Anwender durchgeführt werden, und auf die das System reagiert:
- Der Anwender wählt den Druckbefehl im Menü.
- Das Programm zeigt die Druckoptionen an.
- Der Anwender stellt die Papiergröße und das Papierformat ein.
- Das Programm zeigt ein Vorschaubild des Druckergebnisses mit der eingestellten Papiergröße.
- …
- Alternativer Weg („Alternative path“). In wenigen Sätzen werden eine oder mehrere Optionen umrissen, die unter den gleichen Ausgangsbedingungen zum gleichen Ziel führen.
- Abbruchkriterien („Exception path“). In wenigen Sätzen werden die „Bruchstellen“ des Prozesses beschrieben, den den Anwender dazu bringen, den Prozess trotz identischer Ausgangsbedingungen und Handlungsschritte abzubrechen. (Für den Druck eines Dokuments ist Papierstau ein Abbruchkriterium.)
- Voraussetzungen („Preconditions“). Welche Voraussetzungen müssen erfüllt sein, damit der Anwender den Prozess starten kann?
- Folgen („Postconditions“). In wenigen Sätzen wird beschrieben, welche Prozesse nun erforderlich sind – oder auch nicht.
Das Ergebnis ist ein Stapel unterschiedlicher Anwendungsfälle, die der Hersteller im besten Fall in der Produktion berücksichtigt („Hoppla! Da fehlt ein Absperrventil!“) oder aber der Technikredakteur als Schnittstelle abfängt, indem er dem Anwender beschreibt, wie er sein Ziel trotzdem erreichen kann.
Profis werden an der Gliederung erkannt haben, dass es aus redaktioneller Sicht natürlich besser ist, die Voraussetzungen vor der Durchführung zu erwähnen. Allerdings handelt es sich um einen Use case, nicht um ein Handbuch, das 1:1 so weitergegeben werden kann. Im Gegenteil: Ein Technikredakteur, der bereits vor dem „Schreiben“ der Dokumentation die Zeit und das Hirnschmalz investiert hat, eine Sammlung der Anwendungsfälle anzulegen, greift wesentlich tiefer in das Informationsnetz des Produkts ein, denn er kann auch den Produktverantwortlichen kommunizieren, dass möglicherweise manche Handlungen unnötig komplex oder gar unmöglich sind.
Analogie
Im Grunde genommen sind Anwendungsfälle die Szenen eines Stücks, die sinnvoll ineinander greifen müssen, ohne dass der Zuschauer und die Darsteller den Faden verlieren. Die Scripts der Szenen entstehen aus der engen Zusammenarbeit mit den Produktverantwortlichen und -erstellern. Und dabei steht auch mal der Technikredakteur als Dreh- und Angelpunkt der Produktentwicklung im Mittelpunkt…
Im Laufe der Zeit stellt sich das so genannte „Pareto-Optimum“ ein, bei dem es innerhalb der vorgegebenen Zeit nicht möglich ist, die Dokumentation zu verbessern, ohne einen Mehraufwand zu betreiben, der nicht bezahlt wird. ↩
Das ist auch der Grund für die Backmischungen, die sozusagen den kleinsten gemeinsamen Nenner darstellen: man muss nichts können, noch nicht einmal schmecken. ↩
Aber selbst dann repräsentiert er vermutlich aufgrund seiner Kenntnisse nicht den durchschnittlichen Anwender. ↩
Für den Technikredakteur klingt das ziemlich vertraut, denn er baut Instandhaltungs- oder Montageanleitungen idealerweise immer so auf. Leider bleiben diese Erkenntnisse den Produktverantwortlichen oft verborgen, solange sie nicht die Dokumentation lesen. ↩