Informationsarchitektur und Benutzerführung

Informationsarchitektur und Benutzerführung

0:00 Wir haben jetzt Material und wissen, für wen wir bauen. Bevor es an die Oberfläche geht, kommt die Frage, die darüber entscheidet, ob Menschen sich zurechtfinden: Wie ist das Ganze eigentlich geordnet, und wie heißen die Dinge? Der Leitsatz dieses Moduls ist absichtlich provokant — die Beschriftung eines Knopfes hat mehr Hebel als die Farbe daneben.

0:19 In vielen Projekten ist die Aufmerksamkeit genau umgekehrt verteilt. Über Farben wird stundenlang diskutiert, die Beschriftung übernimmt jemand aus dem Datenmodell. Und was noch wichtiger ist: Die schönste Oberflächengestaltung aus dem nächsten Modul kann eine falsche Struktur nicht retten.

Informationsarchitektur und Benutzerführung

0:36 Acht Kapitel, die den Weg von der Ordnung zur Benennung gehen. Wir starten bei den mentalen Modellen — also bei den Erwartungen, die Menschen mitbringen —, schauen dann auf Navigation und Hierarchie und lernen zwei sehr günstige Verfahren kennen, mit denen sich eine Struktur belegen statt behaupten lässt. Danach geht es um gestaffelte Information, um Beschriftungen, um Suche und Filter.

0:58 Das letzte inhaltliche Kapitel gehört den Zuständen abseits des Normalfalls — leer, ladend, fehlerhaft, unterbrochen. Die werden am spätesten entworfen und am häufigsten gesehen.

Mentale Modelle und erwartungskonforme Gestaltung

1:09 Beginnen wir bei etwas, das jeder Nutzer mitbringt, bevor er Ihre Seite überhaupt geöffnet hat: Erwartungen. Sie stammen aus hunderten anderen Anwendungen — und wer gegen sie arbeitet, zahlt dafür in einer Währung, die knapp ist. Stellen Sie sich vor, Sie steigen in einen Mietwagen. Sie suchen nicht das Lenkrad, Sie greifen einfach zu.

1:30 Genau das ist ein mentales Modell — eine Erwartung, die aus tausend anderen Autos stammt und in dieses hier mitgebracht wird. Im Web ist es dasselbe: Der Warenkorb liegt oben rechts, das Logo führt zur Startseite, unterstrichener Text ist ein Link. Diese Konventionen hat sich niemand ausgedacht, sie haben sich eingespielt.

1:49 Und deshalb kostet jede Abweichung Aufmerksamkeit — Aufmerksamkeit, die für die eigentliche Aufgabe dann fehlt. Bei einem Buchungsvorgang unter Zeitdruck ist das keine Kleinigkeit. Jetzt kommt der Einwand, den ich in jedem Seminar höre: Dann sieht doch alles gleich aus. Die Antwort steht in der letzten Zeile — Erkennbarkeit vor Originalität, weil Wiedererkennen schneller ist als Verstehen.

2:12 Konventionen sind eingespart, nicht erfunden; sie kosten null Lernaufwand, und das ist ein echter Gewinn, den Sie geschenkt bekommen. Jede Abweichung muss deshalb ein Problem lösen, sonst zahlt sie nur Aufmerksamkeit ohne Gegenleistung. Am teuersten sind Abweichungen übrigens bei selten benutzten Funktionen — bei denen kann sich niemand etwas einprägen, weil die Gelegenheit dazu fehlt.

2:34 Weichen Sie also dort ab, wo Sie es täglich üben lassen, nicht bei der Erstattung. Der erste Stolperstein ist der Klassiker aus der Markenabteilung: Konventionen brechen, um sich vom Wettbewerb zu unterscheiden. Nur unterscheidet man sich damit in einer Dimension, in der niemand Unterscheidung sucht. Der zweite ist heimtückischer — vertraute Symbole mit neuer Bedeutung belegen.

2:57 Das Herz als Filter, der Stern als Sortierung, das Zahnrad als Hilfe. Menschen lesen Symbole nicht, sie erkennen sie wieder, und das Wiedererkennen bringt die alte Bedeutung mit. Und der dritte ist der stille: die eigene Vertrautheit im Team für allgemeine Verständlichkeit halten. Sie haben das Produkt hundertmal benutzt. Ihre Nutzer zweimal im Jahr.

Navigation, Hierarchien und Seitenstrukturen

3:18 Damit zur Navigation. Sie sieht harmlos aus — ein paar Menüpunkte — und ist in Wahrheit eine der schwierigsten Entwurfsaufgaben überhaupt, weil sie drei Fragen gleichzeitig beantworten muss und dabei meist zwei Ordnungen zu vereinbaren hat. Eine Navigation beantwortet immer drei Fragen auf einmal: Wo bin ich gerade, was gibt es sonst noch, und wie komme ich zurück. Schon das ist anspruchsvoll.

3:41 Bei Fahrtwind kommt ein zweites Problem hinzu, und das kennen Sie aus Ihren eigenen Projekten: Zwei Ordnungen konkurrieren. Man kann nach Reiseart sortieren oder nach Kundenkonto — beide sind sinnvoll, beide haben ihre Anhänger im Team. Der übliche Ausweg ist, beides anzubieten. Das ist der falsche Ausweg. Solche Konflikte löst man nicht mit mehr Menüpunkten, sondern mit einer Entscheidung darüber, welche Ordnung die Hauptnavigation trägt.

4:07 Die letzte Zeile ist der Punkt dieser Tabelle. Die Ordnung nach Reiseart passt zum Erstbesuch, zum Vergleichen, zum Suchen — und bricht bei Wiederkehrenden, die schon eine Buchung haben. Die Ordnung nach Kundenkonto passt zu Umbuchung, Erstattung und Belegen — und bricht bei Menschen ohne Konto, die es bei einem Busportal reichlich gibt.

4:26 Beides gleichrangig anzubieten passt dagegen zu niemandem und bricht bei jeder zweiten Aufgabe. Das klingt hart und ist meine ehrliche Erfahrung: Die scheinbar diplomatische Lösung ist die einzige, die alle Nutzergruppen gleichzeitig verliert. Entscheiden Sie sich — und geben Sie der zweiten Ordnung einen eigenen, klar benannten Einstieg.

4:46 Der erste Stolperstein haben wir gerade behandelt: beide Ordnungen gleichrangig anbieten und die Entscheidung an den Nutzer weiterreichen. Das ist keine Freiheit, das ist eine Hausaufgabe. Der zweite ist der berühmteste Fehler der Informationsarchitektur überhaupt — die Navigation nach dem Organigramm des Anbieters schneiden.

5:04 Ihre Nutzer kennen Ihre Abteilungen nicht und wollen sie nicht kennenlernen. Und der dritte ist die typische Reaktion auf Kritik: Menüpunkte hinzufügen, wo eine Zusammenlegung nötig wäre. Jede Beschwerde führt zu einem neuen Eintrag, und nach zwei Jahren hat die Hauptnavigation vierzehn Punkte. Wachstum ist bei Navigation kein Zeichen von Pflege, sondern von unterlassener Entscheidung.

Card Sorting und Tree Testing

5:27 Jetzt zu zwei Verfahren, die ich für die besten Preis-Leistungs-Sieger dieses ganzen Seminars halte. Sie laufen unmoderiert, brauchen kleine Stichproben und beenden Strukturdebatten mit Daten statt mit Meinungen. Die beiden Verfahren beantworten unterschiedliche Fragen. Card Sorting zeigt, wie Nutzende Inhalte gruppieren würden — es ist offen und liefert Ihnen Kategorien, auf die Sie selbst nicht gekommen wären.

5:51 Tree Testing prüft dagegen, ob Menschen in einer vorhandenen Struktur fündig werden; hier steht die Struktur schon, getestet wird die Auffindbarkeit. Die Reihenfolge ist entscheidend: erst offen sortieren lassen, dann die daraus gebaute Struktur testen. Umgekehrt bestätigen Sie nur, was Sie ohnehin bauen wollten. Beide Verfahren laufen unmoderiert über einen Link, und beide liefern schon mit fünfzehn bis zwanzig Personen brauchbare Aussagen.

6:16 Günstiger kommen Sie an belastbare Befunde nicht heran. Fünf Schritte. Wichtig ist gleich der erste: Karten ohne Kategorienamen, sonst geben Sie die Antwort vor. In Schritt zwei lassen Sie die Teilnehmenden ihre Gruppen selbst benennen — diese Namen sind Gold wert, weil sie die Wörter Ihrer Nutzer sind. Schritt drei enthält eine feine, aber wichtige Unterscheidung: Bauen Sie aus den Häufungen, nicht aus dem Durchschnitt.

6:41 Ein Durchschnitt aus zwei sinnvollen Ordnungen ergibt eine dritte, die keiner Person entspricht. Dann fahren Sie fünf typische Suchaufgaben als Tree Test. Und Schritt fünf ist der eigentliche Ertrag: Werten Sie die Irrwege aus. Ein Irrweg zeigt Ihnen präzise, welches Wort falsch verstanden wird. Der erste Stolperstein macht das Verfahren wertlos, ohne dass man es merkt: Kategorien vorgeben und das Ergebnis für offenes Sortieren halten.

7:07 Sie messen dann Zuordnungsfähigkeit, nicht mentale Modelle. Der zweite ist der Mittelwertfehler, den wir gerade hatten — aus widersprüchlichen Sortierungen ein Mittel bilden. Widersprüche in den Sortierungen bedeuten meist, dass es zwei Nutzergruppen mit verschiedenen Modellen gibt. Das ist ein Befund, kein Rauschen. Und der dritte ist der stille Selbstbetrug: den Tree Test an genau der Struktur fahren, die man ohnehin bauen wollte.

7:32 Dann ist der Test kein Prüfmittel mehr, sondern ein Beleg für die Präsentation.

Progressive Disclosure

7:37 Weiter zu einer sehr wirksamen Technik gegen überladene Oberflächen: Information gestaffelt anzeigen. Sie funktioniert gut — solange eine Bedingung eingehalten wird, und die betrifft ausgerechnet die Barrierefreiheit. Nicht alles muss gleichzeitig sichtbar sein, und das ist eine Erleichterung für alle. Bei der Fahrtwind-Buchung interessieren Gepäckoptionen erst nach der Sitzplatzwahl — vorher sind sie nur Lärm.

8:02 Progressive Disclosure staffelt Information also nach Bedarf, wie ein gut sortierter Werkzeugkasten mit Einlegeböden. Die Bedingung ist allerdings der wichtigere Teil dieser Folie: Was versteckt wird, muss auffindbar bleiben. Versteckt heißt nicht unerreichbar — und schon gar nicht per Tastatur unerreichbar. Genau da geht es in der Praxis regelmäßig schief, weil das Ausblenden rein visuell gedacht wird.

8:25 Die nächste Folie zeigt, wie klein der Unterschied im Code ist. Oben sehen Sie die verbreitete Variante: ein anklickbarer Bereich und ein per Anzeigeregel ausgeblendetes Feld. Sie hat zwei Probleme. Das Bedienelement ist kein Bedienelement — nicht fokussierbar, keine Rolle, keine Tastatur, genau wie in Modul eins. Und der Zustand offen oder geschlossen wird nirgends gemeldet.

8:48 Unten dieselbe Funktion, richtig gebaut: eine echte Schaltfläche, die ihren Aufklappzustand ausdrücklich mitteilt und auf den zugehörigen Bereich verweist, dazu ein Attribut, das den Inhalt tatsächlich aus dem Baum nimmt statt ihn nur unsichtbar zu machen. Der Unterschied im Aufwand: eine Zeile. Der Unterschied in der Bedienbarkeit: alles.

9:09 Der erste Stolperstein ist der eben gezeigte: Inhalte nur visuell ausblenden und sie fokussierbar lassen. Dann wandert der Tastaturfokus in einen unsichtbaren Bereich, und die Person weiß nicht mehr, wo sie ist — das ist schlimmer als gar kein Aufklappen. Der zweite: den Zustand nirgends melden. Ein Screenreader liest dann eine Schaltfläche vor, ohne sagen zu können, ob dahinter etwas Offenes oder Geschlossenes liegt.

9:33 Und der dritte ist ein reines Abbruchproblem: Pflichtangaben hinter eine Aufklappfläche legen. Was man aufklappen muss, um weiterzukommen, gehört sichtbar — sonst suchen Menschen einen Fehler, den sie nicht sehen können.

Verständliche Bezeichnungen und Microcopy

9:47 Jetzt kommt das Kapitel zum Leitsatz dieses Moduls. Es geht um Wörter — und um die erstaunliche Tatsache, dass die billigste Änderung in der ganzen Oberfläche oft die wirksamste ist. Die Beschriftung eines Knopfes ist eine Gestaltungsentscheidung mit enormem Hebel, und sie kostet nichts außer Nachdenken. „Weiter" sagt nichts — weiter wohin, mit welcher Folge?

10:08 „Zahlungspflichtig buchen" sagt alles. Und bei Fahrtwind ist genau diese Formulierung sogar rechtlich gefordert, denn das deutsche Fernabsatzrecht schreibt eine eindeutige Beschriftung der Bestellschaltfläche vor. Das ist ein schöner Fall, in dem Verständlichkeit und Pflicht zusammenfallen. Die Regel dahinter ist einfach: Gute Microcopy benennt das Ergebnis der Handlung, nicht den technischen Vorgang — und sie verwendet die Wörter der Nutzenden, nicht die des Datenmodells.

10:35 Achten Sie auf das Muster in der rechten Spalte, denn alle vier Zeilen folgen derselben Logik: Die bessere Fassung nennt die Folge. Statt „Weiter" die Kosten, statt „Abbrechen" das, was verloren geht, statt „Absenden" den Vorgang, den man tatsächlich anstößt. Die letzte Zeile ist die interessanteste, weil sie aus der Technik kommt: Eine Fehlernummer ist für Menschen bedeutungslos.

10:58 „Abfahrtsdatum liegt in der Vergangenheit" nennt Ursache und Korrektur in einem Satz. Nehmen Sie das als Prüffrage mit: Kann jemand nach dem Lesen sagen, was gleich passiert und was er tun soll? Wenn nicht, fehlt die Folge. Der erste Stolperstein ist der bequemste: Beschriftungen aus dem Datenmodell übernehmen. Dann steht auf dem Knopf der Name der Entität statt der Handlung — „Reservierung" statt „Sitzplatz reservieren".

11:23 Der zweite klingt absurd und passiert ständig: zwei Knöpfe nebeneinander, die beide „Weiter" heißen, weil beide in Schritte führen. Für Tastatur und Screenreader ist das nicht unterscheidbar; es sind schlicht zwei identische Bedienelemente. Und der dritte ist ein Blickwinkelproblem: die Fachsprache des Anbieters verwenden. Ihre Kundschaft weiß nicht, was ein Kontingent ist oder was Sie mit Stornokategorie meinen.

11:48 Sie will einen Platz buchen.

Suche, Filterung und komplexe Datenstrukturen

11:51 Sobald die Datenmengen groß werden, verschiebt sich die Aufgabe. Es geht dann nicht mehr darum, etwas zu finden, sondern darum, etwas wegzulassen. Und genau dabei entsteht einer der häufigsten Abbruchgründe überhaupt. Bei großen Ergebnismengen wird aus dem Navigationsproblem ein Reduktionsproblem. Filter übernehmen dann die Führung — und sie sind erstaunlich oft schlecht gemacht.

12:14 Ein guter Filter muss drei Dinge zeigen: was er gerade tut, wie viele Treffer bleiben und wie man ihn einzeln zurücknimmt. Fehlt der sichtbare Zustand, entsteht die klassische Sackgasse: eine leere Ergebnisliste, deren Ursache niemand findet. Der Nutzer sieht nichts und weiß nicht, ob es keine Fahrten gibt oder ob er sich vor drei Klicks in einem Untermenü selbst ausgeschlossen hat.

12:35 Das ist ein technisch triviales Problem und eine der stärksten Abbruchursachen im Netz. Vier Anforderungen, und die erste enthält eine wichtige Präzisierung: Aktive Filter müssen einzeln benannt sein, nicht als Anzahl. „Drei Filter aktiv" hilft niemandem — welche drei? Zweitens die verbleibende Trefferzahl, am besten schon bevor man den Filter anwendet.

12:56 Drittens die Möglichkeit, einen einzelnen Filter zurückzunehmen, ohne alle zu verlieren; das rettet Menschen aus der Sackgasse, ohne sie ganz von vorn anfangen zu lassen. Und viertens die Erklärung, warum das Ergebnis leer ist und welcher Filter dafür verantwortlich ist. Diese vierte Anforderung ist selten umgesetzt und liefert den größten Gewinn — sie verwandelt eine Sackgasse in eine Handlungsanweisung.

13:21 Der erste Stolperstein: aktive Filter nur als Zahl anzeigen. Damit ist die Information formal vorhanden und praktisch nutzlos. Der zweite ist ein Barrierefreiheitsthema, das uns in Modul elf ausführlich beschäftigt: Beim Ändern eines Filters wird die Ergebnisliste ausgetauscht, ohne dass es angesagt wird. Sehende bemerken die Änderung, alle anderen nicht — für sie passiert scheinbar nichts.

13:44 Und der dritte trifft mobile Nutzung: Filter hinter einem Dialog verstecken und dabei den Zustand verlieren. Man öffnet den Dialog, setzt etwas, schließt ihn — und beim nächsten Öffnen ist alles zurückgesetzt. Dann filtert niemand mehr, sondern scrollt.

Zustände abseits des Normalfalls

13:59 Das letzte inhaltliche Kapitel gehört den Zuständen, die keiner gern entwirft. Sie werden am spätesten gebaut und am häufigsten gesehen — und einer davon entscheidet über bares Geld. Leere Ergebnisse, Ladezustände und Fehler entstehen fast immer zuletzt, oft unter Zeitdruck, manchmal gar nicht. Dabei sieht sie jeder Nutzer regelmäßig — deutlich häufiger als die perfekt bestückte Beispielansicht aus dem Entwurf.

14:25 Jeder dieser Zustände hat eine Aufgabe: Das leere Ergebnis erklärt, warum es leer ist und was jetzt hilft. Der Ladezustand sagt, worauf gewartet wird. Und die Fehlermeldung nennt den nächsten Schritt, nicht nur eine Nummer. Am wichtigsten ist mir aber der vierte, der auf der nächsten Folie dazukommt: der unterbrochene Ablauf.

14:45 Reale Buchungen werden unterbrochen — der Zug kommt, der Akku ist leer, jemand ruft an. Die rechte Spalte beschreibt Ihren Alltag im Netz. Leere Zustände mit einem hübschen Bild und dem Wort „Nichts gefunden". Dauerspinner ohne jede Zeitangabe, bei denen man nach zwanzig Sekunden nicht weiß, ob noch etwas passiert. Fehlercodes ohne Erklärung.

15:06 Und die letzte Zeile ist die teuerste: Der Zwischenstand ist verloren. Wer eine Buchung nach der Unterbrechung nicht fortsetzen kann, bucht meistens gar nicht mehr — nicht aus Ärger, sondern weil der Moment vorbei ist. Das ist kein Komfortthema, das ist unmittelbar Umsatz. Und technisch ist es meist eine Frage von wenigen Zeilen Zustandsspeicherung.

15:28 Der erste Stolperstein ist gut gemeint: den leeren Zustand als Gestaltungsfläche für Illustrationen benutzen. Die Fläche ist frei, also kommt eine hübsche Zeichnung hinein — und die Information, was jetzt zu tun ist, fehlt weiterhin. Der zweite ist ein Durchreichfehler: Fehlermeldungen aus dem Backend unübersetzt anzeigen. Was für den Server eine korrekte Antwort ist, ist für Menschen keine.

15:51 Und der dritte ist der technische Kern des Unterbrechungsproblems: den Zwischenstand nur im Arbeitsspeicher halten. Ein Zurück im Browser, ein Tabwechsel, ein Anruf — und alles ist weg. Speichern Sie den Fortschritt so, dass er eine Unterbrechung überlebt.

Übung — eine Navigation gegen die eigene Struktur testen

16:07 In der Übung führen Sie einen Tree Test durch — mit einem entscheidenden Kniff bei der Aufgabenformulierung. Sie werden merken, dass die Wortwahl der Aufgabe über das Ergebnis mitentscheidet. Sie bauen einen Tree Test für die Fahrtwind-Struktur und werten ihn aus. Geübt wird die Überprüfung einer vorhandenen Informationsarchitektur mit einem unmoderierten Verfahren — und vor allem die Ableitung: aus Irrwegen konkrete Änderungen machen.

16:31 Erfolgreich sind Sie, wenn fünf Suchaufgaben durchgeführt sind, Erfolgsquote und Irrwege ausgewertet vorliegen und zwei begründete Änderungen an Hierarchie oder Benennung daraus folgen. Der Zusatz für die Schnellen ist der eigentliche Lerneffekt: Formulieren Sie eine Aufgabe bewusst mit den Wörtern der Nutzenden statt mit denen der Navigation, und vergleichen Sie die Quote.

16:51 Sobald die Aufgabe die Menüwörter enthält, misst der Test nur noch Lesefähigkeit. Der erste Schritt ist der schwierigste und der wichtigste: fünf Aufgaben formulieren, ohne die Wörter aus der Navigation zu benutzen. Das fällt erstaunlich schwer, weil man die Struktur ja kennt. Dann führen Sie den Test gegenseitig durch, ohne Hilfestellung — auch das ist Disziplinsache.

17:13 Halten Sie je Aufgabe drei Dinge fest: gefunden, nicht gefunden, und vor allem wo abgebogen wurde. Gruppieren Sie die Irrwege nach dem missverstandenen Wort, und leiten Sie zwei begründete Änderungen ab. Die Fußzeile bringt es auf den Punkt: Zählen Sie nicht nur die Erfolge. Die Irrwege tragen die Information. Der erste Stolperstein ist der, den ich am häufigsten sehe: Aufgaben mit den Navigationswörtern formulieren und anschließend hohe Quoten feiern.

17:40 Sie haben dann bewiesen, dass Menschen lesen können. Der zweite ist ein Auswertungsfehler — nur Erfolg und Misserfolg notieren, ohne den Abbiegepunkt festzuhalten. Ohne den Abbiegepunkt haben Sie eine Zahl und keine Erkenntnis. Und der dritte ist eine Überinterpretation: aus einem einzigen Irrweg eine Umbenennung ableiten.

17:59 Eine Person kann sich schlicht verklickt haben. Interessant wird es, wenn drei Leute an derselben Stelle in dieselbe falsche Richtung gehen — dann liegt es am Wort, nicht an den Menschen. Vier Punkte für die Mitnahme. Konventionen kosten keinen Lernaufwand — deshalb muss sich jede Abweichung rechtfertigen, nicht die Konvention.

18:18 Konkurrierende Ordnungen brauchen eine Entscheidung, keine zusätzlichen Menüpunkte; die diplomatische Lösung verliert alle. Versteckte Inhalte müssen auffindbar bleiben und ihren Zustand melden — das kostet eine Zeile und entscheidet über Bedienbarkeit. Und viertens: Leer, ladend, fehlerhaft und unterbrochen sind Entwurfsaufgaben, keine Restfälle.

18:39 Zum Schluss noch ein Hinweis, der Ihnen im Projekt Geld spart: Card Sorting und Tree Testing sind die günstigsten belastbaren Verfahren im ganzen Seminar. Nutzen Sie sie, bevor Sie über Farben streiten.