Die besten Produkte gehen von echten Problemen aus: Gegensprechanlage über zu erledigende Jobs. Teil 3 endgültig

Im letzten Teil geht es darum, wie das Konzept der zu erledigenden Aufgaben die Prinzipien der Erstellung und Verbesserung eines IT-Produkts ändert. Der dritte Teil der Übersetzung des Buches "Gegensprechanlage über zu erledigende Jobs". Kapitel sieben bis neun.

Erster Teil
Zweiter Teil

Kapitel 7. Personen ablehnen: Eine Jobgeschichte

Gepostet von: Paul Adams

Bei Intercom überdenken wir ständig interne Prozesse, um ein herausragendes Produkt zu schaffen. Daher stellen wir uns die Frage: Wie kann der Prozess der Erstellung eines Produkts so gestaltet werden, dass die Menschen es für wertvoll und bequem halten und es auch lieben? Wir haben uns auf die Forschung konzentriert, für die wir Mitarbeiter mit Forschungserfahrung eingestellt haben. Gleichzeitig kommuniziert jedes Mitglied des Produktteams persönlich mit Kunden: Produktmanagern, Designern und natürlich Forschern. Wir haben auch einen Forschungsdirektor eingestellt, und das viel früher als die meisten anderen Startups. Er wurde Sian Townsend, Leiter des Google Maps-Forschungsteams.

Natürlich müssen Sie regelmäßig mit Kunden kommunizieren, um sich selbst und ihre Bedürfnisse zu verstehen. Es ist jedoch keineswegs offensichtlich, welches Werkzeug dafür geeignet ist. Wir haben uns ständig Gedanken über Ideen aus den ersten Prinzipien gemacht und sie ziemlich früh auf den Kommunikationsprozess mit Kunden angewendet.

Wir waren große Fans von Jobs-to-be-Done, aber alles, was wir geschrieben haben, wurde hauptsächlich auf Milchshakes und Schokoriegel angewendet. Es gab nur eine kleine Studie zur Verwendung von Jobs-to-Done für die Softwareentwicklung. Also haben wir unseren eigenen Prozess basierend auf dem erstellt, was wir bereits wussten.

Während des größten Teils meiner Karriere habe ich Personen und Skripte verwendet, um Kunden zu verstehen. Diese Werkzeuge, die Alan Cooper in dem Buch „Eine psychiatrische Klinik in den Händen von Patienten“ populär gemacht hat, sind zu einem der am weitesten verbreiteten von Forschern und Designern geworden. Alan Cooper hat auch ein unglaubliches Buch geschrieben, "About the Interface", das ich allen Designern empfehle, die sich unserem Team anschließen. Aber ich bitte sie, den Abschnitt über Personen zu überspringen.

Bei Googl habe ich Hunderte, wenn nicht Tausende von Menschen für viele Projekte geschaffen. Wir haben Coopers Methode sorgfältig befolgt, aber am Ende bin ich zu dem Schluss gekommen, dass Personen nur einen begrenzten Wert haben. Sie helfen normalerweise dabei, sich in Mitarbeiter hineinzuversetzen, die weit davon entfernt sind, mit Benutzern zu kommunizieren, aber selten zu bahnbrechenden Ideen oder einem neuen Blick auf das Problem führen.

Und wir bei Intercom haben nie wieder Leute benutzt.

Das erste Mal habe ich den Wert von Personen in Frage gestellt, als ich von Google zu Facebook gewechselt bin. Sie haben eine unglaubliche Menge an Informationen darüber gesammelt, wie Benutzer tatsächlich mit ihrem Produkt interagieren. Und die Kommunikation mit Daten Wissenschaftler hörten nicht auf, neue Dinge zu lehren.

Eines der erstaunlichsten Dinge, die ich gelernt habe, war das unglaublich ähnliche Verhalten verschiedener Menschen. Menschen ließen mich glauben, dass Menschen sehr unterschiedlich sind, dass sie wirklich unterschiedliche Ziele haben. Aber die Ähnlichkeiten waren trotz verschiedener Faktoren unverhältnismäßig größer: Rasse, Alter, Geschlecht usw.

Zum Beispiel sind die Motive einer Mutter von drei Kindern aus den USA, die Fotos von einem Familienpicknick veröffentlicht, im Grunde die gleichen wie die eines koreanischen Teenagers, der Bilder von der gestrigen Ernennung veröffentlicht. Die Ziele und Details mögen völlig unterschiedlich sein, aber die Motivation ist dieselbe. Personen werden niemals dazu führen, dass dasselbe Produkt für ein völlig anderes Publikum entwickelt wird. Die besten ihrer Art konzentrieren sich auf Erfolge, „was das Verhalten der Menschen antreibt“ und auf Attribute. In der Praxis konzentrieren sich die meisten Menschen jedoch nur auf Attribute.

Personen teilen das Publikum künstlich. Und vor allem sollten Sie das Publikum Ihres Produkts künstlich einschränken, indem Sie sich auf Attribute konzentrieren und nicht auf Motivation und gewünschte Ergebnisse. Sobald ich das merkte, war ich von der Person enttäuscht.

Aus Motivation zu entwerfen ist viel besser als aus Attributen zu entwerfen. Dies ist der Hauptunterschied zwischen Personen, die noch zu erledigen sind. Personen - über Rollen und Attribute und zu erledigende Jobs - über Situationen und Motivation. Personen erklären, was für Menschen sie sind, was sie tun und was sie tun, aber sie erklären nie vollständig, warum Menschen etwas tun, obwohl dies viel wichtiger ist.

Mitte 2013 stellten wir bei Intercom fest, dass wir nach einem Tool suchten, mit dem sich die Gründe ermitteln lassen, warum Kunden etwas unternehmen. Wir haben jede Woche mit vielen Kunden gesprochen, und unser Kundenserviceteam hat noch häufiger gesprochen und Entwicklungstickets erstellt, die die Probleme und Einschränkungen unseres Produkts berücksichtigen. Eine solch direkte Beziehung zu Kunden kann nicht überschätzt werden, aber es gab zwei Herausforderungen, die wir bewältigen mussten:

1. Die Leute verstehen ihre Probleme, aber nicht die Lösung. Darüber hinaus ist es für sie natürlicher, eine Lösung in Form eines Antrags auf Entwicklung von Merkmalen vorzuschlagen. Die Beschreibung der vorgeschlagenen Lösung ist viel einfacher als das Problem. Aus diesem Grund müssen Sie zu den Kunden zurückkehren, um Fragen zu stellen und deren Problem wirklich zu verstehen.
   
2. Bei der Beantwortung sprechen die Leute zunächst in der Sprache der Attribute darüber, was sie wollen, geben jedoch keinen Grund an, warum dies für sie wichtig ist. Daher muss man weiterhin tief in das Verständnis ihrer Motivation eintauchen. Die Hauptsache ist zu verstehen, welche Art von Problem Kunden tatsächlich zu lösen versuchen und warum sie gelöst werden müssen.
   

Wenn das Problem des Kunden bereits klar ist, wie können diese Erkenntnisse für das Designteam greifbar werden? In etwas Lakonisches, das leicht zu diskutieren und zu merken ist. Ich kann mich nicht an die Anzahl aller Fälle während meiner Arbeit bei Google erinnern, in denen wir Kollegen dazu gebracht haben, zu recherchieren und Menschen mitzugestalten, damit wir sie später nicht mehr verwenden. Dies liegt daran, dass Menschen schwer zu merken sind, sie sind zu detailliert, um sie leicht zu verstehen. Personen sind für Fast-Food-Teams nicht präzise genug.

Neben Personen gibt es noch ein weiteres beliebtes Tool - User Stories, die von der Agile Community beworben werden. Wir haben nie User Stories verwendet, da sie empirisch nicht von der Forschung abhängig zu sein scheinen. Sie sind technisch und werden sicherlich nicht vom Kunden verursacht. Sie sollen die Funktionalität beschreiben, nicht die Motivation der Menschen.

Nachdem wir über dieses Problem nachgedacht und von den ersten Prinzipien ausgegangen waren, erfanden wir Jobgeschichten. Dann hatte dieses Artefakt keinen Namen. Und später hatte Alan Klement einen Namen für uns. Aber der Prozess war fertig und passte perfekt zu uns. Wir haben zum ersten Mal Job Stories getestet und in einem Blogbeitrag über „ Dribbling “ -Design geklagt . Wir haben lange und intensiv über zukünftige Aufgaben nachgedacht, und dies führte zur Schaffung eines eigenen Prozesses, der sich auf Situationen, Motivationen und Ergebnisse konzentrierte:

[Wenn ______] [Ich möchte ______] [Ich kann ______]

"Wann ..." - über die Situation, "Ich will ..." - über Motivation, "Ich kann ..." - über das Ergebnis. Wenn wir die Situation verstehen, in der Menschen auf ein Problem stoßen, die Motivation, es zu lösen, und wie das Endergebnis aussieht, haben wir die Möglichkeit, ein wertvolles Produkt für unsere Kunden herzustellen.

Job Stories sind heute unser Hauptinstrument, das die Konditionalität durch Recherche, die Verständlichkeit des Problems und die Darstellung in prägnanter Form garantiert. Dies bedeutet, dass unser Ergebnis der Untersuchung des Problems sowohl für das Design- als auch für das Engineering-Team geeignet ist.

Bevor wir mit einem Projekt beginnen, erstellen wir bei Intercom eine sehr einfache einseitige Kurzbeschreibung, die heruntergeladen werden kann . Es ist sehr einfach und sollte 1 A4-Seite einnehmen. Es enthält den Abschnitt „Jobgeschichten“, der uns hilft, das Problem und die Chancen, die wir angehen, nicht zu vergessen, und der uns die Möglichkeit gibt, uns während des gesamten Projekts zu konzentrieren.



Personen haben definitiv einen Platz zu sein. Ich finde sie nützlich, um Unterstützung im politischen Spiel zu erhalten, wenn Menschen echte Kundenbedürfnisse nur verbal lösen. Personen können auch stärkere Verbindungen zu aktuellen Benutzern des Produkts herstellen. Aber sie gut zu machen ist ein zeitaufwändiger Prozess. Personen sind auf Unterschiede zwischen Menschen fixiert und schwer zu merken und sich darauf zu beziehen. Es stellt sich heraus, dass viele Menschen mit unterschiedlichen Eigenschaften eine sehr ähnliche Motivation haben. Es ist leicht zu verstehen und die Tatsache, dass alles, was Sie versuchen zu zerschlagen, in einer Reihe von kurzen, einprägsamen Sätzen erklärt werden kann. Wenn Sie dies nicht überzeugt, denken Sie daran, dass Menschen die Marktgröße Ihres Produkts künstlich reduzieren. Deshalb ertrinken wir für Jobgeschichten.

Kapitel 8. Entwerfen von Funktionen mit Job Stories

Gepostet von: Alan Klement

Als Des mich bat, für den Inside Intercom-Blog zu schreiben, präsentierte ich meinen Partnern von Aim, einem Werbemarktplatz für Immobilien, gerade die zu erledigenden Jobs.

Unser Entwurfszeichnungsprozess war aufgrund mangelnden Konsenses gemischt. Jeder von uns - ich als Generaldirektor, technischer Direktor und Leiter der Designgruppe - schlug vor, was zu entwerfen ist. Weil wir keinen effektiven Prozess hatten, um eine Idee zu genehmigen und andere abzulehnen.

Und dann dämmerte es mir. Ohne Bezug auf zu erledigende Jobs begann ich, auf die erfolgreichsten Vorschläge der Mitbegründer zu achten. Ich habe darüber gesprochen, woran unsere Kunden leiden, und beschrieben, wie viel besser ihr Leben sein wird, wenn wir es reparieren. Dann zeigte er, wie gut ihre Vorschläge für eine bestimmte Entwurfsaufgabe sind. Als Ergebnis habe ich die Arbeit beschrieben, die der Kunde ausführen muss, und das Ergebnis, wenn die Arbeit erledigt ist.

Mit der Sprache "Zu erledigende Aufgaben" für die Kommunikation konnten wir unser erstes Design in nur wenigen Minuten validieren. Es gab kein Zurück.

***

Personen und User Stories haben einen Ort, an dem Kunden und Produktteams sehr weit voneinander entfernt sind. Dies ist jedoch kein Problem mehr.

Traditionell ist die Antwort auf die Fragen "Wer ist unser Kunde?" und "Was brauchen Kunden?" liegt in der Marketing-, Geschäfts- oder sogar Verkaufsabteilung. Wenn die Informationen gesammelt werden, sollten sie in einem Format erstellt werden, das jeder versteht, und dann in das Produktentwicklungsteam aufgenommen werden.

Während dieses Wasserfallprozesses werden die Nuancen geopfert, die für die Herstellung guter Produkte erforderlich sind: Ursachen, Ängste und Motivation. Zu erledigende Jobs sind eine Philosophie, sich auf diese Nuancen zu konzentrieren. Um dieses Konzept auf das Endprodukt zu übertragen, sollten Job Stories während des Feature-Designs, der Benutzeroberfläche und der Benutzeroberfläche verwendet werden.

Personenversagen

Wie Des bereits sagte, werden Personen normalerweise durch Attribute definiert, die nicht mit Ursache-Wirkungs-Beziehungen zusammenhängen. Zum Beispiel erklären Geschlecht, Alter, Rasse und Wochenendpräferenzen einer Person nicht, warum sie Snickers liebt. Aber die Situation, in der es nur 30 Sekunden gibt, um etwas zu kaufen und zu essen, um den Hunger für die nächsten 30 Minuten zu stillen, erklärt alles.

Fehler User Stories

"Als Benutzer kann ich Ordner so markieren, dass sie nicht gesichert werden, sodass meine Sicherungsdiskette nicht mit dem gefüllt wird, was nicht benötigt wird." Diese User Story hat drei große Probleme:

1. Wird von einer Person verwendet.
   
2. Realisierung verbindet Motivation und Erwartungen.
   
3. Ignorierter Kontext, Einstellung und Ängste.

Funktionen schlagen oft fehl. Wenn eine Funktion anhand der User Story identifiziert wurde, ist es nicht leicht zu verstehen, warum sie fehlgeschlagen ist. Dies geschieht, wenn Motivation und Erwartungen in einer Entscheidung kombiniert werden. Aufgrund dieser Assoziation ist es unmöglich zu verstehen, was genau falsch war - das Problem liegt in der Umsetzung oder in der Annahme der Motivation.

Einführung in Job Stories

Job Stories, die Paul Adams erstmals im Blog von Intercom erwähnt und hier entwickelt hat , sind ein völlig anderer Ansatz für die Entwicklung von Funktionen. Aber wie integrieren Teams sie in ihren Workflow?



Hier ist ein Ansatz:

1. Wir beginnen mit hochrangiger Arbeit.
   
2. Wir definieren kleinere Arbeiten, die dazu beitragen, Arbeiten auf hohem Niveau auszuführen.
   
3. Wir beobachten, wie die Leute das Problem jetzt lösen. Das ist die Arbeit, die sie machen.
   
4. Wir verwenden Job Story, um die Ursache-Wirkungs-Beziehungen, Ängste und die Motivation dessen zu bestimmen, was Menschen jetzt tun.
   
5. Wir schaffen eine Lösung, die diese Job-Story löst.
   

Betrachten Sie als Beispiel den Prozess des Entwerfens eines Verkäuferprofils durch ein Produktteam als Teil eines Produkts, das Autohändlern hilft, einen Kredit an Kunden zu erhalten.

Profildesign

In der frühen Phase der Erstellung eines Designs bespricht das Team, wie das Benutzerprofil aussehen und mit welchen Funktionen es gefüllt werden soll. Zu Beginn steht Sarah, ein Mitglied des Teams, auf und zeichnet ein einfaches Layout an die Tafel. Sie zeigt auf ihn und sagt: "Dies ist das Profil des Verkäufers."

Das Team ist von seiner Entscheidung nicht beeindruckt. Zu jedem Teil des Layouts wird eine Reihe von „Warum“ -Fragen gestellt. Selbst nach all diesen Fragen akzeptiert oder lehnt das Team diese Idee nicht ab. Diese Fragen lauten: „Warum benötigt das Produkt dieses Profil?“, „Warum sollte das Profil hier und nicht an einem anderen Ort sein?“, „Welche Informationen sollten angezeigt werden?“, „In welchen Situationen ist es nützlich?“, „Welche Art von Arbeit erledigt dies? Profil? "

Um diese Fragen zu beantworten, wurde die Funktionsbeschreibung mithilfe der Job-Story neu gestaltet.

Erste Schritte mit hochrangiger Arbeit

Die Hauptaufgabe des Produkts besteht darin, dem Autohändler zu helfen, einen Kredit an einen potenziellen Kunden zu erhalten. Der Kunde und der Verkäufer müssen viele komplexe Papiere ausfüllen.

Wir definieren kleinere Jobs, die dazu beitragen, hochrangige Arbeiten auszuführen.
Um einen Kreditantrag fehlerfrei auszufüllen, müssen Verkäufer und Kunde eine große Menge an Informationen über das Auto und die Kreditbedingungen eingeben. Da die Informationen sensibel sind, muss der Kunde das Gefühl haben, dass die Übertragung von Daten an den Verkäufer sicher ist.

Wir beobachten, wie die Leute das Problem jetzt lösen. Das ist die Arbeit, die sie machen.
Bei der Übermittlung solcher Informationen prüfen Käufer in der Regel visuell den Verkäufer und das Autohaus und stellen fest, ob sie Vertrauen verdienen. Kunden geben normalerweise vertrauliche Finanzinformationen ein, indem sie in der Nähe des Verkäufers sitzen. Dies hilft ihnen, sich sicher zu fühlen, dass die Informationen korrekt ausgefüllt werden und gleichzeitig nicht für Personen verfügbar sind, die sie nicht sehen sollten.

Wir verwenden die Job-Story, um die Ursache-Wirkungs-Beziehungen, Ängste und Motivationen dessen zu bestimmen, was Menschen jetzt tun:

1. Wenn Autohändler und ihre Kunden über ein Produkt interagieren ...
   
2. ... Kunden wollen dem Unternehmen, dem Prozess und dem Verkäufer vertrauen.
   
3. Verkäufer möchten sicher sein, dass der Prozess für den Kunden angenehm ist ...
   
4. ... und er kann seine Finanzinformationen sicher eingeben.
   

Es ist in Job Geschichte geschrieben. Sie können angeben, indem Sie mehr Situationskontext hinzufügen: wann und wo alles gefüllt ist, zu Hause oder im Autohaus. Sowie die Befürchtungen jeder Partei, die mit dem Profil und seiner Vervollständigung verbunden sind.

Erstellen Sie eine Lösung, die diese Job-Story erfüllt

Das Team entscheidet, welches Design das Profil haben soll, damit der Kunde seine Arbeit abschließen kann. Wenn zu wenig Informationen im Profil angezeigt werden, wird die anfängliche Arbeit nicht gelöst, und das große Array kann zu negativen Konsequenzen führen. Infolgedessen entscheidet das Team:

1. Während der Verwendung des Produkts wird das Profil des Verkäufers ständig auf dem Bildschirm angezeigt, sodass der Käufer nicht befürchtet, dass er sich nicht in der Nähe des Verkäufers befindet.
   
2. Das Profil sollte ein Foto des Verkäufers, seiner Position, der Anzahl der verkauften Autos und der Betriebszugehörigkeit im Unternehmen enthalten, damit kein Zweifel an der Zuverlässigkeit des Verkäufers und seiner Erfahrung besteht.
   
3. Das Profil sollte angeben, wie der Verkäufer kontaktiert werden soll: Telefonnummer, E-Mail-Adresse und die Schaltfläche „Frage stellen“, damit der Kunde keine Angst hat, das Formular falsch auszufüllen.
   

Hier ist eine Beispiellösung:



Das Folgende ist eine Aufschlüsselung der Benutzeroberfläche: die Arbeit, die jedes Element des Profils leistet, und welche Situationen es löst.



Jetzt haben wir ein Produkt, in dem die Wurzeln jeder Lösung für den Job gefunden werden können: ein Gefühl der Sicherheit bei der Übertragung personenbezogener Daten durch den Kunden zu vermitteln.

Sounddesign für Menschen
Erfolgreiche Produkte zu schaffen bedeutet, echte Menschen zu beobachten, die ihre Probleme lösen, den Kontext der Situation zu untersuchen, in der sie sich befinden, und Ursachen, Ängste und Motivation zu verstehen.

Abstrakte Attribute, die Kombination von Realisierung mit Motivation und Erwartungen machen Teams verrückt. Wenn das Team tief greift und die Arbeit des Kunden studiert, schafft es Lösungen effizienter. Job Stories eignen sich am besten für das Produktdesign.

Kapitel 9. Fragen Sie nach dem Warum - richtig

Gepostet von: Dan Ritzenthaler

Bis ich zu den zu erledigenden Jobs kam, habe ich das Grundproblem kaum definiert, so dass es auf eine einfache Aussage hinauslief. Wie kann ich es einfach und klar vor Teammitgliedern ausdrücken? Es ist notwendig, das Problem aus verschiedenen Blickwinkeln zu betrachten, um es besser zu verstehen. Und stellen Sie die Frage "Warum?" - Eine der besten Möglichkeiten, tiefer in das einzutauchen, was Kunden versuchen.

Es gibt viele abstrakte Tipps und Studien, wie man Ursache-Wirkungs-Beziehungen entdeckt. Zum Beispiel die Five Why-Technik. In diesem Kapitel werden wir über das Streben nach einem Mittelweg sprechen, darüber, wie man sich landeinwärts durch die Konversationsebenen bewegt, aber nicht zu schnell, um keine wertvollen Erkenntnisse zu verlieren. Die Hauptsache ist, auf jeder „Warum“ -Ebene einzigartige Einblicke zu finden, bevor Sie fortfahren.

***

Ich kann nicht aufhören, die Frage "Warum?" für jede Ihrer Aussagen, und dann ... wieder werde ich fragen "warum?". Dies ist eine professionelle Verformung.

Hier haben Sie zum Beispiel eine Bohrmaschine gekauft. Warum? Ja, weil Sie ein paar Fotos in einen Rahmen hängen möchten. Warum willst du Bilder aufhängen? Wahrscheinlich, um Ihr Zuhause bevölkerungsreicher zu machen. Warum ist dir das wichtig?

Beim Produktdesign ist die Grundursache oft zu schnell. Aber der Wert, Fragen zu stellen, warum? besteht normalerweise nicht darin, das Ziel zu erreichen, sondern in der Bewegung darauf zu.

Dies gilt insbesondere für Interviews mit Kunden. Nehmen Sie sich Zeit und widmen Sie jedem „Warum?“ - Level Zeit, um viele verschiedene Ideen zu testen. Dann wird die Zeit, die mit dem Kunden verbracht wird, produktiver - die erhaltenen Erkenntnisse werden viel interessanter und nützlicher.

Produktive Gesprächsstufen

Sie können immer so tief graben, wie Sie möchten. , . «?».

, . , , :

1. -, : ? , .
   
2. -, : ? , .
   
3. -, : , ? .
   

. , : « ?», .

, , — . , .

— . , .

? ? ? ? : ?

? , , ? , ? ? , , ?

, . , , .

— . , , .

, ? ? , ? , - ? , , ?

? , , ? , , ? , ?

. , , .

— . , , , .

, , ? , ? ?

? -, ? , ? , ?

, . , .

, , . . . , , . , .

Fazit

Intercom Jobs-to-be-Done . . . , , , .

, Jobs-to-be-Done. , , . , Intercom, .

, , . , , Intercom . , .

Jobs-to-be-Done . — , . , . , .

, . des@intercom.com

Danke fürs Lesen.