prototype

star 4

Utforsk designkonsepter visuelt med Aksel-tema i nettleser, og lever som Figma-skisse. Brukes via /prototype når et konsept skal visualiseres.

navikt By navikt schedule Updated 6/10/2026

name: prototype description: "Utforsk designkonsepter visuelt med Aksel-tema i nettleser, og lever som Figma-skisse. Brukes via /prototype når et konsept skal visualiseres."

Prototype — fra konsept til synlig skisse

Utforsk designkonsepter interaktivt i nettleseren, iterer med designeren, og lever som Figma-skisse med ekte Aksel-komponenter.

Når brukes denne?

  • Designer vil se et konsept visuelt (ikke bare beskrevet)
  • Variant-sammenlikning for å velge retning
  • Rask validering av layout, hierarki eller flyt
  • Situasjonsdesign — vis alle situasjoner brukeren kan møte

Når gå rett til Figma (hopp over Fase 1)

  • Du itererer videre på et eksisterende Figma-design
  • Oppgaven er detaljjustering eller finpuss (spacing, farger, typografi)
  • Designeren allerede vet hva de vil og trenger Figma-komponenter
  • Komponentbygging og produksjonsnære leveranser

Visual Companion er best for tidlig utforsking — når retningen er uklar og du vil se 2-3 konsepter raskt. Når retningen er valgt, gå rett til Figma.

Fase 1: Visuell utforsking (Visual Companion)

Interaktivt nettleserverktøy for å utforske designkonsepter med Aksel-styling.

Forutsetninger

  • Node.js ≥ 18 (for HTTP-server)
  • @navikt/ds-css i node_modules — KREVES for ekte farger; uten den blir alt fargeløst/klint
  1. Sørg for at avhengigheter er installert (kreves for Aksel CSS):
    [ -d node_modules/@navikt/ds-css ] || pnpm install
    
  2. Start serveren:
    node .github/skills/prototype/scripts/server.js --project-dir .
    
  3. Les startup-JSON fra stdout — den inneholder url, screen_dir, state_dir
  4. Gi designeren URL raskt; for eksisterende flater først etter verifisert før/etter

Eksisterende flate: nåtilstand først

Klassifiser selv. Bruk issue-/oppgavetekst når det finnes; ellers bruk prompt, side-/rutenavn, komponentnavn og appkontekst. Endring/forbedring/ny komponent på kjent side = eksisterende flate. Ved tvil, anta eksisterende flate.

For eksisterende løsning er dette en gate før første visuelle forslag, også ved Figma/chat:

  1. Hent faktisk side med Playwright/lokal app først; alternativt Figma, demo-URL eller manuelt skjermbilde.
  2. Verifiser riktig side og fjern/stubb lokal cookie-, login- og modalstøy før screenshot.
  3. Vis før/etter med samme viewport, data og sidekontekst; forklar hva som er endret og uendret.
  4. Åpne Visual Companion selv før deling og sjekk at skjermbilder laster (naturalWidth > 0).
  5. Aldri rekonstruer eksisterende side fra kode og presenter den som nåtilstand.

Tilby visual companion

Spør designeren én gang om nettleservisning når innholdet er visuelt. Hvis nei — jobb kun med tekst og Figma.

Bestemme per spørsmål: nettleser eller chat?

Bruk nettleser når innholdet er visuelt: wireframes, mockups, layout-sammenlikninger, side-by-side-varianter og komponenteksempler. Bruk chat for kravspørsmål, scope, konseptuelle valg og avveininger.

Skrive innhold

Skriv HTML-fragmenter til screen_dir. Serveren wrapper automatisk i Aksel-temat og laster ekte @navikt/ds-css fra prosjektets node_modules.

VIKTIG — Aksel-korrekthet:

Før du skriver en HTML-mockup, sjekk alltid /aksel-design skill for:

  • Riktige komponentnavn og struktur
  • Korrekt spacing (token = pixelverdi, f.eks. --ax-space-16 = 16px)
  • Korrekt fargebruk (--ax-bg-*, --ax-text-*, --ax-border-*)

Bruk ekte .aksel-*-markup fra references/aksel-markup-fasit.md — generert fra @navikt/ds-react (ds-reacts egen DOM), rendrer autentisk Aksel via ds-css. Frame-malen setter rot-konteksten (data-color="accent") som gjør primærknapper blå. .mock-* er kun for ikke-Aksel-stillas. Fargene ligger i CSS-en (data-color/data-variant), ikke i JS.

Tokens i v8: --ax-space-{px} (f.eks. --ax-space-16 = 16px, --ax-space-24 = 24px). Radius: --ax-radius-4, --ax-radius-8, --ax-radius-12.

Se references/visual-companion.md for alle CSS-klasser og eksempler.

Regler:

  • Semantiske filnavn: konsept-a.html, layout-v2.html
  • Aldri gjenbruk filnavn
  • 2–4 alternativer per skjerm
  • Forklar spørsmålet på siden: «Hvilken tilnærming passer best?»
  • Skaler fidelitet etter spørsmålet — wireframe for layout, detaljer for detaljer
  • Norske tegn (æ/ø/å) direkte som UTF-8 — aldri \u00f8-escapes; serveren skriver ordrett, så escapen blir synlig tekst i skissen («m\u00f8te» i stedet for «møte»)

Les brukervalg

Etter at designeren har sett skjermen:

  1. Les $STATE_DIR/events for klikk-data
  2. Kombiner med designerens tekstrespons
  3. Iterer eller gå videre

Variant-utforskning

  1. Lag 2–3 varianter som valgalternativer på skjermen
  2. Spør: «Hvilken variant foretrekker du?» med beskrivende navn
  3. Iterer på valgt variant
  4. Når konseptet er valgt — gå til Fase 2

Situasjoner brukeren møter

Vis ulike situasjoner som separate mockups eller sekvens: normal, venter (lasting), feil, tom tilstand, og ferdig/bekreftelse.

Fase 2: Figma-leveranse

Når konseptet er valgt, bygg en Figma-skisse av den valgte varianten.

Krav

Figma MCP-verktøy tilgjengelig.

Flyt

  1. whoami → finn planKey
  2. create_new_file → opprett fil, del URL når relevant kontekstgate er passert
  3. search_design_system → finn relevante Aksel-komponenter
  4. use_figma preflight → importer + logg varianter, default-variant, tekst-node-navn og fonter (se referanse)
  5. use_figma → bygg skissen inkrementelt, én seksjon per kall med eksakte variant-navn og node-navn fra preflight
  6. get_screenshot → parity-gate: sammenlign mot Visual Companion-fasiten (se referanse for sjekkliste)
  7. Fiks eventuelle problemer, del oppdatert lenke ved milepæler

Sjekk katalogen først — den er fasiten. Alle 45 aktive Aksel-komponenter har key, akser, defaults, tekst-noder og feller ferdig uttrukket i references/aksel-figma-katalog.json (maskinlesbar kilde) og .md (lesbar). For layouten rundt komponentene (luft, farger, kanter, typografi) bruk references/aksel-figma-tokens.md. Drift-validert — hopp over preflight for det katalogen dekker. Detaljer i references/figma-prototype.md.

Komponenten (ikke hele siden) er enheten du bygger — men for eksisterende flater gir du kontekst via bakgrunn + redigerbar overlay: skjermbilde av den ekte siden med et injisert tomt felt, og den redigerbare komponent-instansen plassert oppi (se references/figma-prototype.md). Aldri håndkod en tilnærming av modulen inn i skjermbildet — det gir drift; den ekte komponenten er eneste fasit. Lever tilstander som én variant-komponent (Tilstand-akse), ikke løse statiske rammer, og slå sammen nesten-like tilstander.

Komponent-gate

Før du bygger i Figma, søk Aksel-biblioteket:

search_design_system(query: "<komponentnavn>", fileKey: "<key>")

Finnes komponenten? → Bruk den. Finnes den ikke? → Bygg custom, men med Aksel-tokens.

Komponent-instansiering

  • Preflight først: importer + logg varianter, default og tekst-noder i ETT kall
  • Bygg inkrementelt: ett use_figma-kall per seksjon (atomisk — én feil ruller tilbake hele kallet)
  • defaultVariant er ofte feil: GlobalAlert/LocalAlert=Error, Tag=Neutral, Checkbox=unchecked. Antall barn (RadioGroup/Accordion/Tabs) er også en variant-akse — velg bevisst
  • Tekst via findOne/findAllWithCriteria med eksakt name (ikke setProperties() for tekst); les font med loadFontAsync(node.fontName) — Aksel = Source Sans 3
  • Komposisjon: søknadssteg→FormProgress; bygg Table fra Table cell; skjul Slot-placeholdere; layoutSizingHorizontal="FILL" kun etter append; farger via search_design_system — aldri gjett RGB
  • Leveranse: samle tilstander i én variant-komponent (Tilstand-akse) via combineAsVariants — Figma- og Figma Make-vennlig. For sidekontekst: skjermbilde-bakgrunn + redigerbar overlay (aldri håndkodet modul i bildet). Se references/figma-prototype.md

Se references/figma-prototype.md for fullstendige regler og eksempler.

Valgfritt: Kodeprototype (opt-in)

Fra skisse til ekte, klikkbar kode med @navikt/ds-react og mockdata — kjørbar lokalt og i demo. Tilbys etter et Visual Companion- og/eller Figma-resultat når retningen er valgt.

Designer-agenten skriver aldri kode selv. Spør «Skal jeg få bygget dette som en klikkbar prototype med mockdata?» og deleger til konditor med disse rammene:

  • Ekte Aksel-komponenter + alle tilstander (normal/lasting/feil/tom/ferdig)
  • Kun mockdata (fixtures/MSW) — ingen ekte API-er, PII, secrets eller accessPolicy
  • Egen prototype/*-branch, aldri main/prod, merket «prototype – ikke for prod»
  • Kjørbar lokalt + efemert demo-miljø; utviklere tar over for ekte data og UU-live-review før prod

Etter bygging: del demo-lenke/branch. Tilby Issue så utviklerne tar prototypen videre.

Iterasjon

Vis resultat → designer gir feedback → juster → gjenta til fornøyd.

UU, opprydding og degradation

  • Sjekk kontrast og semantikk i designet. Full WCAG: /accessibility-review ved overlevering.
  • Etter leveranse: server.js --project-dir . --cleanup fjerner .visual-companion/.
  • Uten Figma MCP → beskriv konseptet, lever som Issue.
  • Uten Node.js → Chat + Figma direkte (hopp over Visual Companion).
  • Uten Playwright → manuelt skjermbilde fra designer.

Boundaries

✅ Alltid

  • Bruk Aksel-komponenter og -tokens
  • Returner URL / Figma-lenke for resultater
  • Bruk handlingsspråk — aldri verktøynavn
  • Spør designer før større endringer
  • Del lenker raskt; for eksisterende flater først etter verifisert nåtilstand/før/etter

🚫 Aldri

  • Skriv kode i prosjektets kildekode (deleger til konditor)
  • Lever kodeprototype til main/prod eller mot ekte data — kun prototype/*-branch med mockdata
  • Eksponer verktøynavn til designeren
  • Feilsøk build-problemer (fall tilbake til neste metode)
  • Hopp over UU-sjekk ved leveranse
Install via CLI
npx skills add https://github.com/navikt/crm-ips --skill prototype
Repository Details
star Stars 4
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator