Akteure und Rollen: funktionale Klarheit

Für eine formale Beschreibung von Use-Cases oder kurzen User-Storys genügen sogenannte Akteure. Diese entsprechen nicht (theoretisch) realen Personen, sondern den Nutzer-Rollen. In einem Webshop gibt es beispielsweise die Rollen Besucher, Kunde, Neukunde, Stammkunde. Wie sich diese unterscheiden, ist für jedes Projekt zu definieren:

  • Besucher: jeder, der die Seite aufruft und benutzt, auch ohne etwas zu kaufen
  • Kunde: (Untergruppe der Besucher) jeder, der eine Bestellung auslöst
  • Neukunde: (Untergruppe der Kunden) jeder, der eine erste Bestellung auslöst und bislang kein Kundenkonto angelegt hat
  • Stammkunde: (Untergruppe der Kunden) jeder, der bereits mindestens drei Bestellungen ausgelöst hat und über ein Kundenkonto verfügt

Je nach Shop-Funktionalität sind möglicherweise weitere Unterscheidungen möglich. Womöglich benötigt es eine weitere Rolle „potenzieller Kunde“ für jene Besucher, aus deren Verhalten sich eine Kaufabsicht ableiten lässt, aber diese noch nicht ausgeführt wurde und noch keine Information vorliegt, ob es sich um einen Stammkunden handelt. Auch ist im Beispiel die Rolle „Kunde“ der Oberbegriff; für bestimmte Situationen wird zwischen „Neu-“ und „Stammkunde“ unterschieden. Werden Personas erstellt, ist es sinnvoll, bei jeder die Rollen anzugeben, die diese ausfüllt.

Rollen definieren

Die Definition von Rollen hängt also immer vom Anwendungsfall ab, der mit ihnen beschrieben wird. Daraus leiten sich die Perspektive und der Zuschnitt der Rollen ab. Der Webshop kann einen Besucher erst ab einer Identifikation (durch Cookie oder nach Anmeldung) als Stammkunde erkennen. Hier genügt in den meisten Fällen die Unterscheidung zwischen „unbekannter Besucher“ (nicht identifiziert) und „bekannter Besucher“ (identifiziert, wiederkehrend). Für das System, das anschließend die aufgegebenen Stellen verarbeitet, ist eine Unterscheidung in verschiedene Kunden (Neukunde, Stammkunde, A-, B- oder C-Kunde) aber durchaus relevant.

Für eine taugliche Nutzung der Rollen ist daher im Vorfeld zu klären, welche Unterschiede in welchen Nutzungskontexten relevant sind und welche nicht. Darf Nutzerperson A etwas, was Nutzerperson B nicht darf, dann benötigen sie verschiedene Rollen. Ist ihre Arbeit zwar sehr unterschiedlich, aber sie dürfen letztlich das Gleiche tun, dann benötigt es auch nur eine Rolle für beide – es sei denn, ihre Tätigkeit ist sehr verschiedenen Unternehmensbereichen zugeordnet. Dann sollten ebenfalls zwei verschiedene Rollen definiert werden. Schließlich kann ja eine reale Person auch mehrere Rollen ausfüllen (beispielsweise Team-Leiterin, Vereinsschatzmeisterin, Mutter, Autofahrerin, Online-Kundin).

Rollen helfen somit auch, verschiedene Aufgaben und Aufgabengebiete klar voneinander zu trennen, auch wenn diese in der Praxis in einer Person zusammenfallen. Beispielsweise sind Web-Analyse, Controlling und Marketing drei verschiedene Aufgabengebiete, unabhängig davon, ob sie auf drei Abteilungen, drei Personen verteilt oder von einer Person in Personalunion erledigt werden.

Akteure nutzen

Je nach Software können mehrere Dutzend Akteure definiert werden. Die Menge der Akteure und deren Definitionen orientiert sich sowohl an der Realität als auch an den tatsächlichen Nutzerrechten. Mithilfe der Akteure werden im nächsten Schritt User-Storys und Use-Cases sowie Anwendungsfälle beschrieben.

Akteure eignen sich vor allem, um überschaubare Projekte oder Funktionalitäten zu beschreiben. Das Grob-Konzept einer Software oder Webseite oder bestimmte Kernabläufe beschreiben sich besser mit Personas und Szenarien. Aus diesen ergeben sich dann Einzel- oder Teilfunktionen. Während beispielsweise Personas die allgemeine Funktionsweise eines Webshop veranschaulichen, werden die konkreten (Teil-)Funktionen separat mithilfe von Akteuren beschrieben. Aus Persona-Sicht genügt es festzuhalten, dass Nutzer Produkte bewerten können. Aus Akteurssicht handelt es sich um einen in sich abgeschlossenen Vorgang, der als Anwendungsfall mit allen relevanten Details notiert wird.

Da es sich bei Akteuren/Rollen, User-Storys und Use-Cases um interne Dokumente mit letztlich technischem Charakter handelt, müssen diese nicht den political-correctness-Vorgaben in allen Aspekten entsprechen – sie sollen vor allem gut lesbar und schnell erfassbar sein. Beispielsweise ist es effizient, „der Kunde“ oder „der Nutzer“ zu schreiben, einige Use-Cases oder User-Storys können bewusst feminin formuliert werden, wenn diese aufgrund der Zielgruppe oder bekannter Nutzungen eher weibliche Personen betreffen. Werden beispielsweise Anwendungsfälle für Baby-Sachen in einem Webshop tendenziell öfter von Frauen genutzt, ist es hilfreich, von „Kundin“, „Besucherin“ oder „Nutzerin“ zu sprechen. Dadurch ist in allen Folge-Schritten klar, dass die Bedürfnisse von Frauen besonders zu berücksichtigen sind. Ansonsten verschlechtern Sätze wie „Der Kunde/die Kundin kann seine/ihre getätigten Bestellungen in seinem/ihrem Kundenkonto aufrufen“ die Lesbarkeit und sind wenig hilfreich. Aus solchen Aussagen sollen die Beteiligten vor allem ableiten, welche Funktionen benötigt werden, dafür ist ist die Präzisierung des Geschlechts nicht hilfreich.

Rollen in Usability-Projekten

Um arbeitsteilige Prozesse – wie das Entwickeln einer „User Experience“ oder Usability – zu beschreiben, sind Akteure und Rollen ebenfalls geeignet. Dabei kann ein Akteur einer Person oder einer Personengruppe entsprechen. Manche dieser Rollen überlagern sich auch, sodass eine Person zwei oder gar drei Rollen im Rahmen eines Projektes übernimmt:

Auftraggeber: definiert die Basis-Anforderung für eine Software oder Webseite

  • Zielgruppe und Personas
  • Basis-Funktionalitäten anhand von User-Storys und/oder Use-Cases
  • Ressourcen und Zeitraum, organisatorische Rahmenbedingungen
  • Prioritäten

Projektleiter: Stellvertreter des Auftraggebers im Alltag gegenüber den anderen Akteuren (auf Detail-Level)

  • vereinbart mit dem Auftraggeber (ggf. in einem Workshop gemeinsam mit anderen Akteuren) den Umfang anhand von Personas und User-Storys
  • leitet gemeinsam mit umsetzenden Akteuren (und/oder ggf. anderen) die Akteure und Use-Cases sowie Anwendungsfälle ab
  • dokumentiert Personas, User-Storys, Akteure/Rollen, Use-Cases und Anwendungsfälle
  • koordiniert die Umsetzung, sorgt für reibungslosen Ablauf, besorgt nötige Zuarbeiten
  • sorgt für rechtzeitiges Testen und Erfüllen der Anwendungsfälle und Use-Cases
  • verwaltet das Budget und die Ressourcen und achtet auf Einhaltung
  • achtet gemeinsam mit Usability-Experte auf Einhalten der gesetzlichen Verordnungen, Befolgung der Normen

Usability-Experte: definiert den konkreten Ablauf der Anwendungsfälle aus Nutzersicht

  • multidisziplinär, aktiv in alle fachlichen Bereiche vernetzt (u.a. Marketing, Design und Entwickler)
  • berücksichtigt technische, fachliche und ästhetische Erfordernisse
  • definiert das Set der Interaktionsformen und Interaktionsmöglichkeiten für die Software bzw. Webseite („Grammatik“, Guidelines für das User-Interface)
  • verwendet die optischen Bausteine des Standards oder definiert mit dem Designer, welche noch konkret zu erarbeiten sind
  • organisiert Tests und leitet ggf. daraus Änderungen ab
  • befolgt Normen, orientiert sich an Regelsammlungen, User-Interface-Patterns, Best-Practice-„Standards“
  • moderiert zwischen den verschiedenen Ansprüchen und Erwartungen

Designer: erarbeitet die konkrete Erscheinung

  • definiert Styleguide und arbeitet aktiv daran, diesen auf die Software oder Webseite anzuwenden und überwacht dessen korrekte Anwendung
  • orientiert sich am Corporate Design, gestalterischen bzw. ästhetischen Vorgaben des Auftraggebers (v.a. in Bezug auf die Zielgruppe)
  • liefert grafische Entwürfe für bestimmte Ansichten oder benötigte Elemente: Icons/Symbole, Logos, angepasstes Aussehen von Standard-Elementen (v.a. bei Webseiten)
  • wird nur benötigt, wenn das Standard-Set an optischen Bausteinen nicht genügt (diese Abwägung trifft er gemeinsam mit Usability-Experte und Projektleiter oder Auftraggeber)

User-Interface-Designer: Misch-Akteur, der Aufgaben des Usability-Experten, Designers und Entwicklers übernimmt; der Fokus liegt dabei weniger auf Design und Umsetzung als vielmehr auf der Schaffung einer Bedienung, die eine gute Usability aufweist

Entwickler: setzt die funktionalen Anforderungen im Design um

  • wird bereits in der Prototyping-Phase aktiv eingebunden bzw. übernimmt Umsetzungsaufgaben in dieser Phase
  • formuliert nicht-funktionale Anforderungen (v.a. technische Grenzen)
  • in der Praxis oft als Entwicklerteam oder -abteilung mit CTO (Chief Technical Officer) oder Software-Architekt anzutreffen, insbesondere Personen mit breitem technischen Know-how werden möglichst früh eingebunden, um Lösungsansätze auf Realisierbarkeit zu prüfen oder gemeinsam Ideen zu entwickeln

Fachabteilungen: liefern benötigte Zusatzinformationen oder benötigen Zwischenergebnisse für ihre Arbeit

  • unterstützen bei der Erstellung der Personas, User-Storys und Use-Cases
  • gehören sie selbst zur Zielgruppe stehen sie für Interviews zur Verfügung und/oder ermöglichen die Erfassung ihrer Anforderungen durch Vor-Ort-Beobachtungen und Inquiries
  • dazu gehören alle Abteilungen, auf deren Arbeit die Software oder Webseite einen direkten oder indirekten Einfluss hat, beispielsweise:
    • Marketing, Marktforschung, Produktmanagement, Reporting: Erfolgsmessung, Aufspüren von Stellen mit Handlungsbedarf, Erdenken neuer Funktionen und Produkte, Erstellen von PR- und Werbematerialien (verspricht nur, was die Software oder Webseite auch einlöst)
    • Controlling: Auswertung der Ist-Situation und Benennung von Problemstellen, Risikobewertung für künftige Projekte
    • Kundenbetreuung/Support und Vertrieb: Sammlung von Problemfällen und Nutzerhinweisen, Schulung für neue Software oder Webseite, Unterstützung bei der Anforderungserfassung (quasi Vertretung der Kundeninteressen bei Workshops oder später internen Tests)

Nutzer: alle Personen, die die Software oder Webseite später nutzen sollen

  • für bestimmte Ziele, Aufgaben
  • mit eigenen oder fremden Motivationen
  • in bestimmten Kontexten (Prozesse, Umfeld, Situationen, etc.)

Besucher: (Sonderfall von Nutzern für Webseiten) alle Personen, die eine bestimmte Webseite aufsuchen oder auf diese gelangen

Kunde: (Sonderfall von Besuchern für Webseiten) alle Personen, die in einem Webshop eine tatsächliche Kaufabsicht hegen und gewillt sind, diese umzusetzen

Tester: Personen, die anhand von Aufgaben oder Szenarien die Nutzung der Software oder Webseite vornehmen

  • neben den tatsächlichen Ergebnissen werden auch Daten über den Test\-ablauf erfasst, z.B. lautes Denken, Eye-Tracking, Mausbewegungen, Frage- oder Evaluierungsbogen
  • Tests werden – je nach Fokus – entweder mit Prototypen, Alpha- oder Beta-Versionen oder der fertigen Software oder Webseite durchgeführt

Autor:  bei LinkedIn