Archive - Edition 3: Portals

back To Overview of Edition

Leading Article

What is a Portal?

What's in a Portal: MiniApps, Generic MiniApps

User-Centered Portal Design

Graphic Design and Branding

"Real" Portal Projects

 

Entwerfen des Interaktionsdesigns

By Margarete Fuss, SAP AG – 21. Mai2001

Disclaimer: Please note that this edition was written in 2001. Therefore, statements in the articles, particularly those regarding SAP's products, product strategy, branding strategy, and organizational structure, may no longer be valid.

English Version

Der folgende Artikel beschreibt das Entwerfen des Interaktionsdesigns - einer der wichtigsten Schritte auf dem Weg zu einem benutzerzentrierten Anwendungssystem. Dieser Schritt folgt direkt auf die Erhebung und Analyse von Daten zur Arbeitspraxis, die im Rahmen von Site Visits gewonnen werden und leitet aus diesen Daten sukzessive das User Interaction Design ab.

Dazu werden die folgenden Teilschritte im Rahmen von Interaction Design Sessions durchgeführt:

  1. Bilden einer Vision der neuen Arbeitspraxis
  2. Erarbeiten benutzerorientierter Arbeitsszenarien (Storyboards)
  3. Aufbau einer Interaktionsstruktur (User Environment)
  4. Entwerfen der Benutzungsschnittstelle
  5. Entwickeln und Testen eines Papierprototypen

Sie werden weiter unten ausführlicher dargestellt.

(Die Schritte entsprechen der "Contextual Design"-Methodik: Beyer, Hugh; Holtzblatt, Karen; Contextual Design; 1998; Morgan Kaufmann Publishers, Inc., San Francisco, California)

 

Benötigte Dokumente

Zum Entwerfen des Interaktionsdesigns benötigt man ausführliche Daten über die gegenwärtige Arbeitspraxis im betrachteten Anwendungsbereich. Je vollständiger und strukturierter diese Daten zur Verfügung stehen, umso besser wird das Interaktionsdesign.

Idealerweise wurden vor Beginn der Design Sessions Site Visits durchgeführt und deren Ergebnisse zu Arbeitsmodellen konsolidiert. Geht man nach der "Contextual Design"-Methodik (s.o.) vor, so sind dies die Modelle Flow, Sequence, Cultural, Physical und Artifact sowie das Affinity Diagram (siehe auch den Artikel "Contextual Design at SAP" von Karen Holtzblatt & Hugh Beyer und das "SAP Usability Glossary" in der SAP Design Guild).

Sollte es aus pragmatischen Gründen nicht möglich sein, Site Visits durchzuführen, so sollte wenigstens eine "Brainstorming Session" stattgefunden haben. In einer "Brainstorming Session" wird das im Unternehmen vorhandene Wissen über einen Anwendungsbereich zusammengetragen. Teilnehmer einer Brainstorming Session sollten dementsprechend vor allem Berater, Vertriebs- sowie Marketingmitarbeiter sein. Sie erarbeiten aus ihrer Expertise heraus gemeinsam Benutzerrollen und Bedienszenarien, die dann die Grundlage für Interaction Design Sessions darstellen.

Sehr hilfreich beim Entwerfen des Interaktionsdesigns sind auch "Personas". Dieses von Cooper (s. Cooper Interaction Design) entwickelte Beschreibungsmittel gibt User Interface Designern und Entwicklern ein klares Design-Ziel. Eine Persona ist ein Archetyp, der die Bedürfnisse und Ziele einer bestimmten Gruppe von Personen repräsentiert, die das zu entwickelnde Produkt benutzen wird.

 

Zusammensetzung des Teams

Die erfolgreiche Durchführung von Interaction Design Sessions hängt stark von der richtigen Zusammensetzung des Design-Teams ab. Am effektivsten ist es, wenn das Team, das an den Site Visits teilgenommen hat, auch die Design Sessions durchführt. Zu Beginn der Design Sessions, d.h. nach der Konsolidierung der Site Visit-Ergebnisse, ist jedoch auch ein günstiger Zeitpunkt neue Mitglieder ins Team zu nehmen. Inhaltlich bieten sich dafür vor allem User Interface Design-Experten an. Häufig kommt es auch vor, daß aus arbeitsorganisatorischen Gründen nicht alle Personen den gesamten Prozeß von den SiteVisits bis zum Design mitmachen können. Auch für solche Fälle sollte man diesen Punkt zwischen Konsoliderung der Site Visit-Ergebnisse und dem Bilden einer Vision für das Wechseln von Teammitgliedern vorsehen.

Idealerweise sollte das Team folgendermaßen besetzt sein:

Mindestens eine Person aus

 

Schritt 1: Bilden einer Vision der neuen Arbeitspraxis

Bei diesem Schritt wird ein "Big Picture" der neuen Arbeitswelt erstellt: eine Vision erzählt die Geschichte, wie die Arbeit in der neuen - vom Team erfundenen - Welt ausgeführt wird.

Die Vision ist Grundlage für das konkrete Design des neuen Produkts und ist der wichtigste Input für die nächsten User Interaction Design-Schritte. Genau so wichtig ist die Vision auch für die Darstellung des neuen Produkts bei den verschiedensten Zielgruppen:

Diese Gruppen können durch diese Information schon parallel ihre Arbeit aufnehmen.

Beispiel einer Vision

Abbildung 1: Beispiel einer Vision

Die Vision wird durch ein gezieltes Brainstorming des gesamten Teams erstellt: Damit die neu erfundene Welt genau auf die Anforderungen der späteren Benutzer zugeschnitten ist, muss dem Team die existierende Arbeitswelt genau bekannt und vor allem präsent sein. Man beginnt diesen Schritt deshalb mit einem "Wall Walk": Die Team-Mitglieder schauen sich alle konsolidierten Arbeitsmodelle und das Affinity Diagram in Ruhe an. Dabei notieren sie Design Ideen auf Post-It!s und heften diese an die Modelle.

Beispiel eines Affinity Diagramms

Abbildung 2: Beispiel eines Affinity Diagramms

Anschließend werden im Rahmen eines Brainstormings die verfügbaren Technologien identifiziert.

Durch diese ersten Schritte ist das Team ideal darauf vorbereitet die verfügbaren Technologien an den richtigen Stellen bei der Neugestaltung der Arbeit einzusetzen. Es folgt deshalb ein Brainstorming von "Hot Ideas", d.h. die am wichtigsten empfundenen Ideen werden durch Zuruf an einem Flipchart gesammelt.

Für jede "Hot Idea" erfindet das Team eine Geschichte, die erzählt wie die Arbeit in einer neuen Welt ausgeführt wird. Diese Geschichten werden beim Erfinden auf Flipcharts gezeichnet und die jeweiligen Vor- und Nachteile festgehalten. Aus den einzelnen Visionen wird dann eine gemeinsame Vision erstellt, die die Nachteile eliminiert und die Pluspunkte verstärkt.

Gerade für diesen letzten Schritt ist ein geschulter Moderator sehr wichtig, damit ein optimales Teamergebnis erzielt wird.

 

Schritt 2: Erarbeiten benutzerorientierter Arbeitsszenarien (Storyboards)

Die Vision beschreibt zwar alle Aspekte der neuen Arbeitspraxis, sie ist aber noch viel zu grob um daraus eine Spezifikation des neuen Systems ableiten zu können. Aus diesem Grunde erarbeitet das Team als nächstes Storyboards. Diese definieren die neue Arbeitspraxis, die in der Vision erzählt wird, im Detail und sind die Grundlage für das neue Design.

Ein Storyboard läßt sich in der Darstellungsweise mit einem Comic vergleichen, wobei jedes Bild im Storyboard eine Interaktion mit dem System, eine Interaktion mit einer anderen Person oder einen manuellen Schritt repräsentiert. Benutzungsschnittstellen werden nur grob gezeichnet, wichtig sind hier Gesamtstruktur und Funktionen. Es kommt also nicht auf präzise Sprache, das Aussehen von Icons oder das Layout an.

Beispiel eines Storyboards mit Post-It!-Anmerkungen nach der Gesamtteam-Diskussion

Abbildung 3: Beispiel eines Storyboards mit Post-It!-Anmerkungen nach der Gesamtteam-Diskussion

Zur Erstellung der Storyboards wird zuerst die Vision in einzelne Aufgaben aufgeteilt. Das Team wird in kleinere Gruppen geteilt (2 - 4 Personen/Gruppe), die jeweils ein Storyboard für eine Aufgabe entwickeln.

In einer Gruppe schaut man sich die Arbeitsmodelle, das Affinity und die Vision bzgl. der Aufgabe an. Das Sequence Model hat in diesem Schritt eine herausgehobene Bedeutung, da es das alte Arbeitsszenario beschreibt. Es dient deshalb als Bezugsmodell und wird zur Überprüfung des Storybords herangezogen (z.B. bzgl. Vollständigkeit oder Lösung identifizierter Probleme). In einem Brainstorming werden dann Alternativen dafür gesammelt, wie die Aufgabe im Rahmen der Vision unterstützt werden kann. Die Ideen werden aufgezeichnet und Vor- und Nachteile gesammelt, evtl. wird eine weitere Alternative entwickelt. Das Entwickeln von Ideen und anschließende Bewerten wird solange weiter gemacht, bis die Gruppe sich einig ist, welche Idee weiter verfolgt werden soll. Für diese Idee malt die Gruppe dann ein Storyboard und überprüft es mittels der konsolidierten Arbeitsmodelle.

Im Gesamtteam stellt jede Gruppe ihr Storyboard vor und es wird gemeinsam überprüft. Unstimmigkeiten werden entweder direkt behoben oder in der Kleingruppe gelöst.

 

Schritt 3: Aufbau einer Interaktionsstruktur (User Environment)

Die Interaktionsstruktur repräsentiert die Struktur der Anwendung wie sie den Benutzer unterstützt - unabhängig von der Benutzungsschnittstelle oder der Implementation.

Zur Verdeutlichung kann man die Interaktionsstruktur mit einem Wohnungsplan vergleichen. Er enthält alle Räume, was man in ihnen tun kann und welche Verbindungen dazwischen bestehen. Er beschreibt nicht, welche Farbe die Wände haben, aus welchem Material die Türen sind und welcher Fußbodenbelag gewählt wird. Er ist das zentrale Kommunikationsmittel für den Architekten, seine Kunden und Handwerker.

Wohnungsplan

Abbildung 4: Wohnungsplan

Die Interaktionsstruktur teilt das System in abgeschlossene Bereiche, die abgeschlossene Arbeitsaktivitäten unterstützen. Diese Bereiche werden Fokusbereiche genannt.

Jeder Fokusbereich zeigt

Ein Fokusbereich hat die folgende Struktur:

Mit der Interaktionsstruktur hat man eine strukturelle Sicht auf die Arbeit. Sie gibt keine sequentiellen Abläufe vor und bietet trotzdem für jede notwendige Handlungssequenz in der Arbeit die richtigen Funktionen und Objekte. Damit hat man ein viel mächtigeres Beschreibungsinstrument als die reine Darstellung von Szenarien, wie z.B. die Use Cases in der Objektorientierten Modellierung.

Interaktionsstruktur eines Mailsystems

Abbildung 5: Interaktionsstruktur eines Mailsystems (Klick ins Bild für größere Version)

Vorteile einer Interaktionssstruktur für das Entwicklungsteam

Das Team kann

Eine Interaktionsstruktur kann abhängig von der Projektart auf zwei verschiedene Arten entwickelt werden:

Interaktionsstruktur aus Storyboards ableiten

Die Fokusbereiche werden bottom-up aus den Storyboards abgeleitet. Für jedes Storyboard wird eine Gruppe gebildet. Die Gruppe spielt das Storyboard Schritt für Schritt durch. Dabei geht sie für jeden Schritt, der eine Aktion mit dem System darstellt, folgendermaßen vor:

Die so entstandene Interaktionsstruktur wird anschließend im Gesamtteam sehr sorgfältig im Rahmen eines Walkthroughs überprüft, denn sie bildet letztendlich die Grundlage für die Benutzungsschnittstelle.

 

Schritt 4: Entwerfen der Benutzungsschnittstelle

Wenn man eine Interaktionsstruktur vorliegen hat, beschränkt sich das Entwerfen der Benutzungsschnittstelle auf die Auswahl des Interaktionsstils und die Zuordnung der angemessenen Interaktionselemente.

Aus dem Physical Model wird der erforderliche Plattform-Typ und der Interaktionsstil (Maus, Tastatur, Spracheingabe,...) abgeleitet. Wenn diese Festlegung erfolgt ist, kann man für die einzelnen Elemente der Interaktionsstruktur die Elemente der Benutzungsschnittstelle bestimmen. Für eine Web-Anwendung könnte das z.B. sein:

Dabei müssen die User Interface Standards (Styleguides) und Usability-Prinzipien der gewählten Plattform berücksichtigt werden.

Auch das Entwerfen der Benutzungsschnittstelle erfolgt in Gruppen. Jede Gruppe bekommt einen zusammengehörenden Teil der Interaktionsstruktur und skizziert in einem Brainstorming zunächst mehrere alternative Entwürfe. Durch gemeinsames Bestimmen von Vor- und Nachteilen wird ein bester Entwurf herausgearbeitet und ein Papier-Prototyp gebaut.

Die Gruppen stellen ihre Papier-Prototypen im Gesamtteam vor und beseitigen anschließend evtl. ermittelte Inkonsistenzen oder Probleme.

 

Schritt 5: Entwickeln und Testen eines Papierprototypen

Ein Papierprototyp stellt eine Benutzungsschnittstelle mit Post-its dar, die Fenster, Drucktasten, Menüs... repräsentieren. Ein Papier-Prototyp ist dadurch ausführbar, daß der Entwickler das Verhalten des Rechners simuliert. Die Benutzer führen beim Test ihre alltäglichen Arbeitsaufgaben mit dem System durch. Der eigentliche Zweck des Papierprototypen ist erreicht, wenn Entwickler und Benutzer beim Test gemeinsam am Re-Design der Benutzungsschnittstelle arbeiten.

Beispiel eines Papierprototypen

Abbildung 6: Beispiel eines Papierprototypen

Papierprototypen sind aus den folgenden Gründen sinnvoll:

Bevor man den Papierprototypen mit einem Benutzer testet, sollte man sich eine Ausgangsarbeitssituation überlegen, in der der Benutzer beginnen soll, mit dem Prototypen zu arbeiten. Dies ist wichtig, um einen gezielten Einstieg zu gewährleisten. Anschließend sollte aber ein Szenario aus der angetroffenen Arbeitspraxis verwendet werden.

Ebenfalls vor dem Benutzertest sollten alle offenen Punkte der vorangegangenen Schritte zusammengefaßt werden, damit man seine Aufmerksamkeit beim Test vor allem auf diese Aspekte lenkt oder gezielte Fragen einbringen kann.

Für einen Test mit einem Papierprototypen sind immer zwei Personen notwendig: Eine, die Notizen macht und eine, die die Interaktionen am Papierprototyp ausführt.

Stellt sich beim Test heraus, daß der Benutzer größere Probleme bei der Bedienung des Prototypen hatte, sollte eine Alternative entwickelt und getestet werden. Falls notwendige Änderungen des Prototypen die Interaktionsstruktur betreffen, so ist diese entsprechend anzupassen.

Die Endversion des Papierprotypen wird fixiert und stellt zusammen mit der angepaßten Interaktionsstruktur die Spezifikation des neuen Produkts dar.

 

top top