Es war seltsam. Jay (Name des Studienteilnehmers geändert) saß vor einem Desktop-Computer mit einem geöffneten Browser. Doch es war sein Smartphone, nach dem er griff.

Auf dem Handy öffnete Jay sogleich die mobile App seiner Bank. Nachdem er sich eingeloggt hatte, überflog er seine Kontostände, dann machte er sich daran, einen Geldbetrag von seinem Girokonto auf sein Hypothekenkonto zu bewegen.

Ich war verwirrt, warum er stattdessen nicht die Website der Bank nutzte. "Die Smartphone-App ist viel einfacher", antwortete Jay. "Ich nehme diesen Transfer jeden Monat vor und kann das mit dem Handy schneller erledigen."

Das faszinierte mich. Jay hatte die Bank-Website viele Male genutzt. Er zeigte mir, wie er verschiedene Aufgaben damit erledigte. Aber als es darum ging, Geld zu transferieren, war es für ihn einfacher, die mobile App zu verwenden.

Heuern und feuern

Jay musste einen Geldtransfer vornehmen. Um dieses Bedürfnis zu erfüllen, wählte er die mobile App statt der Bank-Website.

Wir können Jays Wahl in Form zweier Aktionen beschreiben: Für den Job des Geld-Transferierens feuerte Jay die Website der Bank und heuerte seine mobile App.

Die Wahl, die User treffen, um eine Sache zu feuern und etwas anderes zu heuern, ist wichtig. Warum treffen sie diese Wahl? Wenn sie sich entscheiden, unser Design zu feuern und das Design von jemand Anderem zu heuern - wollen sie uns damit sagen, dass unser Design auf die eine oder andere Art defizitär ist?

Warum haben sie diese Wahl getroffen? Diese Frage führt zu einem Problem des Widerstands. In Jays Fall rief die Website Widerstand im Hinblick auf den Job des Geld-Transferierens auf. Die mobile App löste diesen Widerstand auf.

Hätte das Design-Team der Bank den Widerstand und seine Ursachen verstanden, hätte es mehrere Optionen gehabt. Sie könnten die Effektivität der Überweisungsfunktion der App vermarkten, damit auch andere Kunden daraus Vorteile ziehen. Oder sie könnten das Design der Website überarbeiten, um die Dinge zu entfernen, die Jay gebremst hatten, damit die Website in Zukunft zu einer begehrenswerten Lösung wird.

Das ist die Kraft von Jobs To Be Done. JTBD (wie die Jüngeren es nennen) ist ein neuer Ansatz, um über Wahl und Widerstand zu sprechen. Der Job ist der Fortschritt, den ein Nutzer erzielen will. (In unserem Fall versucht Jay, den Fortschritt, seinen Hypothekenkredit zurückzuzahlen, zu erzielen.) Der Nutzer heuert und feuert Produkte oder Dienstleistungen, um diesen Fortschritt effektiv zu machen.

Wo Jobs To Be Done herkommt

Jobs To Be Done wurde mit Clayton Christensens Büchern über Innovation und Disruption bekannt, speziell Competing Against Luck von 2016. (Der Untertitel des Buchs spricht für sich: The Story of Innovation and Customer Choice.)

Christensen ist die beste Ressource für die Beschreibung, wie JTBD zu innovativen Produkten führt, die wir gefunden haben. Es ist das, was man erwarten kann, wenn eine führende Autorität der Harvard Business School darüber nachdenkt, wie Unternehmen innovative Produkte liefern können.

Doch Christensens Buch beschreibt nicht, wie man dorthin gelangt. Das hat eine kleine Armee von Beratern hervorgebracht, um diese Lücke zu füllen. Jeder von ihnen hat sein eigenes Buch geschrieben, darunter Chris Spiek und Bob Moesta mit Jobs-to-be-Done The Handbook, Alan Klement mit When Coffee & Kale Compete und Anthony W. Ulwick mit Jobs To Be Done Theory To Practice.

In allen Fällen sprechen die Autoren darüber, aufzudecken, wie die User ihre Wahl treffen. Ulwick tendiert zu einem stärkeren Fokus darauf, was die Leute mit den Produkten oder Diensten tun. Die anderen richten den Fokus eher auf den Fortschritt, den die Leute erzielen wollen.

(Dieser Unterschied hat eine Verzweigung in der JTBD-Community verursacht, die zuweilen streitlustig sein kann. Dieser Wettstreit macht es gelegentlich schwierig zu verstehen, was JTBD bietet. Diverse UX-Professionals haben mir erzählt, dass sie JTBD den Rücken gekehrt haben, weil ihnen die Grabenkämpfe und das exzessive Streben, Beratungsleistungen zu verkaufen, auf die Nerven gingen.)

Das Gerüst von Jobs To Be Done

Die JTBD-Gläubigen erzählen uns, dass Teams, die nicht wissen, für welchen Job ihre Nutzer heuern, sehr wahrscheinlich schlechte Design- und Marketing-Entscheidungen treffen werden. In JTBD zielen Marketing und Design auf den gemeinsamen Nenner ab, sicherzustellen, dass das Produkt oder der Dienst die unbefriedigten Bedürfnisse des Kunden (oder des Users, der kein Kunde ist) adressiert. Das könnte nützlich sein.

Vor nicht allzu langer Zeit konnten wir in einer Studie, die wir mit Versicherungsvertretern durchgeführt haben, beobachten, wie mehrere von ihnen auf Tabellen zurückgegriffen haben, um Angebote für ihre Kunden zu erstellen. Sie sagten uns, dass sie lieber ihre eigenen Tabellen bauen und nutzen, als die Tools zu verwenden, die die IT-Abteilung ihres Versicherungsunternehmens entwickelt hat, weil die Tools der IT zu kompliziert seien.

Wir könnten die Wahl der Vertreter als das Feuern der IT-Tools und das Heuern der Tabellen betrachten. Der Job to be Done besteht darin, dem Kunden schnell ein Versicherungsangebot zu erstellen.

In anderen Studien, die wir über die Jahre durchgeführt haben, konnten wir beobachteten, wie Kunden Probleme lösen. Viele dieser Kunden entschieden sich dazu, die gebührenfreie Nummer des Kunden-Supports zu wählen und mit einem menschlichen Service-Ansprechpartner zu reden, statt auf die online verfügbare Wissensbasis zurückzugreifen. Diese Kunden erzählten uns, dass sie menschliche Interaktion bevorzugen, weil das in ihnen Vertrauen in die Problemlösung wecke.

Diese Kundenwahl könnten wir als das Heuern des Callcenter-Ansprechpartners und das Feuern der Wissensbasis betrachten. Der Job to be Done besteht darin, ein Problem vertrauenswürdig zu lösen. Ein Job to be Done ist eine andere Art, ein unbefriedigtes Bedürfnis zu beschreiben. Er setzt es in den einfachen Kontext eines Dienstes.

Jobs To Be Done erzwingt einen nutzerforkussierten Ansatz

Christensens Basisargument lautet, dass wir etwas Innovatives entwickeln, indem wir uns auf die Jobs fokussieren, die der Kunde erledigen will - speziell wenn er nicht durch ein bereits am Markt verfügbares Produkt erledigt wird. Wir erfüllen das unbefriedigte Bedürfnis eines Kunden auf eine Art und Weise, wie es niemand sonst tut. Christensen nutzt JTBD, um einen nutzerfokussierten Blick auf Innovation zu fördern.

Das Schöne daran ist, dass wir nun eine Harvard-Business-School-Autorität haben, die dafür plädiert, mit Kunden zu sprechen. Christensen verbringt ein ganzes Kapitel nur damit, Wirtschaftsführer dafür zu schelten, zu sehr nach innen gerichtet zu sein. Er rät ihnen, primär auf das zu hören, was er passive Daten nennt, statt auf die normalen Daten, in denen die Organisation schwimmt.

Passive Daten sind schwer zu bekommende qualitative Daten, die über Marktdaten hinausgehen. Christensen spricht es nicht aus, aber passive Daten sind das, was wir Nutzerforschung nennen. Er argumentiert, dass wir nach draußen gehen und mit Kunden reden müssen, um die tatsächlichen Jobs aufzudecken, die sie erledigen wollen.

Nutzerforschung: für JTBD ein mysteriöser Schritt

Eine der besten Eigenschaften all dieser Bücher über JTBD ist der Umfang an Fallstudien. Christensens Buch ist voll davon, ebenso die Bücher von Klement und Ulwick. Spiek und Moesta haben einen Podcast produziert, der mit Fallstudien gefüllt ist.

Wir haben ziemlich schnell festgestellt, dass all diese Fallstudien einem Basismuster folgen:

• Akt 1: Wir treffen einen Manager oder einen hochrangigen Stakeholder, der sich sicher ist, dass er verstanden hat, warum Kunden sein Produkt wählen.
• Akt 2: Der Manager/Stakeholder entdeckt Jobs to be Done.
• Akt 3: Aufgrund der Jobs-to-be-Done-Aktivitäten verändert das Unternehmen sein Produkt oder seine Marktpositionierung.
• Epilog: Profit!

Was uns daran fasziniert hat, war der Mangel an Spezifikation dahingehend, was auch immer zwischen den Akten 2 und 3 passiert. Nur Spiek und Moesta beschäftigen sich etwas tiefergehend mit der Frage, wie sie determinieren, worin die Jobs der Kunden bestehen. Bei allen anderen bleibt es ein mysteriöser Schritt.

Spiek und Moesta nutzen einen Interviewprozess. In einer Podcast-Episode stellen sie ihre Technik vor, indem sie ein Interview teilen, das sie mit einem Kursteilnehmer über die Erfahrung beim Kauf einer Matratze geführt haben. (Christensen hat das achtseitige Transkript des Interviews in seinem Buch nachgedruckt.)

Ulwick umreißt in seinem Buch ungelogen einen Prozess mit 84 Schritten, den er Outcome-Driven Innovation nennt. (Wirklich, es sind 84 Schritte, kein Scherz!) Aber die tatsächliche Nutzerforschung beschreibt er nur in einem einzigen Schritt:

Schritt 12: Führen Sie Kundeninterviews durch, um den Kern des funktionalen Job-To-Be-Done zu definieren. (Die nachfolgenden 72 Schritte sind variierende Aktivitäten, um zu validieren, dass das Team Schritt 12 korrekt durchgeführt hat.)

Dieser Mangel an Diskussion legt nahe, dass JTBD Nutzerforschungs-agnostisch ist. Unabhängig von ihrem Umfang oder ihrer Qualität wird die Nutzerforschung zu den gleichen Ergebnissen führen.

Nun wissen wir allerdings aus vielen Jahren der Design-Praxis, dass es sehr wohl auf die Qualität der Nutzerforschung ankommt. Unzureichende oder qualitativ schlechte Forschung wird keine strategisch wichtigen unerfüllten Bedürfnisse aufdecken. Die Details der Nutzerforschung undefiniert zu lassen, öffnet späteren Prozessproblemen Tür und Tor.

Welche Probleme das sind und inwiefern JTBD mit einem Hilfsmittel für Zauberkünstler vergleichbar ist, zeigt der Autor im zweiten Teil des Artikels.

Dieser Artikel wurde im Original am 17. Januar 2019 unter dem Titel Jobs To Be Done: An Occasionally Useful UX Gimmick von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden User-Experience-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im UX-Special von //SEIBERT/MEDIA.