Aufgabenbasiertes Informationsarchitektur-Audit: Reale Wege systematisch prüfen

Prüfen Sie zuerst repräsentative Aufgaben und ihre realistischen Wege, bevor Sie Menüs neu ordnen oder einen neuen Sitemap-Entwurf freigeben. Ein überladenes Hauptmenü, hohe Ausstiege oder Beschwerden über schwer auffindbare Inhalte zeigen lediglich, wo Fragen beginnen könnten. Erst die Verfolgung eines konkreten Vorhabens – von unterschiedlichen Einstiegen über Navigation, Querverweise und Suche bis zum benötigten Inhalt oder Vorgang – zeigt, ob Inhalt, Bezeichnung, Gruppierung, Orientierung, Suche oder Bedienung tatsächlich versagt.

Welche Entscheidung soll der Audit vorbereiten?

Der Audit soll eine klar abgegrenzte Entscheidung vorbereiten: etwa eine Sektion reparieren, Bezeichnungen ändern, eine Migration absichern oder prüfen, ob die Evidenz für einen breiteren Relaunch reicht. Legen Sie vor der Sitemap- oder Interface-Prüfung fest, welche Zielgruppen, Aufgaben, Einstiege, Seitentypen, Geräte, Sprachfassungen, Berechtigungen und Journey-Zustände dazugehören. Das Ergebnis gilt dann für diese Kontexte und nicht für eine erfundene durchschnittliche Nutzerin oder einen durchschnittlichen Nutzer.

Informationsarchitektur umfasst Organisation, Bezeichnungen und Navigation; sie soll Menschen dabei unterstützen, Inhalte zu finden, ihre Position und Möglichkeiten zu verstehen und eine beabsichtigte Aufgabe abzuschließen. Ein aufgabenbasierter IA-Audit untersucht daher das vorhandene Routensystem. Er ist weder ein vollständiges Inhaltsinventar noch ein technischer SEO-Audit, eine umfassende Barrierefreiheitsprüfung oder bereits der Entwurf eines Redesigns. Diese Arbeiten können anschließen, beantworten aber andere Fragen.

Definieren Sie außerdem den Evidenzstandard. Halten Sie bekannte Tatsachen, beobachtetes Verhalten, Befunde aus einer fachlichen Inspektion und noch ungetestete Hypothesen in getrennten Feldern fest. „Der Menüpunkt wirkt unklar“ ist zunächst eine fachliche Einschätzung; „vier Teilnehmende erwarteten dahinter einen anderen Inhalt“ wäre eine Beobachtung aus einem bestimmten Test. Diese Trennung verhindert, dass eine plausible Vermutung unbemerkt zur angeblich bewiesenen Ursache wird.

Wie entsteht aus Evidenz ein repräsentativer Aufgabensatz?

Ein repräsentativer Aufgabensatz verbindet erkennbare Nutzerziele mit ihrer Herkunft, dem jeweiligen Anlass und einem überprüfbaren erfolgreichen Ergebnis. Eine belastbare Aufgabe hält fest, was Menschen erreichen wollen, wie sie heute vorgehen, wo Probleme auftreten und welches Ergebnis sie benötigen. Formulieren Sie jede Aufgabe als gewünschtes Ergebnis in einer Sprache, die Nutzerinnen und Nutzer erkennen würden, ohne den Zielbegriff oder die erwartete Menüoption vorwegzunehmen.

Nutzungsanalysen, interne Suchanfragen, Supportkontakte, Feedback, frühere Studien, Interviews, Beobachtungen und Beschäftigte mit direktem Nutzerkontakt können zur Evidenz beitragen. Eine dokumentierte Digital.gov-Studie leitete realistische Testszenarien aus früherer Forschung ab und ließ ihre inhaltliche Abdeckung vor dem Test prüfen. Stakeholder-Aussagen und fachliche Annahmen bleiben dagegen als Hypothesen gekennzeichnet, bis sie durch Evidenz von tatsächlichen Nutzerinnen und Nutzern gestützt werden.

• Erfassen Sie Zielgruppe und Auslöser: Wer versucht in welcher Situation etwas zu erreichen?
• Notieren Sie realistische Einstiegskontexte, etwa eine externe Zielseite, eine Bereichsseite, ein angemeldetes Portal oder die interne Suche.
• Definieren Sie den erfolgreichen Inhalt oder Vorgang und das Ziel, an dem der Abschluss überprüft werden kann.
• Dokumentieren Sie Quelle, Aktualität und Stärke der Evidenz für jede Aufgabe.
• Balancieren Sie häufige Aufgaben mit folgenreichen, schwierigen und bisher unterversorgten Vorhaben.

Was gehört in das Aufgaben-Routen-Arbeitsblatt?

Das Arbeitsblatt soll jede evidenzbasierte Aufgabe mit ihrem Ergebnis, den plausiblen Wegen, den geprüften Hinweisen, beobachtetem Verhalten, der Diagnose und dem geplanten Retest verbinden. Beginnen Sie nicht automatisch auf der Startseite. Eine Person kann über eine Suchmaschine auf einer Detailseite landen, innerhalb eines Bereichs stöbern, einem kontextbezogenen Link folgen, ein angemeldetes Portal öffnen oder unmittelbar die interne Suche verwenden.

Erfassen Sie an jedem Entscheidungspunkt den sichtbaren Hinweis, die dadurch ausgelöste Erwartung, das tatsächlich erreichte Ziel und die Möglichkeit, eine falsche Wahl zu erkennen und zu korrigieren. WCAG-Erfolgskriterium 2 Punkt 4 Punkt 5 verlangt grundsätzlich mehr als einen Weg, um eine Seite innerhalb einer zusammengehörigen Seitenmenge zu finden; ausgenommen sind Seiten, die Ergebnis oder Schritt eines Prozesses sind. Als mögliche Wege nennt die W3C-Erläuterung unter anderem verwandte Links, eine Sitemap, Suche und umfassende Navigation.

Ein IA-Audit fragt nicht, ob die Sitemap ordentlich aussieht, sondern ob Menschen über realistische Wege ein benötigtes Ergebnis erreichen.

Wie wird die vollständige Route statt nur das Menü geprüft?

Prüfen Sie jeden wesentlichen Routenteil vom realistischen Einstieg bis zum erfolgreichen Inhalt oder Vorgang. Dazu gehören externe Zielseiten, globale und lokale Navigation, Übersichtsseiten, Gruppierungen, Überschriften, Breadcrumbs oder andere Standortsignale, kontextbezogene Links, interne Suche und die Zielseite selbst. An jeder Station muss erkennbar sein, wo man sich befindet, welche Ebene erreicht wurde, welche nächste Handlung möglich ist und wie eine unproduktive Wahl korrigiert werden kann.

Bewerten Sie Bezeichnungen nach der Erwartung, die sie im konkreten Umfeld erzeugen. Microsoft empfiehlt, Navigation an Perspektiven, häufigen Aufgaben und mentalen Modellen der Nutzerinnen und Nutzer auszurichten. Ein tragfähiger Navigationsbegriff ist zutreffend, im jeweiligen Kontext vertraut, knapp erfassbar und von benachbarten Optionen unterscheidbar. WCAG-Erfolgskriterium 2 Punkt 4 Punkt 6 verlangt zudem, dass vorhandene Überschriften und Bezeichnungen ihr Thema oder ihren Zweck beschreiben.

Wiederholen Sie wichtige Aufgaben über Seitentypen, Desktop und Mobilgerät, Sprachfassungen, Berechtigungen und Zustände hinweg, sofern sich dadurch die verfügbaren Wege materiell verändern. WCAG-Erfolgskriterium 3 Punkt 2 Punkt 3 betrifft die gleichbleibende relative Reihenfolge wiederholter Navigationsmechanismen, sofern die Nutzerin oder der Nutzer keine Änderung auslöst. Es verbietet keine lokale oder sekundäre Navigation. Die Verwendung der Suche ist nicht automatisch ein Beleg für misslungene Navigation: Sie kann ein bevorzugter und gültiger Alternativweg sein.

Welche Forschungsmethode klärt welchen unsicheren Weg?

Wählen Sie die Methode nach der offenen Evidenzfrage, nicht nach dem Werkzeug, das gerade verfügbar ist. Eine fachliche Inspektion und vorhandene Verhaltensdaten helfen, wahrscheinliche Schwachstellen zu lokalisieren, belegen aber noch kein beobachtetes Nutzerversagen. Card Sorting passt, wenn unklar ist, wie Menschen Inhalte gruppieren oder Kategorien benennen würden. Es validiert weder den vollständigen Navigationsweg noch die gerenderte Zielseite.

Tree Testing isoliert, ob eine Hierarchie und ihre Bezeichnungen das Finden eines Ziels unterstützen, blendet aber große Teile der gerenderten Oberfläche aus. Für Fragen zu tatsächlicher Navigation, Seitensignalen, Bedienelementen, Querverweisen, Suche, Fehlerkorrektur oder Abschluss braucht es aufgabenbasierte Tests auf der Website. NIST beschreibt Usability-Tests als Arbeit repräsentativer Nutzerinnen und Nutzer an repräsentativen Aufgaben; daraus folgt jedoch keine universelle Teilnehmerzahl.

• Wählen Sie Abschluss und benötigte Hilfestellung, wenn die Entscheidung die praktische Erreichbarkeit des Ergebnisses betrifft.
• Beobachten Sie Fehler, Umwege, Zurückspringen und Zeit, wenn Sie Reibung innerhalb eines Weges unterscheiden müssen.
• Erfassen Sie reformulierte Suchanfragen, Ergebniswahl und Zielvertrauen, wenn Suche Teil der Route ist.
• Fragen Sie nach der Erwartung hinter einer Auswahl, ohne den richtigen Weg vorzugeben.
• Werten Sie abweichende Wege und Begründungen aus: Sie können mehr über mehrdeutige Gruppierungen oder Bezeichnungen verraten als eine bloße Abschlussquote.

Wie führen Befunde zu begrenzten Änderungen oder zu einem begründeten Relaunch?

Führen Sie jeden Befund zuerst auf eine konkrete Fehlerart zurück und wählen Sie danach den kleinsten Eingriff, den die Evidenz trägt. So wird aus einem Symptom nicht automatisch eine neue Navigation. Ein fehlender Inhalt verlangt eine andere Reaktion als ein irreführender Begriff, eine unerwartete Gruppierung, ein schwacher Querverweis, ein unbrauchbares Suchergebnis oder ein Bedienelement, das einen ansonsten plausiblen Weg blockiert.

• Abdeckung: Der benötigte Inhalt, Vorgang oder Zustand fehlt oder ist unvollständig.
• Einstieg: Ein wahrscheinlicher Startkontext bietet keinen plausiblen Weg.
• Bezeichnung oder Gruppierung: Ein Hinweis verspricht das falsche Ziel oder Kategorien überlappen unklar.
• Orientierung, Querverweis oder Konsistenz: Standort, nächster Schritt oder wiederkehrender Mechanismus ist nicht verlässlich.
• Suche: Relevante Anfragen liefern fehlende, irreführende oder schwer interpretierbare Ergebnisse.
• Interaktion: Die Struktur ist plausibel, doch Bedienelement oder Seitengestaltung verhindert die Nutzung.

Priorisieren Sie mit sichtbaren Eingaben: Bedeutung der Aufgabe, betroffene Zielgruppen, beobachtete Häufigkeit, Folgen des Scheiterns, Stärke der Evidenz und Abhängigkeiten der Behebung. Ein universeller Gesamtwert würde diese Unterschiede verdecken und ist durch die herangezogenen Quellen nicht begründet. Mögliche Maßnahmen reichen von Inhaltskorrektur, Link- oder Begriffsreparatur über Neugruppierung und Suchoptimierung bis zur Restrukturierung eines Bereichs. Jede Empfehlung erhält eine verantwortliche Stelle und einen definierten Retest.

Schließen Sie mit einer Retest-Entscheidung, nicht standardmäßig mit einer neuen Sitemap. Ein Redesign ist erst dann plausibel begründet, wenn wichtige Aufgaben in relevanten Kontexten wiederholt scheitern, die Befunde durch Beobachtung gestützt sind, die Ursache strukturell ist und begrenzte Reparaturen voraussichtlich nicht ausreichen. Ziehen Sie erfahrene IA- oder UX-Fachleute bei komplexem Forschungsdesign und weitreichenden Strukturkonflikten hinzu. Die hier genannten WCAG-Prüfpunkte belegen für sich allein keine vollständige Barrierefreiheitskonformität; dafür ist eine geeignete Konformitätsbewertung erforderlich.