Von der Anforderung zum UI Design: Nutzungsszenarien als Brücke

Kennt ihr das auch? Ihr habt die Anforderungen an eine Anwendung gesammelt und beschrieben. Jetzt wollt ihr die Benutzeroberfläche gestalten. Aber wie kommt ihr eigentlich von den Anforderungen zum UI Design? Womit fangt ihr an? 

Ich stelle euch in diesem Blogpost das Konzept der “Nutzungsszenarien” als mögliche Brücke zwischen Anforderungen und UI Design vor.

Benutzeroberflächen konzipieren – womit fange ich an?

Wenn es darum geht, Entwürfe für Benutzeroberflächen zu machen, wird oftmals direkt das Prototyping-Werkzeug “Papier und Stift” genannt: “Fang einfach an, skizziere erste Ideen und Anordnungen und prüfe sie.”

Ich bin ebenfalls Fan von Papier und Stift und nutze dieses Werkzeug oft für erste Entwürfe. Aber: Es gibt noch einen Zwischenschritt, den man einschieben kann, um sicherzustellen, dass alle erhobenen Anforderungen im UI Design berücksichtigt werden: Nutzungsszenarien.

Nutzungsszenarien – was heißt das?

Nutzungsszenarien beschreiben vollkommen system- und darstellungsneutral, welche Aktionen Nutzer am späteren System ausführen können und wie das System darauf reagiert. Sie können beispielsweise in Tabellenform aufgebaut werden. Wichtig ist: Gestalterische Komponenten, wie Buttons, Dialoge und Co. kommen an dieser Stelle noch nicht vor. Vielmehr verbindet man die vorher erhobenen Anforderungen und identifizierten Kern- und Teilaufgaben der Nutzer mit Benutzeraktionen und Systemreaktionen.

Das ist euch noch zu abstrakt? Dann hilft vielleicht ein Beispiel:

Blick in die Praxis: Wie aus dem Brief die E-Mail wurde

Nehmen wir an, wir befinden uns in der Vergangenheit: E-Mails sind noch nicht erfunden, wir schreiben noch Briefe. Uns ist jedoch aufgefallen, dass das Schreiben und Versenden von Briefen recht lange dauern kann, daher wollen wir den Prozess beschleunigen. Also analysieren wir zuerst, wie die Nutzer aktuell beim Versenden von Briefen vorgehen. Als Ergebnis haben wir eine Reihe von Kern- und Teilaufgaben identifiziert, die der Nutzer ausführt, um sein Ziel (den Brief versenden) zu erreichen.

Die generelle Kernaufgabe (KA) heißt: “Brief verschicken”. Diese Kernaufgabe unterteilt sich zum Beispiel in die folgenden Teilaufgaben (TA):

• Empfänger auf den Briefumschlag und/oder den Brief schreiben
• Absender auf den Briefumschlag und/oder den Brief schreiben
• Ggf. Betreff formulieren
• Brieftext schreiben
• Ggf. Anlagen, wie Fotos oder weitere Dokumente, beilegen
• Brief (und Anlagen) in den Umschlag packen
• Briefmarke auf den Umschlag kleben
• Brief zur Post bringen

Darüber hinaus haben wir die folgende Anforderung an das spätere System abgeleitet.

• Der Nutzer muss im System Briefe versenden können, ggf. mit Anhang.

Die gewonnenen Informationen haben wir genutzt und sind in eine Kreativsession gegangen, um zu überlegen, in welche Richtung eine mögliche Lösung gehen könnte. Ergebnis: Wir wollen den Prozess elektronisch unterstützen und erfinden das Konzept der “E-Mail”. Wie diese im Detail funktioniert, wissen wir noch nicht.

Jetzt kommt das Nutzungsszenario ins Spiel. In tabellarischer Form können wir die vorhandenen Informationen nutzen und um Benutzeraktionen und Systemreaktionen ergänzen, beispielsweise wie in der nachfolgenden Tabelle:

Wie ihr seht, ist in der Tabelle an keiner Stelle ein konkretes Interaktionselement aufgeführt. Vielmehr geht es um die allgemeinen Aktionen des Benutzers und die darauf folgenden Reaktionen des Systems. Auch ist zu beachten, dass wir nun in der Soll-Situation sind. Das bedeutet, dass wir die Teilaufgaben aus dem alten Prozess natürlich nicht 1:1 übernehmen können. Vielmehr müssen wir uns basierend auf den Ergebnissen der Anforderungserhebung überlegen, welche Teilaufgaben im zukünftigen System noch notwendig sind. Teilweise wollen wir natürlich auch Prozesse automatisieren, die bisher manuell passiert sind, sodass wir hier ggf. gar keine Benutzeraktionen, sondern nur Systemreaktionen haben.

Wie geht es nach dem Nutzungsszenario weiter?

Jetzt kann es beispielsweise mit “Papier und Stift” oder anderen Prototyping-Werkzeugen weitergehen. Die erstellten Nutzungsszenarien nehmen wir als Grundlage und müssen uns eigentlich nur an diesen entlang hangeln. Das Ganze ist quasi wie eine Art Plan, den wir abarbeiten können. Wir müssen uns an dieser Stelle also nicht mehr überlegen, was alles dargestellt werden muss, sondern nur noch wie. Wir überlegen uns also für jede Benutzeraktion, welches Eingabeelement am besten geeignet ist und wie das Feedback des Systems aussehen soll.

Was bringen Nutzungsszenarien für die Gestaltung des UI Designs?

Das E-Mail-Beispiel ist natürlich konstruiert, aber Nutzungsszenarien können in verschiedenen Projekten tatsächlich eine gute Brücke zwischen Anforderungen und UI Design bilden, insbesondere dann, wenn ihr auf der grünen Wiese startet.
Mir persönlich gefällt vor allem, dass ich systematisch vorgehe und nicht einfach irgendwas zu Papier bringe. Ich kann sicherstellen, dass alle Anforderungen wirklich im System adressiert werden und meine Anforderungsliste quasi abhaken.

Wenn wir direkt mit der Auswahl und Gestaltung von konkreten Interaktionselementen anfangen, laufen wir Gefahr, die Anforderungen aus den Augen zu verlieren und uns in Details zu verzetteln, ohne das große Ganze zu adressieren. Bei Nutzungsszenarien bleiben wir erstmal auf einer abstrakten Ebene und konzentrieren uns auf das Notwendige.

Da der Einsatz von Nutzungsszenarien allerdings auch einen gewissen Aufwand mit sich bringt, setze ich sie nicht immer ein. Wenn ich zum Beispiel schon ähnliche Konzepte habe, mir das Benutzer- und Systemverhalten schon sehr klar ist oder ich nur Dinge verbessere, ist der Aufwand im Vergleich zum Nutzen aus meiner Sicht zu hoch.