Informationsarchitektur

Wie die Inhalte einer Website oder App geordnet und benannt sind (Informationsarchitektur) und wie Nutzer zu ihnen gelangen (Navigationsarchitektur). Ermittelt wird sie am besten mit den Nutzern per Card Sorting und geprüft per Tree Testing.

Grundgedanke

Eine Gartenhütte baut man ohne Grundriss, ein Hochhaus nicht. Viele Websites teilen Inhalte einfach in Gruppen ein, die zu Menüpunkten werden; dann findet sich nur der Betreiber zurecht. Wer nichts findet, glaubt, es gebe das Angebot nicht (Quelle - Praxisbuch Usability und UX, S. 239).

Card Sorting

Nutzer sortieren Inhalte, die auf Karten stehen, in Gruppen und benennen die Oberkategorien (Kap. 12):

Tree Testing ist dem geschlossenen Card Sorting überlegen: Einsortieren ist ein anderer Denkvorgang als Suchen, und es lassen sich drei und mehr Ebenen testen statt nur zwei (S. 124).

Richtwerte für offenes Card Sorting: mindestens 15 Probanden (manche Experten: 20–30), höchstens 60 Karten, 60 bis maximal 75 Minuten pro Sitzung. Karten nummerieren, Blankokarten und andersfarbige Karten für Kategorienamen bereithalten, lautes Denken fördern, Karten zwischen Sitzungen mischen. Auswertung qualitativ (Kommentare verdichten) und quantitativ (häufigste Gruppierungen in Excel oder SPSS). Ergebnis ist meist eine Sitemap mit zwei Ebenen (S. 124–127).

Wann: vor Layout, Screendesign und Navigation, sonst werden Änderungen teuer. Stakeholder (Marketing, SEO, Redaktion, IT) früh einbeziehen (S. 128).

Inhalte gliedern

• Zuerst ungeordnete Listen von Themen, Inhalten und Funktionen, noch keine Sitemap (S. 240).
• Nutzerlogik vor Systematik: Ein Obsthändler gliedert nach „Obst“ und „Gemüse“, nicht botanisch nach „Sammelfrüchten“ und „Beeren“ (S. 241).
• Keine logischen Brüche auf einer Ebene: „Was wir machen“ (lösungsorientiert) nicht neben „Liste der Ansprechpartner“ (systematisch).
• Nicht Einzuordnendes: eigene Kategorie, prominenter Hinweis auf der Startseite oder Querverweise.
• Mehrere Wege zum Ziel ab etwa 40 Seiten: direkt (Suche, alphabetische Liste) und assoziativ (gegliederte Navigation) (S. 242).
• Für Wachstum planen, nicht nur für den Start.

Sitemap

Zeigt alle Seiten und ihre Verknüpfung; gleichartige Seiten als Stapel. Nicht jeder Querlink gehört hinein. Werkzeuge: OmniGraffle, Visio, Axure. Eine Sitemap auf der Website schadet nicht, aber Nutzer sollen sich ohne sie zurechtfinden (S. 243–244).

Navigationskonzepte

Kap. 25:

• Horizontale Navigationsleiste: effizient, aber nur für wenige Punkte; auf dem Smartphone passen meist nur vier bis fünf.
• Tab Bar in Apps: unten (iOS, gut für den Daumen) oder oben (Android).
• Hamburger-Menü: viel Platz, aber Menüpunkte versteckt, eine Interaktion mehr, Nutzer müssen sich die Punkte merken. Auf dem Desktop oft übersehen. Besser mit Label „Menü“ und Umrandung. Empfehlung: auf dem Desktop immer sichtbare Hauptnavigation (S. 267–269).
• Navigationshub: Startseite als Drehscheibe, gut für Apps mit wenigen klaren Aufgaben (Flug buchen, einchecken).
• Mega-Dropdown: zweistufige Übersicht; mit etwa 0,5 s Verzögerung öffnen und schliessen, nicht bildschirmfüllend, Gruppen vertikal und klar abgesetzt.
• Akkordeon-Menü: mobiles Gegenstück, höchstens drei Ebenen.
• Off-Canvas: Menü fährt seitlich herein; auf grossen Bildschirmen nicht empfohlen.

Die Nielsen Norman Group hat eine Checkliste mit 15 Navigations-Guidelines (S. 274). Header, Footer und weitere Elemente: UI-Richtlinien.

Verwandt

• Nutzerzentrierte Entwicklung – Konzeptionsphase
• Prototyping – Wireframes auf Basis der Sitemap
• UI-Richtlinien – Suche, Filter, Header und Footer
• Wiki-Operationen – die eigene Informationsarchitektur dieses Wikis (Index, Ordner)