11 dec. 2025·5 min
Konsekvent UI i React-appar med designtokens och regler
Lär dig promptteknik för konsekvent UI i React-appar med designtokens och komponentregler så att AI-genererade skärmar matchar mellanrum, typografi och formulärbeteende.
Lär dig promptteknik för konsekvent UI i React-appar med designtokens och komponentregler så att AI-genererade skärmar matchar mellanrum, typografi och formulärbeteende.
UI-inkonsekvens visar sig ofta i små detaljer som känns fel när du klickar runt. En sida har generös padding, en annan känns trång. Rubriker hoppar mellan storlekar, knappar ändrar form och färg, och samma input beter sig olika beroende på skärm.
För det mesta kommer driften från några grundläggande saker:
Detta är vanligt när skärmar genereras från separata prompts. Varje prompt är i praktiken en nystart, så modellen fyller i saknade beslut genom att gissa. Även “använd modern styling” lämnar hundratals små val: 8px vs 12px gap, 14px vs 16px brödtext, när visa fel, hur en primär knapp ser ut.
Du kan manuellt fixa två eller tre sidor, men det skalar inte. Du hamnar i att jaga engångs-CSS-justeringar, kopiera stilar mellan filer och fixa formulär igen. Reglerna finns i huvudet, inte i projektet.
Föreställ dig att du genererar en inloggningsskärm idag och en profilsida imorgon. Om den ena visar fel bara vid submit men den andra visar fel vid blur, märker användarna det. Om primärknappens höjd ändras mellan skärmar känns appen hopklistrad.
Konsekvens blir standard när varje skärm följer samma delade system: designtokens (mellanrum, typografi, färg) plus en liten uppsättning komponent- och formulärregler.
Designtokens är enkla namngivna värden du återanvänder i hela UI:t. Istället för att be om “bekväm padding” på varje skärm använder du en token som space-4. Istället för “lätt rund” använder du radius-md. Namnet förblir stabilt även om du senare ändrar vad det mappar till.
Tokens är de beslut du vill att varje skärm ska dela. De tar bort smak och gissningar, vilket är precis vad som orsakar drift när du genererar eller bygger nya sidor.
Typiska tokens täcker mellanrum, typografi, färger, form och en liten mängd elevation. Vinsten är praktisk: en header använder alltid samma storlek, ett kort alltid samma padding, och en primär knapp behåller samma färg och radie.
Tokenisera det som påverkar produktens övergripande känsla: mellanrumsskala, fontstorlekar och radavstånd, kärnfärger (text, bakgrund, primär, danger, kant) och ett litet set av kant-radier.
Behåll innehållsdrivna val flexibla, som textlängd, vilken ikon som används eller om en sektion behöver två eller tre kort.
När du genererar skärmar (även med verktyg som Koder.ai) minskar en liten tokenmängd uppfront mängden gissningar och gör output märkbart mer konsekvent.
En tokenmängd är bara en kort meny av tillåtna värden. Mindre är bättre eftersom det lämnar mindre utrymme för slumpmässiga val, men den behöver fortfarande täcka det som gör att skärmar känns fel.
Börja med mellanrum. Välj en skala och använd den överallt för padding, gap och layout. Ett set som 4, 8, 12, 16, 24, 32 täcker de flesta UI. Om en design kräver 10px eller 18px, avrunda till närmaste token istället för att införa nya tal.
Definiera sedan typografiska standarder så rubriker och brödtext slutar drifta. Du behöver inte ett jättestort typsystem. Du behöver tydliga, upprepbara steg.
Ett kompakt set som förblir användbart utan att bli uppblåst:
Tillgänglighet hör också hemma i systemet. Definiera en fokus-outline-stil (färg, tjocklek, offset) så tangentbordsanvändare får konsekventa fokus-tillstånd. Sätt ett minimalt tappmål (som 44x44) för mobil. Begränsa textfärger till ett litet, betrott set för att hålla kontrasten förutsägbar.
Om knappar ibland känns trånga är det ofta för att en skärm använde padding 10 och en annan 12. Med tokens kan du säga: “Knappar använder paddingY=8, paddingX=16, radius=12, fokus-token, minhöjd 44.” När de siffrorna är fasta slutar generatorn improvisera.
Tokens sätter siffrorna. Komponentregler sätter vanorna.
Välj en liten uppsättning kärnkomponenter och behandla dem som de enda byggstenarna för skärmar. Håll dem tråkiga och återanvändbara: Button, Input, Select, Checkbox, Card. Du kan lägga till TextArea och Modal, men de bör följa samma system (etiketter, mellanrum, tillstånd).
Begränsa sedan varianter och definiera när de är tillåtna. Till exempel: Button har primary, secondary och danger. Primary är för huvudåtgärden på skärmen (vanligtvis en). Secondary är för avbryt eller lågt prioriterade åtgärder. Danger är endast för destruktiva åtgärder som radera. Om varianten inte kan motiveras, standardisera till secondary.
Mellanrumsregler förhindrar subtil drift. Definiera standarder inuti komponenter: knapp-padding, input-höjd, gap mellan etikett och fält, standardgap mellan staplade fält. Lägg även till några layoutr regler: Cards har fast intern padding och konsekvent header/body-avstånd; Modals använder samma breddsteg och footer-justering.
Slutligen, gör tillstånd icke-förhandlingsbara eftersom det är här UI ofta börjar se slumpmässigt ut:
När du genererar ett formulärtungt flöde som “Create project” förhindrar dessa regler blandade knappstorlekar, skiftande etikettpositioner eller ett engångs-“special”-kort som bara dyker upp på en sida.
Även med stabil visuell stil kommer många “det känns fel”-klagomål från formulärbeteende. Om varje skärm hanterar etiketter, fel och fokus olika upplevs det som inkonsekvent.
Välj ett formulärmönster och använd det överallt: etikett, optional/required-markör, hjälptext, sedan feltext. Håll också ordvalet konsekvent (till exempel mening-stil för etiketter, kort hjälptext och felmeddelanden som börjar med ett verb).
Reglerna som förhindrar mest drift:
Lås storlek och layout så skärmar inte “andas” olika. Definiera en input-höjd, en knapphöjd och en standardfältbredd. På desktop, justera fält till ett konsekvent grid och stapla etiketter ovanför inputs. På mobil, gör fälten fullbredd och undvik tvåkolumnsformulär om det inte är nödvändigt.
Ett enkelt exempel: en “Create project”-skärm kan ha Name, Region och Description. Även om Region är en select, behandla den som vilket fält som helst: samma höjd, samma etikettposition, samma felrad. Om användaren skickar med tomt Name flyttar fokus till Name, felet visas under det och layouten förblir stabil.
Om du genererar skärmar i Koder.ai, lägg dessa formulärregler i din prompt en gång och återanvänd dem över features så varje nytt formulär beter sig likadant utan upprepade fixar.
Behandla din prompt som ett litet UI-kontrakt. Håll den kort, specifik och återanvändbar så varje ny skärm snappar till samma mellanrum, typografi, komponenter och beteenden.
Ett praktiskt mönster är att klistra in en kompakt UI-spec högst upp i din förfrågan, och sedan beskriva skärmen i vanligt språk.
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
Efter specen, lägg till några acceptanskontroller som fångar drift tidigt:
Om du använder en chattbaserad generator, håll den här specen stabil över förfrågningar. Att ändra den varje gång motverkar syftet.
Skriv UI-kontraktet innan du genererar något: ett litet token-set (mellanrum, typ, färger, radier, skuggor) plus ett kort komponent-inventarium (Button, Input, Select, Card, Modal, Table, Toast). Om en token eller komponent saknas kommer modellen att uppfinna en och ditt UI kommer att driva.
Skapa sedan en referensskärm som använder reglerna. En formulärtung sida är ett bra stresstest eftersom den inkluderar rubriker, hjälptext, valideringsfel, primär- och sekundärknappar och en succestoast. Behandla den skärmen som baseline.
Bygg nya skärmar genom att komponera vad du redan definierat. Be inte om “ny styling.” Be om samma Card, samma mellanrumsskala, samma typografiska steg och samma fältmönster.
Ett enkelt arbetsflöde:
Om en “Search users”-skärm får tightare mellanrum än referensen, tweak inte marginals manuellt. Uppdatera spacing-tokens eller Card-padding-regeln en gång, och generera om.
Om du arbetar i Koder.ai kan snapshots och rollback hjälpa här: lås en baseline, experimentera säkert och återställ snabbt om en ändring börjar introducera drift.
Det snabbaste sättet att tappa konsistens är att behandla tokens och regler som förslag. Små undantag multipliceras över nya skärmar.
En vanlig fälla är att ändra mellanrumsskalan mitt i projektet. Tidiga skärmar använder 8, 16, 24. En ny skärm introducerar 10 och 18 “för att det ser rätt ut.” Nu tillåts drift, och gamla skärmar uppdateras aldrig.
En annan driftkälla är att låta generatorn uppfinna nya komponentstilar. Om du inte säger “bara dessa knappvarianter existerar” kan den skapa en ny radie eller annan input-padding på en skärm.
Tillstånd är ytterligare ett frekvent miss. Loading, empty och error-tillstånd förändrar ofta mellanrum och beteende. Om du lägger till dem i efterhand får du ofta stressade mönster som inte matchar resten.
Håll också koll på fel typ av specificitet: “gör det modernt med mjuka skuggor” är vagt, medan beteenderegler som “fel visas under fältet”, “inaktiverade knappar behåller fokus-stilar” och “Enter skickar endast på sista fältet” är konkreta och upprepbara.
Om du vill ha ett lättviktigt styrblock att klistra in i prompts, håll det kort:
Innan du mergar en genererad skärm, gör en tvåminutersgenomgång.
Börja med mellanrum. Leta efter slumpmässiga värden som 13px eller one-off-marginaler som lagts till “bara för att det ska passa.” Om du använder tokens ska varje gap komma från det godkända setet, inklusive gutters, card-padding och mellanrum mellan formulärfält.
Kontrollera sedan typografin mot din typskala. Rubriker ska stega ner förutsägbart. Brödtext ska inte byta storlek mellan liknande sektioner. Radavstånd spelar också roll, särskilt på täta sidor som inställningar.
Skanna knapparna nästa. Varianter och storlekar ska följa dina regler: primär för huvudåtgärden, sekundär för mindre viktiga åtgärder, danger bara när det verkligen raderar. Knapphöjd, ikonplacering och etikettstil ska matcha.
För formulär handlar konsistens mest om struktur. Etiketter stannar på en plats, required-indikatorer följer en regel, hjälptext och fel konkurrerar inte, och fel visas på ett konsekvent ställe.
En kort checklista:
Gör slutligen en snabb mobilpass. Krymp bredden och bekräfta att layouten anpassar sig utan att uppfinna nya fontstorlekar eller mellanrum.
Föreställ dig ett enkelt onboardingflöde: tre skärmar (Profile, Preferences, Confirm), plus en inställningssida senare. Du vill att varje skärm ska kännas som den kom från samma designer, även om de genererades i separata körningar.
Innan du genererar något, tillhandahåll ett litet token-set och några komponentregler:
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
Generera nu “Profile” och “Preferences” separat. Eftersom båda skärmarna måste använda Page, Card, Field och Button row som definierats, får de samma marginaler, etikettmellanrum och knappplacering. Confirm-steget passar fortfarande, även om det har mer read-only-text.
Formulärbeteende är där drift ofta smyger in, så definiera det en gång och återanvänd det: submit inaktiverad tills giltig, inlinefel bara efter blur eller submit, Enter skickar bara på sista steget, och Back-knappen rensar aldrig redan ifyllda värden.
När du behöver en ny UI-del, låt inte modellen improvisera. Lägg till en regel och generera om med återanvändning i åtanke:
Gör tokens och regler till en återanvändbar spec du faktiskt använder. Om den är för lång för att klistras in, kommer den inte att följas.
En praktisk spec innehåller vanligtvis: din token-tabell (mellanrum, typ, radier, färger), ett kort komponentregelset (knappar, inputs, cards, rubriker), formulärbeteenderegler (valideringstidpunkt, fel, disabled/loading), layoutstandarder (sid-padding, maxbredd, sektionavstånd) och en kort “gör aldrig så här”-lista (slumpmässiga marginaler, ad-hoc fontstorlekar).
Gör sedan en vana: uppdatera specen först, inte individuella pixlar.
Om du använder Koder.ai (koder.ai), är planning mode en bra plats för att upprepa och bekräfta specen innan du genererar UI. När du vill prova alternativ hjälper snapshots och rollback dig att utforska utan att förlora en stabil baslinje.
Eftersom varje skärmförfrågan är en nystart. Om du inte tillhandahåller ett delat system fyller generatorn i saknade detaljer genom att gissa—mellanrum, typsnittsstorlekar, knapp-padding, skuggor och formulärbeteende—så små skillnader byggs upp över sidor.
Design tokens är namngivna, återanvändbara värden för saker som mellanrum, typsnittsstorlekar, färger och radier.
Istället för “bekväm padding” använder du något som space-md. Namnet förblir stabilt och varje skärm återanvänder samma beslut så UI:t slutar att driva.
Börja litet och täck bara det som orsakar synlig drift:
Sätt ett kompakt UI-spec-block högst upp i varje förfrågan och behandla det som ett kontrakt:
Beskriv skärmen under det. Nyckeln är att hålla specen oförändrad över skärmar.
Tokens definierar siffrorna; komponentregler definierar vanorna. Användbara regler inkluderar:
Standardregel: om en variant inte kan motiveras, återgå till standarden.
Välj ett mönster och använd det överallt:
Detta undviker det vanliga problemet att “en skärm validerar på blur, en annan bara vid submit”.
Definiera några icke-förhandlingsbara state-regler:
Om du inte specificerar states kommer varje skärm tendera att uppfinna egna mönster.
Låt det inte improviseras. Lägg till det som en dokumenterad utökning av ett befintligt mönster:
Om du inte kan beskriva den med tokens är den oftast för anpassad och kommer orsaka drift.
Skapa en “referens”-skärm som stressar systemet (en formulärtung sida fungerar bra), återanvänd sedan samma spec för varje ny skärm.
I Koder.ai kan du använda planning mode för att upprepa och bekräfta specen innan du genererar, och använda snapshots and rollback för att behålla en stabil baslinje medan du experimenterar.
Gör en snabb kontroll innan du accepterar skärmen:
Om något är fel, uppdatera specen/tokens och generera igen—patcha inte one-off-marginaler.
Om du behöver ett “nytt” värde, avrunda till närmaste token istället för att uppfinna 10px eller 18px.