Hvornår et design system betaler sig — og hvornår det er en mappe

Et design system, I ikke har besluttet, koster uger I ikke ser på en sprint-tavle. Hver ny side genåbner farve, spacing og 'er det her knappen?'. Designeren tegner. Udvikleren gætter. Review handler om pixels, ikke om om produktet er rigtigt. I tror I er langsomme til at bygge. I er langsomme til at blive enige om det, I allerede har bygget.

Teams køber den forkerte medicin. De ser et slide med tokens, theming og 'governance', og tegner et system-projekt oven på et site, der stadig skifter budskab hver anden uge. Eller de gør det modsatte: de har ingen kontrakt, så hver landing er et unikt sæt. Begge dele koster. Den ene i teater. Den anden i at I aldrig kan skifte en farve ét sted.

Det er også et performance- og SEO-spørgsmål, ikke kun et æstetik-spørgsmål. Tre forskellige knap-implementeringer er tre steder I kan glemme fokus, kontrast og den state, en crawler og en skærmlæser skal kunne. Et ærligt sæt komponenter er kedeligt — og det er derfor det holder. Variation, I ikke har besluttet, er den stille måde et Next.js-site bliver tungt og ulogisk på.

Vi skriver det, fordi 'design system' er blevet et køb, I tager før I har en sætning om hvad der må variere. Et ærligt setup er kedeligt: en farveskala, en type-skala, otte-punkt spacing, tre knap-varianter, og et navn der må sige nej. Uden den sætning har I Storybook. I har ikke et system, I kan skifte rebrand på.

Et design system er de beslutninger, UI'et skal overholde, skrevet så både Figma og koden kan læse dem. Tokens er navngivne værdier: farve, type, spacing, radius, skygge. Komponenter er de få mønstre, I har sagt ja til. Dokumentation er den sætning, der forklarer hvornår I bruger den primære knap, og hvornår I ikke gør. Ejerskab er hvem der må tilføje en fjerde.

En component library er en mappe af komponenter. Den kan være rigtig. Den er ikke et system, før tokens og nej-retten findes. I kan have 40 komponenter og stadig opfinde den 41. I kan have fire og være færdige, hvis de fire er de eneste, I tillader på et marketing-site.

Storybook er et sted at se komponenterne. Det er nyttigt, når I har noget at vise. Det er teater, når I starter med Storybook-setup og 'addon-docs', før I har besluttet om knappen har en loading-state. Et galleri uden kontrakt er hvordan I får et pænt intern-site, produktion aldrig bruger.

Og det er ikke et theme I køber. Tailwind, shadcn, Radix, Polaris, Carbon — de er startkits og primitives. De giver jer et sprog. De giver jer ikke jeres beslutninger. 'Vi bruger shadcn' er en afhængighed. 'Vi har tre knapper, de her tokens, og den her person siger nej' er et system. Det første kan I installere en eftermiddag. Det andet kan I ikke købe.

Den første fejl er at starte systemet, før produktet har et ansigt. I bruger uger på tokens og 'foundations', mens H1 og tilbuddet stadig skifter. Så bygger I et library til et produkt, I ikke har. Når budskabet lander, passer komponenterne ikke, og I har et system, I skammer jer over at åbne. Tre ærlige blokke på et MVP slår et library, I aldrig tør slette.

Den anden fejl er Storybook som bevis. I kan vise 20 states. Produktion bruger tre, og de tre er kopieret ind i siderne alligevel, fordi 'det var hurtigere'. Et library, siderne ikke importerer, er et internt site. Mål systemet på om en ny landing kan samles af det, I allerede har — ikke på om docs-sitet er pænt.

Den tredje fejl er at kopiere et stort systems API og kalde det jeres. Polaris er bygget til Shopify. shadcn er bygget til at I selv tager stilling. Hvis I lader alle varianter ligge 'så vi er dækket ind', har I et katalog, ingen kender. Et lille team dør af valg. Skær væk, indtil I kan nævne komponenterne uden at åbne en mappe.

Den fjerde fejl er at lade hver side være en undtagelse. 'Den her kampagne skal ligne noget andet'. 'Footer på den side er speciel'. Efter et halvt år har I et system på papiret og et unikt site i produktion. Undtagelsen skal have en ejer og en slutdato — ligesom et feature flag. Ellers er undtagelsen blevet produktet.

Et marketing-site i Next.js kan leve længe på et ærligt sæt: heading, sektion, kort, formular, CTA. Det er et system, selv om I ikke kalder det et. Det bliver et problem, når kampagnesider begynder at medbringe deres egne knapper, eller når WordPress-rester og den nye App Router-side ikke deler tokens. Så er det ikke 'lidt variation'. Det er to brands på ét domæne.

En app ved siden af sitet — portal, checkout, admin — er det tidspunkt, systemet typisk begynder at betale sig. To flader, to teams eller to tempoer, og uden tokens I deler, divergerer I på en måned. Her er en fælles knap og en fælles type-skala ikke pynt. Det er den eneste måde en kunde kan tro, at login og forsiden er samme firma.

Et MVP på typisk 8–14 uger skal finde produktet. Et fuldt system-projekt i den periode er hvordan I bygger et library til et UI, I skrotter. Tag tre komponenter, I tør slette. Tag tokens, hvis I allerede ved, at app og site skal ligne hinanden. Tag ikke 'design-ops', fordi et slide sagde, at rigtige teams har et system fra dag ét.

Hvis I overvejer at skifte stack 'for at få et system', så vær ærlige: I skifter sted, beslutningen kan sidde. Et WordPress-tema med tre child-overrides er heller ikke et system. Et Next.js-site med hex'er i 20 filer er det samme rod med et andet badge. Skift stak hvis I også har andre grunde. Skift ikke fordi et kit lovede, at komponenter er gratis konsistens.