Rückmeldungen

Das Potenzial interaktiver Schnittstellen besteht darin, dass die Ausgabe eines Systems eng an die Eingabe gekoppelt sein kann. Wir sprechen in solchen Fällen von Rückmeldung. Das beginnt schon auf der untersten Ebene. Ein auf einer Tastatur gedrücktes Zeichen erscheint unmittelbar und genau an der Stelle, an der der Cursor steht. Zugleich bewegt sich dieser, sodass er die Position für das nächste einzugebende Zeichen markiert. Mit der Maus verhält es sich ebenso. Wird sie bewegt, verändert sich entsprechend der Mauszeiger am Bildschirm. Gleitet er über einen Link, ändert sich sein Aussehen und zeigt damit neben möglichen weiteren Informationen an, dass es sich um ein klickbares Objekt handelt. Dieses Kapitel behandelt die ergonomischen Forderungen an dieses Wechselspiel von Ein- und Ausgaben. Insbesondere geht es darum, wann, wo und wie differenziert Rückmeldungen gestaltet werden sollten.

Dazu wollen wir noch einmal kurz auf das Grundlagenthema Differenzerfahrung zurückblicken. Dort haben wir Differenzerfahrung als das Überprüfen von Annahmen durch Wahrnehmen und Handeln in unserer natürlichen Umwelt charakterisiert. Eine entscheidende Voraussetzung für Differenzerfahrung ist, dass die Wahrnehmung unabhängig von den Intentionen und Wünschen der wahrnehmenden Person ist. Durch systematisches Variieren der Umwelt und die Analyse der jeweiligen Wahrnehmungsänderungen können wir über komplexe oder unsichtbare Phänomene Hypothesen anstellen und Theorien aufstellen. Ohne Differenzerfahrung können wir kein Wissen über die Umwelt erlangen und, als Konsequenz daraus, auch nicht wissen, ob eine Handlung, die wir durchführen, das intendierte Ziel erreicht oder nicht.

Nutzungsschnittstellen sind ebenso Teil unserer natürlichen Umwelt. Um über ein Programm etwas erfahren und wahrnehmen zu können, ob eine Handlung innerhalb der Objektwelt der Nutzungsschnittstelle erfolgreich ist, müssen wir Differenzerfahrungen machen können. Das erfordert, dass auf eine Eingabe eine wahrnehmbare Reaktion des Systems dergestalt erfolgt, dass anhand dieser Rückmeldung die möglicherweise vielfältigen Konsequenzen der jeweiligen Handlung erschließbar sind. Nur wenn aus dem, was als Folge einer Handlung wahrgenommen wird, auch etwas geschlossen werden kann, kann Differenzerfahrung gelingen. Eine Rückmeldung muss also genügend differenziert sein, damit sie nützlich ist:

Damit Rückmeldungen des Systems den Anspruch erfüllen, Differenzerfahrung ohne unnötige Umwege, also ohne erzwungene Sequenzialität, zu ermöglichen, muss eine Reihe weiterer Forderungen erfüllt sein, die sich aus den Eigenschaften der menschlichen Wahrnehmung ableiten lassen:

Im Kapitel Architektur der Wahrnehmung haben wir die Wahrnehmung des Menschen als selektiv beschrieben. Der Bereich des scharfen Sehens ist eingeschränkt. Dieses Manko wird durch eine hohe Bewegungsempfindlichkeit im peripheren Sichtbereich ausgeglichen. Eine Reaktion auf eine Handlung muss also, damit sie verlässlich wahrgenommen werden kann, entweder dort erfolgen, wo die Handlung stattfindet, oder die Aufmerksamkeit auf sich zieht. Letzteres behandeln wir im Kapitel „Ereignisbehandlung“. Aus der ersten Alternative leiten wir die Notwendigkeit nach der Lokalität der Rückmeldung ab:

Neben dem räumlichen Aspekt kommt der zeitlichen Dimension eine besondere Bedeutung zu. Wir tendieren dazu, eine Kopplung zwischen zwei Ereignissen herzustellen, wenn sie nahezu zeitgleich erfolgen. Wenn Sie eine Türklinke anfassen, sich im gleichen Augenblick das Licht im Raum einschaltet oder wenn Sie auf den Knopf an einer Fußgängerampel drücken und direkt danach ein Auto hupt, dann haben diese Ereignisse in der Regel nichts miteinander zu tun. Durch ihre enge zeitliche Abfolge erscheinen sie uns aber auf den ersten Blick als Ursache und Wirkung. Umgekehrt nehmen wir eine Änderung in der Umwelt nur dann als kausal mit einer Handlung zusammenhängend wahr, wenn diese innerhalb eines kurzen Zeitraums erfolgt. Überschreitet dieser Zeitraum eine gewisse Schwelle, wird eine Veränderung nicht mehr direkt als Folge der Handlung wahrgenommen. Aus dieser Beobachtung können wir die Forderung nach Unmittelbarkeit der Rückmeldung ableiten:

Unmittelbarkeit, Differenziertheit und Lokalität der Rückmeldung sind als Grundforderungen an jede Form von Rückmeldung zu stellen.

Differenziertheit: Feed-Back und Feed-Forward

Eine differenzierte Rückmeldung hat in unserer Denkweise immer zwei Komponenten: Das Wort „Rückmeldung“ an sich deutet an, dass sie in die Vergangenheit gerichtet ist. Eine gute Rückmeldung sollte aber möglichst auch einen Aspekt haben, der in die Zukunft, also nach vorne gerichtet ist. Eine nach vorne gerichtete Rückmeldung zeigt mögliche Anschlusshandlungen auf und beschreibt im Fehlerfall Ursachen und was zur Korrektur getan werden kann. Wir stellen dem Begriff der Rückmeldung im engeren Sinne, also dem „Feed-Back“, deshalb den Begriff „Feed-Forward“ an die Seite. Im Gegensatz zu einem Feed-Back, das die Folgen einer Handlung widerspiegelt, beschreibt ein Feed-Forward die aktuelle Situation und welche Operationen möglich sind¹³.

Die Situation, in der differenziertes Feed-Back und Feed-Forward gefordert ist, muss übrigens keine Fehlersituation sein und ist es in den meisten Fällen auch nicht. Ein gutes Beispiel für Feed-Forward haben Sie in der Einleitung zu diesem Kapitel schon kennengelernt. Ein sich ändernder Mauszeiger beim Überfahren eines Elements auf dem Bildschirm ist der nach vorne gerichtete Teil der Rückmeldung. Die Zeigeränderung zeigt an, dass ein selektierbares Objekt vorliegt und – bei entsprechender Differenziertheit – auch, was im Falle eines Klicks passieren wird.

Die drei Forderungen Differenziertheit, Unmittelbarkeit und Lokalität sind gleichermaßen unverzichtbar, auch wenn es je nach Nutzungskonstellation im Einzelfall unterschiedliche Priorisierungen geben mag. Erfolgt eine Rückmeldung an ungünstiger Stelle oder verzögert, kann das Irritationen und unnötige Fehlbedienungen zur Folge haben. Ist eine Rückmeldung nicht differenziert, weiß man unter Umständen nicht, was geschehen ist oder noch geschehen kann. Auch das kann zu Irritationen und Fehlhandlungen führen. Noch wichtiger ist uns aber, dass ein System ohne differenzierte Rückmeldung bei der Nutzung nicht erschließbar ist. Entweder müssen alle möglichen Konstellationen zuvor erlernt worden sein oder es ist kommunikativer Zusatzaufwand bzw. entsprechender Rechercheaufwand erforderlich, um die unterbrochene Aufgabe fortsetzen zu können. Etwas pathetischer ausgedrückt: Mängel in der Differenziertheit der Rückmeldung entmündigen die Person vor dem Bildschirm!

Beispielsweise würden Sie im Fehlerfall statt einer aussagekräftigen Fehlermeldung nur einen allgemeinen Hinweis der Art erhalten: „Es ist etwas passiert!“ Dieses Feed-Back ist nicht hilfreich, da es keinerlei Anhaltspunkte dafür bietet, was passiert ist und was getan werden kann. Das gilt auch für nicht differenziertes Feed-Forward. Stellen Sie sich eine Bildschirmmaske vor, die Sie darüber informiert, dass ein Datenträger nicht lesbar ist. Als mögliche Operation wird Ihnen neben „Abbrechen“ nur die Option „Beheben“ angeboten. Aber was passiert, wenn man auf „Beheben“ klickt? Wird der Datenträger repariert oder formatiert? Das eine ermöglicht den erneuten Zugriff auf die gespeicherten Dateien, das andere löscht alle Daten und gestattet das Schreiben einer neuen Datei. „Beheben“ ist nicht differenziert genug, um angemessene Handlungsstrategien entwickeln zu können.

Differenziertes Feed-Back bedeutet also, nicht nur zu beschreiben, dass etwas passiert ist, sondern auch was passiert ist und gegebenenfalls, warum es passiert ist. Erst ein solches Feed-Back ermöglicht Differenzerfahrungen, indem der aktuelle Zustand des Systems eingeschätzt und in Beziehung zu den jeweiligen Handlungszielen gesetzt werden kann. Differenziertes Feed-Forward beinhaltet darüber hinaus, dass alle Optionen für Anschlusshandlungen aussagekräftig beschrieben sind.

Gestaltung von Meldungsboxen

Ein wichtiger Bereich unter den unzähligen Formen von Rückmeldungen sind textuelle Meldungen, in denen Handlungsoptionen dargelegt und angeboten werden. Die klassische Form solcher Meldungen erscheint in Meldungsfenstern. Ihr Inhalt umfasst nicht nur Fehlermeldungen im eigentlichen Sinne, sondern auch Hinweise oder Bestätigungsanforderungen. Diese Arten von Meldungen und Interaktionen müssen nicht unbedingt in eigenen Fenstern angezeigt werden. Gerade in modernen Anwendungen und in Web-Anwendungen werden diese Elemente oft anders dargeboten als in den klassischen Boxen. Der Übersichtlichkeit halber beschränken wir uns auf Meldungsboxen, um die grundlegenden Prinzipien zu veranschaulichen.

Wie auch immer eine Meldung grafisch gestaltet wird, ihr Inhalt, allem voran der Meldungstext, muss differenziert sein. Dies betrifft sowohl den Feed-Back-Teil als auch den Feed-Forward-Teil. Eine Meldung, die nur Feed-Back, aber kein Feed-Forward beinhaltet, kann in Ausnahmefällen sinnvoll sein, etwa bei der Bestätigung einer abgeschlossenen Operation wie „Export abgeschlossen“.

Diese Meldung erscheint, nachdem ein Programm geöffnet werden sollte. Außer dem Fehlercode wird keinerlei Hinweis darauf gegeben, was die Ursache des Fehlers ist. Im Internet finden sich in Support-Dokumenten Listen, in denen diese Codes aufgeschlüsselt sind. Die „36“ bedeutet in diesem Fall „Daten können nicht geschrieben werden“. Es bleibt schleierhaft, warum in der Meldung statt der Nummer nicht dieser Text geschrieben steht. Doch auch dies wäre nicht besonders hilfreich, denn er grenzt zwar den Bereich möglicher technischer Ursachen ein, ist aber weder aussagekräftig noch situationsspezifisch. Welche Daten können denn beim Anwenden der Anwendung nicht geöffnet werden und warum? Noch schlechter sieht es in der Meldung mit dem Feed-Forward aus, denn es werden keine Anschlusshandlungen oder alternative Handlungsoptionen aufgeführt.

Bei dieser Meldung ist es schon besser. Der fett geschriebene Text gibt ein recht differenziertes Feed-Back und informiert darüber, dass der gewählte Dateiname nicht verwendet werden kann. Leider erfährt man nicht, dass das in diesem Fall am Doppelpunkt liegt, der in Dateinamen nicht zulässig ist. Immerhin wird ein Feed-Forward gegeben, das empfiehlt, keine Satzzeichen zu verwenden oder den Namen zu verkürzen. Die spezifischere Rückmeldung, dass ein Doppelpunkt das Problem darstellt, würde bezüglich der Änderung des Dateinamens deutlich mehr Optionen lassen. Diese genauere Analyse des Problems würde zudem auch ein direktes Handlungsangebot mit Buttons zum direkten Beheben des Fehlers ermöglichen.

Gutes Feed-Back und Feed-Forward bereitzustellen, ist leider nicht so einfach. Das Meldungsfenster erscheint, nachdem die Anwendung, mit der ein Text bearbeitet worden ist, geschlossen werden soll, ohne dass die Änderungen zuvor gespeichert worden sind. Da dies zu Datenverlust führen kann, verlangt das System eine Bestätigung der Operation. Die abgebildete Meldungsbox ist klar eingeteilt. Die erste Textzeile ist das Feed-Back, alles Weitere danach ist Feed-Forward¹⁴.

In ihrem Feed-Back-Teil enthält die Meldungsbox einen typischen Fehler, der nur deshalb nicht auffällt, weil man sich an ihn gewöhnt hat. Dort steht: „The text has been edited.“ Das mag so sein, ist aber nicht das Problem, denn die Bearbeitung des Textes entspricht ja der auszuführenden Aufgabe. Der wirkliche Anlass liegt in der Tatsache begründet, dass die zu diesem Zeitpunkt aktuelle Textfassung bislang noch nicht abgespeichert worden ist.

„Aber das eine folgt aus dem anderen, oder?“

Das eine folgt aus dem anderen nur dann zwangsläufig, wenn Sie die Eigenarten aktueller Nutzungsschnittstellen kennen. So muss man wissen, dass man beim Laden einer Datei eine Kopie des Textes öffnet, die dann bearbeitet wird, nicht jedoch der Inhalt der Datei. Will man die Kopie der geladenen Textdatei mit ihren Änderungen dauerhaft sichern, muss man sie explizit speichern. Eine ergonomisch gestaltete Nutzungsoberfläche sollte solcherart implizites Wissen nicht voraussetzen, sondern explizit beschreiben, da es insbesondere in der anfänglichen Nutzung nicht vorausgesetzt werden kann. Die Tatsache, dass wir gelernt haben, mit einer Vielzahl schlechter Designentscheidungen zu leben, ist keine Ausrede für eine ergonomisch unzureichende Gestaltung.

„Aber man kann doch nicht immer einen kompletten Roman hinschreiben, nur weil ein Anfänger vielleicht etwas nicht wissen könnte!“

Das ist auch nicht nötig. Würde dort stattdessen stehen „The edited text has not been saved yet“, gäbe es kein Problem mehr, weil die Ursache und damit der Auslöser für diese Meldung jetzt präzise angegeben ist. Eine einfache Regel hilft in solchen Fällen weiter: Das Feed-Back muss Aufschluss über den Aspekt des System- oder Objektzustands geben, auf dessen Grundlage die Meldung angezeigt wird. Ist dies nur indirekt der Fall, hat man einen Ansatzpunkt, die Meldung zu verbessern.

Zur Illustration des Gesagten versuchen wir, eine zugegebenermaßen sehr schlechte Meldung zu verbessern. Es handelt sich um eine Software, die automatisch Web-Content generiert und diesen auf einen Web-Server hochzuladen versucht¹⁵. Wenn die unter „Homepage“ eingetragene Netzwerkadresse ungültig ist, tritt ein Fehler auf. Die Software ist aber so robust gebaut, dass sie in diesem Fall die Daten nicht verwirft, sondern lokal speichert.

So weit so gut; doch die dann erscheinende Fehlermeldung gibt Rätsel auf. Zum einen enthält sie kein direktes Feed-Forward. Es wird weder gesagt, was zu tun ist, noch was getan werden kann. Auch das Feed-Back ist verbesserungswürdig. Das beginnt schon bei der Titelzeile „Nicht erlaubt / Fehlende Eingabe …“. Kann sich das System nicht für eine Alternative entscheiden? Und was bedeutet „nicht erlaubt“? Und warum ist es nicht erlaubt? Nach dieser kryptischen Überschrift folgt der eigentümliche Text „Die angegebene Homepage existiert nicht. Dokument wird gespeichert“. Schon im ersten Satz gibt es wieder ein sprachliches Problem. Die Homepage existiert nicht? Unsinn! Unter der angegebenen Adresse konnte keine Homepage gefunden oder es konnte keine Verbindung hergestellt werden. Wir neigen umgangssprachlich dazu, Daten gleichzusetzen mit dem, worauf sie sich beziehen. Statt bei einer Personendatenbank „Datensatz löschen“ oder „Karteieintrag löschen“ zu sagen, heißt es „Person löschen“. Auch in einer Literaturdatenbank werden nicht Bücher angelegt oder gelöscht, sondern bibliographische Angaben. Das eigentliche Buch hat mit der Datenbank nichts zu tun, denn es wird durch den Eintrag weder erschaffen noch zerstört. Wie eigenartig diese Sprechweise ist, merkt man, wenn man sie auf andere Bereiche überträgt, etwa auf das Telefonieren. Der Logik dieser Meldung folgend müssten wir, wenn wir beim Telefonieren eine falsche Nummer gewählt haben, statt der Ansage, dass die Rufnummer nicht vergeben sei, die Meldung erhalten „Ihr Gesprächspartner existiert nicht!“ zu hören bekommen.

Sehen wir einmal von kafkaesken Bürokratien ab, wo eine nicht vorhandene Personalnummer als gleichbedeutend mit der Aussage scheint, dass es diese Person nicht gibt, erzwingt eine ergonomische Gestaltung eine präzise Sprache, vor allem, wenn es um das Verständnis technischer Vorgänge geht. Diese werden zur Entwicklungszeit festgelegt und sollten immer, unabhängig von den vielfältigen Nutzungskonstellationen, die ihnen zugrunde gelegte Designrationalität widerspiegeln. Solange es nicht zu bürokratisch wird, gilt es also, den inhaltlichen Vorgang möglichst präzise zu beschreiben. Falls diese Beschreibungen zu lang werden sollten, kann man sich gegebenenfalls mit „Eintrag löschen“ behelfen. Auch der zweite Satz dieses Beispiels ist nicht besser, denn er scheint in keinem Zusammenhang mit dem ersten Satz zu stehen und ihm noch zu widersprechen. Das liegt daran, dass er so unspezifisch ist. Man kann ihm nicht entnehmen, dass die Daten lokal statt auf dem Server gespeichert werden.

Hier sehen Sie eine verbesserte Fassung dieser Fehlermeldung. Schon der Titel benennt, wenn auch noch recht allgemein, als Ursache des Problems, dass die Daten nicht hochgeladen werden können. Der fett geschriebene Text innerhalb der Meldung beschreibt dies genauer. Anschließend könnte ein Text folgen wie „Ihre Daten wurden daher lokal gespeichert. Bitte überprüfen und korrigieren Sie den angegebenen Netzwerkpfad und versuchen Sie es erneut“. Das wäre ein differenziertes Feed-Forward. In dieser Überarbeitung gehen wir noch einen Schritt weiter und bieten im Sinne der Eingabeminimalität drei Alternativen für eine Anschlusshandlung an: es dabei zu belassen und die Daten lokal zu speichern, zurückzukehren, um den Fehler zu korrigieren, oder die Änderungen zu verwerfen.

Diese Abbildung zeigt das klassische Schema für Meldungsfenster. Je nach System und Fehlerklasse können Meldungsboxen dieser Art über folgende Teilelemente verfügen. Wenn es eine Titelzeile gibt, sollte sie dafür genutzt werden, den Anlass der Meldung kurz zusammenzufassen, zum Beispiel „Datei mit diesem Dateinamen existiert bereits“. Im Meldungstext folgt dann als Erstes eine ausführliche Erläuterung der Ursache. Wenn die Meldungsfenster im System, für das Sie gestalten, keine Titelzeilen vorsehen, schreiben Sie die Kurzzusammenfassung als erste abgesetzte Zeile mit in den eigentlichen Meldungstext. Verzichten Sie nicht auf ihn! Die Kurzcharakterisierung, zusammen mit aussagekräftigen, konkret beschrifteten Buttons, ist bei routinierter Nutzung ausreichend, denn aufgrund der Vertrautheit mit dem System erkennt man die Situation wieder, ohne den restlichen Meldungstext lesen zu müssen.

Wenn jedoch der Anlass für die Meldung selten auftritt oder die Software nur gelegentlich genutzt wird, kommt der Rest des Meldungstextes ins Spiel. Neben der ausführlicheren Beschreibung des Anlasses enthält dieser eine ausführliche Darstellung der Handlungsoptionen und Konsequenzen. Wenn eine Meldung eine Vielzahl von Handlungsoptionen direkt anbietet, müssen diese beschrieben werden ebenso in den Fällen, in denen die Anschlusshandlungen komplexere manuelle Operationen nach sich ziehen.

Unser Meldungstext enthält keine Frage. Bereits im Kapitel Strukturiertheit haben wir dargelegt, warum das Stellen von Fragen wenig hilfreich ist. Wenn auf eine Frage generische Antworten wie „Ja“, „Nein“ oder „Okay“ folgen, erhöht sich der Zusatzaufwand, denn die Inschrift auf dem Button muss auf die Frage bezogen und interpretiert werden, welche Änderungen im System mit der jeweiligen Antwort einhergehen. In empirischen Untersuchungen haben wir herausgefunden¹⁶, dass bei generischen Buttons Fragen dann kaum einen Nachteil haben, wenn die Buttons spezifisch beschriftet sind. Wir raten dennoch davon ab, eine Frage zu stellen, denn die Frage wird entweder sehr generischer Natur sein, wie „Was wollen Sie tun?“ oder die Beschreibung der Handlungsoptionen muss zur Frage umformuliert werden, was auch bei der Entwicklung mehr Aufwand verursacht, der aber keinen ergonomischen Vorteil verspricht.

Unsere Meldung enthält neben dem eigentlichen Text auf der linken Seite ein Icon. Dieses Icon kann dazu genutzt werden, Meldungen zu klassifizieren. Microsoft definiert für seine Betriebssysteme eine Einteilung in drei Stufen mit absteigender Dringlichkeit: „Fehler“, „Warnung“ und „Information“. Eine von uns durchgeführte Auswertung der Blickdaten bei der Nutzung von Meldungsboxen¹⁷ hat ergeben, dass diese Icons kaum betrachtet werden. Unsere Hypothese ist, dass diese Zusatzinformationen nicht mehr registriert werden, weil jede Meldung über ein solches Icon verfügt. Würde ein Icon wie das doch sehr auffällige Kreuz auf rotem Grund nur dann verwendet, wenn wirklich etwas von herausragender Wichtigkeit angezeigt wird, wäre die Wirkung wahrscheinlich höher. Wir empfehlen deshalb, es nur in den Fällen einzusetzen, in denen Datenverlust oder ähnlich fatale Konsequenzen drohen. In diesen Situationen rechtfertigt sich auch der Einsatz einer Signalfarbe, um zusätzlich die Aufmerksamkeit auf das Problem zu lenken.

Verbesserung: Button und Beschreibung kolokieren

Wenn man spezifisch beschriftete Buttons einsetzt, kann man in vielen einfachen Fällen bei Meldungen auf einen umfangreichen Erklärungstext verzichten. Sind die Operationen komplex genug, dass sie einer zusätzlichen Erklärung bedürfen, ist der im obigen Beispiel gepflegte Meldungsstil nicht ideal, denn die Buttons, die die Funktionen auslösen, und die Erklärungstexte, die die Funktionen beschreiben, sind einander nicht klar zugeordnet.

Die Abbildung zeigt ein verbessertes Meldungsfenster mit umfangreichen Erläuterungstexten, bei dem zusätzlich die im Kapitel Anordnung beschriebene Zuordnungstechnik der Kolokation umgesetzt worden ist. Die Zuordnung der Buttons und ihrer Erläuterungen bildet sich somit auch in der sichtbaren Anordnung der Elemente am Bildschirm ab.

Differenzierte Rückmeldung bei unerwarteten Handlungen

Ein Spezialfall der Behandlung von unerwarteten Eingaben ist der Umgang mit Eingaben zu Zeitpunkten, an denen keine Eingaben getätigt werden können. Dieser Screenshot eines älteren Mail-Programms auf dem Macintosh zeigt, was beim Tippen in einer solchen Situation passiert. Sie ist zum einen besonders gut, weil sie beschreibt, warum die Eingabe, die gerade erfolgt, nirgendwo erscheint. Zum anderen ist sie nicht ideal, da sie einen zusätzlichen Schritt zum Quittieren der Meldung erzwingt. Ob ein Zusatzschritt, der den Arbeitsfluss unterbrechen würde, gerechtfertigt ist, lässt sich schwer feststellen. Es könnte auch ein Hinweis darauf sein, dass aus Versehen ein Gegenstand auf die Tastatur geraten ist. Tatsächlich sollte von einem System nicht nur jede korrekte Eingabe richtig verarbeitet werden, sondern auch jede nicht korrekte. Das Meldungsfenster verkörpert eine ergonomische Zusatzinformation, die signalisiert, dass unnütze Eingaben passieren. Erst auf Basis dieser Information kann man während der Nutzung über die möglichen Ursachen nachdenken und Strategien zur zukünftigen Vermeidung überlegen.

Differenziertheit jenseits des Textes

Differenziertheit bedeutet nicht in jedem Fall, dass es einen sehr ausführlichen Text geben muss oder dass die Rückmeldung nur aus Text bestehen sollte.

Bei der unten abgebildeten Fehlermeldung wurde die aus dem Kapitel Anordnung bekannte Technik der Kopplung angewandt, um zu verdeutlichen, auf welches Objekt am Bildschirm sich die Fehlermeldung bezieht. Es wird im wahrsten Sinne des Wortes „aufgezeigt“, dass „selke“ keine gültige E-Mail-Adresse ist. Auch dieser räumliche Hinweis verkörpert eine Zusatzinformation in Form eines differenzierteren Feed-Backs.

Auch in der in MacOS systemweit eingebauten Funktion, innerhalb der zentralen Menüleiste nach Elementen suchen zu können, gibt es eine räumliche Form der Differenziertheit. Wenn man im Suchergebnis einen Eintrag selektiert, wird das entsprechende Menü geöffnet und auf den Menüeintrag selbst per Zeiger hingewiesen. Es gibt also zusätzlich zur textuellen Rückmeldung auch ein räumliches Feed-Forward, das darüber informiert, wo die Funktion zu finden ist.

Unmittelbarkeit

Damit eine Rückmeldung gut funktioniert, muss sie immer unmittelbar, also ohne nennenswerten zeitlichen Versatz erfolgen. Erfolgt eine Reaktion nicht unmittelbar, stockt nicht nur der Handlungsablauf, sondern es kommt auch zu Irritationen und Fehlhandlungen.

Idealerweise werden Eingabe und Rückmeldung als gleichzeitig wahrgenommen. Tatsächlich erfolgt zwischen der Eingabe und der zugehörigen Ausgabe eine Verarbeitung, die ebenfalls Zeit benötigt. Gleichzeitigkeit in einem strengen Sinn ist auch nicht gefordert, denn wenn die Verarbeitungszeit unter einem Schwellwert von 20 bis 30 Millisekunden bleibt, haben wir den Eindruck, dass etwas gleichzeitig geschieht. Die verstrichene Zeit ist nicht bewusstseinspflichtig und kann sich folglich auch nicht störend auswirken. Der Hörsinn ist empfindlicher. Schon ab 3 Millisekunden Versatz hören wir zwei Töne nicht mehr gleichzeitig. Bei so einem kurzen Abstand ist es jedoch dem Wahrnehmungsapparat nicht möglich zu bestimmen, welcher Ton als erster und welcher als zweiter zu hören war.

Die Grafik illustriert ein Experiment, das der Psychologe Richard Gregory¹⁸ beschreibt, um die Konsequenzen von Störungen im Handlungsfluss zu untersuchen. Die Versuchspersonen haben die Aufgabe, Sterne mit einem Stift nachzuzeichnen und einige Worte zu schreiben. Zunächst tun sie das wie üblich mit Stift und Papier, wobei die Augen das Geschehen beobachten. Bei den nächsten beiden Versionen der experimentellen Anordnung wird die Sicht auf das Blatt Papier und die eigene Hand blockiert. Stattdessen sehen die Versuchspersonen jetzt diese Szene über einem Monitor, wie links in der Abbildung dargestellt. Wie Sie in der mittleren Spalte im rechten Teil der Grafik sehen, gelingt das Zeichnen und Schreiben zwar nicht mehr so präzise wie bei direkter Betrachtung der Szene (linke Spalte), aber immer noch passabel. Problematisch wird es jedoch, wenn die Wahrnehmung dessen, was man mit der Hand auf das Papier zeichnet, technisch verzögert¹⁹ wird. Das Ergebnis sehen Sie in der rechten Spalte. Das Schreiben funktioniert noch erstaunlich gut, vermutlich, weil Schreibbewegungen stark automatisiert und größtenteils ohne Hinsehen durchführbar sind. Das Nachzeichnen des Sterns kann jedoch nur als Desaster bezeichnet werden.

Das gleiche Problem wie beim Zeichnen des Sterns passiert auch, wenn Rückmeldungen, die direkt an die physischen Eingaben gekoppelt sind, verzögert erfolgen. Gibt es zum Beispiel eine merkliche Verzögerung bei der Rückmeldung auf Mausbewegungen, ist man nicht mehr in der Lage, den Mauszeiger ordentlich zu positionieren.

Nicht alle Rückmeldungen am Computer müssen aber derart schnell erfolgen. Denn auch wenn etwas nicht gleichzeitig erscheint, werden Handlung und Reaktion doch als Ursache und Wirkung interpretiert, wenn der Zeitabstand nicht zu groß wird. Die Schwelle, ab der zwei Ereignisse nicht mehr als Ursache-Wirkung angesehen werden, hängt von den individuellen und situativen Gegebenheiten ab. Sie liegt aber in jedem Falle bei wenigen Sekunden. In der Abbildung oben ist ein moderner Kaffeeautomat zu sehen. Wie viele andere moderne Geräte verfügt die Maschine über ein Touch-Display. Die Bedienung dieser Maschine ist allerdings sehr träge, vor allem, wenn sie schon länger gelaufen ist. Wenn man auf „Cappuccino“ drückt, passiert zunächst nichts. Was macht man, wenn man irgendwo draufdrückt und nichts passiert? Aus der Fehlerforschung und eigener Erfahrung wissen wir, dass man bei unerwarteten Diskrepanzen die letzte Handlung wiederholt; man drückt noch einmal. Dies führt hier dazu, dass, sobald die Maschine wieder „ansprechbar“ ist, ein weiteres Tipp-Ereignis an der angetippten Stelle ausgelöst wird. Allerdings ist diese Stelle nun mit „Abbrechen“ beschriftet. Dass für den Bruchteil einer Sekunde ein zweiter Bildschirm erscheint, nur um dann gleich wieder die Startseite anzuzeigen, ist bei der Nutzung sehr irritierend. Einmal abgesehen von der nicht nachvollziehbaren Verzögerung gibt es keine unmittelbare Rückmeldung, dass eine Eingabe registriert worden ist.

Rückmeldungen haben somit zwei Komponenten, die beide unabhängig voneinander in der Nutzungsschnittstelle auftreten sollten. Unmittelbarkeit muss immer eingehalten werden. Damit dies auch dann geschehen kann, wenn noch keine Ergebnisse vorliegen, muss direkt nach einer Eingabe zumindest dieser Umstand, dass diese erkannt und nun verarbeitet wird, an der Nutzungsschnittstelle signalisiert werden evtl. mit dem Hinweis, dass Wartezeiten auftreten können. Beträgt die Wartezeit mehr als ein paar Sekunden wie bei der Kaffeemaschine, sollte fortlaufend der jeweils aktuelle Stand angezeigt werden.

Fortlaufende Rückmeldung

Insbesondere bei der Verarbeitung großer Datenmengen benötigen Verarbeitungsprozesse am Computer so viel Zeit, dass bis zur Ergebnismeldung die Wahrnehmungsschwelle deutlich überschritten wird: Sie müssen warten. Warten, ohne etwas tun zu können, ist eine sehr belastende Aktivität, die gerade in hektischen Zeiten viel Stress erzeugt. Wenn wir auf die Verarbeitungsgeschwindigkeit keinen Einfluss haben, wird es umso wichtiger, durch fortlaufende Rückmeldung Handlungsoptionen zu eröffnen.

Wenn also eine zeitlich unmittelbare Rückmeldung des Ergebnisses nicht möglich ist, muss der Prozess selbst zum Gegenstand der Rückmeldung werden und der Fortschritt fortlaufend differenziert angezeigt werden.

Fortschrittsanzeigen wie die obige entlasten, weil sie es gestatten, alternative Handlungsstrategien zu entwickeln. Wenn man nicht weiß, wie schnell oder langsam ein Prozess ist, und man keine Zeit verlieren darf, muss man kontinuierlich den Bildschirm beobachten, um den Zeitpunkt nicht zu verpassen, wenn das Resultat vorliegt. Bei einem halbwegs gleichförmigen Verarbeitungsprozess gestattet es eine Fortschrittsanzeige schon nach kurzer Beobachtungsdauer abzuschätzen, wie viel Zeit noch bis zum Erreichen des Ergebnisses verstreichen wird (Monitoring). Aufgrund der auch zeitlich differenzierten Rückmeldung, die auch eine Abschätzung der ungefähren Restdauer enthalten sollte, kann die Dauer des Prozesses eingeschätzt werden. Diese Befreiung vom Monitoring ermöglicht es, andere Aktivitäten auszuführen oder auch eine Pause einzulegen. Ein akustisches Signal und gegebenenfalls eine Meldung darüber, dass der Prozess fertig ist, erlauben es, passend zum Prozessende die Aktivitäten fortzuführen. Mehr dazu im folgenden Kapitel in unseren Hinweisen zu Ereignissen.

Das Problem der wahrgenommenen Zeit

Zeit ist ein sehr subjektives Gefühl. Der Eindruck variiert stark mit unserem inneren Zustand und unseren Erwartungen. Der Microsoft-Forscher Steven Seow hat dazu einige Untersuchungen durchgeführt²⁰. Nach Seow sollte es bei der Gestaltung von Abläufen in der Nutzungsschnittstelle immer das Ziel sein, dass die wahrgenommene, gefühlte Zeit stets kürzer erscheint als die tatsächliche Zeit. Zumindest sollte die wahrgenommene Zeit nicht länger als die tatsächlich vergangene Zeit erscheinen. Seow identifiziert einige Situationen und Gestaltungsoptionen, die die wahrgenommene Zeit länger erscheinen lassen, als sie tatsächlich ist.

• Bei sehr großen Mengenangaben, die man nicht einschätzen kann, beispielsweise wenn bei einer Installation „Noch 43.538 Elemente“ angezeigt wird, sollte man in so einem Fall auf die Anzahl von Restmengen verzichten.
• Wenn es keine Informationen über den zu erwartenden Zeitaufwand gibt, sollte immer eine geschätzte Restzeit angezeigt werden. Idealerweise sollte man bei langen Vorgängen schon vor dem Start eine geschätzte Restzeit angeben, um die Chance zu eröffnen, diese Operation aufgrund von Zeitmangel eventuell zu verschieben.
• Besonders ärgerlich ist es, wenn die Restzeit im Laufe des Prozesses wieder ansteigt oder die letzten paar Sekunden ewig zu dauern scheinen. Um solchen Ärgernissen vorzubeugen, sollte de Restzeit eher über- als unterschätzt werden.
• Fortschrittsanzeigen, die sich lange nicht zu bewegen scheinen, sollten vermieden werden. Eine Möglichkeit besteht darin, sie nicht linear zu gestalten (dazu weiter unten mehr).
• Für den Fall, dass eine Fortschrittsanzeige bis zum Ende durchläuft und dann die nächste Fortschrittsanzeige für den folgenden Prozessschritt beginnt, lautet die Empfehlung, mehrere Progress-Bars zu verwenden, von denen eine den Vorgang des aktuellen Schrittes und eine den Vorgang des Gesamtprozesses anzeigt.
• Zwar gibt es Ausnahmen, in denen die vergangene Zeit am Ende eines Prozesses wichtig ist, doch ist in den meisten Fällen die Vergangenheit nicht interessant. Schlimmer noch – so paradox es klingt – kann die gefühlte Zeit durch die Angabe der bereits vergangenen Zeit länger erscheinen.

Neben diesen Gestaltungshinweisen, die Zeit nicht länger erscheinen zu lassen als sie ist, gibt es eine Reihe von Tricks, wie man es schafft, dass die wahrgenommene Zeit kürzer erscheint, als sie eigentlich ist. Seow beschreibt zum Beispiel, dass bei einem Installationsvorgang das Kopieren von Dateien schon beginnen kann, während noch Konfigurationseinstellungen abgefragt werden. Die Zeit, in der Eingaben getätigt werden, wird nicht als Wartezeit empfunden, sodass der Installationsvorgang kürzer erscheint.

Auch bei der Gestaltung der Fortschrittsanzeigen kann man einige Tricks anwenden. Seow beschreibt nicht lineare Fortschrittsanzeigen mit einem logarithmischen Verlauf, wie dies in der Abbildung dargestellt ist.

Dazu ein Beispiel: Nehmen Sie an, Sie wollten tausend Bilder über eine recht langsame Netzwerkverbindung verschicken. Zur Fortschrittsanzeige dient Ihnen ein Fortschrittsbalken, der aus zehn Segmenten besteht. Bei einer linearen Fortschrittsanzeige würde alle hundert Bilder ein zusätzliches Segment erscheinen. Im nicht linearen Fall erscheint das erste Segment erst nach 230 Bildern, zwischen dem vorletzten und letzten Balken liegen hingegen nur noch dreißig Bilder. Eine solche Fortschrittsanzeige erweckt den Eindruck, dass der Prozess gerade am Ende, wenn die Aufmerksamkeit auf den Fortschritt besonders hoch ist, schnell vonstatten geht. In der Konsequenz wird der Prozess insgesamt als schneller empfunden.

Andere Tricks, die einen schnelleren Fortschritt suggerieren, beziehen sich auf das optische Erscheinungsbild des Fortschrittsbalkens. Studien von Chris Harrison et al.²¹ haben ergeben, dass Fortschrittsbalken, die nicht stets die gleiche Farbe haben, sondern die farblich pulsieren und bei denen sich die Frequenz des Pulsierens zum Ende hin erhöht, als schneller angesehen werden als gleichmäßig pulsierende oder nicht pulsierende Fortschrittsbalken. Ebenfalls werden Fortschrittsbalken, die ein sich nach links bewegendes Muster aufweisen, als schneller laufend wahrgenommen als statische Fortschrittsbalken.

Sind solche Tricks unethisch? Tatsächlich findet keine Täuschung in Bezug auf die abgelaufene Zeit statt. Beeinflusst wird lediglich die subjektive Zeitwahrnehmung. Insofern entstehen in der Nutzung keinerlei Nachteile. Umgekehrt jedoch kann die Maßnahme dazu beitragen, Stress zu reduzieren.

Lokalität

In Douglas Adams’ „Per Anhalter durch die Galaxis“ wird die Erde zerstört, weil sie der Trasse einer intergalaktischen Schnellstraße im Wege steht. Auf den Einwand hin, dass man dies doch nicht einfach so unangekündigt machen könne, wird entgegnet, dass die Pläne dafür schon lange auf Alpha Centauri ausgelegen hätten. Nun sind Entfernungen am Bildschirm nicht so groß, wie von der Erde zu Alpha Centauri, doch kann es auch bei der Gestaltung von Rückmeldungen am Bildschirm passieren, dass sie einfach nicht gesehen werden, weil sie zu weit weg sind. Bei der Nutzung ist die Aufmerksamkeit auf den Ort der Handlung gerichtet. Wenn an einer anderen Stelle des Bildschirms etwas passiert, wird es nur wahrgenommen, wenn über das periphere Sehfeld ein starker Reiz die Aufmerksamkeit auf sich zieht. Doch selbst dann wird zunächst nur registriert, dass sich etwas geändert hat, aber nicht was. Viel besser wäre es, wenn die Rückmeldung zur Handlung nicht auf Alpha Centauri erfolgen würde, sondern lokal angezeigt wird, also da, wo ohnehin gerade der Fokus der Aufmerksamkeit liegt.

Unten sehen Sie den schon schon bekannten Parkscheinautomaten. Die eingezeichneten Pfeile stellen die Beziehung zwischen dem Ort der Eingabe und dem Ort der dazugehörigen Ausgabe dar. Welcher Effekt durch das Drücken des Knopfes T (Tagesticket) eintritt, wird deutlich entfernt vom Ort der Handlung in der zentralen Anzeige des Automaten angezeigt. Solange man nicht mit dem Automaten und seinen gestalterischen Defiziten vertraut ist, gibt es eine hohe Wahrscheinlichkeit, dass man die angezeigte Rückmeldung nicht wahrnimmt bzw. erst nach ihr suchen muss, denn am Ort der Handlung, da wo man gerade den Knopf gedrückt hat, gibt es keinen Hinweis.

Einen solchen Hinweis sehen Sie auf diesem Foto der Steuerung eines Fahrgeschäfts in einem Freizeitpark. Wenn man einen der Knöpfe drückt und damit einen gewissen Zustand aktiviert, leuchtet der Knopf auf. Es leuchtet nicht an einer anderen Stelle ein Lämpchen, sondern der gedrückte Knopf selbst leuchtet auf, die Rückmeldung erfolgt also so lokal wie möglich.

Die bewusste Wahrnehmung beschränkt sich jeweils auf den kleinen Bereich des scharfen Sehens. Umgekehrt kann man sagen, dass alles, was bewusst wahrgenommen werden soll, in diesen Bereich gebracht werden muss. Das Auge erwandert die Umwelt als Teil des Verstehensprozesses. Zwar sind diese Wanderungsbewegungen des Auges bei Erwachsenen standardisierter als bei Kindern, doch ist zum Zeitpunkt der Entwicklung schwer abschätzbar, wo eine Person gerade hinsieht. Eine recht verlässliche Annahme ist jedoch, dass der Fokus der Aufmerksamkeit am Ort des Handelns liegt, es sei denn, es handelt sich um antrainierte Situationen, bei denen der Ort der Rückmeldung aus Effektivitäts- oder Sicherheitsgründen vom Ort des Handelns getrennt ist. Beispiele sind das Bewegen einer Maus oder das Blindschreiben auf einer Tatstatur bzw. das Schalten beim Autofahren. In allen anderen Fällen ist es möglich, erzwungene Sequenzialität zu reduzieren, indem die Rückmeldung am Ort der Handlung erfolgt, denn das ist zugleich der Ort der Wahrnehmung. Bei den antrainierten entkoppelten Handlungen gibt es jedoch auch einen besonderen Punkt am Bildschirm, der einen Aufmerksamkeitsfokus verkörpert. Beim Blindschreiben ist das beispielsweise der Eingabecursor, der die Position für die jeweiligen Anschlusshandlungen markiert.

Noch stärker als beim Eingabecursor ist diese Kopplung beim Mauszeiger. Immer dann, wenn er bewegt wird, soll ja ein bestimmter Zielpunkt auf dem Bildschirm angesteuert werden, wozu der mehr oder weniger kontinuierliche Abgleich zwischen der aktuellen Position des Mauszeigers und des Zielpunkts erforderlich ist. Dadurch steht der Mauszeiger im Fokus der Aufmerksamkeit, sodass Rückmeldungen, die an anderer Stelle angezeigt werden, meist unbemerkt bleiben.

Diese beiden Screenshots verdeutlichen solch eine Situation. Auf dem rechten ist das in den Text eingebettete Bild selektiert, auf dem linken jedoch nicht. Die Selektion ist aufgrund eines Mausklicks erfolgt. Rückmeldungen in der Nähe des Mauszeigers werden mit hoher Wahrscheinlichkeit wahrgenommen. Die um das Bild herum erscheinenden Punkte, mit denen die Bildgröße geändert werden kann, verkörpern eine solche Rückmeldung. Es gibt aber noch eine weitere Rückmeldung auf die Selektionshandlung, die an anderer Stelle erfolgt ist und deshalb vermutlich übersehen wird. Die Icons in der Menüleiste haben sich geändert. Die Elemente zur Schriftmanipulation, die in dieser Situation keine Bedeutung haben, sind verschwunden und haben anderen Icons Platz gemacht, die Funktionen zur Manipulation des Bildes anbieten, etwa der Positionierung auf der Seite.

Eine in dieser Hinsicht bessere Lösung ist im abgebildeten CKEditor gewählt worden. Auch in diesem Fall erscheinen die Bearbeitungsmöglichkeiten automatisch erst dann, wenn ein Text markiert worden ist. Die Anzeige erfolgt lokal am Ort des Handelns und hat eine sichtbare Zuordnung zu dem Objekt, auf das es sich bezieht. Diese Art der lokalen Einblendung funktioniert jedoch nur gut, wenn die Menge der erscheinenden Objekte überschaubar ist.

Dieser Screenshot zeigt eine vorbildliche lokale Rückmeldung in Microsofts Webmail-Lösung Outlook.com. Abgebildet ist ein Ausschnitt des Menüs, mit dessen Hilfe sich eine geöffnete Mail einer Kategorie zuordnen lässt. Klickt man dort auf „New category“, erscheint direkt an Ort und Stelle das Eingabefeld für den Namen der neuen Kategorie, nicht etwa, wie in vielen anderen Fällen, in einem Extrafenster in der Bildschirmmitte.

Mauszeiger als Mittel der lokalen und differenzierten Rückmeldung

Immer dann, wenn der Mauszeiger absichtlich bewegt wird, können man davon ausgehen, dass die Aufmerksamkeit auf ihn gerichtet ist. Zusätzliche Informationen zur aktuellen Handlung sollten daher an der Mausposition dargestellt werden. Am einfachsten geht das, indem der Mauszeiger selbst verändert wird.

Diese Abbildung zeigt ein klassisches Ensemble von Mauszeigern. Doch nicht nur die Zeigerform selbst eignet sich für eine Rückmeldung. Wenn beispielsweise ein Datei-Icon verschoben wird, ist es üblich, dass das Icon zusätzlich am Mauszeiger hängt. Diese Rückmeldung signalisiert die gerade stattfindende Aktion. Das Potenzial einer solchen lokalen Rückmeldung eröffnet noch weitere Formen der Gestaltung.

Die Abbildung zeigt das Verschieben einer Datei unter Windows 7. Man sieht an der Mauszeigerposition nicht nur das Objekt, das gerade verschoben wird, sondern auch einen informativen Text. Die komplette an den Mauszeiger gekoppelte Ausgabe ist nicht nur lokal am Ort der Wahrnehmung, sondern auch sehr differenziert, denn man sieht genau, welches Objekt ausgewählt worden ist (Feed-Back), und erhält zudem präzise Angaben darüber, was passiert, wenn die Maustaste losgelassen wird; in diesem Fall „Nach Desktop verschieben“ (Feed-Forward). Auf die gleiche Weise wird auch angezeigt, wo ein „Fallen lassen“ gar nicht möglich ist.

Auch in der Bildbearbeitung Pixelmator ist ausgenutzt worden, dass der Mauszeiger der Ort der Wahrnehmung ist. In der obigen Situation ist ein Kopierpinsel ausgewählt. Für die Durchführung ist jedoch zunächst die Angabe erforderlich, von wo kopiert werden soll. Dies wird direkt am Mauszeiger in Klartext mitgeteilt.

Hinweise direkt am Mauszeiger werden leider viel zu selten praktiziert. Diese Technik ist jedoch sehr nützlich, denn sie erfolgt nicht nur am Ort der Wahrnehmung, sondern spart außerdem noch Platz, da die Rückmeldung sonst an einer anderen Stelle des Bildschirms untergebracht werden müsste, beispielsweise in einer zusätzlichen Statusleiste, auf die man jetzt verzichten kann.