Schlagwort-Archiv: Personas

chi2016: User Research to Inform Product Design: Turning Failure into Small Successes

Forrester Research und NANMANN berichten in ihrem Beitrag von einem fehlgeschlagenen UI Design-Projekt, welches sich durch Personas in einen kleinen Erfolg verwandelte. Zum Hintergrund: Forrester Research ist ein Unternehmen, welches Analysen und Berichte an Unternehmen verkauft. Vor einiger Zeit wurde das Geschäft von Berichten und Excel-Tabellen hin zu Dashboards erweitert. Die Hoffnung war, dass Dashboards eine interaktive Aufbereitung bieten, die Anwendern dabei hilft die Daten besser zu verstehen und den Lieferprozess für die Analysen und Berichte vereinfacht.

Leider trafen die entwickelten Dashboards die Kundenaforderungen nicht richtig, so dass nach einem Jahr nur 25% der Kunden Dashboards nutzten. Also wurden zwei UX Professionals (1x von intern und 1x von extern) beauftragt, die Probleme zu identifizieren und zu lösen. Die Analyse ergab 3 grundlegende Probleme: Die Ziele der Nutzer wurden mit den Dashboards nicht adressiert. Es war weder eine vergleichende Auswertung der Daten noch eine tiefe Analyse der Daten möglich. Die UX Pros sollten nun diese Probleme lösen. Wichtig zu wissen: Sie waren nicht Teil des Entwicklungsteams, sondern mussten von außen über Empfehlungen versuchen eine Verbesserung zu erreichen.

Also veranstalteten sie mit dem Entwicklungsteam für Dashboards einen Kickoff und versuchten es für ihre Analyse sowie ihr Vorgehen zu gewinnen. Es wurden 6 Interviews mit Dashboard-Nutzern durchgeführt. Das gesamte Entwicklungsteam nahm an den Interviews teil und analysierte sowie dokumentierte die Ergebnisse. Die zu Beginn erkannten Probleme wurden bestätigt. Außerdem bewerteten die Kunden Dashboards als unwichtig. Aus den Interviews wurden 3 relativ einfache Vorschläge entwickelt. Die Änderungen waren zwar einfach, wirkten sich aber bis in die Informationsarchitektur und auf die Anzahl der Dashboards aus. Die Empfehlungen wurden zwar vom Entwicklungsteam positiv aufgenommen, nicht aber vom Produktmanagement. Diese waren mit den Veränderungen nicht einverstanden, die sie nach der Anzahl der Dashboards bonifiziert werden, die verkauft werden. Eine bessere Informationsarchitektur hätte eine geringer Anzahl und damit vermeintlich weniger Bonus für das Produktmanagement bedeutet. Das Produktmanagement beauftragte eine neue Studie und entschied sich gegen die Vorschläge. Aufgrund der heftigen Gegenwehr gab das Entwicklungsteam seine Bestrebungen die Dashboards zu verbessern auf. Die Veränderung war gescheitert.

Die UX Professionals sammelten als Projektabschluss die Erkenntnisse zusammen und dokumentierten sie in Form von Personas sowie Anforderungen. Überraschenderweise wurden dann diese Personas vom Dashboard-Entwicklungsteam unter der Hand wieder aufgegriffen. Sie wurden in die Arbeitsräume gehängt und als Orientierung für die Entwicklung verwendet. In Schwung kam das Ganze, als die eigenen Forrester-Analysten diese Personas als ein gutes Beispiel in einem öffentlichen Bericht aufgriffen. Eine Entwicklerin nahm das zum Anlaß ein anwenderorientiertes Dashboard auf Basis der Erkenntnisse aus dem gescheiterten Projekt zu entwickeln. Dies war so erfolgreich, dass ein Produktmanager mit seinem Team die Dashboards seit dem nach diesem Konzept erstellt. Heute nutzen über 50% der Nutzer die Dashboards und das obwohl einige Produktmanager noch immer die Erreichung ihrer persönlichen Ziele über die Unternehmensziele stellen.

Siehe auch

User Research to Inform Product Design: Turning Failure into Small Successes

Personas sind kein Allheilmittel

Personas sind eine beliebte und weit verbreitete Methode um zu ermitteln für welche Anwender ein Produkt entwickelt werden soll und um die Anwendersicht einfach in Designentscheidungen einfließen zu lassen. Es steht außer Frage, dass Personas dabei sehr gute Dienste leisten. Allerdings habe ich manchmal den Eindruck, dass Personas als Allheilmittel verstanden werden – getreu dem Motto „Nur mit Personas wird das Design gut.“. Ich habe in den letzten Jahren viele Projekte zur Erstellung von Personas betreut. Dabei bin ich zur Überzeugung gekommen, dass Personas in der Tat eine sehr nützliche Methode ist, wenn sich ein Team darauf einlässt. Es passiert aber auch immer wieder, dass Personas schlicht nicht funktionieren.
Aber mal von Anfang an. Warum macht man eigentlich Personas?
In der Praxis fehlt teilweise die genaue Kenntnis über die realen Anwender eines Produktes. Die fehlenden Erkenntnisse werden dann häufig durch subjektive Eindrücke (z.B. „Ich finde, wir sollten Sonnengelb nehmen. Mich spricht das an.“) oder logische Überlegungen (z.B. „Es könnte ja Anwender geben, die genau diese Funktion haben wollen.“) ersetzt. In dieser Situation kann es leicht passieren, dass wichtige Anwendergruppen einfach übersehen werden. Außerdem kann es leicht zu Missverständnissen hinsichtlich der Anwenderanforderungen kommen, da nicht alle im Entwicklungsteam das gleiche Verständnis über die Zielgruppe haben. Sehr oft zu beobachten ist, dass dieser Umstand in einer Überproduktion von Anforderungen mündet, d.h. es werden Funktionen erdacht, die niemand braucht.


Quelle: Microsoft/MSN

Personas setzen genau an dieser Stelle an. Sie sind archetypische Beschreibungen von Anwendern, welche wesentlichen Merkmale der Zielgruppe beschreiben. Durch Personas …
* entwickeln alle Projektbeteiligten ein gemeinsames Verständnis zur Zielgruppe.
* werden Missverständnisse vermieden.
* werden die Ziele und Bedürfnisse der Anwender in den Mittelpunkt von Anforderungsanalyse und Konzeption gerückt.
* lassen sich Designentscheidungen aus Anwendersicht treffen.
* lassen sich Anforderungen leichter priorisieren (Persona-Prioritätenmatrix).
* lassen sich Testpersonen für User Centered Design-Maßnahmen, wie z.B. Usability Testing, gezielter rekrutieren.


Persona-Prioritätenmatrix

Personas sind im Wesentlichen ein Kommunikationsmittel im Rahmen der Anforderungsanalyse und Konzeption.
Wenn es um die Erstellung von Personas geht, dann unterscheide ich die beiden Ansätzen „Reale Personas“ (nach Cooper) und „Realistische Personas“ (nach Norman). Reale Personas basieren auf repräsentativen Marktforschungsdaten und versuchen ein möglichst genaues Bild der Zielgruppe zu vermitteln. Bei der Erstellung von Personas ist häufig ein hoher Marktforschungsanteil notwendig. Daher sind reale Personas auch eine beliebte Empfehlung von UX Agenturen. Realistische Personas basieren auf der Idee, dass in vielen Unternehmen genügend Wissen über die eigene Zielgruppe vorhanden ist. Realistische Personas basieren daher meist auf Erfahrungswerten und Annahmen. Sie entstehen in der Regel durch Workshops in denen das Wissen zu den Anwendern aus den Sichten Vertreib, Marketing, Entwicklung und Service zusammengetragen wird. (Siehe dazu auch: Der Persona Workshop)
Meine Erfahrungen in den letzten Jahren haben mich darin bestätigt, dass der Ansatz „Realistische Personas“ nach Norman in den meisten Fällen der Richtige ist. Nur in den Fällen in denen kein Wissen zu den Anwendern vorliegt, ist die datenorientierte Herangehensweise nach Cooper sinnvoll.
Der wesentliche Grund für die Vorteile der realistischen Personas liegt im Wesen der Methode. Personas sind ein Kommunikationsmittel, welches seine Wirkung am besten entfaltet, wenn es in der Zusammenarbeit der Projektbeteiligten entsteht.
Zusammengefasst sprechen folgende Punkte für die Herangehensweise nach Norman:
* Kosten und Zeitaufwand für reale Personas stehen meist nicht im Verhältnis zum Nutzen.
* Das vorhandene Unternehmenswissen über IST-Anwender und die zukünftig angestrebte Zielgruppe wird genutzt. Durch die Beteiligung der Wissensträger entsteht eine höhere Akzeptanz der Personas.
* Realistische Personas lassen sich schnell und einfach erstellen.
* Der Erstellungsprozess von realistischen Personas fördert das gemeinsame Verständnis zur Anwenderschaft.
Nun aber zu dem Punkt warum Personas kein Allheilmittel sind. Wie gesagt: Es ist tatsächlich so, dass Personas oft gut funktionieren, aber eben nicht immer. Personas funktionieren nicht in jedem Projektteam. Aus Erfahrung funktionieren sie schlecht bis gar nicht, wenn …
* Der Projektleiter bzw. das Projektteam den Nutzen von Personas nicht erkannt hat.
* In einem Projektteam Designentscheidungen nur von der oberen Hierarchieebene getroffen werden.
* Das Projektteam nicht anwenderorientiert vorgeht und denkt.
* Sich das Projektteam oder einzelne Mitglieder nicht auf die Arbeit mit „nicht-existierenden“ Personen einlassen kann.
* Ein Persona-Verfechter im Team fehlt.
* Personas schlecht in den Entwicklungsalltag integriert werden. Beispielsweise schwer zugänglich abgelegt werden.
* Personas zu viele sinnlose oder irrelevante Informationen beinhalten und dadurch in der Praxis nicht anwendbar sind.
Wenn ihr also Personas einsetzen wollt, lohnt ein Blick auf diese Punkte, um zu erkennen, ob sich der Aufwand – auch wenn es nur ein kleiner ist – lohnt und welche Hindernisse zu erwarten sind.

Der Persona-Workshop: Realistische Personas mit wenig Aufwand erstellen

Nachdem ich in meinem Artikel Personas sind kein Allheilmittel den „realistischen“ Ansatz zur Erstellung von Personas nach Norman in den Vordergrund gestellt habe, möchte ich an dieser Stelle den Erstellungsprozess von „realistischen Personas“ erläutern.
Die Erstellung von „realistischen Personas“ geschieht in der Regel in drei Schritten: 1. Sammlung und Grobbeschreibung, 2. Detailbeschreibung, 3. Priorisierung.

Sammlung und Grobbeschreibung

Der Kern dieses Schrittes ist der Persona-Workshop. In diesem sammeln die Mitarbeiter eines Projektteams, die über Kenntnisse zur Zielgruppe verfügen, das Wissen zur Anwenderschaft und dokumentieren dieses in Form von groben Persona-Beschreibungen. In der Regel sollten dabei Mitarbeiter mit den Schwerpunkten Vertrieb, Marketing, Service, Produktmanagement und Entwicklung teilnehmen. Wichtig ist, dass möglichst alle Mitglieder des Projektteams dabei sind. Das verringert am Ende den Kommunikationsaufwand.
Der Persona-Workshop läuft in der Regel wie folgt ab:
Einleitung (ca. 15 min): Zu Beginn des Workshops wird vom Produktverantwortlichen das Ziel des Workshops vorgestellt und die Wichtigkeit betont.
Einführung in UCD (ca. 30min): Gerade in Teams, welche noch keine oder wenige Erfahrungen mit den Methoden des User Centered Design gemacht haben, ist eine Einführung in das User Centered Design sinnvoll. Dies dient unter anderem dazu den Stellenwert von Personas zu vermitteln und aufzuzeigen an welchen Stellen Personas im weiteren Entwicklungsvorgehen Verwendung finden.
Vorstellung der Methode „Personas“ (ca. 30 min): Hier geht es darum den Teammitgliedern, die noch keine Personas gemacht haben zu vermitteln, worum es bei der Methode geht. Inhalte des Vortrages sollten sein: Motivation für Personas, Erstellung von Personas, Verwendung von Personas, Integration in den Entwicklungsalltag.
Übung zu Personas (ca. 15 min): Dieser Schritt dient dazu Berührungsängste abzubauen und praktisch zu vermitteln, worauf es bei der Erstellung von Personas ankommt. Dazu sammeln alle Workshopteilnehmer zu einem möglichst produktfremden Thema ganz grobe Personas. Ich verwende dafür gern Themen, zu den möglichst viele etwas sagen können, wie z. B. Kaffeeautomaten oder Fahrscheinautomaten.
Sammlung der Personas (ca. 90 min): Die Gruppe wird in Kleingruppen a 3 Personen aufgeteilt. Jede dieser Gruppen sammelt ganz grob alle Personas, die ihnen zum Produkt einfallen.
Vorstellung der Personas und Gruppierung (ca. 30-60 min min je nach Anzahl der Kleingruppen): Jede Kleingruppe stellt in ca. 10 min die von ihnen gefundenen Personas allen Workshopteilnehmern kurz vor und gruppiert ihre Personas mit ähnlichen Personas der anderen Kleingruppen.
Zusammenfassung, Beschreibung und Bebilderung (ca. 90 min): Die gruppierten Personas werden in den Kleingruppen verteilt. Dabei erhalten die Kleingruppen je eine oder zwei Gruppen von gefundenen Personas. Aufgabe der Kleingruppen ist nun aus diesen Gruppen einzelne Personas abzuleiten sowie diese auszuformulieren und zu bebildern. Zur Bebilderung dienen entweder Zeitschriften oder Ausdrucke von Bildern aus einer Bilddatenbank.
Vorstellung der Personas (ca. 60 min je nach Anzahl der gefundenen Personas und Kleingruppen): Eine Person je Kleingruppe präsentiert die Personas auf einer Metaplanwand in 10 min. Die restlichen Teilnehmer wandern im Rotations- oder SpeedDating-Verfahren alle 10 min von Metaplan-Wand zu Metaplan-Wand. Durch dieses Verfahren lernen alle Teilnehmer die finalen Personas kennen und können noch kleinere Ergänzungen und Anmerkungen einbringen.


Quelle: Aufbau Persona-Workshop

Weiteres Vorgehen: Zum Abschluss des Workshops wird vereinbart, in welcher Form den Projektteilnehmern zur Verfügung gestellt werden und wie diese im Entwicklungsprozess verwendet werden sollen.
Das Ergebnis eines Persona-Workshops sind in der Regel handschriftliche Persona-Beschreibungen auf Metaplan-Wänden.

Detailbeschreibung

Im Nachgang des Workshops werden die Persona-Beschreibungen im Detail ausgearbeitet und in eine präsentier- bzw. verteilbare Form gebracht (Poster, A5-Kärtchen, Word-Dokumente). Bei den verwendeten Bildern sollte unbedingt darauf geachtet werden, dass nur Bilder verwendet werden, für die die Nutzungsrechte vorliegen. Ich verwende dafür aus Kostengründen meist günstige Bilder von http://www.istockphoto.com/.

Priorisierung

Die detaillierten Personas werden dann nochmals im Team präsentiert und in Zusammenhang mit den Anwendungsszenarien des Produktes priorisiert.


Persona-Prioritätenmatrix

Integration von Personas in den Entwicklungsprozess

Damit die Personas, welche in den Workshops entstanden sind, auch im Entwicklungsalltag funktionieren, sollten folgende Punkte beachtet werden:
* Alle Beteiligten müssen die Persona-Methode kennen, (auch die, die nicht an dem Workshop teilnehmen konnten)
* Die Anzahl der verwendeten Personas muss überschaubar sein,
(max. 10 Personas – ca. 2 Haupt- und ca. 8 Nebenpersonas)
* Die Beschreibung der Personas sollte auf das Notwendigste reduziert sein. Es sollten nur produktrelevante Informationen enthalten sein.
* Die Personas sollten allgegenwärtig kommuniziert werden, um so leicht zugänglich und erinnerbar zu werden, z.B. über Poster in Besprechungsräumen oder Kärtchen
* Alle Beteiligten sollte eine Kurzreferenz mit den Personas zur Verfügung gestellt bekommen (möglichst in Papierform),
* Personas sollten in Gesprächen wie bekannte real existierende Personen behandelt werden.
* Es muss min. eine Person im Projektteam geben, die vor allem am Anfang immer wieder die Personas ins Gespräch bringt.

Siehe auch

Personas sind kein Allheilmittel

Personas in Technology Product Design


Screenshot: adducive.com

Article by Brian Krause at adducive.com about Personas in Technology Product Design:
„People react emotionally to technology. An enthusiastic reaction results in blockbuster success like the iPod; the knack that Steve Jobs has for drawing people to Apple’s products explains his success. Unfortunately, reactions of frustration and irritation do not have correspondingly negative commercial consequences, at least not while there are so few choices that aren’t frustrating and irritating.
Specifically, the reaction we have to technology is guided by the reaction we would have to another person. Reeves and Nass demonstrated this in The Media Equation. They showed that even people who know how computers work are unable to keep themselves from assigning human traits to computer programs.
This is not surprising. We spend our lives learning how to get along not with technology, but with other people. It is a complex, endlessly fascinating activity that our brains and senses are quite well adapted to. Because of this experience, we can, from just a first impression, and with no effort, fill in all sorts of details and assumptions about someone we just met. Sometimes, this doesn’t serve us well and we act on stereotypes and unfair assumptions, but this ability is useful and essential to getting along with strangers and intimates alike.
(…)
Technology often seems like it was developed without thinking about people because it was. It seems more serious and efficient to focus on the technical challenges and hard data. That’s what business is, the engineering side, especially. Worrying about fictitious people seems like it’s not very intellectual, at least in a left-brain sense. Yet speculating about people engages some of the most well-developed and little-understood mechanisms of our brains. And besides, we can’t help it.“

Internetverweis

Personas in Technology Product Design