Produktdesign-Frameworks in der Praxis: Wie man aus der Theorie herauskommt, ohne zur Geisel der Methode zu werden

Jedes Produktteam entdeckt irgendwann Frameworks. Double Diamond, Design Thinking, Jobs to be Done, Design Sprint. Sie bleiben an der Wand hängen, werden zu Prozessfolien und vermitteln für eine Weile das beruhigende Gefühl, dass es jetzt eine Methode gibt.

Das Problem tritt später auf. Das Team hält sich buchstabengetreu an das Ritual und liefert dennoch durchschnittliche Produkte. Die Schritte wurden abgeschlossen, die Post-its blieben hängen und das Ergebnis verbesserte sich nicht. Die Frage, die niemand laut stellt, ist: Hilft der Rahmen oder ist er zum Theater geworden?

Dieser Text richtet sich an diejenigen, die die Theorie bereits kennen und sie wirklich anwenden möchten, ohne die Methode zur Religion zu machen.

Welche Design-Frameworks wirklich für Sie tun

Ein Framework hat keine Intelligenz. Er trifft keine Entscheidungen, er versteht seinen Benutzer nicht und er kennt sein Geschäft nicht. Was es bewirkt, ist, das Denken zu strukturieren, eine Reihenfolge von Fragen vorzugeben und zu verhindern, dass das Team aus Angst wichtige Schritte überspringt.

Das ist die These: Der Wert eines Frameworks liegt darin, die Kosten für gutes Denken zu senken, und nicht darin, das Denken zu ersetzen. Es organisiert das Gespräch, richtet das Team aus und sorgt für gemeinsames Vokabular. Wenn Sie anfangen, Antworten zu diktieren, anstatt Fragen zu verbessern, wird das zu einer Krücke.

Die beste Verwendung eines Gerüsts ist als Gerüst. Man richtet es zum Bauen ein und irgendwann lernt man, damit zu arbeiten, ohne es bei jedem Schritt betrachten zu müssen.

Double Diamond in der Routine: wirklich divergieren und konvergieren

Double Diamond ist auf dem Papier einfach: Erforschen Sie das Problem (entdecken und definieren), dann erforschen Sie die Lösung (entwickeln und liefern). Zwei öffnende und schließende Diamanten.

Im Training scheitert er, wenn das Team die erste Raute überspringt. Die Eile, etwas zu liefern, führt dazu, dass jeder zur Lösung eilt, bevor er das Problem versteht. Das Ergebnis ist ein gut ausgeführtes Produkt für die falsche Frage.

Sich wirklich bewerben bedeutet, die Entdeckungsphase zu schützen. Es bedeutet, dem Druck „Wir wissen bereits, was zu tun ist“ zu widerstehen und Zeit damit zu verbringen, das Problem zu verstehen, bevor wir eine Antwort entwerfen. In einem echten Team geht es weniger darum, dem Diagramm zu folgen, als vielmehr darum, die Disziplin aufzubringen, nicht zu früh zusammenzuarbeiten.

Jobs to be Done: die Frage, die den Fokus verändert

„Jobs to be Done“ ist kein Prozess, sondern eine Linse. Anstatt zu fragen: „Was will der Benutzer“, fragen Sie: „Welche Fortschritte versucht er in seinem Leben zu machen?“ Die Leute wollen keine Übung; Sie wollen ein Loch in der Wand und unten das Regal installieren.

Es ändert, was Sie priorisieren. Eine Rathaus-Serviceplattform zum „Anbieten von Online-Formularen“ gebe es beispielsweise nicht. Es dient dazu, dass Bürger ein Problem mit möglichst wenig Reibungsverlusten lösen können. Wenn man das Problem auf „Job“ umformuliert, erweisen sich scheinbar wesentliche Funktionen als Rauschen.

Der häufige Fehler besteht darin, JTBD als Präsentationsjargon zu verwenden, ohne Entscheidungen zu ändern. Wenn das Framework nicht veränderte, was in der Roadmap enthalten ist oder nicht, wurde es nicht angewendet, sondern erwähnt.

Design Sprint: Leistungsstark und oft missbraucht

Der Design Sprint komprimiert Entdeckung, Prototyping und Test auf wenige Tage. Es eignet sich hervorragend, um eine schwierige Entscheidung zu treffen oder eine riskante Richtung schnell zu bestätigen.

Der falsche Zweck besteht darin, es als Standardprozess für alles zu betrachten. Sprint ist teuer, es konzentriert ältere Leute ganze Tage lang. Es für triviale Probleme zu verwenden ist verschwenderisch; Noch schlimmer ist es, es ohne ein gut formuliertes Problem zu verwenden, da Sie die Energie des Teams damit verschwenden, schnell die falsche Frage zu beantworten.

Der Design Sprint zahlt sich aus, wenn es um eine Entscheidung mit hohem Risiko und wenig Konsens geht. Dann ist er Gold wert. Ansonsten handelt es sich meist um eine Zeremonie.

Wie man im Alltag zwischen ihnen wählt

Bei der Wahl geht es nicht darum, welches Framework besser ist, sondern darum, welche Frage Sie jetzt beantworten möchten.

Ich weiß nicht, was das Problem ist. Beginnen Sie mit der Entdeckung, dem ersten Double Diamond-Diamanten, Interviews, Beobachtungen.
Ich kenne das Problem, aber ich verstehe die Motivation des Benutzers nicht. Verwenden Sie „Jobs to be Done“, um es neu zu formulieren.
Ich habe eine riskante Entscheidung und brauche schnelle Anweisungen. Design Sprint.
Ich habe die Lösung bereits, ich muss sie verfeinern und liefern. Konzentrieren Sie sich auf die Ausführung, auf den zweiten Diamanten, und testen Sie ihn im realen Einsatz.

Beachten Sie, dass diese Frameworks nicht miteinander konkurrieren, sondern unterschiedliche Momente abdecken. Sie mit Kriterien zu vermischen ist ausgereifter, als eine einzelne Methode als absolute Wahrheit zu verteidigen.

Frameworks kombinieren, ohne zum Flickenteppich zu werden

Selten kann ein einzelnes Framework ein Projekt von Anfang bis Ende abwickeln. Das erfahrene Team kombiniert Ansätze, aber wenn sie schlecht kombiniert werden, entsteht ein verwirrender Prozess, bei dem niemand weiß, warum sie die einzelnen Dinge tun.

Das Geheimnis besteht darin, jedes Framework als Reaktion auf eine Phase zu behandeln und nicht als Identität für das Team. Sie können Double Diamond als allgemeines Grundgerüst verwenden, Jobs to be Done, um das Problem innerhalb der Entdeckungsphase neu zu formulieren, und einen einmaligen Design Sprint, wenn eine bestimmte Entscheidung stecken bleibt. Das ist keine Inkonsistenz; Es geht darum, für jeden Moment das richtige Werkzeug zu verwenden.

Was diese Kombination gesund hält, ist die Klarheit des Zwecks. Bevor eine Technik übernommen wird, sollte das Team wissen, wie es zwei Fragen beantwortet: Welche Frage versuchen wir zu beantworten und woher wissen wir, dass dieser Ansatz geholfen hat? Wenn niemand antworten kann, wurde der Rahmen aus Gewohnheit oder Mode gewählt, nicht aus Notwendigkeit.

Ein Beispiel für eine Kombination, die funktioniert: Ein Produktteam einer öffentlichen Behörde kartiert die „Aufgabe“ des Bürgers (die Lösung eines Problems), verwendet den ersten Double Diamond-Diamanten, um die tatsächlichen Zugangsbarrieren zu verstehen, und führt erst dann einen kurzen Sprint durch, um den kritischen Fluss zu entwerfen und zu testen. Jeder Schritt führt logischerweise zum nächsten. Der Prozess dient dem Problem und nicht umgekehrt, was genau das Gegenteil von dem ist, was passiert, wenn sich Frameworks ohne Kriterien ansammeln.

Die Falle des Prozesses, der zum Theater wird

Das größte Risiko in der Praxis besteht darin, nicht den falschen Rahmen zu wählen. Es ist der Prozess, der zur Leistung wird. Teams, die ihre Designrituale lieben, vergessen manchmal, dass das Ritual nie das Ziel war.

Ich habe Teams gesehen, die stolz darauf sind, die Methode perfekt zu befolgen und Produkte zu liefern, die niemand verwendet hat. Die Zeremonie vermittelte ein Gefühl des Fortschritts und verschleierte gleichzeitig das Fehlen schwieriger Entscheidungen. Ein gut umgesetztes Framework ersetzt niemals den Mut, Grenzen zu setzen, Nein zu sagen und ein Risiko einzugehen.

Eine ausgereifte technische Führung nutzt Frameworks, um das Urteilsvermögen zu beschleunigen, und nicht, um sich davor zu verstecken. Wenn das Team erklären kann, warum es einen bestimmten Ansatz verwendet und wann es damit aufhören würde, dient die Methode dem Produkt. Wenn niemand eine Antwort darauf weiß, ist das Produkt zum Diener der Methode geworden.

Schließung

Produktdesign-Frameworks sind Denkwerkzeuge, keine Erfolgsformeln. Was in der Praxis diejenigen, die befreien, von denen unterscheidet, die nur Rituale durchführen, ist die Fähigkeit zu wissen, welches Ritual sie wann anwenden und wann sie es aufgeben sollten.

Der beste Produktdesigner ist nicht derjenige, der den schönsten Prozess verfolgt. Es ist das, was das richtige Ergebnis liefert und gegebenenfalls den Prozess selbst unterbricht, um dorthin zu gelangen.

Wenn Ihr Team weiterhin Frameworks befolgt, ohne dass sich die Ergebnisse verbessern, liegt das Problem möglicherweise nicht an der Methode, sondern an der Art und Weise, wie sie verwendet wird. Es lohnt sich, darüber zu reden, und es gibt hier weitere Artikel über Entdeckung und Design im Alltag, die tiefer in das Thema eintauchen.