Zoekfunctie toevoegen aan je AI-gebouwde app (zodat mensen dingen ook echt kunnen vinden)

Er is een moment dat elke goede AI-gebouwde app een keer meemaakt: hij raakt vol. De receptenapp die heerlijk overzichtelijk was met twaalf recepten, wordt een klus bij driehonderd. De klantentracker die netjes was met acht klanten, verandert in eindeloos scrollen bij tweehonderd. Er is niets stukgegaan. De app werd gebruikt, en dat is precies de bedoeling — maar nu duurt het ding waarvoor mensen komen, één specifiek item vinden, te lang.

Dat is het signaal dat het tijd is om zoeken aan je app toe te voegen — een veld waarin je een paar letters typt om een lange lijst terug te brengen tot het ene item dat je zoekt. Niet omdat zoeken indrukwekkend is, maar omdat scrollen geen vinden is. Laten we doornemen hoe je dit doet zonder te overbouwen, want de mooiste versie is meestal niet de juiste eerste stap.

Wanneer is het tijd om zoeken aan je app toe te voegen?

Je merkt het vanzelf: scrollen begint langer te duren dan zou moeten — je lijst is gegroeid van een overzichtelijk handjevol items naar honderden, en om één specifiek ding te vinden moet je langs alles scrollen. Er is niets stukgegaan om hier te komen; de app werd gebruikt, en dat is precies de bedoeling.

Hier is een concreet voorbeeld van dit probleem. Een hondentrimster bouwde een app om haar klanten bij te houden — naam, naam van de hond, ras, notities over welke honden de föhn haten. De eerste maanden was het een overzichtelijke lijst waar ze in één oogopslag doorheen kon kijken. Tegen de tijd dat ze tweehonderd klanten had, opende ze de app terwijl er een klant vlak voor haar stond, en moest ze langs honderd namen scrollen om “Bella’s baasje” te vinden.

De app deed precies wat ze had gevraagd. Alleen was de lijst geen handige manier meer om er één ding in terug te vinden. Dat is wat zoeken oplost: het verandert “scrollen tot je het ziet” in “typ een paar letters en het staat er”.

Als je app een lijst toont van wat dan ook — bestellingen, recepten, klanten, producten, notities — en die lijst blijft groeien, dan loop je hier vroeg of laat tegenaan. Het goede nieuws: de eerste, eenvoudigste versie van zoeken lost dit voor bijna iedereen op.

Hoe voeg je zoeken toe aan een AI-gebouwde app?

Begin met een filterveld — een tekstveld boven je lijst dat alles verbergt wat niet overeenkomt terwijl je typt — niet met de slimst mogelijke “AI-zoekfunctie”. Dat is de hele eerste stap, en voor de meeste apps is het ook de enige stap die je nodig hebt.

Als je een AI-bouwer om zoeken vraagt, is het verleidelijk om meteen de slimst mogelijke versie te vragen: begrijpt wat je bedoelt, herkent synoniemen, rangschikt op relevantie. Doe dat niet. De slimme versie is trager, kost meer om te draaien, is lastiger goed te krijgen — en je hebt hem vrijwel zeker nog niet nodig.

Typ “bella” en de lijst krimpt tot de Bella’s. Dat is alles. Het is direct, kost vrijwel niets om te draaien, en het is wat mensen echt bedoelen als ze zeggen: “Ik wil kunnen zoeken.”

Vraag je bouwer precies dat: “Voeg een zoekveld toe boven deze lijst dat items filtert op basis van wat ik typ.” Je zult verrast zijn hoe vaak dat het hele project is.

Naar welke velden moet zoeken eigenlijk kijken?

Alleen de twee of drie velden die het ding waar je naar zoekt echt identificeren — niet elk veld van elk item. Dit aan je bouwer vertellen is de ene instructie die het verschil maakt tussen goed en frustrerend zoeken, en de meeste mensen slaan hem over.

Standaard doorzoekt een bouwer misschien alles — elk veld van elk item. Dat klinkt grondig, maar is meestal slechter. Stel je voor dat je in die klantenlijst zoekt en resultaten krijgt omdat het woord “klein” voorkwam in een notitieveld over het formaat van een hond. Nu zit je resultaten uit te ziften die technisch gezien overeenkomen, maar niet zijn wat je bedoelde.

Wees dus specifiek over welke velden ertoe doen. Voor de trimster zijn dat de naam van de klant en de naam van de hond — niet de notities, niet het ras, niet de afsprakengeschiedenis. Voor een receptenapp is dat de titel van het recept en misschien het hoofdingrediënt, niet de volledige bereidingswijze. Vertel je bouwer: “Zoeken moet alleen naar het titel- en naamveld kijken.” De juiste twee velden doorzoeken wint het altijd van alle twaalf doorzoeken.

Moet je eerst zoeken of filters bouwen?

Vaak filters — want veel van wat mensen “zoeken” noemen, is eigenlijk “laat me een subset zien”, en een zoekveld is daar het verkeerde gereedschap voor. Dit verrast niet-technische bouwers vaak.

Een wederverkoopster met driehonderd voorraaditems wil meestal niet typen — ze wil tikken op “Verkocht” of “Op voorraad” of “Deze week geplaatst”. Dat is een filter: een paar knoppen of een dropdown die de lijst inperkt op een categorie die je al bijhoudt. Filters zijn vaak makkelijker te bouwen dan zoeken en dagelijks nuttiger, omdat mensen veel vaker bladeren op status dan dat ze op naam naar één specifiek ding jagen.

Een goede vuistregel: voeg een zoekveld toe voor “ik weet ongeveer hoe het heet”, en voeg filters toe voor “laat me dit type zien”. Onze hondentrimster bleek uiteindelijk beide nodig te hebben — een zoekveld om direct naar een klant te springen als die voor haar staat, en een filter voor “toe aan trimbeurt” zodat ze in één oogopslag kon zien wie ze op een rustige middag een berichtje moest sturen. Dezelfde data, twee compleet verschillende manieren om erbij te komen.

Als je er maar één als eerste kunt bouwen, kijk dan hoe mensen de app daadwerkelijk gebruiken. Blijven ze vragen “waar zijn alle X”, dan willen ze een filter, geen zoekveld.

Wat moet er verschijnen als zoeken niets vindt?

Een simpele, specifieke melding — iets als “Geen klanten gevonden voor ‘zelda’ — controleer de spelling of wis de zoekopdracht” — geen leeg scherm, want dat oogt als “de app is stuk”. Dat is hij niet; er is gewoon geen match, en de meeste mensen vergeten dit van tevoren te bedenken.

Standaard is het vaak een leeg scherm. Vertel je bouwer dus wat er in die lege toestand moet staan. Die ene zin maakt het verschil tussen een gebruiker die denkt dat je app stuk is, en een gebruiker die denkt dat hij iets verkeerd heeft getypt.

Zorg er meteen ook voor dat er een duidelijke manier is om de zoekopdracht te wissen en de hele lijst terug te krijgen. Een klein “x” in het veld, of een “wis”-link. Mensen komen vaker vast te zitten in een zoekopdracht waar ze niet uit kunnen dan je zou denken.

Wanneer heb je AI-gestuurd zoeken nodig in plaats van een filterveld?

Twee specifieke signalen, geen gevoel: typefouten en betekenis. Als mensen zoeken op “stephanie” en “Stefanie” missen, wil je een tolerante zoekfunctie die bijna-matches herkent — vraag je bouwer om “zoeken dat nog steeds resultaten vindt als de spelling net niet klopt”. En als je écht “vind me notities over factuurproblemen” nodig hebt in plaats van “vind het woord factuur”, dan heb je te maken met de slimme, AI-gestuurde vorm van zoeken — de extra kosten en complexiteit waard zodra het een probleem oplost dat het simpele veld niet kan.

Begin er alleen niet mee. Begin met het veld dat filtert, voeg tolerante matching toe zodra typefouten pijn doen, en grijp pas naar de slimme versie zodra “match de woorden” niet meer volstaat. De meeste apps hebben nooit meer nodig dan stap één.

Kijk dus, voordat je iets bouwt, een week lang naar jezelf terwijl je je eigen app gebruikt. Het ding waar je steeds naar zit te scrollen — een klant, een bestelling, een recept — daar is je zoekveld voor bedoeld. Bouw het eerst voor dat ene ding, en je hebt het probleem opgelost voor bijna iedereen die de app gebruikt.