Wenn deine Suche mehrere ähnlich benannte Vorgänge findet, hilft die Liste erst weiter, wenn Nutzer den richtigen erkennen können. Dafür brauchen sie etwa Datum, zuständige Person, Standort oder Status. Welche dieser Angaben wichtig ist, hängt davon ab, was sie über den gesuchten Vorgang bereits wissen.
Erst klären, wonach Menschen suchen
In einer Web-App kann „Suche“ sehr verschiedene Aufgaben bedeuten: einen bekannten Datensatz wiederfinden, offene Vorgänge zusammenstellen oder unbekannte Dokumente zum Thema entdecken. Für jede Aufgabe werden andere Angaben gebraucht.
Du kannst die passenden Angaben aus typischen Suchsituationen ableiten, ohne dafür ungeprüft personenbezogene Suchtexte zu sammeln. Wer eine Kennung kennt, braucht einen anderen Einstieg als jemand, der nur ein ungefähres Datum oder den fachlichen Zusammenhang erinnert. Diese Unterschiede bestimmen sowohl die Suchfelder als auch die Informationen in jedem Treffer.
Kommt ein Anlagenname in einem internen Wartungsportal an zwei Standorten vor, braucht die suchende Person eine Möglichkeit, beide Treffer zu unterscheiden. Name, Standort und Status können diese Auswahl ermöglichen; ein größeres Vorschaubild würde den fehlenden Standort nicht ersetzen.
Die Anfrage im Ergebnis sichtbar halten
Nach dem Suchen muss erkennbar bleiben, worauf sich die Liste bezieht. Die Suchkomponente des U.S. Web Design System empfiehlt unter anderem, den Suchbegriff auf der Ergebnisseite im Eingabefeld zu erhalten. Bei einer Anwendung gehören auch aktive Filter und der Suchbereich dazu.
Zeige beispielsweise, ob die Suche nur offene Vorgänge oder auch das Archiv umfasst. Ein Filter darf nicht unsichtbar erhalten bleiben, während jemand einen neuen Begriff ausprobiert. Andernfalls wirkt eine richtige Suche wie ein fehlerhafter Index.
Achte auch auf die Rückkehr aus einem Treffer: Bleiben Begriff, Filter und Listenposition erhalten? Wer bei jedem geöffneten Datensatz neu suchen muss, verliert einen Teil seines Arbeitskontexts.
Leere Ergebnisse haben unterschiedliche Ursachen
„Nichts gefunden“ kann heißen, dass kein passender Datensatz existiert. Vielleicht ist aber ein Filter zu eng, die Kennung wurde anders geschrieben oder die Rolle darf den Inhalt nicht sehen. Die Oberfläche sollte nur Erklärungen geben, die sie tatsächlich unterscheiden kann.
| Beobachtbarer Zustand | Hilfreiche Rückmeldung |
|---|---|
| Suche mit aktiven Filtern liefert keine Treffer | Begriff und Filter zeigen; gezieltes Zurücksetzen anbieten |
| Verbindung zur Suche ist fehlgeschlagen | Technischen Fehler benennen; erneuten Versuch ermöglichen |
| Eingabe entspricht keinem erlaubten Kennungsformat | Erwartetes Format am Feld erklären |
Welche Meldung passt, ergibt sich aus dem Zustand, den das Backend tatsächlich liefert. Kann es einen Grund nicht unterscheiden, würde ein konkreter Erklärungstext mehr behaupten, als bekannt ist. Auch bei fehlenden Rechten muss die Rückmeldung helfen, ohne die Existenz vertraulicher Datensätze zu verraten.
Die Treffer mit einer Arbeitsaufgabe testen
Mit bekannten Suchsituationen kannst du anschließend prüfen, ob diese Zuordnung funktioniert. Eine eindeutige Kennung, mehrere ähnliche Treffer und ein begründeter Leerzustand fordern jeweils etwas anderes von der Oberfläche. Entscheidend ist deshalb nicht nur, ob jemand ein Ergebnis öffnet, sondern ob es das richtige ist und die Arbeit danach weitergehen kann.
Wenn die Suche scheitert, hilft dir die Unterscheidung zwischen einem fehlenden Datensatz, einem nicht erkennbaren Treffer und einem ausschließenden Filter. Jeder Befund führt zu anderer Arbeit an Suchlogik, Darstellung oder Daten. Für die Eingrenzung gibt es die UX-Entscheidungsberatung; die Entwicklung einer Web-App-Oberfläche setzt eine geklärte Aufgabe voraus.
