I början av webben var sökfältet en lyx, som lades till på en webbplats när den blev "för stor" för att navigera genom att klicka. Vi behandlade det som ett register längst bak i en bok: en bokstavlig, alfabetisk lista med ord som pekade på specifika sidor. Om du skrev exakt det ord författaren använde hittade du det du behövde. Om du inte gjorde det möttes du av en "0 resultat hittades"-skärm som kändes som en digital återvändsgränd. Tjugofem år senare bygger vi fortfarande sökfält som fungerar som 1990-talets registerkort, även om människorna som använder dem har kopplats om i grunden. Idag, när en användare landar på din webbplats och inte kan hitta vad de behöver i den globala navigeringen inom några sekunder, försöker de inte lära sig din klassificering. De går mot sökrutan. Men om den rutan sviker dem och kräver att de använder ditt specifika varumärkesordförråd, eller straffar dem för ett stavfel, gör de något som borde hålla varje UX-designer vaken på natten. De lämnar din webbplats, går till Google och skriver site:yourwebsite.com [query]. Eller, ännu värre, de skriver bara in sin fråga och hamnar på en konkurrents webbplats. Jag personligen använder Google över en webbplatssökning nästan varje gång. Detta är Site-Search Paradox. I en tid där vi har mer data och bättre verktyg än någonsin, är våra interna sökupplevelser ofta så dåliga att användare föredrar att använda en global sökmotor för biljoner dollar för att hitta en enda sida på en lokal webbplats. Som informationsarkitekter och UX-designers måste vi fråga, varför vinner "Big Box" och hur kan vi ta tillbaka våra användare? "Syntaxskatten" och döden för exakt matchning Den främsta anledningen till att webbplatssökning misslyckas är vad jag kallar Syntax Tax. Det här är den kognitiva belastningen vi lägger på användare när vi kräver att de ska gissa den exakta teckensträngen vi har använt i vår databas. Forskning från Origin Growth on Search vs Navigate visar att ungefär 50 % av användarna går direkt till sökfältet när de landar på en webbplats. Till exempel, när en användare skriver in "soffa" på en möbelsajt som har kategoriserat allt under "soffor" och sajten inte returnerar något, tänker användaren inte "Åh, jag borde prova en synonym." De tänker: "Den här webbplatsen har inte vad jag vill ha." Detta är ett misslyckande för Information Architecture (IA). Vi har byggt våra system för att matcha strängar (bokstavssekvenser) snarare än saker (koncepten bakom orden). När vi tvingar användare att matcha vårt interna ordförråd, beskattar vi deras hjärnkraft.
Varför Google vinner: It's Not Power, It's Context Det är lätt att räcka upp händerna och säga: "Vi kan inte konkurrera med Googles teknik." Men Googles framgång handlar inte bara om råkraft; det handlar om kontextuell förståelse. Även om vi ofta behandlar sökning som ett tekniskt verktyg, behandlar Google det som en IA-utmaning. Data från Baymard Institute avslöjar att 41 % av e-handelssajterna inte stöder ens grundläggande symboler eller förkortningar, och detta leder ofta till att användare överger en webbplats efter ett enda misslyckat sökförsök. Google vinner eftersom det använder stemming och lemmatisering – IA-tekniker som känner igen "löpning" och "spring" är samma avsikt. De flesta interna sökningar är "blinda" för detta sammanhang, och behandlar "löparsko" och "löparskor" som helt olika enheter. Om din webbplatssökning inte kan hantera en enkel plural eller en vanlig felstavning, debiterar du faktiskt dina användare en skatt för att vara människa.
Användningen av "Kanske": Designa för probabilistiska resultat I traditionell IA tänker vi i binärer: En sida är antingen i en kategori eller så är den inte det. Ett sökresultat är antingen en matchning eller så är det inte. Modern sökning, som användare nu förväntar sig, är sannolikhet. Det handlar om "förtroendenivåer." Enligt Forresters har användare som använder sökning 2–3 gånger större sannolikhet att konvertera än de som inte gör det, om sökningen fungerar. Och 80 % av användarna på e-handelssajter lämnar en webbplats på grund av dåliga sökresultat. Som designers designar vi sällan för medelvägen. Vi designar en "Resultat hittade"-sida och en "Inga resultat". Vi saknar det viktigaste tillståndet: "Menade du?" Ange. Ett väldesignat sökgränssnitt bör ge "fuzzy" matchningar. Istället för en kall "0 resultat hittades"-skärm bör vi använda vår metadata för att säga: "Vi hittade inte det i "Elektronik", men vi hittade 3 matchningar i "Tillbehör". Genom att designa för "Kanske" kan vi hålla användaren i flödet. Fallstudie: Kostnaden för "osynligt" innehåll För att förstå varför IA är bränslet försökmotorn måste vi titta på hur data är uppbyggd bakom kulisserna. Under mina 25 år av praktik har jag sett att en sidas "finnbarhet" är direkt kopplad till dess strukturerade metadata. Tänk på ett storskaligt företag som jag arbetade med som hade över 5 000 tekniska dokument. Deras interna sökning gav irrelevanta resultat eftersom "Title"-taggen för varje dokument var det interna SKU-numret (t.ex. "DOC-9928-X") snarare än det mänskliga läsbara namnet. Genom att granska sökloggarna upptäckte vi att användare sökte efter "installationsguide." Eftersom den frasen inte förekom i den SKU-baserade titeln ignorerade motorn de mest relevanta filerna. Vi implementerade ett kontrollerat ordförråd, som var en uppsättning standardiserade termer som mappade SKU:er till mänskligt språk. Inom tre månader sjönk "Exit Rate" från söksidan med 40 %. Detta var inte en algoritmisk fix; det var en IA-fix. Det bevisar att en sökmotor bara är så bra som kartan vi ger den. Den interna språkklyftan Under mina två decennier i UX har jag märkt ett återkommande tema: interna team lider ofta av "Kunskapens förbannelse." Vi blir så nedsänkta i vårt eget företags vokabulär, eller ibland kallat affärsjargong, att vi glömmer att användaren inte talar vårt språk. Jag arbetade en gång med en finansiell institution som var frustrerad över höga samtalsvolymer till deras supportcenter. Användare klagade på att de inte kunde hitta information om "utbetalning av lån" på webbplatsen. När vi tittade på sökloggarna var "utbetalning av lån" den sökta termen nummer 1 som resulterade i noll träffar. Varför? Eftersom institutionens IA-team hade märkt varje relevant sida under den formella termen "Lånfrisläppande". För banken var en "payoff" en process, men en "Loan Release" var det juridiska dokumentet som var "saken" i databasen. Eftersom sökmotorn letade efter bokstavliga teckensträngar, vägrade den att koppla samman användarens desperata behov med företagets officiella lösning. Det är här IA-proffsen måste fungera som översättare. Genom att helt enkelt lägga till "utbetalning av lån" som ett dolt metadata-sökord på sidorna för lånesläpp, löste vi ett supportproblem för flera miljoner dollar. Vi behövde inte en snabbare server; vi behövde en mer empatisk taxonomi. Granskningsramverket för 4-stegs webbplatssökning Om du vill återta din sökruta från Google kan du inte bara "ställa in den och glömma den." Du måste behandla sökning som en levande produkt. Här är ramverket jag använder för att granska och optimera sökupplevelser: Fas 1: "Nollresultat"-revisionen Dra dina sökloggar från de senaste 90 dagarna. Filtrera för alla frågor som gav noll resultat. Gruppera dessa i tre hinkar:
Verkliga luckorInnehåll användaren vill ha som du helt enkelt inte har (en signal för ditt innehållsstrategiteam). Synonym luckor Innehåll du har, men beskrivet i ord som användaren inte använder (t.ex. "Soffa" vs "Soffa"). Formatluckor Användaren letar efter en "video" eller "PDF", men din sökning indexerar bara HTML-text.
Fas 2: Fråga avsiktskartläggning Analysera de 50 vanligaste frågorna. Är de navigerande (letar efter en specifik sida), informativa (letar efter "hur man gör") eller transaktionella (letar efter en specifik produkt)? Ditt sökgränssnitt bör se olika ut för varje. En navigeringssökning ska "snabblänka" användaren direkt till destinationen och helt förbigå resultatsidan. Fas 3: Det "fuzzy" matchningstestet Skriv avsiktligt fel dina topp 10 produkter. Använd pluralformer, vanliga stavfel och amerikansk vs brittisk engelska stavning (t.ex. "Color" vs. "Colour"). Om din sökning misslyckas med dessa tester, saknar din motor stöd för "stamming". Detta är ett tekniskt krav som du måste förespråka för ditt ingenjörsteam. Fas 4: Omfattning och filtrering av UX Titta på din resultatsida. Erbjuder den filter som faktiskt är vettiga? Om en användare söker efter "skor" bör de se filter för storlek och färg. Generiska filter kan vara lika dåliga som inga filter. Återta sökrutan: en strategi för IA-proffs För att stoppa exodusen till Google måste vi gå bortom "Boxen" och titta på byggnadsställningarna. Steg A: Implementera semantiska byggnadsställningar. Returnera inte bara en lista med länkar. Använd din IA för att ge sammanhang. Om en användare söker efter en produkt, visa dem produkten, men visa dem också manualen, FAQs och relaterade delar. Denna "associativa" sökning efterliknar hur den mänskliga hjärnan fungerar och hur Google fungerar. Steg B: Sluta vara bibliotekarie, börjaatt vara en concierge. En bibliotekarie berättar exakt var boken finns på hyllan. En concierge lyssnar på vad du vill uppnå och ger dig en rekommendation. Sökfältet ska använda prediktiv text inte bara för att komplettera ord, utan för att föreslå avsikter. Använda en Google-driven sökfält Att använda ett "Google-drivet" sökfält, som det kan ses på University of Chicagos webbplats, är i huvudsak ett erkännande att en webbplatss interna organisation har blivit för komplex för att dess egen navigering ska kunna hanteras. Även om det är en snabb "fix" för stora institutioner att se till att användarna hittar något, är det i allmänhet ett dåligt val för företag med djupt innehåll.
Genom att delegera sökningen till Google överlämnar du användarupplevelsen till en extern algoritm. Du förlorar förmågan att marknadsföra specifika produkter, du exponerar dina användare för tredjepartsannonser och du tränar dina kunder att lämna ditt ekosystem i det ögonblick de behöver hjälp. För ett företag bör sökning vara en kurerad konversation som guidar en kund mot ett mål, inte en generisk lista med länkar som driver dem tillbaka till den öppna webben.
Checklista för enkel sökning UX Här är en sista checklista som referens när du bygger sökupplevelsen för dina användare. Arbeta med ditt produktteam för att säkerställa att du engagerar dig med rätt teammedlemmar.
Döda återvändsgränden. Säg aldrig bara "Inga resultat hittades." Om en exakt matchning inte finns där, föreslå en liknande kategori, en populär produkt eller ett sätt att kontakta supporten. Fixa "nästan" matchningar. Se till att sökningen kan hantera pluralformer (som "växt" kontra "växter") och vanliga stavfel. Användare ska inte straffas för en tumme. Förutsäg användarens mål. Använd en meny med "autoförslag" för att visa användbara åtgärder (som "Spåra min beställning") eller kategorier, inte bara en lista med ord. Prata som en människa. Titta på dina sökloggar för att se vilka ord människor faktiskt använder. Om de skriver "soffa" och du kallar det "soffa", skapa en bro i bakgrunden så att de hittar vad de behöver ändå. Smart filtrering. Visa bara filter som betyder något. Om någon söker efter "skor", visa dem storlek och färgfilter, inte en allmän lista som gäller för hela webbplatsen. Visa, inte bara lista.Använd små miniatyrer och tydliga etiketter i sökresultaten så att användarna kan se skillnaden mellan en produkt, ett blogginlägg och en hjälpartikel med ett ögonkast. Hastighet är förtroende. Om sökningen tar mer än en sekund, använd en laddningsanimering. Om det går för långsamt går folk omedelbart tillbaka till Google. Kontrollera "misslyckande"-loggarna. En gång i månaden, titta på vad folk sökte efter som gav noll resultat. Det här är din "att-göra-lista" för att fixa navigeringen på din webbplats.
Slutsats: Sökfältet är en konversation Sökrutan är den enda plats på din webbplats där användaren berättar exakt, med sina egna ord, vad de vill ha. När vi inte förstår dessa ord, när vi låter Googles "Big Box" göra jobbet åt oss, förlorar vi inte bara en sidvisning. Vi förlorar möjligheten att bevisa att vi förstår våra kunder. Framgång i modern UX handlar inte om att ha mest innehåll; det handlar om att ha det mest lättillgängliga innehållet. Det är dags att sluta beskatta användare för deras syntax och börja designa för deras avsikt. Genom att gå från bokstavlig strängmatchning till semantisk förståelse och genom att stödja våra sökmotorer med robust, människocentrerad informationsarkitektur kan vi äntligen överbrygga gapet.
