Fortschritt:

Design Thinking

Thinking (nach Marczewski)

  1. Define (Definieren)
  2. Empathise (Einfühlen)
  3. Ideate ("Ideen entwickeln")
  4. Experiment (Experimentieren)
  5. Test (Testen)
  6. Innovation Lenses
    1. Desirability (Erwünschtheit)
    2. Feasibility (Durchführbarkeit)
    3. Viability (Lebensfähigkeit)
  7. User View

1. Design Thinking (nach Marczewski)


Der Design Thinking Ansatz nach Marczewski ist ein etwas detaillierterer Ansatz, als es GAME ist. Zudem wird er des Häufigeren zur Entwicklung von Spielen herangezogen, so auch bei Gamification.

Das Hauptschema unterteilt sich dabei in fünf Teile: Define (Definieren), Empathise (Einfühlen), Ideate ("Ideen entwickeln"), Experiment (Experimentieren), Test (Testen). Diese werden nun näher beschrieben.

2.1 Define (Definieren)

Define bedeutet eigentlich nur, dass das aktuelle Problem verstanden und klar definiert wird. Dazu gehört, dass man dieses immer wieder hinterfragen sollte, um sich dessen Bedeutung klar zu sein und Fehler bei der Interpretation auszuschließen.[1]

2.2 Empathise (Einfühlen)

Der Kunde ist auch hier quasi "König". Bei Empathise steht der Nutzer an der ersten Stelle, das heißt, es geht um die Frage nach dem Nutzertyp(en). Wer sind diese und warum soll ein solcher Ansatz für welchen Zweck angewandt werden. Deren Ziele sollten klargestellt und mögliche Reaktionen abgeschätzt werden.[2]

2.3 Ideate ("Ideen entwickeln")

Ideate beinhaltet im Großen und Ganzen nur das Sammeln von Ideen für den Gamification Ansatz. Zusätzlich sollen die gefundenen Lösungsideen auf ihre Sinnhaftigkeit analysiert werden, bevor es an das Experimentieren geht.[3]

2.4 Experiment (Experimentieren)

Die Experiment-Phase dient dazu, aus den nun besten gesammelten Ideen, Stück für Stück einen Prototyp zu entwerfen, von dem man der Meinung ist, er sei das vorerst bestmögliche System.[4]

2.5 Test (Testen)

Letztendlich geht es hier nun um das Testen des zuvor entworfenen Prototypens an einer Zielgruppe.[5]
game ueberblick
Abbildung 1: Design Thinking Schema (FIGURE 49, Marczewski (2015), S.187)

Allgemein ist dazu noch zu sagen, dass es innerhalb dieses Schema wichtig ist, zu jedem Zeitpunkt des Ablaufs auch wieder Schritte zurückgehen zu können. Dennoch sollten keine übereilten oder unüberlegten Schritte begangen werden.[6]

3. Innovation Lenses

Zu den genannten Schritten gibt es laut Marczewski sogenannte Innovation Lenses. Dies sind im Prinzip Rahmen, beziehungsweise unterstützende Maßnahmen, die bei den Phasen Ideate, Experiment und Test eine Rolle spielen. Sie unterteilen sich in drei Bereiche.

3.1 Desirability (Erwünschtheit)

Hierbei hinterfragt man den eigenen Prozess punkto der Erwünschtheit beim Kunden. Denn nicht alles, was einem selbst als Entwickler gefällt oder der eigenen Meinung nach in dem System nicht fehlen sollte, muss nicht gleichzeitig auch dem Kunden gefallen. Der Kunde kann andere Vorstellung und Ziele haben und gerade auf diese sollte man sich fixieren.[7]

3.2 Feasibility (Durchführbarkeit)

Die Frage, die man sich laut Marczewski auch immer stellen sollte, ist, ob das Projekt überhaupt umsetzbar ist. Der Blick geht hier auf finanzielle oder sonstige Ressourcen, die zur Umsetzung benötigt werden. Sind diese nicht vorhanden oder möglich, sollte man das Vorhaben neu strukturieren.[8]

3.3 Viability (Lebensfähigkeit)

Die Viability stellt sich in etwa ähnlich wie die Feasibility dar. Man stellt sich die Frage, ob das Projekt, wenn es umgesetzt wurde, so bestehen kann oder nicht und welcher weiteren Unterstützung es bedarf (auch finanziell), um es "am Leben zu halten".[9]

4. User View

Wie schon in den Bereichen zuvor angemerkt, ist die wohl wichtigste Rolle beim "Frameworking" der Nutzer. So hat Marczewski die Nutzersicht als einzelnen wichtigen Punkt aufgefasst. Hier wird am meisten der Punkt Empathise und der Desirability verdeutlicht. Sich also immer zu hinterfragen: Welchen Zweck hat das was ich tue für den Nutzer? Welche Auswirkungen hat dies später beim Nutzer? Ist die aktuelle Umsetzung oder Verbesserung für den Nutzer überhaupt von Nöten oder gar relevant?[10]
Marczewski Zwiebel
Abbildung 2: "The user doesn't care!" ((FIGURE 52, Marczewski (2015), S.192)

Marczewski stellt dabei eine Hierarchie der Teilbereiche der Entwicklung auf, die von mehr und minderer Bedeutung beim Nutzer sind:

So kommt es dem Nutzer deutlich mehr auf Feedback-Bereiche innerhalb des Systems an, die ihm Rückmeldungen geben, wie "correct" oder eine ganze Auswertungs-Umgebung.[11]

Von sehr geringer Bedeutung dahingegen spielt bei dem Nutzer die Umsetzung des Systems. „Den Nutzer kümmert es nicht wie clever ein Entwickler war. Sie wollen nur ein System das läuft und anwendbar ist.“[12]

Somit bleibt abschließend der Punkt, dass die "Probleme des Nutzers, definitiv mehr die Probleme des Entwicklers"[13]sind und man immer darauf achten sollte, welche Ideen oder Umsetzungen auch wirklich für den Nutzer relevant sind.

Quellen

[0]  Marczewski, A. (2015), Gamified UK: Even Ninja Monkeys Like to Play – Gamification, Game Thinking & Motivational Design, S.184
[1]  Ebd, S.186
[2]  Ebd, S.186
[3]  Ebd, S.186
[4]  Ebd, S.186
[5]  Ebd, S.186
[6]  Ebd, S.187
[7]  Ebd, S.188
[8]  Ebd, S.188
[9]  Ebd, S.188
[10]  Ebd, S.191
[11]  Ebd, S.192
[12]  Ebd, S.193
[13]  Ebd, S.193