Was vorher fertig sein muss
Eine konkrete IA-Struktur (Hierarchie aus Card Sorting oder bestehender Navigation) liegt vor, die getestet werden soll.
5-10 typische Suchaufgaben aus echten Nutzerszenarien sind formuliert, ohne dass die Aufgabenbeschreibung die Zielkategorie verrät.
Was vor Start vorliegen muss
Tree-Testing-Tool (Treejack von Optimal Workshop, UserZoom, Maze); Tree-Struktur als JSON oder CSV; Tasks mit Zielpfad markiert; Survey-Setup; Recruiting-Link.
Ein UX-Researcher als Owner; Recruiter für 15-30 Teilnehmer pro Variante; optional Stakeholder zur Task-Validierung; Notizen-Empfänger im Team.
IA-Struktur als Tree mit allen Knoten und Endknoten; Task-Liste mit Zielpfaden; Hypothesen (welche Tasks scheitern wahrscheinlich); Demografie der Zielgruppe.
1-2 Tage Setup, 3-7 Tage Datensammlung, 1-2 Tage Auswertung
Tree im Tool aufbauen (alle Knoten exakt wie geplant). Tasks formulieren: konkrete Suchaufgabe, NICHT Kategorie-Name nennen. Pilot mit 2-3 Personen. Hauptdurchlauf mit 15-30 Teilnehmern (mehr für Varianten-Vergleich).
Die eine Frage, die diese Methode beantwortet
Können die Teilnehmer die richtigen Antworten in der vorgeschlagenen Navigationsstruktur finden, und welche Pfade führen sie auf Irrwege?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Tree-Aufbau | 2-4 h | IA-Struktur ins Tool importieren oder manuell anlegen. Pro Knoten Label exakt wie geplant. Visuelle Hilfen weglassen, nur Text-Hierarchie. | Ein falsches Label im Tree verzerrt alle nachfolgenden Tasks. Vor Pilot Tree gegen IA-Dokument prüfen, Knoten für Knoten. |
2Phase 2: Task-Formulierung | 2-3 h | Pro Task realistisches Suchszenario formulieren („Sie möchten Ihre Lieferadresse für Ihre Bestellung ändern, wo klicken Sie?“). Zielpfad im Tool markieren (kann mehrere korrekte Pfade haben). | Vermeide Wörter aus Kategorien im Task-Text. Wenn Kategorie „Konto & Profil“ heißt, im Task nicht „in Ihrem Konto“ schreiben - sonst verrät der Text die Antwort. |
3Phase 3: Pilot | 1-2 h | 2-3 Personen den Test durchlaufen lassen. Auf Verwirrung achten: Tasks unklar, Labels missverständlich, Tree zu tief. Nach Pilot Tasks oder Tree anpassen. | Pilot zeigt Format-Fehler frühzeitig. Hauptdurchlauf direkt nach falschem Pilot ist Datenverschwendung. |
4Phase 4: Hauptdurchlauf | 3-7 Tage Laufzeit | 15-30 Teilnehmer pro Tree-Variante. Bei A/B-Vergleich (alt vs. neu) mind. 30 pro Gruppe. Anonyme asynchrone Bearbeitung, Tool zeichnet Pfade auf. | Unter 10 Teilnehmern ist statistische Aussage dünn. Bei mehreren Varianten exponentiell mehr Teilnehmer nötig. |
5Phase 5: Auswertung und Iteration | 1-2 Tage | Pro Task: Success Rate (richtige Endknoten), Directness (direkter Pfad ohne Umwege), häufigste Fehlpfade. Tasks mit <60% Success Rate sind kritisch. Label oder Hierarchie anpassen, ggf. neuer Test. | Success Rate allein irreführend. Directness niedrig + Success hoch bedeutet trial-and-error. Pfad-Analyse zeigt wo Nutzer scheitern. |
Was am Ende rauskommt
Tree-Testing-Report mit Tree-Visualisierung, Task-Liste, Success-Rate-Tabelle pro Task, Directness-Werten, Top-3-Fehlpfaden pro Task, Sample-Beschreibung und priorisierten Empfehlungen für IA-Anpassung.
Pro Tree-Version eigener Test-Run mit Datum. Vergleich zwischen Versionen explizit dokumentieren (Verbesserung pro Task in Prozentpunkten). Tree-Snapshots als JSON-Export im Repo, sodass IA-Historie nachvollziehbar bleibt.
Kompakte Arbeitsvorlage für Tree Testing mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
Wofür wird die Methode eingesetzt?
Welche Frage soll am Ende beantwortet sein?
Welche Daten, Beobachtungen oder Materialien liegen vor?
Owner, Datum, Erfolgssignal.
Konkret gefülltes Szenario, fiktives Beispiel
Konkret gefülltes Szenario, fiktives Beispiel
Tree-Variante: Neue IA mit 6 Top-Level-Kategorien (siehe Card Sorting KW 18) Sample: 24 Bestandsnutzer, asynchron via Treejack, Vergütung 10 EUR
| Task | Success Rate | Directness | Häufigster Fehlpfad |
|---|---|---|---|
| Passwort zurücksetzen | 96% (23/24) | 87% | Konto & Sicherheit → Konto-Einstellungen → ✓ |
| Rechnung herunterladen | 79% (19/24) | 63% | Abrechnung → Rechnungen ✓ (Fehler: 5 gingen erst zu Funktionen) |
| API-Token erstellen | 42% (10/24) | 28% | KRITISCH: 8 gingen zu Konto, 6 zu Funktionen, nur 10 zu Integrationen & API |
| Mitarbeiter einladen | 71% (17/24) | 54% | Konto → Mitarbeiter ✗ (richtig: Erste Schritte) |
| Abo kündigen | 88% (21/24) | 79% | Abrechnung → Kündigung ✓ |
Symptome erkennen, gegensteuern
Task enthält Kategorie-Schlüsselwort, Tester finden Pfad zu leicht.
Task formulieren ohne Kategorie-Sprache. Statt „Wo finden Sie Ihre Abrechnung?“ besser „Sie möchten die letzte Rechnung herunterladen, wo klicken Sie?“. Pilot prüft Wortwahl.
Test mit 5-8 Teilnehmern, Success Rates haben extreme Schwankungen.
Mindestens 15 für Pattern-Erkenntnis, 30+ für statistisch belastbare Vergleiche. Bei A/B getrennte Samples nötig.
Hierarchie hat 5+ Ebenen, Tester verlieren Orientierung und springen zurück.
Tiefe auf max 3-4 Ebenen begrenzen. Wenn mehr nötig, IA-Restrukturierung statt Tree-Test.
Stakeholder erwarten Aussage über Design, Tree-Test liefert nur Textstrukturen.
Erwartungs-Setting vorab: Tree Test misst IA und Labels, nicht visuelles Design. Für Design-Feedback Usability Test oder First-Click ansetzen.
Test zeigt Probleme, IA wird trotzdem unverändert ausgerollt.
Test-Erkenntnisse als gating für IA-Launch. Bei Success-Rate-Schwellwerten unter 60% iterieren und re-testen, nicht launchen.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.