Din webbplatssökning ser “helt okej” ut tills du tittar på inspelningar. Folk trycker på ikonen, tvekar, skriver något, får ingen hjälpsam återkoppling och lämnar. Det värsta är att du kanske aldrig ser det i analytics eftersom misslyckandet sker på några sekunder.
Den här prompten för site search UI är byggd för UX-designers inom e-handel som behöver en sökfältsspec som inte faller ihop på mobil, produktchefer som vill minska avhopp vid “inga resultat” utan att starta en total redesign, och front-end leads som vill ha implementerbara beteenden (tillstånd, tangentbordsflöde, ARIA-etiketter) istället för en snygg mock. Resultatet är en produktionsredo komponentblueprint som täcker placering, storlek, interaktioner, tillgänglighetskrav och valfria förbättringar som förslag och filter när de faktiskt hjälper.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Det du får |
|---|---|---|
|
|
|
Hela AI-prompten: Baymard-stil UI-spec för sökfält för intern sökning
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[PRODUKTBESKRIVNING] |
Ange vilka typer av innehåll användarna ska kunna söka efter, till exempel produkter, kategorier eller annan relevant information. Till exempel: "Produkter, kategorier, blogginlägg och användargenererade recensioner."
|
|
[FORMAT] |
Beskriv om autofullständig-funktion ska ingå och, i så fall, ange eventuella design- eller funktionskrav. Till exempel: "Autofullständig ska visa de 5 främsta resultaten med produktnamn, bilder och priser. Måste stödja tangentbordsnavigering och skärmläsare."
|
|
[KONTEXT] |
Ge detaljer om målgruppen, inklusive sökvanor, förväntningar och eventuella särskilda utmaningar de kan möta. Till exempel: "Användarna är främst mobilshoppare som letar efter kläder. De använder ofta breda sökord och förväntar sig snabba filter för storlek och tillgänglighet."
|
|
[UTMANING] |
Lista eventuella begränsningar eller krav kopplade till plattformen eller tekniken som kan påverka sökfältets design och funktion. Till exempel: "Plattformen använder ett äldre CMS med begränsat API-stöd för dynamisk filtrering. Sökningen måste fungera utan JavaScript som reservlösning för att uppfylla tillgänglighetskrav."
|
|
[PLATTFORM] |
Ange vilka primära enheter användarna kommer att använda för att nå sökfältet, till exempel mobil, dator eller surfplatta, samt relevanta specifikationer. Till exempel: "70 % mobil, 20 % dator och 10 % surfplatta. Mobilanvändare förväntar sig pekvänlig design och responsiva layouter."
|
|
[VARUMARKESTON] |
Definiera ton och stil för varumärkesrösten som ska användas i sökfältets mikrokopior, till exempel platshållartext och felmeddelanden. Till exempel: "Vänlig och lättillgänglig, med ett avslappnat tilltal som "Vad letar du efter i dag?" och "Hoppsan, inga träffar. Försök igen!""
|
Proffstips för bättre resultat från AI-prompten
- Ta med riktiga sökningar, inte gissningar. Klistra in 20–50 senaste sökfrågor på sajten (och några termer som gav “inga resultat”) innan du kör prompten. Fråga sedan: “Utifrån de här sökfrågorna, vilka mönster för förslag och vilken vägledning vid inga resultat minskar misslyckanden?” Du får skarpare UI-beteenden än om du bara beskriver din katalog i generella termer.
- Tvinga fram mobile-first-beslut tidigt. Berätta för modellen vad “mobil header” betyder hos er (sticky header, kollapsad navigation, iOS Safari-särdrag, osv.). En bra följdfråga är: “Ta fram reglerna för mobillayouten först (tryckytor, spacing, när söket expanderar) och mappa sedan samma komponent till desktop.”
- Be om tydliga tillstånd och triggers. Acceptera inte “visa förslag” som en vag punkt. Kräv detaljer: “Lista varje tillstånd (inaktivt, i fokus, skriver, laddar, förslag öppna, fel, inga resultat) och triggern som flyttar mellan dem, inklusive timeouts och debounce-beteende.”
- Iterera med extremer för att minska risk i edge cases. Efter första utkastet kan du fråga: “Få nu UI-specen att fungera för enhandsanvändning på en 6,1-tums telefon och också för navigering enbart med tangentbord på desktop.” De två passen avslöjar snabbt problem med spacing, fokusordning och synlighet.
- Koppla UI-specen till QA-acceptanskriterier. Be modellen göra om blueprinten till testbara kontroller: “Skriv om detta som QA-acceptanskriterier för design + front-end, inklusive tillgänglighetskontroller (synlig fokusmarkering, SR-etiketter, kontrast).” Det är ärligt talat det här steget som gör ett snyggt dokument till något team faktiskt levererar.
Vanliga frågor
UX/UI-designers använder den för att göra om feedbacken “gör söket bättre” till konkreta komponentkrav, inklusive tillstånd och mobilbeteende. Produktchefer använder den för att få intressenter överens om scope (enkel standard vs förslag/filter) och för att undvika ändlösa subjektiva diskussioner. Front-end-utvecklare har nytta av den eftersom prompten ger implementerbara interaktionsregler, tillgänglighetsdetaljer och hur man undviker felutfall, inte bara visuella förslag. CRO- och e-handelsansvariga använder den för att minska avhopp från sök och standardisera ett mönster med hög konvertering över olika mallar.
E-handel-team använder den när stora kataloger och liknande produktnamn skapar tvetydighet, vilket gör förslagsbeteende och vägledning vid inga resultat viktigt. Marknadsplatser får värde eftersom sök ofta är primär navigering, och små UX-missar (dold ingång, svag tydlighet, dåliga tryckytor på mobil) påverkar GMV snabbt. Dagligvaror och CPG direct-to-consumer-varumärken gynnas när användare söker på varumärke, ingrediens eller kosttermer, vilket ökar felstavningar och behovet av “nära match”. B2B-delar och industriella leverantörer använder den för att hantera SKU-liknande sökningar och för att säkerställa att inmatningsupplevelsen är tydlig, tillgänglig och förlåtande på olika enheter.
En typisk prompt som “Designa ett sökfält för min webbutik” misslyckas eftersom den: saknar Baymard-anpassade begränsningar (placering, tydlighet, låg friktion) som förhindrar vanliga UX-felutfall; inte ger någon tillståndsmodell, så du får ett statiskt UI istället för beteenden för fokus, laddning, förslag och inga resultat; ignorerar tillgänglighetskrav som tangentbordsnavigering och skärmläsarmärkning; ger generisk text- och ikonvägledning istället för specifika “undvik detta”-regler (låg kontrast, vaga placeholders, för små tryckytor); och missar discovery-steget som klargör scope, enheter och autocomplete-förväntningar innan specifikationen skrivs.
Ja. Prompten är byggd för att pausa och ställa discovery-frågor om något viktigt saknas, så du kan “anpassa” genom att svara med verkliga begränsningar (katalogstorlek, innehållstyper, mobilheaderns beteende och förväntningar på autocomplete). Du kan också styra output genom att lägga till egna krav direkt, som “sök måste stödja produkter + hjälpartiklar” eller “headern är sticky och sök startar som en ikon på mobil.” När du fått första specen, fråga: “Skriv om komponentblueprinten för vårt exakta brytpunktsystem (360/768/1024/1440) och inkludera acceptanskriterier för QA.”
Det största misstaget är att svara luddigt på discovery-frågorna: istället för “Vi säljer kläder” säg “Vi säljer 8 000 SKU:er inom dam/herr/barn, med frekventa färg-/storleksvarianter och många varumärkessökningar.” Ett annat vanligt fel är att hoppa över enhetsdetaljer; “mobilvänlig” är för svagt, men “sticky header, prioritet på tumräckvidd, iOS Safari, söket expanderar till full bredd vid tryck” ger modellen något som går att bygga. Team glömmer också att specificera innehållsscope, vilket leder till fel förslagslogik; “bara produkter” kontra “produkter + kategorier + hjälpartiklar” ändrar UI-beteendet. Till sist behandlar många tillgänglighet som en checkbox; be om tydlig tangentbordsordning, regler för fokusmarkering och exempel på ARIA-etiketter så att specen håller hela vägen till implementation.
Den här prompten är inte optimal för team som söker design av back-end ranking eller retrieval-algoritmer, eftersom den medvetet fokuserar på UI och beteende. Den passar inte heller perfekt om du bara vill ha en snabb visuell mock utan interaktionsdetaljer, eller om du inte har verifierat att sök är en meningsfull användarväg på din sajt. Om ditt huvudproblem är datakvalitet i katalogen eller taxonomi, börja med att fixa flöden, attribut och kategorilogik och använd sedan den här prompten för att göra sökgränssnittet enklare att använda.
Intern sökning behöver inte vara flashig. Den måste vara uppenbar, förlåtande och tillgänglig, med beteenden som förhindrar återvändsgränder. Klistra in den här prompten i din modell, svara på discovery-frågorna och få en sök-UI-spec som teamet faktiskt kan implementera.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.