Was ist der beste Weg um mit einem neuen Design zu beginnen? Egal ob wir eine neue Software entwickeln, den Aufbau eine Webseite planen oder eine Dienstleistung gestalten wollen – alles beginnt mit einer Geschichte. Eine Geschichte, die beschreibt wie unsere Benutzer eine perfekte Lösung verwenden, wie es ihnen dabei geht und was sie sich dabei denken.
In der frühen Phase eines Projekts werden diese Geschichten von Interaction-Designern als Kontext-Szenarios bezeichnet. Diese Szenarios sind optimistische Erzählungen, welche das Verhalten unserer Benutzer und unserer Lösung beschreiben und uns etwas über die Motivationen und Ziele dieser Menschen verraten. Kontext-Szenarios sind für Designer dasselbe, wie Drehbücher für Filmemacher.
Beim Schreiben der Kontext-Szenarios beginnen wir uns vorzustellen, wie unser Produkt oder Service aussehen kann. Die Geschichtenform beflügelt dabei nicht nur unsere Fantasie, sondern ist eine ideale Gesprächsgrundlage, um die Qualität und den Umfang unserer Lösung im Team und mit unseren Auftraggebern zu besprechen.
Für ein sinnvolles Kontext-Szenario führen wir 30- bis 60-minütige Interviews mit unseren zukünftigen Benutzern und entwickeln evtl. Peronas, um die Menschen, für die wir designen, während des gesamten Prozesses im Kopf zu behalten. Im folgenden Beispiel haben wir ein Termin-Tool für ein Radgeschäft entwickelt. Das vorgestellte Szenario ist (stark) gekürzt und dient lediglich dazu, zu zeigen, wie Szenarios dabei helfen können, eine nützliche Lösung zu entwickeln.
Auszug Kontext-Szenario: Mechaniker
Für Flo beginnt der Arbeitstag kurz vor 10:00 Uhr. Er kommt in die Werkstatt und macht sich zuerst ein Bild davon, welche Räder heute repariert werden müssen. Er wirft einen Blick auf den Bildschirm, und sieht, dass von fünf Rädern, die heute für einen Service-Termin eingetragen sind, drei Mountainbikes und zwei Rennräder sind.
Weil Flo Experte für Rennräder ist, achtet er speziell auf diese beiden Räder. Er sieht, dass eines der beiden Rennräder noch nicht vom Kunden gebracht wurde. Deshalb entscheidet er sich für das zweite, und erfährt, dass es sich um ein blaues Cube handelt, bei dem die Bremse schert, und die Kette getauscht werden muss.
Er sieht auf seinem Bildschirm, dass das Fahrrad die Nummer 23 hat, und findet es dank der Nummer, ohne lange in der Werkstatt danach suchen zu müssen. Nachdem Flo mit der Reparatur des Rads fertig ist, bestätigt er das im System, und widmet sich dem nächsten Service.
Unser neues Buch: Wir erklären dir in klarer und verständlicher Weise, wie User Testing in der Praxis wirklich funktioniert » Zum Buch
So funktioniert’s
In diesem Auszug steht bechrieben, wie Flo mit unserer Software arbeitet, welche Entscheidungen er trifft und wie der Arbeitsablauf aussieht. Die Geschichte selbst basiert auf unseren Beobachtungen und Gesprächen mit den Mitarbeitern und ist unsere Traumvorstellung davon, wie ein Mechaniker mit Hilfe unserer Software seine Ziele erreichen kann.
Um von der Geschichte zu ersten Scribbles zu gelangen, schauen wir uns einfach jeden einzelnen Satz an und überlegen, welche Anforderungen wir für das Interface ableiten können. Zwei Beispiele sollen zeigen, wie das in der Praxis gemacht werden kann:
Beispiel 1
Er wirft einen Blick auf den Bildschirm, und sieht, dass von fünf Rädern, die heute für einen Service-Termin eingetragen sind, drei Mountainbikes und zwei Rennräder sind.
Anforderungen:
- Möglichkeit alle Räder zu sehen, die heute repariert werden müssen
- Möglichkeit den Typ eines Fahrrads zu erkennen (Mountainbike oder Rennrad)
Beispiel 2
Er sieht, dass eines der beiden Rennräder noch nicht vom Kunden gebracht wurde.
Anforderungen:
- Möglichkeit zu sehen, ob ein Fahrrad bereits in der Werkstatt ist
Und darauf kommt es an
Wie ihr vielleicht bemerkt habt, spielt der richtige Detailgrad eine entscheidende Rolle. Wir schreiben in den Szenarios z.B. dass Flo sieht, dass von fünf Rädern, drei Montainbikes und zwei Rennräder sind. Diese Beschreibung ist offen genug, um beim Scribblen verschiedene Darstellungen ausprobieren zu können und das Design iterativ zu verbessern.
Schlecht wäre hingegen, bereits im Szenario eine fixe Form der Darstellung zu beschreiben. Zum Beispiel: Flo sieht eine Liste von Rädern und sieht, dass drei dieser Räder ein Icon für Montainbikes haben und zwei ein Icon für Rennräder. Bei dieser detaillierten Beschreibung stellt sich eigentlich nur noch die Frage, wie die Icons aussehen. In Wahrheit sollen die Szenarios aber den Flow oder den Ablauf der einzelnen Aktionen zeigen, nicht jedoch das Interface selbst beschreiben.
Genauso unbrauchbar wie eine zu genaue, wäre eine zu oberflächliche Beschreibung. Wenn wir z.B. nur schreiben würden, Flo sieht die Räder, die heute repariert werden müssen, dann erhalten wir aus diesem Statement keinen Hinweis auf das Interface. Die Kunst liegt darin, den perfekten Mittelweg zwischen oberflächlich und detailliert zu finden.
Zum Schluss
Der größte Vorteil von Kontext-Szenarios ist meiner Meinung nach, dass sie Geschichten sind, die jeder versteht und unter denen sich jeder etwas vorstellen kann – egal ob Designer, Programmierer oder Auftraggeber. Sie sind eine nützliche Grundlage, um zu entscheiden, was das fertige Produkt wirklich können soll.
Das beste daran ist, dass wir keine Liste von Wunsch-Features erstellen und über verschiedenen Meinungen und Geschmäcker streiten müssen, sondern basierend auf echten Gesprächen mit echten Menschen, eine Lösung entwicklen, die unseren Benutzern dabei hilft, ihre Ziele auf einfache und angenehme Weise zu erreichen.
Nächster Artikel: Die Verantwortung eines Designers
Pingback Unterricht an der FH Salzburg: Kurze Zusammenfassung | Simplease Blog — 22. Mai 2012
[…] der Entwicklung von Software, sind Szenarios unsere Drehbücher. Beim Lesen der Geschichte, entsteht sofort ein Bild im Kopf und ihr beginnt fast automatisch und […]