Design Thinking

Design Thinking ist ein nutzerzentrierter, iterativer Innovations- und Problemlösungsansatz. Interdisziplinäre Teams untersuchen menschliche Bedürfnisse, entwickeln unterschiedliche Lösungsideen und prüfen diese anhand von Prototypen. Dabei entwickeln sich Problemverständnis und Lösungsentwurf gemeinsam weiter. Der Ansatz verbindet Perspektiven aus Design, Sozialwissenschaften, Ingenieurwissenschaften und Wirtschaft (Meinel & Leifer, 2011; Lindberg et al., 2011).

Ziel und Grundverständnis

Design Thinking soll Teams dabei unterstützen, relevante Probleme aus der Perspektive der Nutzenden zu verstehen und geeignete Lösungen zu entwickeln. Im Mittelpunkt stehen drei miteinander verbundene Fragen: Ist die Lösung für die Nutzenden wünschenswert? Ist sie technisch umsetzbar? Ist sie wirtschaftlich tragfähig? Der Ansatz zielt darauf, diese Perspektiven im Gestaltungsprozess zusammenzuführen. Seine Anwendung garantiert jedoch keinen Innovationserfolg (Meinel & Leifer, 2011).

Zu Beginn steht eine vorläufige Problemstellung. Das Team untersucht zunächst, welche Bedürfnisse, Erfahrungen und Nutzungskontexte tatsächlich relevant sind. Erst auf dieser Grundlage verdichtet es seine Erkenntnisse zu einer begründeten Problemsicht. Diese bleibt überprüfbar: Die Erprobung einer Lösung kann zeigen, dass nicht nur der Entwurf, sondern auch das zugrunde liegende Problemverständnis angepasst werden muss (HPI d-school, o. J.).

Grundprinzipien

Meinel und Leifer beschreiben vier Gestaltungsregeln. Sie verdeutlichen, welche Haltung die Zusammenarbeit und die Entwicklung von Lösungen prägen soll (Meinel & Leifer, 2011, S. xv).

• Menschliche und soziale Zusammenhänge berücksichtigen: Die Human Rule betont, dass Gestaltung grundsätzlich sozial geprägt ist. Das Team betrachtet deshalb nicht nur technische Funktionen, sondern auch menschliche Bedürfnisse und die Beziehungen zwischen den Beteiligten.
• Mehrdeutigkeit zunächst zulassen: Die Ambiguity Rule fordert Offenheit für unterschiedliche Deutungen und Lösungsrichtungen. Eine vorschnelle Festlegung kann verhindern, dass das Team neue Zusammenhänge erkennt oder alternative Lösungen erprobt.
• Bestehende Lösungen verstehen: Die Re-Design Rule hebt hervor, dass Gestaltung an frühere Lösungen anknüpft. Das Team untersucht, wie vergleichbare Bedürfnisse bisher erfüllt wurden und welche neuen Möglichkeiten sich durch veränderte technische und soziale Bedingungen ergeben.
• Ideen greifbar machen: Die Tangibility Rule beschreibt Prototypen als Kommunikationsmittel. Skizzen, Modelle und Simulationen schaffen eine gemeinsame Grundlage, um Ideen zu diskutieren und unterschiedliche Vorstellungen sichtbar zu machen.

Diese Regeln sind keine starren Arbeitsschritte. Sie ergänzen das Prozessmodell und sollen insbesondere Experimentieren, Perspektivenvielfalt und gemeinsames Lernen unterstützen (Meinel & Leifer, 2011).

Vorgehen: Das sechsstufige Modell der HPI d-school

Die HPI d-school in Potsdam unterscheidet sechs Phasen: Verstehen, Beobachten, Sichtweise definieren, Ideen finden, Prototypen entwickeln und Testen. Das Modell strukturiert die Arbeit, schreibt aber keinen starren Ablauf vor. Je nach Erkenntnisstand kann das Team einzelne Phasen erneut durchlaufen oder zu früheren Phasen zurückkehren (HPI d-school, o. J.).

1. Verstehen

Das Team klärt die Ausgangssituation und grenzt den Untersuchungsbereich ein. Es sichtet vorhandenes Wissen, untersucht vergleichbare Vorhaben und benennt offene Fragen. Eine vorläufige Gestaltungsfrage beschreibt die Herausforderung aus Sicht der Nutzenden, ohne bereits eine bestimmte Lösung vorauszusetzen. Daraus leitet das Team einen Plan für die weitere Untersuchung ab (HPI d-school, o. J.).

2. Beobachten

Das Team untersucht die Lebens- und Arbeitswelt der relevanten Personen. Dazu führt es beispielsweise Interviews und beobachtet konkrete Nutzungssituationen. Ziel ist es, Bedürfnisse, Verhaltensweisen und Schwierigkeiten im jeweiligen Kontext zu verstehen. Die direkte Auseinandersetzung mit den Nutzenden ergänzt das vorhandene Fachwissen und ermöglicht es, bisherige Annahmen zu hinterfragen (HPI d-school, o. J.).

3. Sichtweise definieren

Das Team führt die erhobenen Informationen zusammen und sucht nach wiederkehrenden Mustern. In dieser Synthese verdichtet es die Ergebnisse zu einer begründeten Problemsicht. Es legt fest, für welche Nutzungsgruppe und welches Bedürfnis es Lösungen entwickeln möchte. Entscheidend ist, dass die Problemsicht auf den Untersuchungsergebnissen aufbaut und nicht lediglich die ursprünglichen Vermutungen des Teams wiederholt (HPI d-school, o. J.).

4. Ideen finden

Das Team entwickelt unterschiedliche Lösungsansätze. Kreativitätstechniken wie Brainstorming oder Rollenspiele können dabei helfen, die Bandbreite möglicher Lösungen zu erweitern. Anschließend ordnet und bewertet das Team die Ideen. Es wählt Ansätze aus, die zu den erkannten Bedürfnissen passen und sich für eine weitere Untersuchung eignen (HPI d-school, o. J.).

5. Prototypen entwickeln

Das Team überführt ausgewählte Ideen in vereinfachte, erprobbare Darstellungen. Je nach Fragestellung eignen sich beispielsweise Papiermodelle, digitale Entwürfe, Videos oder inszenierte Dienstleistungsabläufe. Der Prototyp muss noch kein fertiges Produkt sein. Er soll wesentliche Eigenschaften der Lösung erfahrbar machen und eine gezielte Auseinandersetzung mit ihren Annahmen ermöglichen (HPI d-school, o. J.).

6. Testen

Das Team erprobt die Prototypen mit potenziellen Nutzenden und bezieht bei Bedarf weitere Fachleute oder Projektpartner ein. Es dokumentiert Beobachtungen und Rückmeldungen und vergleicht diese mit der bisherigen Problemsicht. Daraus leitet es ab, welche Eigenschaften der Lösung angepasst werden müssen und welche Fragen weitere Untersuchungen erfordern (HPI d-school, o. J.).

Iteration: Problem und Lösung gemeinsam weiterentwickeln

Iteration bedeutet nicht, nach jedem Test den gesamten Prozess neu zu beginnen. Das Team entscheidet anhand der gewonnenen Erkenntnisse, welche Phase erneut bearbeitet werden muss. Ist beispielsweise ein Entwurf unverständlich, kann eine Anpassung des Prototyps ausreichen. Zeigt sich dagegen ein bislang übersehenes Bedürfnis, muss das Team möglicherweise erneut beobachten und seine Problemsicht verändern. Problemraum und Lösungsraum werden auf diese Weise wiederholt aufeinander abgestimmt (Lindberg et al., 2011; HPI d-school, o. J.).

Für die praktische Durchführung empfiehlt sich, vor jedem Test drei Fragen festzuhalten:

• Welche Annahme soll der Prototyp prüfen?
• Welche Personen und Nutzungssituationen sind dafür relevant?
• Welche Beobachtungen würden eine Änderung der Lösung oder der Problemsicht begründen?

Diese Fragen dienen als Dokumentationshilfe für das hier beschriebene Vorgehen. Sie sind kein zusätzlicher, verbindlicher Bestandteil des HPI-Prozessmodells.

Bedeutung für die IT-Entwicklung

Für die Wirtschaftsinformatik ist Design Thinking insbesondere dort relevant, wo technische Möglichkeiten und menschliche Bedürfnisse aufeinander abgestimmt werden müssen. Lindberg, Meinel und Wagner untersuchen den Ansatz als Ergänzung zur IT-Entwicklung. Im Mittelpunkt steht ein mehrperspektivisches Verständnis komplexer Probleme, das eine überwiegend technische Betrachtung erweitert (Lindberg et al., 2011).

Design Thinking ist dabei nicht mit einem vollständigen Softwareentwicklungsverfahren gleichzusetzen. Sein Beitrag liegt vor allem in der Erkundung von Problemen, der Entwicklung alternativer Lösungsansätze und ihrer nutzerbezogenen Erprobung. Die Verbindung mit bestehenden Entwicklungsprozessen muss deshalb bewusst gestaltet werden. Auch organisatorische Bedingungen können beeinflussen, wie sich der Ansatz in der IT-Entwicklung einsetzen lässt (Lindberg et al., 2011).

Anwendungsbeispiel: Einen digitalen Verwaltungsservice gestalten

Das folgende, hypothetische Beispiel veranschaulicht das Vorgehen. Eine Behörde möchte einen Antragsprozess verbessern. Statt sofort ein neues Onlineformular zu entwerfen, untersucht das Team zunächst, wie Antragstellende den bestehenden Ablauf erleben und an welchen Stellen Schwierigkeiten entstehen.

Interviews und Beobachtungen könnten zeigen, dass nicht die Eingabe selbst das zentrale Problem ist. Möglicherweise ist unklar, welche Nachweise erforderlich sind oder wie der Bearbeitungsstand abgefragt werden kann. Das Team formuliert daraufhin eine präzisere Gestaltungsfrage und entwickelt unterschiedliche Lösungsansätze. Denkbar wären eine verständlichere Nachweisübersicht, eine schrittweise Eingabehilfe oder eine Statusanzeige.

Vereinfachte Prototypen machen diese Ansätze vergleichbar. Das Team prüft mit potenziellen Nutzenden, welche Informationen verständlich sind und welche Fragen offenbleiben. Die Ergebnisse bestimmen, ob es den Entwurf verbessert, weitere Alternativen entwickelt oder das Problem erneut untersucht.

Grenzen und Anwendungshinweise

Ein überzeugender Prototyp ist noch kein Nachweis für den Erfolg einer späteren Umsetzung. Die Forschung zu Design Thinking untersucht ausdrücklich, unter welchen Bedingungen der Ansatz wirkt und wie sich seine Ergebnisse bewerten lassen. Aussagen über einen garantierten Innovationserfolg sind deshalb nicht gerechtfertigt (Meinel & Leifer, 2011).

Für die Anwendung empfiehlt sich daher, Beobachtungen, Interpretationen und offene Annahmen getrennt zu dokumentieren. Ebenso sollte das Team festhalten, welche Nutzungsgruppen beteiligt waren und welche Perspektiven noch fehlen. So bleibt nachvollziehbar, worauf eine Gestaltungsentscheidung beruht und welche Fragen vor der Umsetzung weiter geprüft werden müssen.

Literatur

• HPI d-school. (o. J.). Design Thinking. Hasso-Plattner-Institut. Abgerufen am 7. November 2026, von https://hpi.de/d-school/themen/design-thinking/
• Lindberg, T., Meinel, C., & Wagner, R. (2011). Design thinking: A fruitful concept for IT development? In H. Plattner, C. Meinel, & L. Leifer (Eds.), Design thinking: Understand – improve – apply (pp. 3–18). Springer. https://doi.org/10.1007/978-3-642-13757-0_1
• Meinel, C., & Leifer, L. (2011). Design thinking research. In H. Plattner, C. Meinel, & L. Leifer (Eds.), Design thinking: Understand – improve – apply (pp. xiii–xxi). Springer. Frei zugänglicher Volltext