Warum die Suche in vielen Produkten unterschätzt wird — und wie du Eingabefeld, Autocomplete, Ergebnisseite, Filter und Empty States so gestaltest, dass Menschen schneller finden, was sie suchen
Wenn Nutzer:innen zur Suche greifen, hat deine Navigation entweder versagt — oder dein Produkt ist so groß geworden, dass Suche der schnellere Weg ist. Beides bedeutet: Der Moment, in dem jemand ins Suchfeld klickt, ist einer der ehrlichsten Momente im Produkt. Hier verzeihen Nutzer:innen keine Reibung. Hier reicht ein einziger schlechter Screen, um Vertrauen zu verlieren.
Search-UX ist 2026 eine eigene Disziplin im Product Design. Wer sie ernst nimmt, gewinnt Findbarkeit, Conversion und wahrgenommene Intelligenz des Produkts. Wer sie ignoriert, hat ein Suchfeld, das aussieht wie ein Suchfeld, aber sich anfühlt wie eine Sackgasse: ein leerer Cursor, eine träge Ergebnisseite, ein „Keine Treffer gefunden" ohne Hinweis, was jetzt zu tun ist.
Dieser Artikel zeigt, wie du Suche in Web- und App-Produkten systematisch angehst: vom Eingabefeld über Autocomplete, Ergebnispräsentation und Filter bis zu Empty States, mobilen Eigenheiten und semantischer KI-Suche — mit Mustern, die im kleinen SaaS-Tool genauso tragen wie im großen E-Commerce.
Die Suche ist der ehrlichste Test deines Produkts. Wenn Menschen nichts finden, war es entweder nicht da — oder du hast es unauffindbar gemacht. Beides ist ein Designproblem.
Bevor wir ins Handwerk gehen, ein ehrlicher Blick auf die typischen Ursachen. In Produkt-Audits sehe ich fast immer dieselben Muster.
„Wir haben eine Suche" ist keine UX-Aussage, sondern ein Feature-Ticket. Ob die Suche funktioniert, hängt an Dutzenden kleinen Entscheidungen: Placeholder-Text, Debounce-Timing, Ranking-Logik, Ergebnis-Layout, Filter-Interaktion. Wer diese Details nicht bewusst gestaltet, überlässt sie dem Framework — und Frameworks liefern selten gute UX.
In vielen Produkten kommt die Suche erst dann dazu, wenn die Navigation nicht mehr reicht. Sie wird als MVP eingebaut, funktioniert „irgendwie" und wird danach jahrelang nicht mehr angefasst. Search-Logs werden nicht ausgewertet, Ergebnisqualität nicht gemessen. Dabei ist Suche eines der wenigen Interface-Elemente, das dir direkt sagt, was Nutzer:innen wollen.
Suche ist ein Schnittpunkt aus Design, Content und Data. Wenn Designer:innen die Ranking-Logik nicht verstehen und Entwickler:innen die Ergebnis-UI nicht kennen, entstehen Interfaces, die schön aussehen und trotzdem die falschen Ergebnisse zeigen. Gute Search-UX braucht gemeinsame Sprache über die Disziplinen hinweg.
„Suche nach Produkten, Kategorien, Marken, SKUs oder Kundennummern" — ein Placeholder, der so viel zu tun versucht, dass er nichts mehr transportiert. Nutzer:innen lesen Placeholder maximal einmal, tippen dann los, und der Text verschwindet. Ein guter Placeholder ist ein Beispiel, kein Handbuch.
Diagnose-Tipp: Öffne die Suchlogs deines Produkts der letzten 30 Tage. Wenn du keine hast, ist das schon der erste Befund. Wenn du sie hast, filtere auf Suchanfragen mit null Ergebnissen. Diese Liste ist gleichzeitig eine Roadmap für Content-Lücken und ein Katalog von UX-Verbesserungen.
Nicht jedes Produkt braucht eine prominente Suchfunktion. Bevor du Wochen in eine Search-UX investierst, prüfe die Grundfrage: Ist Suche hier wirklich der beste Weg zum Ziel?
Die meisten guten Produkte bieten beides. Prominent platzierte Navigation für stöbernde Nutzung, gut erreichbare Suche für zielgerichteten Zugriff — und beide funktionieren komplementär, nicht konkurrierend. Wer das Verhältnis nicht bewusst gestaltet, hat entweder eine überladene Startseite oder eine leere Landingpage mit nur einem Suchfeld.
Bevor jemand suchen kann, muss die Suche erreichbar und einladend sein. Diese ersten Millimeter Interface entscheiden, wie oft die Suche überhaupt genutzt wird.
Auf Content-lastigen Sites gehört Suche in den Header, meist rechts, mit erkennbarem Icon. Auf App-artigen Produkten kann sie ganz oben in der Sidebar sitzen oder als globales Feld über allen Screens. Was schlecht funktioniert: Suche versteckt hinter einem Icon-only-Button ohne Beschriftung, den nur Poweruser:innen finden.
Die Lupe ist inzwischen universell verstanden — aber ein sichtbares Textfeld führt zu deutlich mehr Nutzung. Wenn Platz nur für ein Icon reicht, hilft eine Hover- oder Focus-Erweiterung ins volle Feld. Auf Mobile ist ein volles Suchfeld auf der Startseite oft die richtige Wahl.
Gute Placeholder zeigen konkret, was gesucht werden kann: „Suche nach ‚Marketing-Report Q3'" ist besser als „Suche…". Auf Content-Sites: „Suche nach Artikeln, Autor:innen oder Themen" ist okay, „Suche" allein zu leer, ein Doppelsatz zu viel. Faustregel: maximal fünf bis sieben Wörter, konkret, in der Sprache der Nutzer:innen.
Ein Suchfeld ohne sichtbaren Focus-Ring ist ein Barrierefreiheits-Bug. Sobald jemand mit Tastatur ins Feld tabt, muss klar sein: Ich bin jetzt hier. Ein farbiger Rahmen oder Schatten reicht — Hauptsache eindeutig. Weitere Grundlagen dazu stecken im Artikel zu Barrierefreiheit im UX Design.
Sobald etwas im Feld steht, gehört ein Clear-Button (kleines „x" rechts) dazu. Ohne ihn müssen Nutzer:innen manuell alles markieren und löschen — eine unnötige Reibung, die sich in einer Zeile Code beseitigen lässt.
Ein gutes Autocomplete verkürzt Wege, reduziert Tippfehler und zeigt, was überhaupt möglich ist. Ein schlechtes stört, wirkt willkürlich und verlangsamt.
role="combobox" nur aria-expanded; aria-controls, aria-autocomplete und aria-activedescendant gehören zum empfohlenen Muster der W3C-Practices.Wer schon einmal etwas gesucht hat, sucht es oft wieder. Ein kurzer Block „Zuletzt gesucht" spart tippen, wirkt persönlich und zeigt, dass das Produkt Nutzung ernst nimmt. Wichtig: löschbar machen, damit Privatsphäre kontrollierbar bleibt.
In manchen Produkten (Command-Palettes, Global-Search-Overlays, „Search anything") ist die Suche kein Feature, sondern das Interface. Cmd+K oder Ctrl+K sind zu einem De-facto-Standard geworden. Wer sie sinnvoll einbaut, gibt Poweruser:innen einen Zugang, der Navigation und Aktionen zusammenführt.
Wenn Nutzer:innen die Ergebnisliste sehen, entscheidet sich in Sekunden, ob sie klicken oder abbrechen. Die Präsentation trägt hier fast so viel wie die Relevanz des Rankings selbst.
Was oben steht, wird geklickt. Was auf Seite zwei landet, existiert für die meisten nicht. Ranking wirkt technisch — ist aber eine Produkt- und UX-Entscheidung: Willst du neueste Inhalte oben, meistgesehene, redaktionell kuratierte oder algorithmisch personalisierte? Diese Frage gehört ins Design-Doc, nicht ins Backend-Ticket.
Ergebniskarten ohne diese drei Antworten wirken willkürlich — auch wenn sie technisch die richtigen sind.
Ein Snippet mit dem gesuchten Begriff hervorgehoben (fett oder farbig) transportiert in einem Blick, warum dieses Ergebnis erschien. Ohne Highlighting müssen Nutzer:innen den Titel lesen, den Text scannen, den Zusammenhang selbst erschließen. Mit Highlighting reicht ein Blick.
Autor:in, Datum, Kategorie, Tags — jede Metainformation ist ein Signal. Zu viele davon werden zu Rauschen. Faustregel: maximal drei sichtbare Metadaten pro Ergebnis, alles Weitere in Hover- oder Detail-Ansichten.
Wenn alle Ergebnisse gleich aufgebaut sind, sind sie scanbar. Wenn Videos, Artikel und Produkte in derselben Ergebnisliste jeweils anders aussehen, ist die Liste unruhig. Eine konsistente Grundstruktur mit dezenten Typ-Indikatoren funktioniert besser als drei parallele Layouts. Weitere Grundlagen zur Ergebnispräsentation findest du im Artikel zu Informationsarchitektur und Navigation.
Filter sind der zweitwichtigste Bestandteil einer Suchergebnisseite — und einer der am häufigsten überladenen. Ziel: Nutzer:innen die Kontrolle geben, ohne sie mit Optionen zu erschlagen.
Nicht alle möglichen. Nur die, die für die tatsächlichen Ergebnisse relevant sind. Wenn nur drei Artikel gefunden wurden, brauchen die keinen „Filter nach 20 Kategorien". Filter sollten dynamisch mit den Ergebnissen atmen — dazu gehören auch Facet-Counts („Filter Marketing (12)").
Das meistgenutzte Filter oben, das Nischen-Filter unten oder eingeklappt. Wer keine Nutzungsdaten hat, orientiert sich am Objekttyp: Bei Produkten sind es meist Kategorie, Preis, Verfügbarkeit. Bei Inhalten Datum, Typ, Autor:in.
Auf Desktop funktioniert die klassische Filter-Sidebar links. Auf Mobile ist die Sidebar unmöglich — dort ist ein Filter-Bottom-Sheet oder ein Modal die richtige Wahl. Mit klarer „Ergebnisse zeigen"-Bestätigung, damit die Änderungen erst bei Bestätigung greifen (auf Mobile: gute UX). Auf Desktop kann Live-Filterung schneller sein.
Sobald Filter gesetzt sind, gehören sie prominent an den Anfang der Ergebnisliste: als Chips, einzeln entfernbar, mit einem „Alle zurücksetzen"-Button. Sonst passiert das häufigste Filter-Missgeschick: Nutzer:innen wundern sich über fehlende Ergebnisse und finden nicht, warum.
Sortierung („nach Relevanz", „nach Datum", „nach Preis") gehört sichtbar oberhalb der Ergebnisliste, nicht in die Filter-Sidebar. Sie ändert die Reihenfolge, nicht die Menge — konzeptionell etwas anderes.
Der gefährlichste Zustand einer Suche ist „keine Treffer". Wenn dieser Screen leer bleibt, hört das Produkt für Nutzer:innen an dieser Stelle auf.
Ein guter Zero-Results-State erklärt, warum nichts gefunden wurde, und schlägt konkrete nächste Schritte vor:
Empty States sind ein eigenes Handwerk — mehr dazu im Artikel zu Empty States gestalten im Product Design.
Fuzzy-Matching, Phonetik, Synonyme — all das gehört ins Search-Backend, aber die UI muss es aufgreifen. Wenn dein System „Farbsytem" als „Farbsystem" versteht, sag es sichtbar: „Wir haben deine Suche zu Farbsystem korrigiert. Ursprüngliche Suche anzeigen." Transparenz gewinnt Vertrauen.
Suche darf nicht lange stumm bleiben. Unter etwa einer Sekunde braucht es meist gar keine Rückmeldung; wer früher anzeigt, sollte den Indikator um rund 300 Millisekunden verzögern, damit er nicht flackert. Danach hilft ein Skeleton-Screen oder ein subtiler Spinner im Feld. Was nicht funktioniert: einen kompletten Ergebnis-Layout-Wechsel ohne Übergang. Nutzer:innen brauchen visuelle Kontinuität, sonst wirkt jede Suche wie ein Neustart.
Wenn die Suche technisch scheitert, gehört ein ehrlicher Screen dahin: „Die Suche ist gerade nicht erreichbar. Bitte in ein paar Minuten erneut versuchen." Kein leeres „Keine Ergebnisse", das Nutzer:innen glauben lässt, ihre Anfrage sei falsch.
Was am Desktop funktioniert, funktioniert auf Mobile fast nie eins zu eins. Suche auf 375 Pixel Bildschirmbreite ist eine eigene Herausforderung.
Auf Mobile ist eine Suche hinter einem Icon fast unsichtbar. Prominente Sites platzieren die Suche als volles Feld auf der Startseite — oder öffnen sie als Vollbild-Overlay beim ersten Tap. Beides erhöht die Nutzung deutlich gegenüber einem versteckten Lupen-Icon.
Sobald das Suchfeld fokussiert wird, sollte die Tastatur automatisch erscheinen — und der „Enter"-Button sollte als „Suchen" beschriftet sein (enterkeyhint="search" in HTML). Kleines Detail, spürbarer UX-Effekt.
Filter-Sidebars gibt es auf Mobile nicht. Bottom-Sheets funktionieren besser als Modals, weil sie mit dem Daumen erreichbar sind und den Kontext teilweise sichtbar lassen. Der „Ergebnisse zeigen"-Button gehört ans untere Ende — dorthin, wo der Daumen sowieso liegt.
Auf Mobile funktioniert ein einspaltiges Layout mit größeren Touch-Targets besser als der Versuch, Desktop-Karten zu schrumpfen. Für Suchergebnisse rät die Forschung von Infinite Scroll ab, auf Mobile besonders: Wiederfinden und Orientierung leiden. „Mehr laden" ist die sichere Wahl.
Auf Mobile suchen viele Menschen per Spracheingabe. Ein sichtbares Mikrofon-Icon im Suchfeld signalisiert, dass das unterstützt wird — und ein System, das Sprachanfragen (die tendenziell länger und in ganzen Sätzen sind) genauso gut versteht wie Kurzanfragen, ist heute Basisqualität, nicht Bonus.
Mehr zur Mobile-Perspektive steckt im Artikel zu Mobile First im UX Design.
Suche ist einer der wenigen Interface-Bereiche, in dem Nutzer:innen dir wörtlich sagen, was sie wollen. Wer das nicht auswertet, verschenkt eine kontinuierlich wachsende Roadmap.
Eine Woche Zero-Results-Suchen ist gleichzeitig eine Woche unerfüllter Bedürfnisse. Für einen Blog liest sich die Liste wie ein Redaktionsplan. Für ein SaaS-Produkt wie ein Feature-Backlog. Für einen Shop wie eine Sortimentserweiterung.
Was Nutzer:innen suchen, ist oft persönlich. Suchprotokolle brauchen dieselbe Sensibilität wie andere personenbezogene Daten: Anonymisierung, kurze Speicherfristen, DSGVO-konforme Verarbeitung. Wer Search-Logs sammelt, sollte in der Datenschutzerklärung transparent machen, wie und wozu.
Faustregel: Wenn du deine 20 häufigsten Suchbegriffe nicht auswendig kennst, verlierst du die schnellste Feedback-Schleife deines Produkts.
Semantic Search, Vektor-Embeddings, retrieval-augmented Generation — der Buzz um KI-Suche war 2023/24 laut und ist seit 2024/25 in echten Produkten angekommen — von Google AI Overviews bis zu KI-Antworten in Support-Portalen. Was heißt das für Search-UX?
Klassische Suche findet Wörter. Semantic Search findet Bedeutungen. Wer nach „günstiges Laufband für kleine Wohnung" sucht, meint vielleicht ein klappbares Modell — auch wenn das Wort „klappbar" nicht fällt. KI-basierte Suche versteht diese Intention und liefert passendere Ergebnisse, ohne dass Nutzer:innen ihre Sprache anpassen müssen.
In vielen Produkten reicht es Nutzer:innen nicht mehr, eine Liste von zehn Ergebnissen zu bekommen. Sie wollen eine Antwort. Ein KI-generiertes Snippet über der Ergebnisliste — mit Verweis auf die zugrundeliegenden Quellen — hat sich in Support-Systemen, Wissensdatenbanken und Dokumentationsseiten als Standard etabliert.
Wenn eine KI die Antwort formuliert, gehört das sichtbar dazu. Nutzer:innen müssen erkennen, ob eine Antwort direkt aus einem Dokument stammt oder generiert wurde — und Zugriff auf die Quellen bekommen. Ohne diese Transparenz entsteht falsches Vertrauen, das bei Fehlern in einen Vertrauensbruch umschlägt.
Auch die beste KI-Suche wird Anfragen nicht verstehen. Ein sichtbarer Toggle „Klassische Ergebnisse anzeigen" ist kein Rückschritt, sondern eine Absicherung. Wer nur auf KI setzt und den klassischen Weg entfernt, verliert Poweruser:innen, die genau wissen, wonach sie suchen.
Suchmaschinen sind längst nicht mehr die einzige Findbarkeitsschicht. KI-Assistenten holen sich Antworten aus vielen Quellen — auch aus deinem Produkt, wenn du sie lässt. Wer Content strukturiert (semantisches HTML, JSON-LD, klare Überschriften-Hierarchien), macht seine Inhalte gleichzeitig für klassische Suche, interne Suche und KI-Antworten besser auffindbar. Mehr zum KI-Einsatz im Design-Prozess im Artikel zu KI-Tools im UX-Prozess.
Designer-Reminder: KI-Suche wirkt magisch, wenn sie funktioniert. Wenn sie das nicht tut, wirkt sie wie ein Bug. Gute Search-UX macht sichtbar, wann die Antwort sicher ist, wann sie generiert wurde und wo die Grenzen liegen.
Wenn du diesen Artikel praktisch nutzen willst, geht das in einer halben Stunde — am besten gemeinsam mit Content und Entwicklung. Geh dein Produkt durch und prüfe:
Eine ehrliche Bestandsaufnahme liefert in fast jedem Produkt fünf bis zwölf konkrete Verbesserungen. Die meisten davon sind kein Rebuild, sondern Feinschliff an bestehenden Screens — mit direktem Effekt auf Findbarkeit, Conversion und wahrgenommene Qualität.
Suche ist keine Zusatzfunktion, sondern eines der ehrlichsten Interfaces deines Produkts. Sie zeigt in Sekunden, ob Content gefunden wird, ob Ranking passt, ob Empty States tragfähig sind — und ob Nutzer:innen der Suche vertrauen. Wer sie systematisch gestaltet, gewinnt Klarheit, Conversion und einen dauerhaft besseren Zugang zum eigenen Produkt.
Die wichtigsten Takeaways:
enterkeyhint="search", Sprachsuche.Search-UX ist kein Rebuild-Thema. Es ist ein Feinschliff-Thema — mit überraschend großem Effekt auf Findbarkeit, Zufriedenheit und Conversion. Wer die Suche im eigenen Produkt so ernst nimmt wie die Navigation, gewinnt eine der schnellsten Feedback-Schleifen, die Design überhaupt bekommen kann.
Transparenzhinweis: Die Bilder in diesem Artikel wurden mit KI erstellt. Der Text wurde mit KI auf Rechtschreibung und Grammatik geprüft. Die redaktionelle Verantwortung liegt bei Jannik Noe.
Zusammenarbeit
Ich übersetze komplexe Anforderungen in klare, nutzerfreundliche Interfaces — von der Konzeption bis zum Developer-Handoff.
Push, In-App, E-Mail und Systembanner sind der schmalste Grat im Product Design — zwischen echtem Mehrwert und dem schnellsten Weg zur Deinstallation. Wie du Benachrichtigungen so gestaltest, dass Nutzer:innen sie behalten, statt sie abzuschalten.
Warum Typografie in Web und App eine eigene Designdisziplin ist — und wie du Type-Systeme, Hierarchie und Lesbarkeit so aufbaust, dass sie Marke, UX und Performance gleichzeitig stärken
Wie du in Web- und App-Produkten leere Zustände vom unsichtbaren Loch in eine echte Conversion-Chance verwandelst — vom ersten Login bis zum gefilterten Suchergebnis
Du planst ein digitales Produkt, ein Redesign — oder möchtest euer Team mit einem AI-UX Workshop voranbringen?
Ich unterstütze Unternehmen dabei, komplexe Anforderungen in klare, nutzerfreundliche Lösungen zu übersetzen.