Die Verwendung von Personas war unter Designern und Fachleuten der Branche schon immer umstritten. In letzter Zeit drängten jedoch einige Praktiker auf diesem Gebiet auf den Ersatz des Persona-Methode für die noch zu erledigende Aufgaben (JTBD) Rahmen.
Eine sorgfältige Analyse sowohl der Persona- als auch der JTBD-Methode, zusammen mit den Erkenntnissen aus der Praxis vor Ort, lässt mich glauben, dass es zwar einige Probleme mit der Persona-Methode gibt, diese Technik jedoch bei einigen kritischen Aspekten des Designs hilft, die die JTBD-Methode nicht abdecken kann.
Ab diesem Punkt kommen mir ein paar Fragen in den Sinn: Welche ist die beste Methode? Sollten Sie von Personas zu JTBD wechseln?
Um das Beste aus jedem zusammenzuführen, Ein möglicher Ansatz besteht darin, beide Techniken zusammenzuführen, was zu einer Hybridlösung führt.
Jobs to be done ist ein Framework, das zur Definition des Produktumfangs, seiner Anforderungen oder der Marketingpositionierung verwendet werden kann. Es basiert auf der Prämisse, dass, wenn eine Person ein Produkt oder eine Dienstleistung kauft, diese Person es nicht wirklich kauft, sondern es anstellt, um einen bestimmten Job auszuführen: Die Leute wollen keinen Viertelzoll-Bohrer, sie wollen ein Viertel-Zoll-Loch.
Zusammengefasst besteht eine zu erledigende Aufgabe darin vier Hauptaspekte:
Im ersten Schritt, der Ausstellung, wird der Kontext des Produkts vorgestellt und kurz erklärt, wer, was, wann und wo (aber nicht das Warum).
Im Beobachtungsschritt wird das aktuelle und vergangene Nutzerverhalten identifiziert — nämlich welche Produkte sie verwenden.
Die Situationsanalyse befasst sich mit den Motivationen und Ängsten der Nutzer und erklärt die Herausforderungen, vor denen die Kunden stehen, und was sie zu unterschiedlichen Lösungen drängt.
Schließlich geht es bei der Arbeit, die selbst erledigt werden muss, um das gewünschte Ergebnis, das der Benutzer sucht. Es sollte keine Lösung — weder ein Produkt, eine Funktion oder eine Anforderung — präsentiert werden, sondern stattdessen eine Beschreibung dessen, was der Benutzer auf einer höheren Ebene erreichen sollte.
Diese Methode wird oft als besser geeignet als Personas für die Produktentwicklung angesehen, da sie ergebnisorientiert, objektiv und messbar.
Es gibt viele Herangehensweisen, die für Personas verwendet werden können. Manche sind ziemlich arm, während andere gerade genug tun, um akzeptiert zu werden. In beiden Fällen dienen sie nur bestimmten Zwecken, zu denen Produktdesign und -entwicklung nicht gehören sollten.
Lose definierte Personas sind eine Technik, um Benutzer zu modellieren. Sie sind Archetypen, formalisiert als fiktive — aber realistische — Charaktere. Während viele Designer behaupten, Personas zu verwenden, stellen wir bei der Analyse ihrer Praxis fest, dass das, was als „Personas“ bezeichnet wird, eine Reihe sehr unterschiedlicher Materialien umfasst.
Die Informationen, die eine Persona konfiguriert, ändern sich erheblich von einem Designer zum anderen.und so ändert sich natürlich auch das Potenzial dieser Technik. Wenn wir die verschiedenen Arten, Personas zu erstellen, genau beobachten, können wir vier verschiedene Typen identifizieren:
Die erste Art von Persona ist eigentlich keine Persona, sondern eine Proto-Persona und alle folgenden Arten von Personas können sich als echte Persona oder Proto-Persona herausstellen.
Proto-Personas basieren nicht auf tatsächlichen Recherchen, sondern auf Annahmen über die Nutzer. Diese Art von Persona erfordert, dass die Personen, die an der Erstellung beteiligt sind, aufschlussreiches Wissen über die tatsächlichen Benutzer haben. Sie sollten sie nicht nur von Designern oder Ingenieuren erledigen lassen, sondern stattdessen beispielsweise Mitarbeiter der Kundendienstabteilung mit an den Tisch setzen.
Proto-Personas sollten nur als erster Schritt für die weitere Nutzerforschung verwendet werden, aber niemals als Grundlage für die Definition der Produktanforderungen.
Die zweite Art von Personas, die wir identifizieren können, ist die Empathie-Personas. Diese sind basiert auf der Hintergrundgeschichte einer Person (eine Erzählung über das Leben und den Kontext der Person) normalerweise mit einem Namen, Alter, Foto und Zitat.
Diese Art von Persona kann nützlich sein, um Empathie im Entwicklungsteam zu wecken und ihnen zu helfen, während des Projekts motiviert zu bleiben.
Fachleute, die keinen regelmäßigen Kundenkontakt haben, verlieren möglicherweise den Überblick über den Nutzen und die Relevanz des Produkts. In diesem Fall Jemanden zu kennen, für den das Produkt einen Unterschied machen wird, kann ihm helfen, seine Bemühungen in einem höheren Kontext zu verstehen.
Letztlich nützt diese Art von Persona wenig bis gar nichts, wenn es darum geht, die Produktanforderungen und den Projektplan festzulegen.
Die dritte Art von Personas, die wir identifizieren können, ist die Marketing/Demografie Personas.
Das Schlimmste, was passieren kann, wenn eine Empathie-Persona für andere Ziele als die oben aufgeführten verwendet wird, ist, dass es sich als Zeitverschwendung herausstellen könnte, Die Marketing-/demografischen Personas können Ihrer Produktentwicklung wirklich schaden (vor allem, wenn wir über Marketing-Proto-Personas sprechen).
Marketing-Personas konzentrieren sich auf Demografie, um die Wurzeln des Verhaltens und der Wünsche des Benutzers in diesen Daten zu finden.
Dies ist die Art von Personas, gegen die sich die meisten Verteidiger, die ihre Arbeit erledigen müssen, stellen, da es keine echte Kausalität zwischen Demografie, Zielen und Verhaltensweisen gibt. Die identifizierten Muster sind in der Regel das Ergebnis von Vorurteilen und Stereotypen.
Dieser vierte Ansatz, benannt zielorientierte/designorientierte Personas, verbannt die Hintergrundgeschichte und die Demografie der Persona in einen sekundären Plan und konzentriert sich auf Ziele und Bedürfnisse.
Diese Personas identifizieren spezifisch Lebensziele, Erfahrungsziele und Endziele sowie Bedürfnisse, Frustrationen und Verhaltensweisen. Diese Art von Persona kommt der Methodik der zu erledigenden Aufgaben sehr nahe und bewahrt gleichzeitig einige Eigenschaften, die den Personas einen Teil ihrer Macht verleihen. Eine, die über die Schaffung von Empathie hinausgeht, um das Team zu motivieren.
Wenn Sie mehr über zielorientierte Personas erfahren möchten, empfehle ich Ihnen, Alan Coopers Buch zu lesen Über Face.
Betrachtet man die Kritiker von Intercom, zum Beispiel, eine der prominentesten Stimmen zur Verteidigung von JTBD und gegen Personas, präsentieren uns die folgende User Story, die auf einer Persona basiert:
„Als 35-jähriger Mann namens Peter möchte ich etwas Leckeres essen, wenn ich Hunger habe, damit ich mich nicht mehr hungrig fühle“.
Wir könnten der Kritikerin nur zustimmen, wenn sie darauf hinweist, dass der erste Teil „Als 35 Jahre alter Mann namens Peter...“ irrelevant ist - da es keine Kausalität zwischen diesen Daten und dem letzten Teil des Satzes gibt - Dies ist ein Beispiel für eine Persona-Methode, die User Stories und keine User Journeys verwendet.
Deshalb, wie wir sehen, Dieses Argument gilt nur für Marketing-Personas und nicht für zielorientierte/Design-Personas.
Wenn es eine zielorientierte Person wäre, sähe die Geschichte anders aus:
“ Als älterer Chronikpatient, der den Ruhestand am meisten genießen möchte, möchte ich jederzeit problemlos meinen Arzt kontaktieren können, damit ich mich mit meinem Gesundheitszustand wohl fühlen kann.“
Es würden nur demografische Daten erwähnt, die in einem Kausalzusammenhang mit den Zielen der Persona stehen und sich auf das gewünschte Ergebnis konzentrieren würden., was es der zu erledigenden Aufgabe sehr ähnlich macht.
Immer noch auf der Kritiker von Intercom, bei der Präsentation des äquivalenten JTBD wird das folgende Beispiel gegeben:
„Wenn ich zwischen den Treffen nur 2 Minuten Zeit habe, um den Hunger zu stillen, möchte ich mir etwas schnappen, das schnell und einfach ist.“
Aber was ist „einfach“?
Dinge wie „einfach“ oder „angenehm“ sind subjektive Attribute, sie betreffen nicht das Produkt selbst, sondern die Erfahrung des Benutzers mit dem Produkt, da sie vollständig von den Eigenschaften des Benutzers abhängen.
Das bedeutet, dass es unmöglich ist, diese Attribute auszuwerten, ohne ein Benutzerprofil zu haben.. Konkret zum Beispiel Erfahrungsziele, Fachwissen, Wissen, intellektuelle und motorische Fähigkeiten.
Nehmen wir an, das JTBD soll „einen Ort haben, an dem ich meine Dateien so speichern kann, dass sie leicht zu finden sind“. In Bezug auf das Design kann sich dies in einer hierarchischen und gut organisierten Ordnerstruktur oder in einem einfachen Repository-Ordner mit einem Suchfeld widerspiegeln.
Dies bringt uns zu drei häufigen Fallstricken bei Projekten, die Personas möglicherweise vermeiden können, JTBD jedoch nicht: der elastische Benutzer, das selbstreferentielle Design und die Randfälle.
Wenn wir den Begriff „Benutzer“ nicht erklären, wird er problematisch, wenn er auf bestimmte Designprobleme angewendet wird. Jeder in einem Produktteam hat seine eigenen Vorstellungen, wenn es um Produktentscheidungen geht, und so wird dieser „Benutzer“ elastisch, bequem gebeugt und gestreckt, um den Meinungen und Annahmen der Redner zu entsprechen.
Bei Designentscheidungen kann ein bestimmtes Produkt als „einfach für den Benutzer“ und das nächste Produkt mit der gleichen Komplexität als „zu schwierig für den Benutzer“ angesehen werden.
Unweigerlich fallen Dinge hinein ein selbstreferentieller Prozess entweder mit Designern oder Kunden, je nachdem, wer bei dem Projekt mehr Entscheidungsbefugnis hat, und trifft letztendlich Entscheidungen auf der Grundlage ihres Geschmacks und ihrer Vorlieben.
Auf die gleiche Weise „einfach“, „angenehm“ und „schön“ sind subjektive Begriffe, ebenso wie „wichtig“. Sobald Sie anfangen, über die verschiedenen Aufgaben nachzudenken, die für das Produkt zu erledigen sind, werden Sie wahrscheinlich mit einer Liste enden, für deren vollständige Entwicklung Sie weder Zeit noch Budget haben werden.
Selbst wenn Sie das Budget haben, müssen Sie wissen, wo Sie anfangen sollen. Informationen wie oft eine Persona eine bestimmte Aktion ausführt, helfen sehr, wenn es darum geht, Funktionen zu priorisieren.
Die Methode „Jobs to be done“ erweist sich als sehr nützlich, um das „Was“ eines Produkts herauszufinden, aber sie gibt nicht viel Aufschluss über das „Wie“. Allerdings Die Benutzer sind ebenso besorgt über das Erreichen des Ziels wie über den Prozess, um es zu erreichen.
Darum geht es beim User Experience Design. Die Geradlinigkeit des JTBD ist verlockend, aber sie fällt auf die ingenieurwissenschaftliche Denkweise von Universalität und Objektivität zurück. und es ignoriert, dass es erstens verschiedene Möglichkeiten gibt, dasselbe Ziel zu erreichen, und dass zweitens Nutzer sind emotionale Wesen, die mehr wollen als das Erreichen objektiver Ziele.
Sind zielorientierte Personas die Antwort? Das kann ich nicht mit Sicherheit sagen. In unserer Praxis finden wir immer noch einige Probleme mit dieser Methode. Demografie und Hintergrundinformationen werden zwar in den zweiten Plan verbannt, sind aber immer noch präsent, was zu einigen Problemen führt.
Sie sind als Kommunikationsinstrument zwischen dem gesamten Team gedacht, aber Personas werden von Menschen mit unterschiedlichem Hintergrund bearbeitet, von Entwicklern bis hin zu Kunden, und es kommt oft vor, dass nicht jeder an diesem Prozess der Dekonstruktion der Rolle der Demografie beteiligt ist.
Davon abgesehen erweisen sich diese Eigenschaften oft als erhebliche Ablenkungen. Die Entwickler verlieren sich ein wenig in den Personas, sind sich ihrer Bedeutung für die Implementierungsarbeit nicht bewusst und haben Schwierigkeiten, die relevanten Informationen zu erfassen.
Außerdem haben Kunden manchmal Schwierigkeiten, sich von Vorurteilen darüber zu distanzieren, wie diese „alleinstehende und schüchterne“ Bevölkerungsgruppe in der Persona mit Dingen wie dem Aussehen und der Haptik des Produkts zusammenhängt.
Wenn du die Persona als Er bezeichnest, wirst du Schwierigkeiten haben zu erklären, warum Lavendel immer noch die beste Farbe für dein Interface ist, da das Erlebnisziel der Persona darin besteht, sich ruhig, entspannt und luxuriös zu fühlen.
Wie schaffen wir unter Abwägung beider Optionen einen Charakter, mit dem sich die Teammitglieder identifizieren können, der als die Person angesehen wird, deren Meinung im Entscheidungsprozess am wichtigsten sein sollte, und Stereotypen und Vorurteile im Zusammenhang mit der Profilerstellung vermieden werden?
Eine mögliche Lösung besteht darin, sowohl die Persona- als auch die JTBD-Methode zusammenzuführen. Entwickeln Sie Personas, aber auf eine Weise, die den zu erledigenden Aufgaben näher kommt:
Der Name „zu erledigende Aufgabe“ bringt die Menschen leicht dazu, über Lösungen nachzudenken und nicht über die gewünschten Ergebnisse aus der Sicht des Benutzers. Dies ist zu diesem Zeitpunkt des Design-Thinking-Prozesses, an dem noch keine Designlösungen untersucht und entworfen wurden, verfrüht.
Außerdem ist für jemanden, der mit der JTBD-Methode nicht vertraut ist, nicht klar, worum es bei Beobachtung und Situationsanalyse geht und was der Unterschied zwischen ihnen ist.
Es gibt keine perfekte Methode und wir sollten angesichts aller Methoden eine kritische Haltung einnehmen, wobei anerkannt wird, dass einige Projekte (oder einige Kunden und Teams) besser mit einer Methode bedient werden können, die einer Methode näher kommt, und anderen Projekten/Kunden/Teams mit einer anderen Methode.
Letztlich sollten Methodiken vor allem mit einer flexiblen Denkweise konfrontiert werden, die eher als Richtlinien denn als starre Vorschriften betrachtet wird.. Verbesserungspotenzial sollte immer anerkannt werden.
Einfach ausgedrückt: Sie sollten keine Angst davor haben, Innovationen so zu entwickeln, dass sie besser zu Ihrem Produkt, Ihren Teams und Ihren beruflichen Fähigkeiten passen.
Bei Imaginary Cloud wir haben ein Expertenteam für UI- und UX-Design. Wenn Sie der Meinung sind, dass Sie Hilfe beim Design gebrauchen könnten, schreiben Sie uns hier!
Fanden Sie diesen Artikel hilfreich? Diese könnten dir auch gefallen!
Mit 10 Jahren Erfahrung und einem Hintergrund in der Kognitionswissenschaft. Ich bin begeistert von inklusivem Design und ruhiger Technologie.
People who read this post, also found these interesting:
