Falle #2: Gefälschte User Stories

Als wir zum ersten Mal das Handbuch für nutzerzentriertes Design verschluckten, waren wir ganz begeistert von unseren Personas.

Hier ist einer, Henry, er hat eine ganze Nebenhandlung über seine Scheidung und wie sie sich auf die Beziehung zu seinen Enkeln ausgewirkt hat. Sehr nachvollziehbar. Ich glaube, wir haben hier unsere lila Phase durchgemacht. Wir haben mit viel dünneren, papiernen Charakteren angefangen, sie hatten Sternzeichen, aber man konnte nicht wirklich herausfinden, was sie dazu bewegt hat, die Kasse zu drücken.

Wie auch immer - wir haben in letzter Zeit viel mehr Funktionalität. Die Namen der Charaktere sind viel wahrscheinlicher in der Art von "Single Ticket Buyer". Wie auch immer sie heißen, sie werden wahrscheinlich nicht in User Stories wie dieser auftauchen:

[Als Mäzen möchte ich mich mit reichhaltigen Inhalten über Bildungsprojekte einbringen, damit ich mich stärker einbezogen fühle."

Ich fürchte, das ist eine "Bogus User Story". Das sind die Geschichten, die wir am Ende schreiben, wenn wir versuchen, die Benutzer in die Motivationen unserer Organisation einzupassen. Sie fangen im Grunde mit den Anforderungen der Abteilungen an und versuchen, sie in das Format einer User Story zu bringen. Sie sehen den Teil am Ende der User Story. Der Teil "So kann ich"? Dieser Teil ist der wichtigste Teil einer User Story, denn er soll den Nutzen für den Benutzer darlegen und damit den Grund, warum er diese Funktion haben möchte. Wenn Sie eine lange Liste von intern erstellten Anforderungen haben, wird das schnell lästig. Wer sind diese Leute? Was wollen sie? Das steht einfach im Weg...

Das führt dazu, dass man mit gefälschten Benutzergeschichten konfrontiert wird und dass die Leute an der Front die Funktionen liefern:

1. Sie wissen nicht, wie Sie die Funktion erstellen sollen (weil die User Stories es Ihnen nicht wirklich sagen)
2. Ich weiß nicht, wozu das Feature gut sein soll (weil die Geschichte erfunden ist)

Glückwunsch, Sie haben sich selbst gespielt.

Was ist zu tun?

• Sie könnten es realistisch halten, indem Sie echte Nutzer nach Dingen fragen, für die sie Ihre Website nutzen möchten. Wenn Sie echte Menschen fragen, werden sie Ihnen vielleicht eher Dinge nennen, von denen sie glauben, dass sie sie wollen, als Dinge, die sie brauchen. Noch besser wäre es, wenn Sie echte Nutzer bei der Verwendung eines Tools wie HotJar oder Full Story beobachten oder einen tatsächlichen aufgabenorientierten Nutzertest durchführen.
  
  
• Ich empfehle, einen Blick auf das Jobs To Be Done Framework zu werfen. Jobs To be Done ist recht interessant. Es ist nicht als vollwertiger Ersatz für User Stories gedacht, aber es hat einiges über Personas zu sagen. Es geht davon aus, dass ein Benutzer eine Aufgabe zu erledigen hat, und überlegt, wie Ihr Produkt diese Aufgabe erleichtern wird. Wenn wir an die Aufgabe denken, eine Messe zu besuchen, und dann alle Dinge bedenken, die unser Benutzer tun muss, um diese Aufgabe zu erledigen, gibt uns das Anhaltspunkte für die Hauptaufgaben, die unsere Website erleichtern sollte, von der Suche nach den Messen und Zeiten über die Eingabe der Kreditkartendaten bis hin zur Wegbeschreibung zum Veranstaltungsort. Das Warum ist in die zu erledigende Aufgabe eingebettet, das Wie ist Ihre Aufgabe herauszufinden. Vielleicht ist es hilfreich, Ihr Produkt aus dieser Perspektive zu betrachten, als Parallele zu Ihren User Stories. Letzten Endes macht es keinen großen Unterschied, ob Sie eine geschiedene Waage sind oder nicht, wenn Sie über die Aufgaben nachdenken, die Sie zu erledigen haben.

Falle #10 Bau eines Denkmals
Falle Nr. 9 100% digitale Abdeckung
Falle Nr. 8 Aufteilen und erobern
Falle Nr. 7 Design für das Smartphone Ihres CEOs
Falle Nr. 6 Falsche Propheten
Falle Nr. 5 Post-it-Fetischismus
Falle #4 Bauen statt kaufen
Fallstrick #3 Kaufen statt Kaufen
Falle #2 Gefälschte Anwendergeschichten
Falle #1 Gegen den Strom schwimmen