Grundlage des Persona-Verfahrens ist der Entwurf typischer Anwender. Diese stehen stellvertretend für eine Zielgruppe, nach deren Anforderungen eine Technische Dokumentation verbessert werden kann. Die Optimierung findet während der Konzeptionsphase der Dokumentation statt. Die Personas dienen dabei als Werkzeug, fließen selbst aber nicht in die Dokumentation ein.
Zielgruppe
Die Bedürfnis- und Zielgruppenorientierung ist wichtig, denn eine Dokumentation wird den Anwendern nur dann gerecht, wenn sie so gestaltet ist, wie es die Anwender erwarten, und wenn sie die Informationen enthält, die für die Anwender wirklich nützlich sind. Dies zeigt der Nutzen- und Gratifikationsansatz der Medienpsychologie.
Aufgabe der TD
Nach diesem Ansatz der Medienpsychologie [1] sind Anwender mit einer Technischen Dokumentation dann zufrieden, wenn sie ihre Bedürfnisse befriedigt (Gratifikation) und wenn der Aufwand zum Abruf der Informationen nicht zu hoch ist [2]. Denn Anwender sind bis zu einem gewissen Maße bereit Anstrengungen zu unternehmen, wenn sie sich davon einen entsprechenden Gewinn versprechen.
Wenn diese Voraussetzungen erfüllt sind, werden sie den Umgang mit der Dokumentation als angenehm empfinden, weil Aufwand und Nutzen in einem vernünftigen Verhältnis zueinander stehen.
Das Persona-Verfahren
Die Basis für dieses Verfahren bildet das Interaktionsdesign nach Cooper [3]. Es ermöglicht ein zielgruppenorientiertes und -optimiertes Informationsdesign für Softwareprodukte [1]. Sein Einsatz ist aber auch für Gebrauchs- und Betriebsanleitungen denkbar [4]. Die Vorgehensweise bei der Identifizierung der Bedürfnisse und der daraus resultierenden Optimierung für die Zielgruppen ist relativ unabhängig vom Produkt.
Zunächst müssen die Bedürfnisse und Ziele der Anwendergruppen ermittelt werden, beispielsweise auf Basis von Marketingdaten oder Erfahrungswerten aus dem Service. Die Erkenntnisse kann der Technische Redakteur mittels Personas in die Dokumentation einfließen lassen. Dazu entwickelt er für jede wesentliche Anwendergruppe eine oder mehrere Beispielanwender, die Bedürfnisse und Ziele wirklichkeitsgetreu bis in alle relevanten Einzelheiten beschreiben. Sie orientieren sich aber nicht an realen Personen, weil diese immer bestimmte individuelle Anforderungen haben. Vielmehr basieren sie auf hypothetischen und stereotypen Annahmen, die den typischen Anforderungen der Zielgruppe entsprechen.
Vorgehensweise
Abbildung 1 zeigt die Anwendung des Persona-Verfahrens. Ausgangspunkt sind Angaben zu den Bedürfnissen der Anwender, die aus den dargestellten Quellen stammen können. Diese Angaben werden in Eigenschaften und Kennzeichen von typischen Anwenderfiguren übersetzt. Dies kann als Brainstorming geschehen, während dessen alle Beteiligten diese Personas wie Roman- oder Filmfiguren entwickeln.
Typische Eigenschaften und Kennzeichen werden einzelnen Figuren zugeordnet, und zwar so, dass diese Personas stereotype Charakteristiken annehmen. Beispielsweise werden alle typischen Eigenschaften eines erfahrenen Beraters einer Persona zugeordnet und alle typischen Eigenschaften eines wenig erfahrenen Beraters einer anderen Persona. Dieser Vorgang wird für die Zielgruppe der Endanwender oder Systemadministratoren wiederholt. Es können bis zu zwölf Beispielanwender entstehen, die das mögliche Spektrum an typischen Anwendern in verschiedenen Ausprägungen zeigen:
| Kategorisierung von Personas für die Software-Dokumentation | |||
| Anwendertyp | Ausprägung 1 | Ausprägung 2 | Ausprägung 3 |
| Berater | sehr erfahren | erfahren | wenig erfahren |
| Systemadminstrator | sehr erfahren | erfahren | wenig erfahren |
| Endbenutzer | sehr erfahren | erfahren | wenig erfahren |
Aus den entwickelten Personas wählt der Technische Redakteur mehrere Hauptfiguren aus, die typische Eigenschaften und Kennzeichen der Anwendergruppe haben, z. B. der erfahrene Profi oder der Endanwender mit geringen Kenntnissen. Dies ist der entscheidende Schritt für den Entwicklungsprozess, denn diese Hauptpersonas stehen für die Hauptzielgruppen der Dokumentation. Deren Anforderungen müssen auf jeden Fall erfüllt sein. Wenn diese Anforderungen allerdings weit auseinander liegen, sollte für jede Hauptpersona eine eigene Dokumentation erstellt werden.
Für jede Hauptpersona wird nun ein Szenario entworfen, das den Anwendungskontext des Produkts und der Dokumentation sowie die Hauptaufgaben dieser Persona beschreibt. Anschließend werden die Aufgaben der Persona durch ihre Ziele ersetzt. Eine typische Aufgabe wäre zu lernen mit der Dokumentation das Produkt zu bedienen. Ein typisches Ziel dagegen wäre, den Umgang mit dem Produkt zu beherrschen. Indem die Aufgaben durch Ziele ersetzt werden, wird sichergestellt, dass die Dokumentation zielorientiert ist und nicht aufgabenorientiert. Dies ist ein wesentlicher Aspekt des Persona-Verfahrens, denn die Aufgaben der Persona können sich ändern, während ihre Ziele gleich bleiben.
Für die konkrete Arbeit mit Personas gibt Alan Cooper einige Empfehlungen. Unter anderem rät er einer Persona einen Namen zu geben, um sie in der Vorstellung zu einem Individuum zu machen. Zur weiteren Unterstützung kann die Persona durch ein Foto repräsentiert werden. Denn mit Namen und Gesicht gewinnt die Persona an Profil und erscheint weniger fiktiv. Im Endeffekt wird es für den Technischen Redakteur einfacher sich in den Beispielanwender zu versetzen.
Anwendungsszenario
Stellen Sie sich vor, Sie arbeiten in einem Software-Unternehmen und erstellen Handbücher für Berater, die das Softwareprodukt beim Kunden installieren. Zur Verbesserung der Technischen Dokumentation entwerfen Sie zwei Personas, die typisch sind für den Personenkreis der Berater. Ausgangspunkt sind Informationen über die typischen Berater, die Sie beispielsweise aus Interviews oder Gesprächen mit Kollegen erhalten haben. Mit diesen Informationen entwerfen Sie folgende Personas: eine für den erfahrenen und eine für den unerfahrenen Berater. Dann ordnen Sie ihnen die typischen Kennzeichen und Eigenschaften der Zielgruppe zu. Um die Arbeit mit den Personas anschaulicher zu machen, geben Sie ihnen Namen und fügen ein Bild der Persona hinzu:
| Übersicht über die Anforderungen, Bedürfnisse und Ziele der beiden Personas | ||
| Kennzeichen / Eigenschaften | Persona 1 | Persona 2 |
| Name | Petra Mayer | Franz Huber |
| Alter | 33 | 26 |
| Erfahrung als Berater | 6 Jahre | 10 Monate |
| Produktkenntnis | Sehr gut | Frisch eingearbeitet |
| Betriebwirtschaftliches Wissen | Sehr gut | Grundkenntnisse |
| Einsatzgebiet | Arbeitet nur im süddeutschen Raum | Arbeitet in ganz Deutschland und im Ausland |
| Übersicht über die Anforderungen, Bedürfnisse und Ziele der beiden Personas | ||
| Anforderungen, Bedürfnisse, Ziele | Persona 1: Petra Mayer | Persona 2: Franz Huber |
| Benötigt umfassende Information über alle Funktionen des Produkts | Nein | Ja |
| Benötigt nur Information über neue Funktionen des Produkts | Ja | Nein |
| Benötigt nur deutschsprachige Dokumentation | Ja | Nein |
| Benötigt fremdsprachige Dokumentation | Nein | Ja |
| Benötigt Beispiele, die den Bezug zu betriebswirtschaftlichen Themen herstellen | Nein | Ja |
Fazit
Das Persona-Verfahren arbeitet mit Anwendertypen, die für die wichtigsten Anwendergruppen der Technischen Dokumentation stehen und einen Großteil der Anforderungen, Bedürfnisse und Ziele dieser Gruppen abdecken. Meist ist es nicht möglich, die Interessen und Bedürfnisse aller Anwendergruppen zu berücksichtigen. Zumindest werden aber die Hauptziele erreicht.
Durch Ausrichtung auf die Persona wird die Dokumentation zielgruppenorientiert und -optimiert. Denn die Personas bestimmen nicht nur die Bedürfnisse und Ziele der wichtigsten Anwendergruppen, sondern enthalten auch fundierte Annahmen über ihre Kenntnisse in der Produktbedienung. Dies verhindert, dass die Technische Dokumentation von falschen Voraussetzungen über den Kenntnisstand der Mehrheit der Anwender ausgeht und diese über- oder unterfordert oder ihnen zu viel oder zu wenig Informationen liefert. So ersetzen „Mustermanns“ mit klaren Profilen die anonyme und deshalb konturlose Zielperson.
Literatur:
[1] Mangold, R. (2002): Webdesign ist Informationsdesign: Useradaptierte Webgestaltung auf der Grundlage psychologischer Erkenntnisse. In: Vorträge der tekom-Jahrestagung 2002 in Wiesbaden, Zusammenfassungen der Referate. S. 265. Stuttgart.
[2] Palmgreen, P. (1984): Der „Uses and Gratifications Approach“. Theoretische Perspektiven und praktische Relevanz. In: Rundfunk und Fernsehen, 32, 1984: S. 51–62.
[3] Cooper, A. (1999): The Inmates are Running the Asylum. Why High-tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis, IN: Sams. S. 123ff und S. 155ff.
[4] Greisinger, S. (2002): Zielfahndung – Wer sind meine Anwender und was wollen sie? tekom-Jahrestagung 2002. Wiesbaden.
