von Dr. Eva Köppen (Design Thinking Strategin)
geschrieben am 27.03.2017
Wer assoziiert Design Thinking nicht mit hippen Leuten, die viele bunte Zettel kleben? Und ganz ehrlich: Wie oft denkt man bei Softwareentwicklung nicht an die genialische, introvertierte Einzelkämpferin? Design Thinking und IT – zwei Bereiche die mit Klischees beladen sind und so gar nicht zusammenzupassen scheinen. Können die kollaborative Kreativität des Design Thinking und IT-Entwicklungsprozesse zusammen funktionieren?
Das Dilemma der technologischen Herangehensweise
„Software design“ wird von Softwareentwicklern betrieben, die eine stark naturwissenschaftliche, deduktiv-rationalistische Ausbildung genossen haben. Die klassischen Methoden des „Design“ gehören meist nicht zum Lehrplan. „Software design“ ist damit eine der wenigen Formen des Designs, die rein technologisch ausgerichtet ist. Damit gehen naheliegende Probleme einher: Eine Software-Designerin weiß häufig nicht, für wen sie designed, obwohl ihre IT-Lösung zunehmend die Lebens- und Arbeitswelten von Menschen prägen. Aber was „innovativ“ ist, wird heutzutage zunehmend von den Nutzern entschieden und nicht davon, was ein Expertengremium für technologische Perfektion hält, stellen Lindberg et al. fest.
Design Thinking als komplementärer Ansatz?
Software-Entwickler können zusätzlich zu ihrer Expertise und ihrem Fachwissen Vorgehensweisen etablieren, die ihnen helfen, die Welt der Nutzer besser zu verstehen und so auf innovative Ideen zu kommen. Als Meta-Konzept kann Design Thinking den Arbeitsalltag von Entwickler-Teams so strukturieren, das Nutzer-Interviews, niedrigschwellige Prototypen und Nutzer-Feedback integriert werden.
Unterschiedliche Denkweisen
Leichter gesagt als getan. Es gibt wesentliche Unterschiede zwischen IT‘lern und Menschen, die mit Design-Ansätzen arbeiten. IT-Entwickler denken mehrheitlich sehr analytisch: Es gibt ein fest definiertes Problem, und dieses kann mithilfe eines naturwissenschaftlichen Ansatzes im Meilensteinverfahren gelöst werden. Die Vorgehensweise ist dabei konvergierend: Man schließt den Fokus immer weiter und nähert sich so der Lösung.
Ganz anders bei Personen mit einem Design-Thinking-Mindset. In ihrer Perspektive gibt es kein klar definiertes Problem. Man spricht hier auch von „wicked problems“. „Wicked problems“ haben keine klare Struktur, sie sind komplex und bestehen aus technologischen sowie sozialen Anteilen. Deshalb nähern sich Designer zunächst dem Problem. Statt zu konvergieren, gehen sie zunächst in einen divergierenden Modus. Sie öffnen den Problemraum, um zunächst alle Facetten des Problembereichs zu verstehen. Im Anschluss konvergieren sie indem sie ihre Ergebnisse synthetisieren. Erst dann gehen sie ganz bewusst in den Bereich des Problemlösens – auch hier wird zunächst alles auf den Tisch gepackt, was es an Ideen gibt (divergierend) um dann einige konkrete Ideen zu prototypen und zu testen (konvergierend) (siehe Abbildung).
Für IT-Entwickler heißt das also, sich offenen Herangehensweisen und anderen Denkstilen zu öffnen.
Was ist mit bestehenden Ansätzen?
Dass der Wasserfall- oder Meilenstein-Ansatz in der Software-Entwicklung mit großen Problemen einhergeht, ist allgemein bekannt. Inwischen gelten diese Vorgehensweisen als zu wenig iterativ und unflexibel. Nutzer spielen meist nur am Ende des Entwicklungsprozesses eine Rolle, wenn schon zu viel Code produziert wurde als das man das Gesamtkonzept noch einmal in Frage stellen könnte.
Agile Entwicklungsmethoden wie Scrum haben versucht, auf diese Probleme eine Antwort zu finden. Die Idee hinter Scrum ist, ein Entwicklungsteam nicht durch feste Roadmaps und rigide Meilensteine zu steuern, sondern durch bestimmte Rollen und Regeln im Team, die ein flexibles Anpassen an neue Anforderungen ermöglichen. Die Anforderungsanalyse ist ein Prozess, der parallel zum Umsetzungsprozess läuft. Entwicklungsschritte sind in kurze Sprints eingeteilt, die Feedbackschleifen mit Experten, Kunden und Nutzern erlauben.
Deutlich sichtbar sind die Parallelen zu den Grundanliegen des Design Thinking, wie bspw. Nutzerzentriertheit und Iteration. Allerdings haben Lindberg et al. festgestellt, dass in agilen Entwicklungsprozessen wiederum divergentes Denken verhindert wird und man sich auf inkrementelle Verbesserung konzentriert, anstatt den Fokus zu öffnen und über radikal neue Ideen nachzudenken.
Design Thinking vorgelagert oder integriert?
Durch meine Arbeit mit Scrum-Mastern habe ich festgestellt, dass Design Thinking gerne als vorgeschalteter Prozess betrachtet wird. Mit Design Thinking lassen sich nutzerzentrierte Konzepte erstellen, deren Güte schnell und kostengünstig getestet werden können. Daraus lassen sich sinnvolle Items für das Scrum-Backlog ableiten. Wichtig ist an dieser Stelle, dass die Softwareentwickler bereits in den Prozess eingebunden sind – damit nicht letzten Endes nur „irgendein Konzept“ über den Zaun geworfen wird, sondern ein Wissen über die Entstehung des Konzepts besteht. Dann erst wird der agile Entwicklungsprozess tatsächlich nutzerzentriert.
Über die Autor*innen
