User Centered Design

• Wer ist der Nutzer und was will er mit der Nutzung der Anwendung erreichen? Und wo liegen aktuelle Schmerzpunkte des Nutzers, die mithilfe der Anwendung gelöst werden sollen. Dabei ist es wichtig nicht nur den Nutzer in den Fokus zu nehmen, sondern die Anwendung auch aus den Augen aller anderen Stakeholder zu sehen.
• Das Problem muss identifiziert und aus unterschiedlichen Blickwinkeln betrachtet werden. Das heißt: eine Ursachen-Wirkungsanalyse muss durchgeführt werden.
• Gibt es überhaupt ein Problem oder ist der Nutzer zufrieden aber das Auftraggeber ist mit dem Ergebnis unzufrieden?
• Wenn ja, was genau ist das Problem? Und was ist vielleicht nur eine Ursache des Problems? Bedeutet: das Problem muss auf das kleinste heruntergebrochen werden.
• Was ist unser Ziel? Also wann können wir sagen, wir haben erreicht was wir erreichen wollten?
• Welchen Sinn und Zweck hat das alles?
• Warum brauchen wir das überhaupt?
• Welche unterschiedlichen Ziele haben die einzelnen Stakeholder?

Im nächsten Schritt ist es wichtig festzuhalten, was das System können muss, damit der Nutzer seine Ziele effektiv, effizient und zufriedenstellend erreichen kann. Das beinhaltet zum einen die Voraussetzungen die das System mitbringen muss um das Problem zu lösen. Andererseits aber auch das der Nutzer durch seine Bedienung die Lösung erreichen kann.

Dabei ist es wichtig auch mal den Blickwinkel zu wechseln und verschiedene Kreativitätstechniken zu verwenden (SCAMPER / Innovate like / Negative Brainstorming)

Als Entscheidungshilfe was wirklich gebraucht wird, kann beispielsweise das KANO-Modell dienen.

Sobald dies geklärt ist können mithilfe von Minimum Viable Products (MVPs) Gestaltungslösungen erarbeitet werden. Dabei setzen wir sowohl low fidelity Prototypen als auch high fidelity Prototypen ein.

Gerade bei low fidelity Prototypen ist ein gemeinsames Designen mit dem Team unserer Kunden unabdinglich. Wir skizzieren in Workshops vor Ort gemeinsam erste Ideen auf Papier oder arbeiten mit dem passenden Programm im virtuellen Raum.

So können wir frühzeitig feststellen, dass wir über das Gleiche sprechen. Designfehler und Funktionen, die keinen Mehrwert bringen werden so schnell identifiziert.

Egal wie der Protoyp aussieht – low fidelity Prototypen vs. Beta version – regelmäßiges Testen ist unabdingbar, um Feedback der Nutzer einzuholen und nicht in die Falsche Richtung zu produzieren.

Alles, was wir bis zu diesem Punkt gemacht haben sind Annahmen – nun geht es darum unsere Annahmen zu validieren – denn je früher Abweichungen des Wunsch- und Ist- Status aufgedeckt werden, desto einfacher sind diese zu beheben.