Personas sind zu einem „Klassiker“ in der User Research geworden. Protean regieren sie als Standardmesser für bewährte Praktiken in UX-Methoden. Auf der anderen Seite des Atlantiks präsentieren sich die Jobs-to-be-done jedoch als Herausforderer.

Und wenn Designer die Fragen stellen, die die Benutzererfahrung von morgen ausmachen, teilen wir die Früchte ihrer Überlegungen.
Somit Laubheimer Seite, UX-Spezialist bei Nielsen Norman Group, eröffnet die Debatte über Personas vs. Jobs-to-be-done. Hier ist die Übersetzung von sein Artikel.
Personas vs. Jobs-to-be-done
Jobs-to-be-done konzentriert sich auf die Schwierigkeiten und Bedürfnisse der Benutzer. Gut ausgeführte Personas hingegen enthalten zusätzliche Details über das Verhalten und die Einstellung von Benutzern.
Personas sind seit langem ein fester Bestandteil des benutzerzentrierten Designprozesses; Aber in den letzten Jahren haben Jobs-to-be-done, eine Technik, die sich auf die Bedürfnisse des Kunden konzentriert, an Bedeutung gewonnen.
Bestimmung
Jobs-to-be-done ist eine Reihe von Tools, die auf der Idee basieren, dass jedes Mal, wenn Benutzer ein Produkt „anstellen“, sie dazu verwendet werden, eine bestimmte Mission (die berühmten „Jobs“) auszuführen und somit ein bestimmtes Ergebnis zu erzielen. Jede JTBD entspricht tatsächlich der vollständigen Liste der Benutzeranforderungen.

JOBS-TO-BE DONE: EINE NÜTZLICHE RESSOURCE
Die JTBD-Technik ist eher auf Ergebnisse als auf Funktionalität ausgerichtet und basiert auf einer Darstellung der Benutzeranforderungen. Es wird durch qualitative Studien erhalten, die mit Benutzern durchgeführt wurden (Feldstudien, Vorstellungsgespräche bzw vereinfachte Usability-Tests).
Einer der Schritte besteht darin, festzustellen, was Benutzer dazu motiviert, ein Produkt zu „mieten“ (denken Sie daran, dass sie Missionen erfüllen müssen). Idealerweise lassen sich so auch bestehende Konkurrenzprodukte entdecken, auf deren Nutzer zugunsten unserer verzichtet werden kann. Unter Berücksichtigung all dessen kann sich das Produktteam auf die Art der grundlegenden Benutzerbeschränkungen und -anforderungen konzentrieren. Entwerfen Sie dann aus einem neuen Blickwinkel die Funktionen, die die wichtigsten Benutzeranforderungen am besten erfüllen.
Ein Beispiel: Lieferdienste

Jobs-to-be-done-Tools deuten darauf hin, dass Innovation und großartiges Design aus der Bewertung echter Kundenbedürfnisse und der Schaffung einer Lösung resultieren, die nicht durch Produkte eingeschränkt wird, die diese bereits erfüllen. Eine solch radikale Haltung gegenüber Innovation kann sich jedoch als Strategie herausstellen teuer und riskant zur Produktverbesserung. Und aus gutem Grund ist hier das Lieblingszitat der JTBD-Anhänger:
„Die Leute wollen keinen 60-mm-Bohrer kaufen, sie wollen ein 60-mm-Loch“ – Theodore Lewitt
Anstatt sich auf eine Liste von Produktmerkmalen zu konzentrieren, zwingt das Jobs-to-be-Done-Framework Designer dazu, über die Ergebnisse nachzudenken :
- Werden Benutzer in der Lage sein, die Mission, für die sie das Produkt „gemietet“ haben, (einfach und angenehm) durchzuführen?
- Bietet diese Lösung ein besseres Ergebnis als bestehende Lösungen?

Schließlich bringt eine Beschreibung der zu erledigenden Aufgaben im Allgemeinen zwei Arten von Kriterien zusammen. Die ersten sind die funktionale Erfolgskriterien (der Zweck der Mission, die klaren Anweisungen, um ihn zu erreichen). Die zweiten sind die emotionale Erfolgskriterien (die sich in individuelle emotionale Kriterien der Nutzer und soziale Erwägungen unterteilen lassen, etwa wie sie sich vorstellen, von anderen wahrgenommen zu werden).
Jobs-to-be-done werden normalerweise in einem einzigen Satz zusammengefasst, der beschreibt, was der Benutzer erledigen muss und jeder wichtige Kontext, der die Mission beeinflussen könnte (im folgenden Beispiel Reisen für a Kongress statt für Feiertage). Jobs-to-be-done beinhaltet auch Informationen über objektive Kriterien für funktionalen Erfolg sowie subjektive Kriterien für emotionalen Erfolg, die zu einem guten Erlebnis beitragen.
Emotionale Kriterien werden oft in zwei Teile geteilt : persönliche Kriterien und soziale Erwägungen.
GUT GESTALTETE PERSONAS SIND MEHR ALS EIN DEMOGRAFISCHES VERZEICHNIS
Die meisten Argumente, die vorgebracht werden, dass Personas mit der Ankunft von Jobs-to-be-done nutzlos geworden sind, basieren auf dem Missverständnis, dass es sich hauptsächlich um demografische Repräsentationen von Benutzern handelt.
Darüber hinaus sind demografische Daten für die Entscheidungsfindung im Produktdesign problematisch, da sie keine Daten über Benutzerverhalten und -einstellungen liefern und sich hauptsächlich für Marketing- und Werbezwecke eignen.

Die meisten gut gestalteten Personas enthalten eine Fülle von Informationen, darunter:
- Demografische Angaben, wie Alter, Familienstand und Einkommen;
- persönliche Daten, wie Kurzbiografie, Foto und Name;
- Kognitive oder einstellungsbezogene Details, wie Informationen über die mentales Modell der Persona, sein Schmerzstellen und Wahrnehmung der zu erledigenden Aufgaben ;
- Ziele und Motivationen für die Verwendung des Produkts;
- Verhaltensdetails wie sich die Persona tendenziell verhält, wenn sie das Produkt verwendet.
Demografische und persönliche Daten gibt es aus zwei Hauptgründen:
- Damit Projektteammitglieder Empathie gegenüber dem Nutzer schaffen
- Als Gedächtnistechnik, um es zu schaffen unvergesslich für das Team.
Leider gehen viele Personas (die eigentlich Marketingsegmente sind, die als solche ausgegeben werden) nicht über die demografische oder persönliche Ebene hinaus. Aus diesem Grund wird dieses Tool oft als weniger nützlich als JTBDs für die Entscheidungsfindung während des Designs angesehen.
Eine optimale Persona basiert maßgeblich auf komplexen Verhaltensmerkmalen, Einstellungsdaten und mentale Modelle, die ebenfalls erforderlich sind qualitative Forschung mit echten Benutzern, um die Gründe für das Benutzerverhalten zu entdecken. Diese komplexen Personas enthalten in der Regel Informationen zu bestimmten Zielen, die Benutzer bei der Verwendung des Produkts erreichen müssen. Diese Ziele sind direkt vergleichbar mit den Informationen in der JTBD-Definition.

MINDESTENS: JOBS-TO-BE-DONE FÖRDERT NICHT EMPATHIE
Einer der Hauptgründe, warum sich Personas anfänglich auf realistische Darstellungen von Benutzern konzentrierten, war die Abkehr von einem übermäßig formalen Modell der Benutzererfahrung, das sich um Listen von Aufgaben und Anforderungen drehte.
Auf diese Weise können Sie darüber nachdenken, wie das Erlebnis für den Benutzer aussehen soll. Tatsächlich berücksichtigen die JTBDs dennoch einige Überlegungen zum emotionalen und sozialen Kontext der Motivationen der Benutzer. Sie verallgemeinern diese Informationen jedoch für die gesamte Benutzerbasis.
Dadurch verfehlen wir den Kerngedanken des genauen Nutzungskontextes des Targets und Designer verlieren die Möglichkeit, Empathie gegenüber dem Nutzer zu erzeugen.

PRIORISIEREN SIE VERSCHIEDENE BENUTZER MIT PERSONAS
Stellen Sie sich folgendes Szenario vor : Wir sind Teil eines Teams von Designern, die die neue Version einer Desktop-Produktivitätsanwendung entwerfen. In den letzten Jahren sind Wettbewerber mit innovativen Produkten auf den Markt gekommen, und das Management unseres Unternehmens möchte ihr Produkt neu gestalten, um auf dem Markt wettbewerbsfähiger zu sein. Während es hilfreich ist, Ihre bestehenden und potenziellen neuen Kunden zu befragen, um herauszufinden, welche JTBDs für sie wichtig sind, sollten Sie auch die Hauptunterschiede zwischen diesen beiden Gruppen beachten.
Wenn wir bei der Neugestaltung der Anwendung bei Null anfangen, werden wir bestehende und treue Benutzer dazu zwingen, ihre Verwendung neu zu schulen, da sich ihre bisherige Route geändert hat. Dies wirkt sich auch negativ auf ihre Produktivität aus. Wenn wir ein altes Feature komplett neu entwerfen (oder, wie die „Jobs-to-be-done“-Technik oft vorschlägt: eine völlig andere und innovative Lösung für das Problem erstellen), riskieren wir, die Datenbank zu benachteiligen.

Während derselbe Job-to-be-done unterschiedliche Anforderungen für unterschiedliche Benutzergruppen haben kann, gilt auch das Gegenteil: Eine Benutzergruppe (oder Persona) kann das Produkt für unterschiedliche Missionen in unterschiedlichen Kontexten „mieten“.
Ein Beispiel: Online-Reservierungen
Ich kann dieselbe Buchungsseite für Geschäfts- und Privatflüge nutzen. Diese Arten von Reisen sind in der Tat unterschiedliche zu erledigende Aufgaben, die sehr unterschiedliche Reflexionen hervorrufen, aber mein Modell bleibt das gleiche im Hinblick auf das System, das mir präsentiert wird, sowie meine Einstellung und mein Verhalten - dass ich zu einem NN/g UX-Konferenz oder machen Sie eine Wanderung in Peru. Mein Verhalten und meine Einstellungen ähneln wahrscheinlich denen bestimmter Gruppen von Benutzern und unterscheiden sich auch völlig von denen einer anderen Gruppe. Aus diesem Grund erstellen wir mehrere Personas: um über die Unterschiede zwischen Benutzern nachzudenken, die es uns ermöglichen, Bedürfnisse auszugleichen und sie unter Personas zu priorisieren.
PERSONAS & JOBS-TO-BE-DONE: IT'S A MATCH!
Während einige denken, dass JTBDs Personas vollständig ersetzen können, sind die beiden eigentlich kompatibel. Je nach Bedarf des Kunden und wenn das produktverantwortliche Team bereits Personas oder Jobs-to-be-done verwendet, können diese ergänzend eingesetzt werden: Die vom JTBD-Tool bereitgestellten Informationen können in die Personas integriert werden.

Und umgekehrt: Wenn es sich um Personas handelt, die bereits im Unternehmen existieren, aber nicht die komplexen Motivationen sowie die für eine effektive Persona wesentlichen Verhaltensdaten enthalten, können wir sie zunächst mit Informationen ähnlich dem JTBD verbessern. Beginnen wir damit, Personas mit Informationen zu erweitern, die den zu erledigenden Aufgaben ähneln: Anstatt die Ziele des Benutzers aufzulisten, betrachten wir sie als zu erreichende Ziele. Fragen wir uns, was der Benutzer erreichen möchte. Was sind die wichtigsten Erfolgsüberlegungen (funktional und emotional) für diese Missionen?
Wenn es im Unternehmen großen Widerstand gegen die Erstellung von Personas gibt (wenn unsere Kollegen skeptisch sind oder unsere Hierarchie Schwierigkeiten hat, grünes Licht zu geben), ist es dank Appetit und vorhandener Möglichkeit dennoch möglich, Einfluss auf die Gestaltung der Anwendung zu nehmen Mittel für nutzerzentriertes Design können JTBDs eine sinnvolle Alternative sein. In der Tat kann die Medienberichterstattung über dieses beliebte Tool eine gewisse Begeisterung beim Kunden hervorrufen. Wir haben auch gesehen, dass JTBDs in einem zweiten Schritt in Kombination mit Personas verwendet werden können.
wegnehmen
- Verwenden Sie repräsentative Benutzer und weisen Sie ihnen repräsentative Aufgaben zu, um gültige Tests durchzuführen. Ein Design kann für eine Gruppe perfekt und für eine andere schrecklich sein.
- Differenzieren Sie die Zielgruppen und ihre Motivationen beim Design eines Produkts vermeidet das Auftreten schlechter Funktionalitäten während des Prozesses. Nutzer und Ziele: die notwendigen Zutaten für ein erfolgreiches UX Design!
- Verstehen Sie die Nützlichkeit einer gut ausgeführten Persona ermöglicht es, die spezifischen Bedürfnisse der Nutzer abzubilden. Die komplexen Informationen, die es zusammenführt, fördern die Empathie bei der Produktgestaltung.
Quelle
Persona vs. Jobs-to-be-done , Laubheimer Page @Nielsen Norman Group
Referenzen
- UX-Karten von UX Republic
- Persona-Kit von UX Republic
Kontext: Sébastien Faure, UX Content Manager @UX Republic @sebfaureUX / Phonesavane Soulivong, UX Communication & Marketing @UX Republic @psvn_soulivong / Übersetzung: Eric Bossin
