Design Thinking – Teil 1

Warum nicht einfach mal wie ein Designer denken?

In einer zweiteiligen Blogserie bietet Inga Wiele, ausgebildet am Hasso-Plattner-Institut in Potsdam, einen Einblick in das spannende Konzept und die Methodik hinter Design Thinking.

Neugierig? Auf den SOPHIST DAYS 2014 wird Inga Wiele einen 2-stündigen Workshop zu Design Thinking anbieten.

Lassen Sie sich für Ihre eigenen Projekte inspirieren! 

 

Design Thinking – Erst das Problem verstehen, bevor es gelöst wird

Die Definition von Anforderungen steht in der Regel am Anfang eines Projektes. Fast alle nachfolgenden Entwicklungsschritte bauen darauf auf. Weichen, die in dieser kritischen Projektphase gestellt werden, sind in der Regel später nur sehr aufwändig zu verändern.

Wie kann die Wahrscheinlichkeit erhöht werden, dass die aufgenommenen Anforderungen, zu einer Lösung führen, die den betroffenen Stakeholdern eine Verbesserung (Innovation) bringt?

Design Thinking ist darauf ausgerichtet, Innovationsprozessen Struktur zu geben. Es baut auf bewährten Tools auf und paketiert sie in einem Bündel. Zu diesem Bündel gehören:

  • eine Geisteshaltung, die offen und empathisch auf Menschen (Kunden und Mitarbeiter) blickt,
  • diverse Teams,
  • Räume, die flexibles Arbeiten (vor allem auch im Stehen) ermöglichen,
  • ein in Innovationsprozessen bewährter Prozess.

In diesem Blogbeitrag werde ich auf den Design Thinking Prozess eingehen, der vor allem darauf abzielt, dass das Problem erst verstanden, bevor es gelöst und anschließend die Problemlösung implementiert wird.

A. Problem verstehen

A.1. Verstehen

Die beteiligten Personen (Projektteam, Stakeholder, Endanwender) sind aufgerufen, zuerst ein gemeinsames Problemverständnis zu entwickeln, bevor sie über Lösungen nachdenken.

A.2. Beobachten

Beim Beobachten wird soviel Information wie möglich gesammelt. Das können Interviews, Fachartikel, Experteninterviews, Internetrecherche oder andere Quellen sein. Vor allem geht es aber wirklich um das Beobachten, d.h. bewusstes Hinsehen, wenn Anwender ein Produkt nutzen. Dem Kontext (z.B. lauter Hintergrund, Hektik, Handy am Ohr) kommt dabei eine besondere Rolle zu.

A.3. Standpunkt definieren

Die Beobachtungen werden mit den Aussagen der Nutzer abgeglichen – denn häufig ist Nutzern gar nicht bewusst, wie sie ein Produkt oder eine Serviceleistung wirklich verwenden (z.B. wenn Sie beim Fahrradfahren mit der rechten Hand telefonieren und dann bremsen müssen). Die dabei gewonnenen Einsichten werden in der Gruppe verarbeitet und daraus ein gemeinsamer Fokus auf eine bestimmte Problemstellung entwickelt.

Design Thinkin_Teil 1_Whiteboard

B. Problem lösen

B.1. Ideen finden

Basierend auf den Fragestellungen, die sich aus den Einsichten ergeben, werden so viele Ideen wie möglich gesammelt. Methoden sind dabei verschiedene Brainstorming-Techniken, Achtsamkeitsübungen, Kombinationsexperimente, Spaziergänge….es werden zunehmend mehr.

B.2. Prototypen bauen

Der Prototyp soll das Team in die Lage versetzen, dem Kunden seine Ideen besser zu erklären. Der Kunde soll die Möglichkeit erhalten, mit dem Team in einen Dialog über Problemverständnis und Problemlösung zu gehen, bevor eine teure endgültige Lösung entwickelt wird.

Das Requirements Engineering kann begleitend zum Prototyping erfolgen.

B.3. Iteration

Durch Feedback und Verfeinerung nähern sich die Prototypen sukzessive an die endgültige Lösung an.

C. Implementierung

Der Übergang vom Prototypen zur Implementierung ist letztendlich fließend. Wichtig ist, dass bei der Projektplanung auch Zeit für die Iteration eingeplant wird.

Hier geht es zum zweiten Teil der Blogserie.

Autor: Inga Wiele, gezeitenraum gbr, www.gezeitenraum.com

 

Hinterlasse eine Antwort

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


+ sieben = 13

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>