Das Web als Geschäftssystem betreiben.
Ein praxistauglicher Leitfaden, um Nutzeraufgaben über Navigation, Labels, Querverweise und Suche zu prüfen und Änderungen evidenzbasiert zu begrenzen.
WebChorus Editorial Team9 Min. Lesezeit
Prüfen Sie zuerst repräsentative Nutzeraufgaben und ihre realistischen Wege, bevor Sie Menüs bewerten oder einen neuen Seitenbaum zeichnen. Ein überfülltes Hauptmenü, hohe Ausstiegswerte und Beschwerden über schlechte Auffindbarkeit markieren mögliche Probleme, erklären aber noch nicht deren Ursache. Erst die Routenprüfung zeigt, ob Inhalte fehlen, ein Label falsche Erwartungen weckt, eine Einstiegsseite keinen Anschluss bietet, ein Querverweis fehlt, die Suche ungeeignete Ergebnisse liefert oder ein Bedienelement den grundsätzlich plausiblen Weg blockiert. So wird aus einer allgemeinen Redesign-Debatte eine begrenzte, überprüfbare Entscheidung.
Das Wichtigste in Kürze
Das Audit sollte eine ausdrücklich benannte Entscheidung vorbereiten: etwa einen Bereich reparieren, Labels ändern, eine Migration absichern oder prüfen, ob genügend Evidenz für ein umfassenderes Redesign vorliegt. Informationsarchitektur umfasst Organisation, Labels und Navigation, die Menschen dabei unterstützen, Informationen zu finden, ihren Standort und ihre Optionen zu verstehen und vorgesehene Aufgaben zu erledigen. Der Prüfgegenstand ist deshalb das bestehende Routensystem für ausgewählte Aufgaben, nicht die ästhetische Ordnung eines abstrakten Seitenbaums.
Grenzen Sie dazu Zielgruppen, Ziele, Ausgangssituationen, Seitentypen, Geräte, Sprachfassungen, Berechtigungen und relevante Prozesszustände ein. Ein Weg kann im öffentlichen Bereich verständlich sein und nach der Anmeldung verschwinden; eine Desktop-Navigation kann auf dem Smartphone andere Optionen anbieten. Aussagen des Audits gelten nur für diese dokumentierten Kontexte. Halten Sie außerdem bekannte Tatsachen, beobachtetes Verhalten, Ergebnisse einer Expertenprüfung und noch ungetestete Hypothesen in getrennten Feldern fest, damit Vermutungen nicht unbemerkt den Status von Nutzerbefunden erhalten.
Ein belastbarer Aufgabensatz beschreibt erkennbare Ergebnisse in der Sprache der jeweiligen Zielgruppe und nennt weder das vermutete Ziel-Label noch den erwarteten Navigationsweg. Die GOV.UK-Leitlinie empfiehlt, zu ermitteln, was Menschen erreichen wollen, wie sie bisher vorgehen, welche Probleme sie erleben und welches Ergebnis sie benötigen. Formulieren Sie daher beispielsweise nicht die Anweisung, einen bestimmten Menüpunkt zu öffnen, sondern das Ergebnis, das eine Person aus ihrer Ausgangslage heraus erreichen muss.
Analysedaten, Suchprotokolle, Supportdaten, frühere Forschung, Interviews, Beobachtungen und Beschäftigte mit direktem Nutzerkontakt können Evidenz beitragen; Meinungen ohne Nutzerbezug bleiben Annahmen. Analysedaten und operative Hinweise lokalisieren mögliche Fragen, beweisen aber weder Nutzerabsicht noch Ursache oder passende Strukturmaßnahme. Eine dokumentierte IA-Studie von Digital.gov leitete realistische Aufgabenszenarien aus früherer Forschung ab und prüfte deren thematische Abdeckung vor dem Test. Genau diese Herkunft sollte auch im eigenen Aufgabenregister sichtbar bleiben.
Wählen Sie nicht ausschließlich die häufigsten oder leichtesten Aufgaben. Ein seltener Vorgang kann für eine kleine Zielgruppe geschäftlich entscheidend sein; eine häufige Aufgabe kann bereits gut funktionieren. Der Satz sollte deshalb Häufigkeit, Konsequenz, erkennbare Schwierigkeit und bislang wenig berücksichtigte Bedürfnisse ausbalancieren. Dokumentieren Sie auch die vorgesehene Zielseite oder Aktion, ohne sie den Teilnehmenden zu verraten. Nur so lässt sich später unterscheiden, ob eine Person das richtige Ergebnis über einen unerwarteten, aber gültigen Weg erreicht hat.
Das Arbeitsblatt muss jede belegte Aufgabe mit Ergebnis, Ziel, Ausgangssituationen, plausiblen Routen, geprüften Hinweisen, beobachtetem Verhalten, Diagnose, Maßnahme und erneutem Test verbinden. Erfassen Sie externe Einstiegsseiten, Bereichsseiten, authentifizierte Bereiche und interne Suche als mögliche Startpunkte. Zeichnen Sie getrennt auf, wie Browse-Navigation, kontextuelle Links und Suche zum Ziel führen könnten. Die Startseite ist nur eine mögliche Station und darf nicht stillschweigend zum Ausgangspunkt jeder Aufgabe werden.
An jedem Entscheidungspunkt gehören vier Beobachtungen in den Datensatz: der sichtbare Hinweis, die dadurch erzeugte Erwartung, das tatsächlich erreichte Ziel und die Möglichkeit, einen falschen Schritt zu erkennen und zu korrigieren. Das WCAG-2,2-Erfolgskriterium 2,4,5 verlangt grundsätzlich mehr als einen Weg zu einer Seite innerhalb einer Seitensammlung, sofern diese Seite nicht Ergebnis oder Schritt eines Prozesses ist; dokumentierte Techniken umfassen verwandte Links, Sitemap, Suche und umfassende Navigation. Diese Prüfung ersetzt jedoch keine vollständige Barrierefreiheitsbewertung.
Ein aufgabenbasiertes IA-Audit fragt nicht, ob der Seitenbaum ordentlich aussieht, sondern ob Menschen ein benötigtes Ergebnis über realistische Wege erreichen.
WebChorus Editorial Team
| Aufgabe, Zielgruppe, Auslöser, Ergebnis und Evidenz | Ausgangssituationen, plausible Routen und geprüfte Hinweise | Beobachtung, Maße, Fehlermodus und Evidenzstärke | Kleinste Änderung, Verantwortung und Retest |
|---|---|---|---|
| Angebotsvoraussetzungen vor einer Kontaktaufnahme klären; belegt durch Suchanfragen und Supportfragen | Externe Einstiegsseite, Bereichsseite, Navigation, Querverweis und interne Suche; Labels und Zielseitenversprechen prüfen | Umwege, Rücksprünge, Suchreformulierungen, Zielvertrauen und Abschluss beobachten; möglichen Label- oder Cross-Link-Fehler kennzeichnen | Label und kontextuellen Link begrenzt überarbeiten; verantwortliches Team benennen und dieselben Routen erneut testen |
Prüfen Sie die Route vom realistischen Einstieg bis zum benötigten Inhalt oder zur abschließenden Aktion und untersuchen Sie dabei jede wesentliche Orientierungshilfe. Dazu gehören externe Landingpages, globale und lokale Navigation, Übersichtsseiten, Gruppierungen, Überschriften, Breadcrumbs, kontextuelle Links, interne Suche und das Ziel selbst. An jeder Station lautet die Frage: Erzeugt der sichtbare Hinweis eine zutreffende Erwartung, bleibt die Position verständlich und bietet die Seite einen sinnvollen nächsten Schritt oder eine erkennbare Rückkehrmöglichkeit?
Microsoft empfiehlt, Navigation an Nutzerperspektiven, häufigen Aufgaben und mentalen Modellen auszurichten, und beschreibt wirksame Labels als zutreffend, vertraut, knapp, erfassbar und unterscheidbar. Kürze allein ist damit kein Qualitätsnachweis: Ein kurzes Label kann neben ähnlich benannten Optionen unverständlich bleiben. Das WCAG-2,2-Erfolgskriterium 2,4,6 verlangt, dass vorhandene Überschriften und Labels ihr Thema oder ihren Zweck beschreiben, damit Nutzer Organisation und Informationen besser verstehen können. Prüfen Sie daher stets Cue und Zielseite gemeinsam.
Wiederholen Sie wichtige Aufgaben, wenn Gerät, Sprache, Berechtigung, Seitentyp oder Prozesszustand die verfügbaren Wege materiell verändert. Das WCAG-2,2-Erfolgskriterium 3,2,3 behandelt die gleichbleibende relative Reihenfolge wiederkehrender Navigationsmechanismen, sofern nicht der Nutzer eine Änderung auslöst; lokale oder sekundäre Navigation wird dadurch nicht verboten. Suchen Sie folglich nicht nach schematischer Gleichheit, sondern nach vorhersehbaren wiederkehrenden Mechanismen. Die interne Suche bleibt dabei ein legitimer Alternativweg und nicht automatisch ein Eingeständnis schlechter Navigation.
Wählen Sie die Methode nach der offenen Evidenzfrage, nicht nach Gewohnheit oder Werkzeugverfügbarkeit. Eine Expertenprüfung und vorhandene Verhaltensdaten können wahrscheinliche Schwachstellen lokalisieren, dürfen aber nicht als beobachtetes Nutzerscheitern ausgegeben werden. Digital.gov beschreibt Card Sorting als Methode, mit der sich untersuchen lässt, wie Teilnehmende Inhalte gruppieren und beim offenen Verfahren ihre Gruppen benennen. Damit beantwortet es Fragen zu erwarteter Ordnung und Kategoriensprache, nicht zur vollständigen Nutzung einer bestehenden Website.
Ein Tree Test kann die Auffindbarkeit eines Ziels innerhalb einer Hierarchie isolieren und unklare Kategorien oder Labels sichtbar machen, bildet aber große Teile der gerenderten Oberfläche nicht ab. Für Fragen zu Seitencues, Bedienelementen, Querverweisen, Suche, Fehlererholung und Abschluss ist deshalb ein aufgabenbasierter Usability-Test auf der gerenderten Website geeigneter. NIST beschreibt Usability-Tests als Bearbeitung repräsentativer Aufgaben durch repräsentative Nutzer; mögliche Evidenz umfasst Abschluss, Fehler, Zeit, qualitative Kommentare und Zufriedenheit.
Legen Sie vorab fest, welche Beobachtungen die anstehende Entscheidung tatsächlich beantworten. Je nach Aufgabe können Abschluss, Hilfebedarf, Fehlversuche, Umwege, Zeit, Rücksprünge, Suchreformulierungen, Vertrauen in das erreichte Ziel und die Begründungen der Teilnehmenden relevant sein; daraus entsteht kein verpflichtender Universal-Score. Abweichende Wege und Erklärungen der Teilnehmenden können mehrdeutige Gruppierungen oder Labels offenlegen, selbst wenn einige Personen das vorgesehene Ziel erreichen. Ein alternativer Weg ist jedoch nur dann problematisch, wenn Kontext und Ergebnis dies belegen.
Übersetzen Sie jeden Befund zuerst in einen klaren Fehlermodus und wählen Sie danach die kleinste Maßnahme, die durch die Aufzeichnung gestützt wird. Ein fehlender Inhalt braucht eine andere Lösung als ein missverständliches Label, eine unerwartete Gruppierung, ein fehlender Querverweis, unzureichende Suchergebnisse oder ein unbedienbares Steuerelement. Ohne diese Trennung wird jedes Symptom vorschnell zum Navigationsproblem und jede Häufung lokaler Defekte zum vermeintlichen Beweis für ein vollständiges Redesign.
Priorisieren Sie mit sichtbaren Eingaben: Bedeutung der Aufgabe, betroffene Zielgruppen, beobachtete Fehlerhäufigkeit, Konsequenz, Evidenzstärke und Abhängigkeiten der Behebung. NIST nennt bei repräsentativen Nutzern und Aufgaben unter anderem Abschluss, Fehler, Zeit, qualitative Kommentare und Zufriedenheit als mögliche Evidenzformen. Nicht jede Untersuchung benötigt jedes Maß, und kein universeller gewichteter IA-Wert kann die Entscheidung abnehmen. Halten Sie stattdessen fest, welche Beobachtung welche Priorität und welche konkrete Maßnahme begründet.
Ein Redesign ist erst dann sachlich begründet, wenn wichtige Aufgaben in relevanten Kontexten wiederholt scheitern, die Befunde beobachtet und strukturell sind und begrenzte Reparaturen voraussichtlich nicht ausreichen. Beenden Sie das Audit daher mit einer Retest-Entscheidung, nicht automatisch mit einem neuen Seitenbaum. Bei anspruchsvoller Aufgabenauswahl, Forschungsplanung oder weitreichenden Strukturkonflikten sollte erfahrene IA- oder UX-Forschungskompetenz einbezogen werden. Ein aufgabenbasiertes IA-Audit und die hier ausgewählten WCAG-Prüfpunkte belegen keine vollständige Barrierefreiheitskonformität; dafür ist eine eigenständige fachkundige Prüfung erforderlich.
Ein aufgabenbasiertes IA-Audit prüft belegte Nutzeraufgaben über reale Einstiege, Navigation, Labels, Gruppierungen, Orientierungshilfen, Querverweise, interne Suche und den Abschluss am Ziel. Es dokumentiert plausible Wege, beobachtetes Verhalten, Fehlermodus, Evidenzstärke und Retest. Ein Inhaltsinventar, technisches SEO-Audit, eine vollständige Barrierefreiheitsprüfung oder ein Redesign verfolgt jeweils einen anderen Zweck.
Die herangezogenen Quellen begründen keine allgemeingültige Zahl von Aufgaben oder Teilnehmenden für ein IA-Audit. Der Umfang richtet sich nach der anstehenden Entscheidung, der Vielfalt relevanter Zielgruppen und Kontexte, den Risiken der Aufgaben, der bestehenden Unsicherheit und der benötigten Evidenzstärke. Konkrete Zahlen aus einer einzelnen Fallstudie sollten nicht als allgemeine Vorgabe übernommen werden.
Analysedaten, Suchprotokolle, Ausstiege, Supportkontakte und Feedback können auffällige Stellen und lohnende Forschungsfragen markieren. Sie belegen allein jedoch weder die Absicht einer Person noch die Ursache ihres Verhaltens oder die richtige Strukturmaßnahme. Verbinden Sie solche Signale deshalb mit Beobachtungen, Interviews oder anderen qualitativen Hinweisen und prüfen Sie die betroffene Aufgabe.
Die Nutzung der internen Suche beweist keinen Navigationsfehler. Suche kann ein bevorzugter und gültiger Alternativweg sein, gerade wenn Nutzer ein konkretes Ziel bereits benennen können. Untersuchen Sie Suchbegriffe, Reformulierungen, Relevanz und Verständlichkeit der Ergebnisse, Vertrauen in das Ziel und tatsächlichen Abschluss, bevor Sie einen Such- oder Navigationsfehler diagnostizieren.
Ein Redesign wird plausibel, wenn wichtige Aufgaben über relevante Zielgruppen, Einstiege und Zustände hinweg wiederholt an strukturellen Problemen scheitern und diese Befunde durch Beobachtungen gestützt sind. Lokale Label-, Link-, Inhalts-, Gruppierungs- oder Suchkorrekturen sollten dafür voraussichtlich nicht ausreichen. Auch dann muss die geplante Struktur an denselben Aufgaben und Routen erneut geprüft werden.
Für die Recherche zu diesem Artikel wurden folgende Quellen verwendet:
Mit einem Seitenzweck-Briefing prüfen Sie Content-Anfragen, wählen die passende Lösung und schaffen einen belastbaren Auftrag für die Redaktion.
Erstellen Sie eine nachvollziehbare Website-Strategie, die Zielgruppen-Jobs und Journeys mit Fähigkeiten, messbaren Ergebnissen und Prioritäten verbindet.
Ein praxisnaher Leitfaden für responsive Seitenhierarchien, die Zweck, Belege, Auswahl und nächsten Schritt in jeder Darstellung verständlich halten.
