Modellierung von Informationen und Interaktionen

NUI – Verständlich und eingängig
Kommentare

Das erste iPhone wartete seiner Zeit mit bahnbrechenden Neuerungen in Visualisierung und Interaktion auf. Trotz fehlender Grundfunktionalitäten wie Copy und Paste führten die neuen Multitouch-Gesten und die verständlichen, einfachen Visualisierungsformen zu einem gigantischen Markterfolg. Waren diese Neurungen ein Zufall? Natürlich nicht. Gibt es Methoden, um solche Ideen strukturiert zu erarbeiten? Ja.

Der Weg scheint auf den ersten Blick einfach: Man biete dem Benutzer Lösungen, die er bereits kennt, die er sofort versteht, weil er sie sich nicht erst erschließen muss. Der Benutzer ist in der realen Welt gewohnt, etwas zu berühren, um es zu bewegen. So ist es beim iPhone. Die Zeitzonen sind auf einer Karte dargestellt. Auch diese Darstellungsform ist uns seit Kindestagen bekannt. Somit ist das Geheimnis eines natürlichen, intuitiven User Interface die Modellierung der dargestellten Informationen und Interaktionen im Hinblick auf Korrelation zur realen Welt oder zu anderen bekannten Systemen. An dieser Stelle kann strukturierte Methodik greifen: Aus welchen bekannten Informationseinheiten besteht ein zu visualisierender Sachverhalt? Welche Visualisierungsformen assoziiert der Benutzer mit ihnen? Dieser Beitrag liefert Hintergründe und eine konkrete Vorgehensweise mit anschaulichen Beispielen.

iLegend

Das iPhone ist eine Legende. Es ist zwar auch nicht unfehlbar ‑ ich selbst habe seiner Zeit beispielsweise satte zwei Monate gebraucht, um per Zufall die Pinch-Geste zu entdecken ‑ es hat aber zweifelsfrei ein neues Zeitalter digitaler Endgeräte eingeläutet. Lassen wir dafür als Beweis gelten, dass ausnahmslos jeder Hersteller mobiler Betriebssysteme die iParadigmen versucht nachzuahmen. Und selbst der Desktop und die Heizungssteuerungen werden von Apps nicht mehr verschont.

Was hat diesen andauernden Erfolg ausgemacht? Zunächst erwuchs das iPhone in einem Marketingkontext, der seinesgleichen sucht: Apple als Marke schafft Identität: Schickes Design und hoher Preis geben seinen Käufern das Gefühl sozialer und intellektueller Erhabenheit. Und das kann (soll) sich sehen lassen: Die weithin erkennbaren weißen Kopfhörer des ersten iPods oder der Apple-Aufkleber, der jedem Produkt beiliegt und stolz den Weg auf das Auto findet. Das heißt, egal wie gut das Innenleben des Produkts ist, haben die Marketers schon mal dafür gesorgt, dass sich der Käufer vor dem Auspacken gut fühlt.

Das allein hätte natürlich nicht gereicht. Denn auch nach dem Auspacken hielt die Begeisterung an. Anstelle vieler nichtssagender Hardwaretasten, unkomfortabler Menüs und kniffliger Eingabestifte wartete ein einsamer Hardwarebutton und große bunte App-Icons auf den Benutzer. Die Bedienung erfolgte einfach per Tatschen, neudeutsch „touchen“. Und diese Einfachheit zog sich durch das gesamte System: Es war übersichtlich, verständlich. Klar nach Apples Motto „Weniger ist mehr“. Das Erstaunliche: Es fehlten sogar rudimentäre Grundfunktionen wie „Copy and Paste“. Und dennoch übersteigen offensichtlich die Vorteile der Übersichtlichkeit die Nachteile des geringeren Funktionsspektrums. 

Neben dem mutigen „Weglassen“ ernteten neue Visualisierungs- und Interaktionsformen tosenden Applaus. Per Pinch-Geste lassen sich Karten wie Kaugummi per Fingerspreizung vergrößern. Das Touch-Scrolling stoppt nicht abrupt wie ein Crashtest, sondern rollt sanft aus und federt am Ende sogar nach. Neue Dialoge materialisieren sich nicht parapsychologisch aus dem Nichts auf den Screen, sondern fahren von der Seite ein. Auswahllisten blenden sich als mechanisch anmutendes Drehrad von unten ein. Zeitzonen werden nicht als schnöde Liste, sondern auf einer Karte visualisiert. Eines der Geheimnisse lüftet sich: Das iPhone ist gespickt mit Analogien zur realen Welt. Und warum diese Analogien zum einfachen Verständnis führen, liegt auf der Hand: Der Benutzer kennt all diese Sachverhalte. Er muss sie sich nicht erst erschließen (Abb. 1).

Abb. 1: Ein Multitouch-Leitsystem für Messen

[ header = Die Herausforderung der Wahrnehmung ]

Die Herausforderung der Wahrnehmung

Machen wir einen kleinen Ausflug in die Theorie. Sie lässt uns verstehen, wie „Kennen“ oder vielmehr „Erkennen“ funktioniert. Unsere zahlreichen Sinne zeichnen einen unaufhörlichen Strom an Daten auf. Um diese Datenmenge bewältigen zu können, werden Informationen von unserem Gehirn geclustert und anhand von relevanten Merkmalen zugänglich gemacht. Dieses Konstrukt aus Merkmalen wird auch „Mentales Modell“ genannt. Mein gängiges Beispiel: Das Ausfahrtschild auf der Autobahn. Wir müssen nicht den Text „A-U-S-F-A-H-R-T“ lesen, um zu wissen, dass es dort raus geht. Vielmehr wissen wir um die Ausfahrt anhand von wenigen Merkmalen. Diese mögen die Pfeilform des Schilds sein, die blaue Farbe und vielleicht das große „A“ als Anfangsbuchstabe. Außerdem wird der Kontext eine Rolle spielen. Schließlich sind vorher schon andere Schilder als Vorboten an uns vorbeigezogen. Im Ergebnis muss das Gehirn nicht jedes wahrgenommene Detail aufs Neue analysieren und macht es uns sogar möglich, während des Autofahrens zu telefonieren.

Wenn nun unser Gehirn in bekannten Strukturen arbeitet, plötzlich aber Unterschiede zwischen unseren assoziierten mentalen Modellen und dem tatsächlichen Sachverhalt auftreten, schalten sich alle Automatismen ab. Wir müssen bewusst reflektieren, handeln und uns voll konzentrieren. Da die automatisierten unterbewussten Prozesse losgelöst von bewusstem Handeln ablaufen, und sie auch nicht beliebig manuell abgerufen werden können, wissen wir im Falle einer Störung oft nicht einmal mehr, wie uns unser eingebauter Autopilot dorthin geführt hat. Die Verwirrung ist komplett. 

Auch bei der Nutzung von Software lässt sich dieses Phänomen beobachten. Denken wir an den Umstieg auf eine neue Version einer Software, beispielsweise Windows 8. Einmal im Desktop angekommen mag ein ursprünglicher Windows-7-Benutzer gut klar kommen. Er kann zunächst seine Automatismen abrufen. Wenn aber nach dem Anklicken einer Ecke plötzlich der neue Startbildschirm angekachelt kommt, stimmt das mentale Modell mit der Nutzungserfahrung nicht mehr überein. Was ist passiert? Wo bin ich? Nun muss der Benutzer überlegen, ausprobieren und ist sicherlich derart beschäftigt, dass er nicht dabei telefonieren könnte. 

Halten wir fest: Solange das Gehirn auf Bekanntes, also auf mentale Modelle zurückgreifen kann, müssen wir nicht bewusst nachdenken. Im Kontext von Software geht uns die Bedienung leicht von der Hand. Niemand muss – um das Beispiel von oben aufzugreifen   nachdenken, wie die mechanisch anmutende Auswahlrolle des iPhones funktioniert (Abb. 2). Wir bedienen sie einfach, obwohl wir es vielleicht zum ersten Mal sehen.

Abb. 2: Auswahlrolle auf dem iPhone

[ header = Die Lösung Teil 1-3 ]

Die Lösung Teil 1: Der Benutzer zählt

Um dem Benutzer eine verständliche und eingängige Information und Interaktion zu bieten, ist es also notwendig, seine mentalen Modelle zu kennen und die relevanten Merkmale abzubilden. Dabei ist eine entscheidende Hürde zu nehmen: Unsere eigenen Modelle sind nicht die der Benutzer! Warum das so ist, ist leicht zu erklären: Wir, als Beteiligte am Entstehungsprozess der entsprechenden Software, verfügen über ganz andere Erfahrung und über ganz anderes Wissen. Und wir Menschen können nicht bewusst vergessen. Wenn wir selbst also Merkmale erkennen, dann referenzieren sie ein mentales Modell, das nahezu deckungsgleich ist mit dem tatsächlichen System. Ergo: Wir verstehen quasi alles. Plakatives Beispiel: Ein Entwickler verbaut in einem Formular einen Button mit dem Text „Weiter“. Ihm ist natürlich klar, dass lediglich eine Folgeseite des Formulars aufgerufen wird und der Speichervorgang erst später vollzogen wird. Ein Benutzer muss das noch lange nicht wissen. Eventuell hat er jahrelang mit einer anderen Anwendung gearbeitet, in der ein solches Navigieren eine Speicherung initiiert hat. Oder sogar jede Eingabe per „Direct Action“ sofort den Weg über die Services findet. Die Lösung Teil 1 ist dementsprechend die Einsicht, dass die eigene Perspektive grundsätzlich die falsche ist.

Die Lösung Teil 2: Den Benutzer verstehen

Wenn die eigene Perspektive zu vernachlässigen ist, welche Perspektive ist die richtige? Auf diese Frage liefern verschiedene Methoden Antworten. Die bekannteste Methode ist die Arbeit mit so genannten „Personas“. Es handelt sich dabei um fiktive Personen, die umfassend modelliert werden können. Man überlegt sich also Stellvertreter für die unterschiedlichen Benutzergruppen, gibt ihnen Namen, überlegt, was sie mögen/nicht mögen könnten, sucht ein passendes Foto … Man versucht sich ein schlüssiges Bild zu malen, was diese Personas wissen, welche Erfahrungen, welches Fachwissen sie haben. Diese etwas mystisch anmutende Methode dient dem Zweck, Referenzpunkte zu erarbeiten, um die später erörterten Informations- und Interaktionsmodellierungen nicht mit den eigenen Modellen, sondern den gedanklichen Modellen der Personas abzugleichen.

Die Lösung Teil 3: Dem Benutzer geben, was er braucht

Einer der Erfolgsfaktoren des iPhones – eingangs aufgeführt – ist die Reduktion des Funktionsspektrums, denn diese Reduktion ist ein entscheidender weiterer Schritt bei der Konzeption verständlicher und eingängiger Anwendungen. Nur dann, wenn ich als Benutzer klar abgegrenzte Merkmale ad hoc identifizieren kann, kann ich auch schnell die entsprechenden mentalen Modelle abrufen. Untermauert wird dieser Sachverhalt durch die bereits aus den Sechzigern stammende bekannte Hypothese der „Chunks“ von G.A. Miller. Sie belegte, dass bereits bei mehr als neun zu verarbeitenden Elementen die Kapazität unseres Gehirns erschöpft ist [1]. Stünden dementsprechend neben dem oben beschriebenen Ausfahrtsschild auf der Autobahn zahlreiche weitere Schilder, wäre die Rezeption sicherlich erheblich gestört.

Wie kann nun aber methodisch reduziert werden? Ganz einfach: Dem Benutzer darf nur das gegeben werden, was er in seiner aktuellen Anwendungssituation benötigt. Klingt einfach, oder? Ist es eigentlich auch. Leider verstehen sich heutzutage aber viele Softwareprodukte immer noch als reiner Werkzeugkasten von Funktionen. Alle Features werden irgendwie gruppiert und in Menüs und Untermenüs und Kontextmenüs gehängt. Der Benutzer muss erst einmal verstehen, was die Software leisten kann, dann verstehen, mit welchen Werkzeugen das zu bewerkstelligen ist, wo diese Funktionen zu finden sind und sich aus all dem anschließend einen Arbeitsablauf zusammenbasteln und ihn irgendwann als stabiles mentales Modell abrufbar gespeichert haben. Das Konzept der „Ribbons“ in Office von Microsoft war eines der ersten, das versucht hat, Kontext-sensitive Funktionen einzublenden. Beispiel: Tabellenfunktionen werden erst eingeblendet, wenn ich eine Tabelle in ein Dokument eingefügt habe. Allerdings muss der Benutzer in diesem konkreten Fall wissen, dass er den Cursor in die Tabelle platzieren muss, um die entsprechenden Funktionen eingeblendet zu bekommen. Hier geht die iWelt erheblich weiter: Ich möchte eine E-Mail auf dem iPad schreiben und öffne die Mail-App. Ich sehe eine Liste an E-Mails und es bieten sich mir sage und schreibe zwei Funktionen! „Bearbeiten“, um Elemente aus der Liste der E-Mails zu löschen und „Neu“, um eine E-Mail zu schreiben. Outlook hingegen konfrontiert mich mit dutzenden und aber dutzenden Funktionen. Natürlich ist es schön, einen Regelassistenten im direkten Zugriff zu haben, aber diese Funktion wird sehr selten benötigt, ist aber gleichberechtigt präsent mit dem Menüpunkt „Neue Email“. 

Kommen wir zurück zur Suche nach Methodik: Woher wissen wir, wann der Benutzer welche Funktion benötigt? Die Antwort bekommen wir nur, wenn wir die Arbeitsweise im Detail nachvollziehen. Konkret: Es gilt die unterschiedlichen Anwendungsfälle aus Perspektive des Nutzers zu identifizieren. Dabei sind folgende Aspekte zu klären:

  1. Was motiviert den Benutzer, eine Aufgabe zu bearbeiten? Daraus ergeben sich beispielsweise die Informationen, die der Benutzer über seine Aufgabe bereits hat.
  2.  Welches übergreifende Ziel verfolgt der Benutzer? Was macht ihn abschließend zufrieden oder gar stolz?
  3. Welchen einzelnen Schritt geht der Benutzer mit jeweils welchem Ziel?
  4. Welche Funktionen und Informationen benötigt er für den jeweiligen Schritt? Welche nicht?

Wenn diese Fragen geklärt sind, lässt sich das Funktionsspektrum je nach Bedarf des Benutzers einfach reduzieren. Beispiel: Analysiert man die grundsätzliche Arbeitsweise mit dem Funktionsmonster Excel, könnte man feststellen, dass es in einem entsprechenden Einsatzszenario grundlegend verschiedene Phasen einer Tabellenerstellung gibt. Zum Beispiel Konfiguration der Datenquellen, Design und Formatierung der Datenquellen und Bearbeiten der Daten. In einem solchen Fall spräche nichts dagegen, jede dieser Phasen dem Benutzer deutlich zu machen und entsprechend hintereinander geschaltete Modi zu implementieren. Jeden dieser Modi könnten ausschließlich die speziellen Funktionen beinhalten, die anderen könnten vollständig ausgeblendet werden. Der Benutzer würde ein Arbeitsablauf nahegelegt werden, er müsste aus einem kleineren Spektrum von Funktionen auswählen und könnte weniger falsch machen. 

[ header = Die Lösung Teil 4 & Fazit]

Die Lösung Teil 4: Modellierung der Modelle

Wenn klar ist, welche Schritte den Benutzer zum Ziel führen, lässt sich nun jeder Schritt so gestalten, dass er verständlich und eingängig die benötigten Informationen und Interaktionsmöglichkeiten visualisiert.  Nun ist ja hinlänglich hergeleitet, dass der Weg über bereits Bekanntes führt, sodass der Benutzer sich nichts Neues erschließen muss. Klären wir vorab, woher dieses „Bekannte“ eigentlich kommt. Das wird uns im Folgenden helfen, uns diese Analogien zunutze zu machen. Von allgemeingültig zu spezifisch sind folgende Quellen von Erfahrungswerten identifizierbar: 

  • Realität, Natur
  • Physikalische Begebenheiten, zum Beispiel Gravitation, Mechanik, Masse, Menge
  • Gesellschaftliche Konventionen, zum Beispiel Farbcodes
  • Allgemeinbildung, zum Beispiel Globus, Noten
  • Computererfahrung, zum Beispiel bekannte Paradigmen wie Desktop, Ordner und gängige Icons
  • Fachwissen, zum Beispiel MVVM, Commands und Data Binding, aber auch Feinnadelbiopsie oder Adenosintriphosphat
  • Konkretes Anwendungswissen

Um sich nun diesen Erfahrungsschatz zunutze zu machen, kann wie folgt vorgegangen werden:

  1. Zunächst sind die am jeweiligen Schritt des Anwendungsfalls beteiligten Elemente oder Einheiten zu identifizieren. Beispiele: Person, Ort, Produkt. Wenig hilfreich sind abstrakte Entitäten wie Interfaces, Views und Controls.
  2. Diese Elemente sind nun zu priorisieren. Welche Elemente benötigt der Benutzer wirklich? Kann das System bereits eine Vorfilterung vornehmen?
  3. Es sind Analogien für die Elemente zu finden, die der Benutzer sicher kennt.
  4. Zu den Elementen sind anschließend die im Kontext tatsächlich wichtigen Attribute zu identifizieren. Im Falle der Suche nach einer Person mag ein Identifizierungsmerkmal für einen Anwendungsfall mit wenigen Datenmengen ein Foto sein, für einen anderen der Nachname. In der Regel sind es sehr wenige Attribute, nicht mehr als zwei oder drei. Lassen Sie sich nicht von der gängigen Forderung nach Anzeige aller verfügbaren Attribute irritieren.
  5. Es sind Analogien für die Attribute zu finden. So können Status per Farbcodes eingängig visualisiert werden oder eine Menge durch entsprechend große Visualisierung.
  6. Es sind die im Anwendungsfall durchzuführenden Aktionen mit den Elementen zu identifizieren und ebenfalls Analogien zu finden. Beispiele: Erstellen, Zusammenfügen, Bewegen, Entfernen, Sortieren, Kombinieren. Idealerweise sind die Analogien der Elemente und Aktionen auch im Original vereinbar. Beispielsweise könnte das Stellen der Uhr per Ziehen des Zeigers erfolgen.

Zentral sind hier zwei Herausforderungen: Erstens ist es nicht einfach, die Gewohnheit zu überlisten. Allzu schnell werden die gängigen Visualisierungs- und Interaktionsformen fokussiert. Kreativitätstechniken können hier helfen, neue Wege zu finden. Eine gute Auswahl ist auf Wikipedia zu finden [2]. Zweitens entspricht Neues oft nicht der Erwartung des Benutzers. Als Beispiel weise ich gerne erneut auf mein spätes Entdecken der Pinch-Geste hin. Somit ist darauf zu achten, dass Neues – so eingängig es auch sein mag – immer vorsichtig eingeführt wird. Als Beispiel ist der Installations-Screen von Windows 8 zu nennen, der währende der Installation des Betriebssystems mehr als eindringlich versucht, die unsichtbaren Funktionen in den Ecken zu verdeutlichen.

Zeitlinie und Fazit

Damit haben wir die Ziellinie überquert: Der Benutzer findet die Informationen und Interaktionsformen ad hoc, weil er nur noch diejenigen präsentiert bekommt, die er tatsächlich für seinen aktuellen Kontext benötigt. Und er versteht sie, weil er sie bereits kennt.

Die aufgeführten Lösungen sind nachvollziehbar und klingen nicht nach Rocket-Science. Und dennoch ist die Anwendungslandschaft nach wie vor geprägt von Paradigmen, die diesen Lösungsansätzen ferner kaum sein könnten. Denken wir an all die endlosen DataGrids und unnötigen Informationen, die die Systeme doch längst von uns fernhalten könnten. Aber die Zeit des Umbruchs ist gekommen. Auch weil das iPhone mit der Marktführerschaft die Beweisführung, dass es besser geht, abgeschlossen hat. Eine Chance für uns als Softwareentwicklung und UI-Designer.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -