Mit der Persona Methode oder der User Story können Zielgruppen und ihre Anforderungen beschrieben werden. Wie diese Methoden helfen die Zielgruppen zu finden und zu beschreiben möchte ich aus Sicht der Kommunikation von Produktinformationen und deren technischen Unterlagen erläutern.
Jede kommunizierte Information zu Produkten ist eine „sprachliche Handlung“, die eine kommunikative Absicht verfolgt. Im Funktionsdesign® (eine Standardisierungsmethode der technischen Redaktion) ist die „sprachliche Handlung“ das grundlegende Element.
Doch trifft diese „sprachliche Handlung“ die Informationsbedürfnisse der Empfänger? Wieviele verschiedene Informationsbedürfnisse gibt es? Lassen sich Gruppen von Empfängern bilden und beschreiben?
Persona Methode
Diese Personas werden konkret beschrieben. Autorinnen und Autoren haben dadurch ein „Gesicht“ vor Augen, wenn sie Produktinformationen oder technische Beschreibungen erstellen.
Wie entwickelt man die Personas
- Nutzer beobachten
- Abteilungen mit Kundenkontakten befragen
- Einzelinterviews mit Nutzern oder Fokusgruppen führen
Fragen zur Identifizierung der Personas
- Informationen zur Person: Alter, Geschlecht, Ausbildung, Beruf, Kenntnisse, Interessen und weitere die von Interesse sein könnten
- In welcher Umgebung befindet sich der Nutzer: Ausstattung der Arbeitsumgebung und des Umfeldes, z. B. ob Internetzugang vorhanden ist und ein Rechner zur Verfügung steht.
- Welches Informationsbedürfnis hat der Nutzer: welches Ziel kann damit erreicht werden
Aus diesen Ergebnissen werden die Benutzerbedürfnisse identifiziert, Personas mit typischen Nutzercharakteristiken entwickelt und die befragten Nutzer diesen Gruppen zugeordnet.
Bei einer größeren Menge von Persona werden Hauptpersonas definiert, deren Informationsbedürfnisse erfüllt sein müssen oder die einen spezifischen Einstieg oder Zugang zur benötigten Information erhalten sollen.
Für zielgruppenorientierte Informationsbereitstellung ist dieses Wissen Grundvoraussetzung.
User Story
Die User Story (Anwendererzählung) hat ihren Ursprung in der Softwareentwicklung. In maximal zwei Sätzen wird beschrieben:
Als [Rolle] möchte ich [Ziel/Wunsch] , um [Nutzen]
Bezogen auf die Bereitstellung einer Produktinformation oder technischen Anleitung könnte das folgender Satz sein:
Als Maschinenbediener möchte über den Maschinenbildschirm Videoanleitungen zur Fehlerbehebung an der Maschine angezeigt bekommen, um die Standzeiten der Maschine kurz halten zu können.
Anhand von Kriterien lässt sich erkennen, ob eine User Story „gut“ ist.
- sie sollte unabhängig von anderen User Stories sein
- sie sollte diskutierbar bzw. präzisierbar sein
- sie sollte für den User einen Wert stiften
- die Realisierung sollte abschätzbar sein
- der Umfang sollte realisierbar sein
- der Erfolg der Umsetzung sollte gemessen werden können
Zusammenfassung der User Stories zu Epics
Lassen sich die erhaltenen User Stories zu Überbegriffen zuordnen? Beispiel: Bedienung, Inbetriebnahme, Fehlerbehebung, usw. Diese können auch weiter unterteilt werden.
Werden alle Epics unterhalb von User Stories zusammen gefasst wird ein guter Überblick geschaffen.
Auf Basis dieser Informationen kann die Realisierung einzelner User Stories bewertet und geplant werden.
