In einem Projekt hatten wir mit einigen technischen Problemen zu kämpfen, die leider auch zu mangelnder Begeisterung bei unseren Kunden führten. Es traten verschiedene Bugs auf, die die Benutzererfahrung massiv beeinträchtigten und die Akzeptanz des Produkts senkten. Das Produktmanagement war natürlich nicht begeistert und übte Druck auf die Entwicklung aus. Natürlich gab es eine Task Force, die alle Probleme lösen sollte.

Natürlich gab es, wie es sich für eine Task Force gehört, eine Liste von Problemen, die unbedingt gelöst werden mussten. Und so wurde an verschiedenen Ecken des Systems geschraubt, um die Liste abzuarbeiten. Die Kunden blieben unzufrieden.

Man tappte in die Falle, Probleme anzugehen, die man für wichtig hielt oder für die es eine offensichtliche Lösung gab. Die Priorisierung basierte nicht darauf, welche Probleme für die Kunden besonders relevant waren. Oder besser gesagt, welche für die Kunden den Unterschied zwischen Nutzung und Nichtnutzung ausmachten.

Zu dieser Zeit beschäftigte ich mich in einem anderen Zusammenhang mit der Frage, wie man Kundenbedürfnisse bei neuen Produkten gegeneinander abwägt und wie man die Anforderungen an das System gewichtet. Dan Olsen hat in seinem Buch „The Lean Product Playbook“ eine Pyramide der Nutzerbedürfnisse vorgestellt, die auf der Maslowschen Bedürfnispyramide basiert. Diese Methode kann auch auf bestehende Systeme angewendet werden.

Die Maslowsche Bedürfnispyramide ist ein hierarchisches Modell, das die menschlichen Bedürfnisse in fünf Ebenen unterteilt, von den physiologischen Grundbedürfnissen bis hin zur Selbstverwirklichung.

Psychologische BedürfnisseSicherheitsbedürfnisseSoziale BedürfnisseIndividualbedürfnisseSelbstverwirklichung12345
Maslowsche Bedürfnispyramide

Übertragen wir das Modell nun auf ein Produkt, z.B. das Portal des Online-Bankings. Welche Schritte sind für die Nutzer des Portals wichtig?

Erreichbarkeit der SeiteLadezeit der SeiteBugs im OnlinebankingFeaturesUX des Portals12345
Pyramide der Nutzerbedürfnisse

Die Stufen bauen aufeinander auf, wobei die „funktionierenden“ Stufen für den Benutzer „unsichtbar“ sind: Wenn sie ihre Arbeit verrichten, bemerkt man sie nicht. Die unterste und wichtigste Ebene ist die Verfügbarkeit. Wenn die Seite nicht erreichbar ist („down“), interessiert sich niemand für die Ladezeit. Ist die Seite erreichbar, soll sie schnell laden: Jeder Klick dauert 20 Sekunden, man wird die Seite kaum nutzen können. Lädt die Seite schnell, möchte man sein Online-Banking ohne Fehlermeldungen erledigen. Wenn das klappt, freut man sich über nützliche Funktionen wie den Dauerauftrag oder eine Suchfunktion. Die Spitze der Pyramide bildet dann die (exzellente) User Experience. Natürlich ist die UX auch schlecht, wenn die unteren Stufen nicht erreicht werden. Der UX-Level macht die Nutzung des Online-Portals zu einem Erlebnis, geht schnell und behindert den Nutzer nicht.

Vereinfacht kann man sagen, dass die unteren Stufen 1-3 die Unzufriedenheit reduzieren und die oberen 4-5 die Zufriedenheit erhöhen. Bei den meisten digitalen Produkten fallen heute die nicht erreichten unteren Stufen stärker ins Gewicht: Einer neu entdeckten Website, die nicht oder nur langsam lädt, wird keine zweite Chance gegeben. Die Basismerkmale nach dem Kano-Modell müssen erreicht werden.

Wie lässt sich die Pyramide auf das eingangs beschriebene Problem anwenden? Wir fragen Kunden und andere Nutzer des Produkts, welche Probleme sie bei der Nutzung haben. Wir fragen die Entwickler und den Support, welche Probleme derzeit bekannt sind. Die gesammelten Erkenntnisse werden dann als Pyramide der Benutzerbedürfnisse aufgebaut und Stufe für Stufe analysiert. Haben wir Probleme auf der untersten Ebene? Dann müssen wir diese zuerst angehen. Fehlende Features und schlechte UX sind wichtig, aber wenn das Produkt kaum benutzbar ist, sind sie zweitrangig. Manchmal können Probleme auf höheren Ebenen durch versteckte Probleme auf niedrigeren Ebenen verursacht werden.

Wir haben die Probleme, die die Task Force lösen sollte, in so einer Pyramide angeordnet und so bei allen Beteiligten den Blick dafür geschärft, was für das Produkt am wichtigsten ist, damit es von Kunden akzeptiert wird. Probleme, die weniger spannend erscheinen, jedoch weiter tiefer in der Pyramide liegen, wurden zuerst angegangen. Und so konnten wir Stufe für Stufe das Produkt verbessern.

Kommentare

Jan Bretschneider am 26. Dezember 2024

@blog
🤔 Bist du sicher, dass die Pyramide aus den Bedürfnissen der User*innen stammt und nicht aus der Architektur der Anwendung?
Erinnert doch sehr an Maslow, dessen Modell ja auch viel zu häufig überstrapaziert wird…

Leonid am 26. Dezember 2024

Die Pyramide ist auch eine direkte Ableitung aus der maslowschen Pyramide.

In dem Projekt, von dem ich schreibe, ging es nicht um ein Onlineportal, aber vergleichbare „Beanstandungen“. Die Kunden konnten das Produkt nicht nutzen, weil es nicht anging. Wenn es bootete, dann konnte sie sich nicht verbinden.. Und so weiter. Also haben wir die Pyramide basierend darauf aufgebaut, nicht auf der Architektur.

Jan Bretschneider am 26. Dezember 2024

@blog so habe ich dich auch verstanden. Aber: Die Pyramide ist meines Erachtens ein Modell der Architektur eines Systems, nicht der "Bedürfnisse" seiner Mitglieder.

Kaum jemand würde bei einem Meeting Sitzanordnung, Luftqualität, Art der Verpflegung, Dekoration des Raums oder Timeboxing als Bedürfnis formulieren, aber Änderungen daran können unglaublich viel Einfluss auf Ablauf und Ergebnis haben…

Siehe auch hier: https://wpgs.de/fachtexte/motivation/beduerfnispyramide-maslow-beispiele-kritik-motivationstheorie/#Beduerfnispyramide_von_Maslow_Kritik

Leonid am 26. Dezember 2024

Benutzer formulieren ihre Bedürfnisse auch nicht direkt. Wir haben sie grundsätzlich zu dem Produkt befragt, beobachtet. Daraus die Bedürfnisse abgeleitet. Und das ist auch nicht, was ich im Post schreibe: Niemand hat ein Bedürfnis nach schnell ladender Seite, weil ihr Bedürfnis nach Sicherheit erfüllt.. Es ging bei der Anlehnung an die maslowsche Pyramide einfach um die Hierarchie und Aufeinanderbauen der Bedürfnisse in Bezug auf das Produkt (funktionale und nichtfunktionale Anforderungen).

Jan Bretschneider am 26. Dezember 2024

@blog 🤔 über unser Geschriebenes nachdenkend:
Was ist für dein Team anders geworden, als ihr die Elemente hierarchsiert und als Kundenbedprfnis geframt habt?
Welche internen Mechanismen wurden dadurch anders?
Wer wurde mehr oder weniger gehört?
Welche Blockaden konntet ihr lösen oder aufbauen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert