Storyboards: Eine Erfolgsgeschichte
Was sind Storyboards?
Storyboards sind Geschichtenbretter – jedenfalls wörtlich übersetzt. Ok, wir malen die nicht auf Holz. Storyboards beschreiben die Umsetzung eines fachlichen Anwendungsfalls in eine konkrete Software-Benutzeroberfläche. Beschreibt ein Anwendungsfall (Use Case) die rein fachlichen Abläufe (z.B. Anlegen eines Kontos), so beschreibt das entsprechende Storyboard, wie das in der Software-Oberfläche vor sich geht.
Herkunft
Storyboards verbindet man eher mit der Erstellung von Trickfilmen oder der Planung von Werbespots. Verschiedene Scribbles (flüchtige Skizzen) werden mit Pfeilen und Symbolen miteinander verbunden. Ziel ist es, eine Geschichte zu erzählen und den Ablauf der Geschichte zu verdeutlichen. Nun, da hat die gute alte IT-Welt mal von so neumodischem Kram wie Zeichentrick und Werbung gelernt. Wobei ich mir jetzt gar nicht so sicher bin, ob Storyboards nicht schon viel früher im Filmgeschäft eingesetzt wurden. Das Ziel sollte dasselbe gewesen sein: eine Geschichte erzählen. Wie dem auch sei, die Storyboards haben in die IT Einzug gehalten.
Storyboards in der IT
Diese sogenannten Storyboards helfen auch in der Spezifikation von IT-Projekten. Da finden wir Anforderungs- und Stakeholderanalyse, Riskmanagement und Geschäftsprozessdefinitionen. Alles gut und erforderlich. Parallel zu diesen Aktivitäten versuchen Informatiker eine passende Architektur zu entwerfen. Auch das ist nicht einfach, da es schon sehr früh im Projekt, Performance, Skalierbarkeit etc. zu berücksichtigen gilt.
So, und irgendwann purzeln da sogenannte Use Cases (Anwendungsfälle) aus der Geschäftsanalyse (Business Analysis) heraus. Unter Use Cases verstehe ich textliche Beschreibungen, die festhalten, was Schritt für Schritt fachlich geschieht. Interessierte mögen vielleicht bei Alistair Cockburn nachlesen, wie man solche Use Cases effektiv modelliert.
Jetzt müssen wir die ja nur noch umsetzen, und alles ist gut. Wirklich? Nein, noch ist leider gar nichts gut, wer sagt denn dem Entwickler, wie er den Use Case, der sich hoffentlich ausschließlich auf die fachliche Beschreibung beschränkt hat, in das User Interface zu übertragen hat? Wir haben als Usability Professional und User Interaction Designer hoffentlich den Prozess schon bis zu diesem Punkt begleitet. Sonst wird es wirklich schwierig. Gehen wir aber im folgenden davon aus, dass wir seit Anfang an dabei waren.
Das Storyboard entsteht
So, nun haben wir die Use Cases. Sie sind uns vertraut. Wir überlegen nun, wie die User Interaction aussehen muss, um dem Use Cases gerecht zu werden.
Es geht also nun um die Frage, wie sollen die Use Cases in der geplanten Softwareoberfläche ablaufen. Dabei ist die konkrete Gestaltung der einzelnen Masken (Screen Design) sogar erst mal gar nicht so wichtig. Viel wichtiger ist die Beschreibung der Navigationswege und des entsprechenden Systemverhaltens: Wie komme ich von A nach B und was passiert dabei. Das ist die Aufgabe von Storyboards. Sie orientieren sich am Use Case, transponieren ihn aber in die Softwareoberfläche, die der User Interaction Designer entworfen hat.
Voraussetzungen
Hier wird nun deutlich, welche Voraussetzungen man für die Storyboards benötigt:
klare fachliche Anforderungen
lösungsunabhängig geschriebene Use Cases
Definition des grundlegenden Layout und der Funktionsbereiche
und einen Kunden, der die Benutzerbrille aufsetzt und Fantasie hat
Was sind Storyboards?
Sie bilden die Brücke zwischen Use Case und Oberflächenentwicklung.
Sie beschreiben, wie die Use Cases in der Oberfläche ablaufen.
Sie beschreiben ausschließlich Use Cases, die in der Oberfläche ablaufen.
Sie sind eine gute Grundlage für das Prototyping, ersetzen es aber nicht.
Sie sind ein weiteres Artefakt in der Spezifikation, das als Vorgabe für die Entwicklung dient.
Was sind Storyboards nicht?
Um die Rolle von Storyboards besser einsortieren zu können, sei noch mal verdeutlicht, was sie nicht sind:
Sie sind kein Ersatz für die Business Analysis. Sie ersetzen nicht die Use Cases.
Sie müssen nicht das konkrete Screen Design beinhalten. Die Screens sollten separat beschrieben werden.
Sie sind definitiv nicht das einzige Artefakt der Spezifikation. Das gilt insbesondere, da Storyboards ausschließlich funktionale Anforderungen mit UI-Bezug beschreiben. Storyboards berücksichtigen keine nicht-funktionalen Anforderungen (technische Performance, Ausfallsicherheit…)
Ich weise auf diesen Sachverhalt deshalb so deutlich hin, weil Storyboards durchaus dazu verleiten, sie als DIE Spezifikationsgrundlage zu missbrauchen. Storyboards sind ein sehr visuelles Mittel, welches vom Kunden gut verstanden wird. Das verleitet viele Kunden dazu, sich primär auf die Storyboards zu fokussieren. Das kann ein verhängnisvoller Fehler sein, wenn die Abnahme der Use Cases und nichtfunktionalen Anforderungen ins Hintertreffen geraten. Das müssen Projektmanager und Business Analytiker immer im Hinterkopf behalten.
Aufbau eines Storyboards
Es gibt unzählig viele Möglichkeiten, ein Storyboards aufzubauen. Ich bevorzuge eine Kombination aus Skizzen und Text. Je nach dem mal mit mehr Text und weniger Scribbles oder umgekehrt.
Vorteil von Text in Storyboards: Kann vom Kunden besser abgenommen werden. Häufig sind Erklärungen zu den Scribbes erforderlich. Wie schon erwähnt hangel ich mich dabei am Use Case entlang.
Im Folgenden möchte ich ein kurzes Beispiel geben, wie so ein Storyboard zur Einrichtung eine Fremdkontos innerhalb einer Online-Banking-Site aussehen könnte. Das Beispiel ist rein fiktiv und kein Prototyp für eine reale Kontenverwaltung.
< Anfang Beispiel >
Storyboard Konto anlegen Das System bietet die Möglichkeit, verschiedene Konten zu verwalten. Es ist auch in der Lage Konten fremder Banken mit ihren Umsätzen aufzulisten. Mit der hier beschriebenen Funktionalität kann der Nutzer ein neues Konto in den Verwaltungsbestand aufnehmen.
Der Nutzer navigiert links in der Navigationssicht zu Konten und öffnet sie durch einen Klick.
Das System stellt den Eintrag Konten in der Navigationssicht aktiv dar (blau hinterlegt mit weißer Schrift) und zeigt im Datenbereich die Liste der verfügbaren Konten an. Das System erweitert den Pfad (Breadcrumb Path) um den Eintrag “Konten”. Der Eintrag “Home” wird zum Hyperlink. Klick auf das Bild, um es größer zu sehen.
Liste der verwalteten Konten
Der Nutzer klickt rechts neben der Liste auf die Funktion Neues Konto.
Das System blendet die Erfassungsmaske ein. Die Erfassungsmaske zeigt lediglich eine Auswahlliste zur Kontoart an. Der Pfad wird erweitert um “Konto einrichten”. Der Eintrag “Konten” wird zum Hyperlink.
Der Nutzer wählt als Kontoart “Fremdkonto” aus.
Das System blendet die Felder zur Erfassung eines Fremdkontos ein.
Erfassungsmaske für neues Konto
Der Nutzer gibt die Daten des Fremdkontos ein und bestätigt die Eingaben mit Speichern.
Das System validiert, dass das eingegebene Konto existiert.
Das System legt ein neues Konto mit den Nutzereingaben an. Das System schließt die Erfassungsmaske und navigiert zur Liste der verwalteten Konten (siehe Abbildung 1). Das System fügt das neue Konto der Liste hinzu.Ausnahmen 7.a.1 – Der Nutzer klickt auf Abbrechen: Das System schließt die Erfassungsmaske und navigiert zur Kontenliste. Es wird kein Konto eingerichtet. Die Story endet hier. 8.a.1 – Das eingegebene Konto existiert nicht: Das System blendet einen Dialog ein: Titel: Konto ungültig Text: Das angegebene Konto existiert nicht. Bitte korrigieren Sie die Daten. Button: OK 8.a.2: Der Nutzer bestätigt mit OK. 8.a.3: Das System zeigt die Erfassungsmaske mit den bisher vorgenommenen Eingaben.
< /Ende Beispiel >
So oder ähnlich könnte ein Storyboard aussehen. Es wird deutlich, dass es sich hierbei in keiner Weise um einen Use Case handelt. Ganz im Gegenteil: Der Ablauf beschreibt Schritt für Schritt, wie der Use Case in der Oberfläche innerhalb verschiedener Masken abläuft und wie sich verschiedene Oberflächenelemente verhalten sollen. Diese Informationen stehen in keinem Use Case (dürfen sie auch gar nicht!). Aus dem Screen Design lässt sich das auch nicht ableiten. Und prototypische Clickables lassen die Abläufe bestens erahnen. Nichts gegen die erwähnten Artefakte, sie haben einfach eine andere Aufgabe als Storyboards.
Fazit
Richtig eingesetzt und und mit den richtigen Erwartungen gelesen sind Storyboards ein sehr probates Mittel, die fachliche Spezifikation zu ergänzen. Sie übersetzen die Use Cases in Abläufe innerhalb der Software-Oberfläche. Storyboards dürfen nie der einzige Ergebnistyp der Spezifikation sein, da sie nicht-funktionale Anforderungen und solche ohne UI-Bezug nicht beschreiben.
Und wenn das alles gut läuft, dann sind Storyboards eine Steilvorlage für die Entwicklung. Der Pass wird gerne aufgenommen und in ein Traumtor verwandelt.
#Fachspezifikation #Storyboard #UseCase #UserInteractionDesign