Obwohl in der Beschreibung des Sceranio-based Design Framework Szenarien weitgehend als geschriebene Geschichten auftauchen, sind sie nicht per se textuell:
“Another tool issue is support for creating and manipulating scenario presentations. Scenario narratives are not defined to be text, but they often are codified in text. (?)” (Carroll 2000, S. 326, Hervorhebung C.S.)
Das Scenario-based Design Framework macht wenig konkrete Vorgaben zum Thema Visualisierung. Vorgaben dazu gibt es hauptsächlich in den Phasen Information Design (Skizzen) und Interaction Design (Storyboard von Nutzungssequenzen). Dabei geht es darum, das Aussehen des Systems und den Ablauf von Interaktionssequenzen visuell darzustellen, um den Szenariotext zu ergänzen. Es wird also das System abgebildet, das im Szanrio beschrieben wird. Streng genommen handelt es sich dabei schon um rudimentäre Prototypen (Low-Fi-Prototypen).
Ein Prototyp verwirklicht “versuchsweise” ein neues System, oder einzelne Bestandteile davon, und beinhaltet meist Formen von Visualisierung. “Prototyping” wird von Rosson & Carroll (2002, S. 209) als Schlüsselaspekt der iterativen Gestaltung beschrieben: Designideen werden konkretisiert und evaluiert und die Erkenntnisse fließen in die weitere Entwicklung mit ein. Im SBD ist verläuft das Prototyping parallel zum Schreiben der Szenarios in der Designphase.
Das Framework legt allerdings nicht fest, wann welche Arten von Prototypen eingesetzt werden. Je nach Entwicklungsstand des Projektes können Prototypen aus unterschiedlichen Zielen heraus entwickelt werden: z.B. um Designideen auszuprobieren oder um Besonderheiten eines Entwurfs auf Gebrauchstauglichkeit (Usablility) zu testen. Entsprechend dieser verschiedenen Ziele unterscheiden sich die Prototypen in Art, Umfang und Detailgrad.
Folgende Arten von Protoypen werden von Rosson & Carroll (2002, S. 189) vorgestellt:
- Storyboard — eine Serie von Skizzen oder Screenshots verdeutlicht Schlüsselmomente aus der Nutzungsgeschichte
- Papierprotoyp — aus Papier oder Pappe gefertigter Apperat, welcher Bedien– und Anzeigeelemente simuliert
- Wizard of Oz — ein unsichtarer menschlicher Assistent simuliert die Ein– und Ausgabefunktionalitäten eines Systems, die noch nicht zur Verfügung stehen
- Videoprototyp — eine Videoaufnahme von Menschen die eine oder mehrere Tätigkeiten ausführen
- Computeranimation — Animierte Bildfogen, die eine Ein– und Ausgabesequenz darstellen
- Scenario Machine — ein interaktives System, das eine speziellen Ereingnisablauf aus dem Szenario verwirklicht
- Rapid Prototype — ein interaktives System, das mit spezieller Prototyping-Software erstellt wurde
- Teilweise funktionierendes System — eine funktionsfähige Version des Systems, die aber nur Teile des eigentlichen Funktionsumfangs enthält
Alle genannten Prototyp-Arten bilden ausschließlich das System ab. Einzig der Videoprotoyp bildet eine Ausnahme — hier wird meist ein gespieltes Szenario, und somit die Nutzungssituation, gezeigt.
Im Gegensatz zu den texutellen Szenarien zeigt ein Prototyp immer mehr Detaills:
“In general, a protoype is more refined than a scenario simply because a prototype must take a position on physical details (shape, color, positioning, and so on) that need not be specified in a narrative.” (Rosson & Carroll 2002, S. 209)
Rosson und Carroll (2002, S. 200) weisen darauf hin, wie wichtig es ist, dass Prototypen in den frühen Phasen des Projekts unvollständig bzw. skizzenhaft sind (“roughness”), um zu verhindern, dass man sich vorschnell auf Details festlegt. Solche unvollständigen Prototypen können nicht für sich allein stehen. Hier bieten z.B. die Szenarien den nötigen Kontext.
Betrachtet man Projekte die SBD nutzen in der Praxis, so werden die im SBD vorgesehenen fiktiven Nutzer (hypothetical stakeholder) oft in Personas nach Alan Cooper ausgeformt. Das ist durchaus im Sinne von Rosson & Carroll (2003, S. 1054):
“The use of personas overlaps considerably with our own SBUE framework, although we use the phrase “hypothetical stakeholder” (?)”
Setzt man Personas ein, so handelt es sich auch hier um eine Form der Visualisierung. Die eher abstrakten Nutzerprofile werden zu konkret sichtbaren Personen gemacht.
In der Grafik hervorgehoben sieht man die Arbeitsschritte im Scenario-based Design Prozess, in denen Visualisierung eine Rolle spielt:
Fazit
Fast alle Visualisierungsmethoden, die im Scenario-based Design Framework beschrieben werden, gehen in Richtung Prototyp und haben das Ziel das zu entwicklende System darzustellen. Da erscheit es folgerichtig, dass in der Analysphase und im Aktivity Design keine Visualisierungen angedacht sind — schließlich gibt es hier noch kein abbildbares System.
Was spräche jedoch dagegen, bereits in den frühen Phasen des Entwicklungsprozesses zu visalisieren? Was spräche allgemein gegen das Visualisieren der Nutzungssituationen aus dem Szenarien?
Hypothetische Gründe gegen das Visualisieren in Analysephase und Activitydesign:
- Visualisierungen sind nicht so flexibel und schnell änderbar wie Text — evtl. werden nötige Änderungen nicht umgesetzt, da man den Arbeitsaufwand scheut
- Visualisierungen sind vollständinger (Details) — Text kann mehr “Lücken” lassen
- Aktivitäten/Funktionalität lässt sich schwer darstellen, wenn man sich noch nicht auf Ausgabe– und Eingabedetails festlegen will (wie im Aktivitätsszenario beabsichtigt) — evtl. schränkt das die Freiheit ein, die man dadurch gewinnt, dass man sich in dieser Phase nur um das “was”, aber nicht im das “wie” kümmern muss.
Hypothetische Gründe für das Visualisieren in Analysephase und Activitydesign:
- Text wird zugänglicher, attraktiver für den Leser
- Bei Lesen eines Textes enstehen Bilder “vor dem geistigen Auge”, allerdings sind diese bei jedem Leser verschieden — eine konkrete visuelle Darstellung führt dazu dass alle Beteiligten über das selbe “Bild” reden
- Visualisierungen können auch mit der nötigen “skizzenhaftigkeit” (“roughness”) umgesetzt werden