Design Thinking in der Softwareentwicklung: Der Prozess, der Produkte besser macht

Design Thinking in der Softwareentwicklung

"Wir haben genau das gebaut, was im Requirement stand." "Ja, aber die Nutzer verwenden es nicht."

Dieses Gespräch findet täglich in Unternehmen statt. Das Problem: Wir bauen, was gefordert wird - nicht, was gebraucht wird.

Design Thinking löst dieses Problem. Es stellt Nutzer ins Zentrum und führt zu Produkten, die Menschen tatsächlich verwenden wollen.

Inhaltsverzeichnis

1. Was ist Design Thinking?
2. Die 5 Phasen des Prozesses
3. Design Thinking vs. Agile
4. Praktische Anwendung in Tech-Projekten
5. Tools und Methoden
6. Fallbeispiele
7. Häufige Fehler vermeiden
8. FAQ

---

Was ist Design Thinking?

Design Thinking ist ein nutzerzentrierter Problemlösungsansatz, der durch Empathie, Kreativität und Iteration zu innovativen Lösungen führt.

Die Kernprinzipien

1. Nutzerzentrierung: Verstehen, was Menschen wirklich brauchen
2. Interdisziplinäre Teams: Verschiedene Perspektiven zusammenbringen
3. Prototyping: Ideen früh greifbar machen
4. Iteration: Schnell lernen, schnell anpassen
5. Experimentierfreude: Fehler als Lernen verstehen

Woher kommt Design Thinking?

Entwickelt wurde der Ansatz an der Stanford d.school und durch die Designagentur IDEO populär gemacht. Heute nutzen es Unternehmen wie Apple, Google, SAP und Airbnb.

Warum es für Software relevant ist

Traditionelle Entwicklung	Mit Design Thinking
Requirements → Code → Release	Understand → Ideate → Prototype → Test → Build
Annahmen über Nutzer	Validierte Erkenntnisse über Nutzer
Spätes Nutzerfeedback	Kontinuierliches Nutzerfeedback
Teure Änderungen	Frühe, billige Korrekturen

---

Die 5 Phasen des Prozesses

Phase 1: Empathize (Verstehen)

Ziel: Die Welt aus Sicht der Nutzer verstehen.

Aktivitäten:

• Nutzer-Interviews (nicht Anforderungs-Workshops!)
• Beobachtung im echten Kontext
• Shadowing (Nutzer bei der Arbeit begleiten)
• Customer Journey Mapping

Fragen:

• Was frustriert die Nutzer aktuell?
• Welche Workarounds haben sie entwickelt?
• Was sind ihre eigentlichen Ziele (nicht die angegebenen)?
• Welche Emotionen spielen eine Rolle?

Output: Empathy Maps, Persona Drafts, Journey Maps, Quotes & Insights

Zeitaufwand: 1-2 Wochen (mindestens 5-10 Interviews)

Phase 2: Define (Definieren)

Ziel: Das richtige Problem formulieren.

Aktivitäten:

• Insights synthetisieren
• Patterns erkennen
• Problem Statement (POV) formulieren
• "How Might We" Fragen entwickeln

Das Point of View (POV) Template:

[Nutzer] braucht [Bedürfnis], weil [Insight].

Beispiel: "Ein Buchhalter im Mittelstand braucht eine Möglichkeit, Rechnungen in 10 Sekunden zu erfassen, weil er täglich 50 Rechnungen bearbeitet und der manuelle Prozess 3 Minuten pro Rechnung dauert."

How Might We (HMW) Fragen:

• HMW die Rechnungserfassung automatisieren?
• HMW Fehler bei der Dateneingabe eliminieren?
• HMW dem Buchhalter Zeit für strategische Aufgaben geben?

Output: Problem Statement, HMW-Fragen, Priorisierte Insights

Phase 3: Ideate (Ideen entwickeln)

Ziel: Möglichst viele Lösungsideen generieren.

Aktivitäten:

• Brainstorming (mit Regeln!)
• Crazy 8s (8 Ideen in 8 Minuten)
• Brainwriting
• SCAMPER-Methode
• Analogien aus anderen Branchen

Brainstorming-Regeln:

1. Quantität vor Qualität
2. Keine Kritik während der Ideenfindung
3. Auf Ideen anderer aufbauen
4. Wilde Ideen ermutigen
5. Visualisieren

Ideenbewertung: Nach dem Brainstorming clustern und priorisieren:

• Impact vs. Effort Matrix
• Dot Voting
• Feasibility Check

Output: 50-100+ Ideen, geclustert und priorisiert

Phase 4: Prototype (Prototypen bauen)

Ziel: Ideen greifbar und testbar machen.

Typen von Prototypen:

Typ	Beschreibung	Aufwand
Paper Prototype	Skizzen auf Papier	30 Min
Klickbarer Prototyp	Figma, Sketch, InVision	1-3 Tage
Wizard of Oz	Mensch simuliert Technologie	1 Tag
Concierge MVP	Service manuell erbringen	1-2 Wochen
Funktionaler Prototyp	Minimaler Code	1-4 Wochen

Die goldene Regel:

"Wenn du nicht beschämt bist von der ersten Version deines Produkts, hast du zu spät gelauncht." - Reid Hoffman (LinkedIn)

Output: Testbarer Prototyp (so einfach wie möglich)

Phase 5: Test (Testen)

Ziel: Lernen, was funktioniert und was nicht.

Aktivitäten:

• Usability Tests mit echten Nutzern
• A/B-Tests (wenn möglich)
• Beobachten, nicht erklären
• Feedback sammeln

Testregeln:

1. Neutral bleiben ("Du testest den Prototyp, nicht dich")
2. Beobachten, was Nutzer TUN, nicht nur was sie SAGEN
3. Nach dem "Warum" fragen
4. Notizen für alle sichtbar
5. Schnell iterieren

Was Sie lernen wollen:

• Verstehen Nutzer das Konzept?
• Können sie die Kernaufgaben lösen?
• Wo bleiben sie stecken?
• Was überrascht Sie?

Output: Validierte/Invalidierte Annahmen, Verbesserungsvorschläge, Nächste Iteration

---

Design Thinking vs. Agile

Die Unterschiede

Aspekt	Design Thinking	Agile
Fokus	Problem finden & verstehen	Lösung bauen & liefern
Frage	Was sollen wir bauen?	Wie bauen wir es?
Output	Validiertes Konzept	Funktionierendes Produkt
Timing	Vor der Entwicklung	Während der Entwicklung

Kombination: Double Diamond

Das Double Diamond Modell zeigt, wie beides zusammenpasst:

         Discover → Define → Develop → Deliver
             ↘         ↙        ↘         ↙
              Diamond 1          Diamond 2
           (Design Thinking)      (Agile)

Diamond 1 (Design Thinking):

• Discover: Problem erkunden (divergent)
• Define: Problem fokussieren (konvergent)

Diamond 2 (Agile):

• Develop: Lösungen entwickeln (divergent)
• Deliver: Lösung verfeinern (konvergent)

Integration in Scrum

Sprint-Phase	Design Thinking Aktivität
Refinement	User Research Insights einbringen
Planning	Prototypen als Anforderungsbasis
Sprint	Usability Tests parallel zur Entwicklung
Review	Nutzerfeedback integrieren
Retro	Design-Learnings reflektieren

---

Praktische Anwendung in Tech-Projekten

Anwendungsfall 1: Neues Feature

Ohne Design Thinking:

1. PM schreibt User Story
2. Entwickler baut Feature
3. Nutzer beschweren sich
4. Redesign nötig

Mit Design Thinking:

1. Nutzer-Interviews: Was ist das Problem?
2. Problem definieren: Was genau lösen wir?
3. Ideen generieren: Welche Lösungen gibt es?
4. Prototyp bauen: Low-fidelity Test
5. Testen: Funktioniert es?
6. Erst dann: Entwicklung

Anwendungsfall 2: Produkt-Neustart

Situation: Bestehendes Produkt wird nicht genutzt.

Design Thinking Ansatz:

1. Empathize: Warum nutzen es die Leute nicht?

   • Exit Interviews mit abgewanderten Nutzern
   • Beobachtung der wenigen aktiven Nutzer
   • Support-Tickets analysieren

2. Define: Was ist das eigentliche Problem?

   • Vielleicht: Falsches Problem gelöst
   • Vielleicht: Richtiges Problem, falsche Lösung
   • Vielleicht: Gutes Produkt, schlechte Onboarding

3. Ideate → Prototype → Test: Iteration bis Lösung

Anwendungsfall 3: Interne Tools

Häufiger Fehler: Interne Tools ohne Design Thinking bauen, weil "wir die Nutzer ja kennen."

Realität: Interne Nutzer sind genauso anspruchsvoll - und wenn das Tool nervt, entstehen Workarounds.

Lösung:

• Kollegen als echte Nutzer behandeln
• Shadowing in deren Arbeitsalltag
• Prototypen testen
• Iteration nach Feedback

---

Tools und Methoden

Für Empathize

Empathy Map:

        SAGT           |          DENKT
  Was sagt der Nutzer? | Was denkt er wirklich?
-----------------------|------------------------
        TUT            |          FÜHLT
   Was tut der Nutzer? | Was fühlt er dabei?

Customer Journey Map: Touchpoints des Nutzers mit Emotionen, Pain Points und Opportunities.

Interview-Leitfaden:

• Offene Fragen stellen
• "Erzähl mir von einem typischen Tag..."
• "Was war das letzte Mal, als...?"
• "Warum?" (5x Why Methode)

Für Define

Problem Statement Canvas:

• Wer hat das Problem?
• Was ist das Problem?
• Wann/Wo tritt es auf?
• Warum ist es wichtig?

Jobs to be Done (JTBD): "Wenn [Situation], will ich [Motivation], damit ich [Ergebnis]."

Für Ideate

Crazy 8s:

1. Papier 8x falten
2. 8 Ideen in 8 Minuten skizzieren
3. Keine Zensur
4. Teilen und diskutieren

SCAMPER:

• Substitute (Ersetzen)
• Combine (Kombinieren)
• Adapt (Anpassen)
• Modify (Modifizieren)
• Put to other use (Anders nutzen)
• Eliminate (Eliminieren)
• Reverse (Umkehren)

Für Prototype

Papier-Prototypen: Schnell, billig, keine Software nötig

Figma/Sketch: Klickbare Prototypen in Stunden

Framer/Webflow: Interaktive Prototypen mit echtem Code-Feel

Für Test

5-Second-Test: Zeige Prototyp 5 Sekunden, frage: "Worum geht es?"

Task-Based Usability Test: "Finde das Feature X und nutze es."

Think-Aloud Protocol: Nutzer verbalisiert Gedanken während Nutzung

---

Fallbeispiele

Airbnb: Von Pleite zu Milliarden

Problem: 2009 war Airbnb fast pleite. Niemand buchte.

Design Thinking Ansatz:

• Gründer besuchten Gastgeber persönlich
• Erkannten: Schlechte Fotos der Wohnungen
• Lösung: Professionelle Fotografie anbieten

Ergebnis: Buchungen stiegen sofort. Heute: $80 Mrd. Bewertung.

IBM: Enterprise Design Thinking

Problem: IBM baute Produkte, die niemand nutzen wollte.

Lösung: Enterprise Design Thinking Programm

• 10.000+ Mitarbeiter geschult
• Design Studios in jedem Bereich
• Nutzerforschung als Pflicht

Ergebnis:

• 75% schnellere Time-to-Market
• 300% Return on Investment

Spotify: Squad Model

Problem: Wie skaliert man Design Thinking?

Lösung: Autonome Squads mit

• Eigenem Designer
• Eigenem User Researcher
• Empowerment für Nutzerforschung

Ergebnis: Kontinuierliche Innovation trotz Größe.

---

Häufige Fehler vermeiden

Fehler 1: Design Thinking als Workshop-Event

Problem: Ein 2-Tages-Workshop, dann zurück zum Alltag.

Lösung: Design Thinking als kontinuierlicher Prozess, nicht als Event.

Fehler 2: Mit Lösungen starten

Problem: "Wir wollen eine App bauen. Macht mal Design Thinking."

Lösung: Mit dem Problem starten, nicht mit der Lösung.

Fehler 3: Nutzer nicht wirklich befragen

Problem: "Wir kennen unsere Nutzer" (basierend auf Annahmen).

Lösung: Echte Nutzer, echte Gespräche, echte Beobachtung.

Fehler 4: Zu lange im Prozess bleiben

Problem: Endlose Empathize-Phase, nie zum Bauen kommen.

Lösung: Timeboxen. 2 Wochen Empathize, dann weiter.

Fehler 5: Nur Designer machen Design Thinking

Problem: Entwickler bekommen "fertige" Konzepte.

Lösung: Cross-funktionale Teams von Anfang an.

---

Fazit

Design Thinking ist kein Ersatz für gute Entwicklung - es ist die Voraussetzung dafür. Bevor Sie eine Zeile Code schreiben, sollten Sie wissen:

1. Wer hat das Problem?
2. Was ist das eigentliche Problem?
3. Warum ist es wichtig?
4. Welche Lösung funktioniert?

Die Investition in diese Fragen spart Monate an Entwicklungszeit für Features, die niemand nutzt.

Bei Balane Tech starten wir jedes Projekt mit dem Nutzer, nicht mit dem Code. Kontaktieren Sie uns für mehr Informationen.

---

FAQ

Wie lange dauert ein Design Thinking Prozess?

Minimal 2 Wochen (Sprint-Format), typisch 4-8 Wochen für komplexe Probleme. Kann auch als kontinuierlicher Prozess laufen.

Brauche ich einen professionellen Designer?

Nicht unbedingt. Die Methoden kann jeder lernen. Für hochwertige visuelle Prototypen hilft ein Designer, aber für Papier-Prototypen reicht gesunder Menschenverstand.

Funktioniert Design Thinking für B2B-Software?

Besonders gut sogar. B2B-Nutzer haben oft komplexere Probleme und mehr Workarounds. Die Insights sind Gold wert.

Was, wenn Nutzer nicht wissen, was sie wollen?

Das ist normal - und genau deshalb Design Thinking. Man fragt nicht "Was willst du?", sondern beobachtet Probleme und testet Lösungen.

Wie überzeuge ich mein Management?

ROI-Argumente: Weniger Fehlentwicklung, schnellere Time-to-Market, höhere Nutzerakzeptanz. IBM berichtet 300% ROI.

Ist Design Thinking nur für neue Produkte?

Nein. Auch bestehende Produkte profitieren: Feature-Priorisierung, Redesigns, Problemanalyse bei schlechter Adoption.