Screenshot: www.uigarden.net
Kim Goodwin beschreibt in einem Artikel auf uigarden.net, wie man aus seiner Sicht am besten zu guten Personas kommt. Er ist General Manager, VP of Design bei Cooper und dort auch für die Seminare verantwortlich.
Anstatt mit Hilfe von Befragungen erhebt Kim Goodwin die für die Erstellung von realen Personas notwendigen Daten mit Hilfe von Beobachtung. Dazu testet er die Anwendung mit mehreren Anwendern und beobachtet sie dabei. Die Anzahl der Testpersonen macht er dabei von der Komplexität der Anwendung abhängig. Aus seiner Sicht sollten für eine einfache Anwendung 12 Personas ausreichen. Auf diese Weise findet er heraus, was für Probleme einzelne Anwender haben und was sie zufrieden macht.
A dozen hour-long interviews are usually sufficient for defining a simple consumer product, though it can take several dozen for a complex enterprise application. You’ll know you can stop interviewing when you can predict how each user will respond; this means patterns are beginning to emerge.
Nachdem alle Testsessions durchgeführt sind, leitet er aus den Beobachtungen Verhaltensvariablen ab z.B. serviceorientiert, preisorientiert und listet sie in Form von Skalen auf. Demographische Eigenschaften von Testpersonen berücksichtigt er dabei, wenn sie Einfluss auf die Verhaltensvariablen haben. Danach zeichnet er die verschiedenen Interviews bzw. Testpersonen auf den Skalen ein.
Bei der Analyse sucht er nach den Testpersonen, die sich 6 bis 8 Verhaltensvariablen bzw. demographische Eigenschaften teilen. Diese Sets stellen Verhaltens- bzw. Eigenschaftsmuster dar und sind die Grundlage für die Erstellung einer Persona.
Danach geht er wie üblich vor und gestaltet die einzelnen Personas mit Nutzungskontext, Eckpunkten zum typischen Alltag, Frustrations- und Zufriedenheitsfaktoren aus. Kim Goodwin bevorzugt dabei eine erzählerische Beschreibung anstatt der Auflistung von Eigenschaften.
One or two bits of personality can bring an otherwise dull persona to life, but too much biography will be distracting and will make the persona less credible as an analytical tool. If every aspect of the description can’t be tied back to real data, it’s not a persona—it’s a creative writing project that should not be used for making critical design and business decisions.
Man kann zwischen zwei Persona-Ansätze unterscheiden, deren wesentlicher Unterschied liegt in der Art der Sammlung der Daten, welche als Grundlage für die Beschreibung der Personas dienen. Personas können „real“ im Sinne von Cooper oder „realistisch“ im Sinne von Norman sein. Realistische Personas werden in Gesprächen bzw. Workshops mit Verantwortlichen aus den Bereichen Entwicklung, Marketing und Kundenbetreuung erarbeitet. Realistische Personas spiegeln mit kurzen Beschreibungen die subjektive Wahrnehmung des Unternehmens wider. Sie eignen sich um das in einem Unternehmen vorhandene Anwenderwissen zu sammeln (IST-Personas) und die Anwender zu beschreiben, die bei der Entwicklung addressiert werden sollen (SOLL-Personas).
Reale Personas basieren auf qualitativen und quantitativen Daten aus Markt- und Anwenderforschung. Sie bilden mit detaillierten Beschreibungen die Zielgruppe möglichst exakt ab. Sie eigenen sich besonders um reale IST-Personas, d.h. die Anwender, die bereits das Produkt verwenden, zu beschreiben.
Die Analyse von Verhaltensmustern mit Hilfe von Skalen scheint mir ein hilfreiches Mittel zu sein, um Muster in den verschiedenen Eigenschaften der befragten Anwender zu entdecken. Es könnte auch hilfreich sein, um die Erstellung von realistischen Personas insbesondere SOLL-Personas zu unterstützen, da es visualisiert welche Eigenschaften für die Entwicklung relevant sind und den Persona-Workshops auf diese fokussiert.
Siehe auch:
Getting from Research to Personas: Harnessing the Power of Data
Key steps in creating your reader persona
