Hintergrund
Modelle im UX Design

Im User Experience Design spielen Modelle eine wichtige Rolle. Wir modellieren das bestehende und das zukünftige System. Doch warum gibt es keine IST und SOLL-Personas hingegen IST  und SOLL-Szenarien?

Wenn wir ein User Experience Design entwerfen, wollen wir zuerst die Ausgangslage verstehen. Wir untersuchen im Team die heutige Situation suchen nach Verbesserungschancen. Dann beginnen wir an der Lösung zu arbeiten. Wir entwickeln zu den Verbesserungschancen Lösungsideen und erarbeiten ein Lösungskonzept.

Um die Ausgangslage und die Lösung zu beschreiben, nutzen wir als zentrales Hilfsmittel: Modelle. Ein Modell hilft uns zentrale Aspekte in kohärenter Form zu beschreiben. So wie eine Strassenkarte, mögliche Wege zwischen zwei Orten beschreibt, hilft eine Persona, die für das Design relevanten Aspekte von Nutzern zu formulieren.

Ein Modell kann sowohl für die Beschreibung der Ausgangslage - den IST-Zustand - als auch für die neue Lösung - den Soll-Zustand - genutzt werden. Beispielsweise unterscheiden wir IST- und SOLL-Szenarien. Ein IST-Szenario beschreiben einen exemplarischen Anwendungsfall eines Nutzers mit dem heutigen System und hilft uns Schwachstellen aufzuzeigen. Ein SOLL-Szenario beschreibt einen exemplarischen Anwendungsfall eines Nutzers mit dem zukünftigen System und hilft uns bei der Formulierung einer neuen Lösung.

Einige der Modelle sind gegenüber des IST- oder SOLL-Zustandes agnostisch - das heisst, sie können sowohl für  die Beschreibung der Ausgangslage als auch die neue Lösung genutzt werden. Dazu gehören beispielsweise Personas,  Domain Models und Kontextszenarien.

Diese Modelle beschreiben eher den Kontext des Systems und weniger die Lösung - sie sind also weitgehend lösungsneutral. Betrachten wir diesen Umstand am Beispiel der Personas: Die Nutzergruppen und ihre Anforderungen sind ein zentraler Input für die Entwicklung einer User Experience. Sie existieren aber eigentlich unabhängig vom zu gestaltenden System.

Einige Modelle nutzen wir nur für die Beschreibung der Ausgangslage oder für die Beschreibung der neuen Lösung. So könnten wir natürlich auch eine alte Lösung mit Hilfe von Wireframes beschreiben. Das werden wir aber in der Regel nicht tun - warum auch.

Überhaupt ist die Auseinandersetzung mit der heutigen Lösung ist nicht für alle Projekte von gleicher Bedeutung. Entwickeln wir ein ganz neues Produkt, das in dieser Form noch gar nicht existiert, werden wir uns zwar mit dem aktuellen Kontext und den Nutzerzeilen auseinandersetzen. Wir wollen uns aber nicht mit derselben Intensität ein bestehendes Produkt untersuchen, wie wenn wir dieses verbessern sollen. In solchen Fällen verzichten wir allenfalls sogar auf die Beschreibung von IST-Szenarien.