ux

Geschichten sind unsere Art, die Welt zu verstehen. Das Gewebe aus wenn –> dann, Motivation, Konflikt und Auflösung hilft uns, aus einer Menge von Daten Wissen zu generieren.

Personas, User Journeys und Szenarios sind hilfreiche Tools, die besonders im Zusammenhang ihre Kraft entfalten. 

Eine Persona beschreibt die handelnde Person, ihre inneren Notwendigkeiten und vielleicht auch äussere Zwänge, die sich aus dieser Persona ergeben und nicht allgemein sind. Wichtig sind dabei die Aspekte, die für die nachfolgende Handlung in der User Journey relevant sind.

Das Drama, dass sich aus der Begegnung der Person(a) und ihren aus innerer Notwendigkeit geborenen Wünschen mit der Realität ergibt, diktiert den Bogen der gesamten Geschichte, die durchlaufen wird: die User Journey. Wie bei jedem Drama ist es wichtig, diese Reise abzugrenzen. Also genau zu überlegen, welchen Teil des Lebens unserer Person(a) wir uns ansehen. 

Zum wichtigsten Teil kommen wir eigentlich, wenn wir uns mit dem Szenario beschäftigen. Denn das beschreibt den eigentlichen Kontaktpunkt mit dem, das wir bauen wollen: die detaillierte Interaktion in einem Schritte der Journey der Persona. 

Nehmen wir ein Beispiel: wir sollen einen neuen Fahrkartenautomaten entwickeln. Wie auch immer die Persona aussieht, die wir uns dabei vorstellen – ob alt oder jung, eilig oder mit Zeit, technisch versiert oder nicht – müssen wir uns erst gewahr werden, das diese Persona überhaupt keine Fahrkarte kaufen möchte.

Die Persona möchte vielmehr aus innerer Motivation heraus ein Verkehrsmittel benutzen, um zu einem Ziel zu gelangen. Die für uns relevante Journey beginnt also mit der Formulierung des Ziels und endet mit der Ankunft.

Die Aufgabe einen neuen Fahrkartenautomaten zu bauen, definiert unser Szenario als das Geschehnis des Kaufs.  Die vielen kleinen Dramen, die sich hier abspielen können – der unverständliche Wabenplan, die unklare Zielauswahl, die verwirrenden unterschiedlichen Fahrpreisangebote, Sorgen um die Hygiene an einem öffentlichen Automaten, oder einfach die Sonne, die das Display unlesbar macht – sind zu erkennen, zu priorisieren und mit Lösungen zu versehen. 

Und eine Lösung kann dann auch sein, dass man statt eines Fahrkartenautomaten eine kontaktlose Prepaid-Lösung wie die OV-chipcaard in den Niederlanden vorschlägt.  

Manche Entwürfe müssen schnell entstehen, damit man sie schnell abstimmen kann: mit Stift und Papier, gemeinsam am Board (virtuelle oder zusammen in einem Raum) oder auch mit Software wie Axure oder Balsamiq, die schnelle “Quick & Dirty” Visualisierungen von Ideen erlauben.

Entwürfe, die mehr Design und weniger nur Idee sind, entstehen mit mehr Zeit. Sie kommunizieren, spezifizieren und dokumentieren genauer das gewünschte Endprodukt.

Das können Wireframes sein, die zum Beispiel mit Sketch ein genaues Bild der Screens zeichnen, oder stärker Funktional dokumentieren, wie mit Axure. 

Das können User Stories sein, Spezifikationen und funktionale Beschreibungen. 

Dies funktioniert besonders gut, wenn es bereits ein Design System gibt, das grundlegendes und bereits verwendetes definiert. So muss nicht jedes Mal über Farben, Buttons und Typographie geredet werden, sondern es gibt fertige Komponenten, die nach einem Baukastenprinzip zusammengesetzt und bei Bedarf ergänzt werden können. 

Auch hier sorgt Wiederverwendbarkeit für eine nachhaltige Arbeit.

Testen, testen, testen! Damit schlagen wir die Brücke zurück zur Entdeckung zu Beginn. 

Auch in Bezug auf UX muss Testen systematisiert stattfinden und immer am Ergebnis orientiert sein. Nur wenn wir wissen, was wir beim Nutzer erreichen wollen, können wir diese Veränderung auch messbar machen und ihr Eintreten testen. 

Testen vor Launch verhindert böse Überraschungen.

Aber auch das beständige Sammeln von Feedback nach dem Launch hilft, das Backlog für die Zukunft zu steuern und zu priorisieren. 

Häufig liegt dieses Feedback quasi vor der eigenen Haustür, bei Kundenbetreuern oder zum Beispiel in den Bewertungen in App-Stores.