digitalien.org — Stefan Knecht

Search

Personas und Use Case beschreiben

Personas sind stilisierte, prototypische und idealisierte Nutzertypen, die mit demografischen Merkmalen und lebendig in ihrer Nutzungssituation (Use Cases) beschrieben werden.

Personas sind keine Fingerübung sondern ein Schritt und Werkzeug zur Klärung der Frage: »Wessen Verhalten wird wie und wodurch geändert?«​

Nützlich sind Personas, wenn viele Annahmen über amorphe, nur unscharf bekannte Nutzergruppen getroffen werden müssen weil die wahren Nutzer nicht direkt befragt oder beobachtet werden können. Oder wenn das zwar möglich wäre, doch der Aufwand gescheut wird.

So praktisch die Modellierung von Nutzern ist: nichts ist besser als reale Nutzer mit beobachtbaren Eigenschaften.

Eine Warnung dazu ist weiter unten.

»Wessen Verhalten wird wie und wodurch geändert?«

Sicherlich gibt es Anforderungsanalysen und daraus abgeleitete Produktfeatures. Es käme ja kaum jemand auf die Idee, ins Blaue hinein und nicht datengetrieben Features zu entwickeln. 

Die Frage »Wessen Verhalten wird in welcher Weise durch dieses Deliverable, Feature, Aktivität geändert?« ist der Lackmustest für die Nützlichkeit jedes einzelnen Feature.

Ja, diese immer gleiche Frage ständig erneut zu stellen, kann nervtötend sein. Es nutzt aber nichts, die Alternative ist: nicht fragen, weiter im Dunklen tappen und Aufwand, Zeit, Herzblut in etwas zu investieren, das keinen Unterschied macht.

Glauben statt Wissen wollen Sie noch viel weniger?

Spezifische Nutzer(gruppen) beschreiben​

Akteure beschreiben, so spezifisch sein wie es möglich ist: generische Formulierungen wie “die Nutzer” sind zu allgemein und ein Warnsignal dafür, dass die Motive von Nutzern noch nicht hinreichend durchdrungen sind. Es mag viele verschiedene Nutzertypen und Bedürfnisse geben. Welche?

Auch sind selten alle identifizierten Nutzertypen gleichermassen ausschlaggebend um das ausgewählte Geschäftsziel zu bedienen. Welche sind genau gemeint? Ja, das penible Differenzieren von Nutzertypen und Use Cases ist aufwändig … nicht zu differenzieren ist one-size-fits-all: das ist nicht realistisch.

Drei Akteurtypen betrachten

Alistair Cockburn Alistair Cockburn rät, drei Typen von Akteuren zu betrachten:

  1. Primäre Akteure, deren Ziele erfüllt werden
    (Bsp.: unter-18-jährige Nutzer einer Gaming-Plattform haben Freude an Spielen und Wettbewerb)
  2. Sekundäre Akteure, die in das Produkt/Lösung integrierte Dienste oder Zulieferungen bereitstellen
    (Bsp.: Sicherheitstechniker einer Gaming-Plattform interessiert die robuste Authentifizierung von Nutzern)
  3. off-stage Akteure, die am Verhalten von Nutzern/Kunden interessiert sind, aber weder Dienste bereitstellen noch vom Produkt profitieren
    (Bsp.: die FSK prüft die Einhaltung des Jugendschutzes einer Gaming-Plattform)

Atypische Use Cases erforschen​

Anekdote: Discord war ursprünglich gedacht als Vehikel um Gamern während des Spieles unkompliziert die Möglichkeit zu geben, miteinander zu sprechen, weil das Tippen im Chat zu umständlich war. Die Entwickler erwarteten nicht, dass ihre Plattform als schnelle und robuste Alternative für die peer-to-peer Kommunikation auch ausserhalb hitziger Onlinegaming-Momente entdeckt würde.

Nach dem Wer? nun zum Wie? Wie soll das Verhalten welches Akteur geändert werden?

Wie sollen welche Akteure helfen, das Ziel zu erreichen, was genau sollen sie tun oder unterlassen?

Erinnerung: erst jetzt passiert wirklich etwas: Menschen ändern Verhalten — das ist der Impact, die Konsequenz, die hilft, ein Ziel zu erreichen.

Verhalten in vier Merkmalen betrachten

Etwas spitzfindiger hat ‘Verhalten’ vier Ausprägungen:

  1. anfangen, etwas zu tun
  2. aufhören, etwas zu tun
  3. etwas anders tun
  4. verhindern, etwas zu tun

Die erwünschten Impacts/Verhaltensformen bilden die zweite Ebene der Impact Map. Verhaltensformen können und werden miteinander konkurrieren oder im Widerspruch stehen, manche werden sich überlappen. 

Es werden diejenigen Verhaltensformen identifiziert, die am Einfachsten, mit dem geringsten Aufwand und Komplexität das Ziel erfüllen helfen.

Es müssen natürlich nicht alle Impacts in der Lösung auch umgesetzt werden. Die Kunst ist jene zu finden, die einen wirkungsvollen, effizienten Hebel zum Ziel darstellen.

Personas? Prima, solange keine realen Daten verfügbar sind

Personas sind hilfreich, so lange nichts Besseres und keine realen Daten bereit stehen.

Doch Achtung — Vereinfachungen haben einen Preis:

Personas sind ein latentes Risiko, komplexes menschliches Verhalten zu stark und scherenschnittartig zu vereinfachen. 

Ingrid Domingues warnt eindrücklich davor, Personas mit ‘der richtigen Welt’ zu verwechseln:

Ingrid Domingues
Ingrid Domingues

Demographically biased personas hinder our ability to understand the really important user behaviours, needs and expectations in the context of use. By dressing users up with demographics and photos, personas cause readers to fill in with their own assumptions. If you want to accomplish intentional design – design that makes impact – it's about time you ditch the persona.​

Schon wieder sind es die Annahmen, die ungeprüft auf falsche Fährten locken können … und damit nicht anders, als die Annahmen, wie Nutzerverhalten oder impact über imaginierte Features zu erreichen seien.