Q&A
(26.11.25) Spørsmål: Hvorfor gikk dere bort ifra å ha chips inne i MultiSuggestion?
Svar: Vi gikk bort fra chips inni input, fordi vi så at det i mange tilfeller ble inputs som veldig raskt økte i høyden, og dermed ble litt store og klumpete elementer. Videre så vi noe forvirring med fokus-markering rundt alle chips når input har fokus. Chip kan ikke ikke ligge inni input uansett, men man kan klart endre så selve suggestion rendrer som en input. Kanskje noe å vurdere som en variant i fremtiden.
(17.11.25) Spørsmål: Det er en ganske kraftig markering på inputfelt når de er aktive. Vi vurderer å endre på denne men ville høre hvorfor dere har valgt denne markeringen?
Svar: Vi har valgt denne markeringen for å oppfylle kravene til synlig fokus (2.4.7) samt kontrastkravene i 1.4.11. I tillegg følger markeringen noen AAA-suksesskriterier i både WCAG 2.1 og 2.2. Det er mulig å gjøre markeringen mer subtil og bare oppfylle minimumskravene, altså ikke oppfyller AAA-nivå, men det er ikke noe vi anbefaler. Fokusmarkeringen i Designsystemet vises bare ved tastaturfokus gjennom :focus-visible, slik at den kun er synlig når den trengs. Inputfelt er et unntak, siden de alltid mottar tastaturfokus. Derfor må de også alltid ha fokusmarkering.
(29.10.25) Spørsmål: Er det meningen at det skal dukke opp to feilmeldinger når det blir brukt counter og errormessage på TextField?
Svar: Ja, det er hensikten for å tydeliggjøre at det er to ulike feil og to ting du må rette opp før du kan gå videre. Den ene feilen kan f.eks være at du har brukt ugyldige tegn, mens den andre forteller deg at du har for mange tegn. De er gjort ganske fremtrendende for å tydeliggjøre hvorfor du ikke kan komme videre/sende inn.
(02.10.25) Spørsmål: Er det rett at Storybook har en Label komponent, men ikke Figma filen? Vil gjerne bruke Label i Figma der den er bruk i Storybooks, men er usikker på om det er en grunn til at det er satt opp slik?
Svar: Ja, vi gjorde Label i Figma om til rene tekstelementer i en tidligere versjon. Det er fortsatt stylet likt som i Storybook og representerer det samme. Dette er gjort for at komponentene i Figma skal beholde overstyringer mer konsekvent. Vi har erfart at instanser av andre komponenter som ligger i en komponent kan skape problemer når man bytter mellom varianter og når man swapper.
Du kan se i denne videoen at det nesten fungerer nå: https://github.com/user-attachments/assets/d56f27a3-c540-4c46-9eb7-ba63f636d970
Ulempen med dette valget er at man ikke kan styre styling på tvers av alle labels et sted i filen.
Det står info om stylingen til label, description og legend på siden med typografi komponenter i Figma filen.
(17.07.25) Spørsmål: Hva er forskjellen på main- og supportfarger i temabyggeren? Såvidt jeg kan se behandles disse likt når det genereres CSS fra dem?
Svar: Det stemmer, de behandles likt. De er "kategorisert" til kun 4 farger per kategori pga. begrensning i funksjonaliteter i Figma og deres prising. Det gjør at du kan ha flere farger uten å måtte være på Figmas "Enterprise plan".
Edit 20.11.25: Figma har nå utvidet dette, så vi skal vurdere hvordan vi gjør dette fremover. Figma: "We have increased the number of modes to 10 for those on the Professional plan and 20 for those on Figma Organization."
(11.06.26) Question: How do you measure the success and adoption of Designsystemet?
Answer:
Because Designsystemet is open source, free to use, and available without any formal agreement, we do not have exact figures on how many organisations use it. However, we monitor several indicators that give us a good understanding of adoption and engagement. These include the number of downloads of our code packages, users of our Figma libraries, membership in our Slack community (which includes representatives from more than 300 organisations), and the overall level of activity and engagement within the community.
As adoption increases, we see greater consistency in how digital services behave across organisations. Our goal is not for services to look identical, but for common interface elements and interactions to work in predictable ways. For example, users can expect components such as dropdown menus to behave similarly regardless of which public service they are using. The same applies to common patterns, such as error messages and external links, which behave in consistent and predictable ways across services. This reduces the learning curve for citizens when moving between services and supports greater digital inclusion.
Designsystemet helps organisations build more accessible, consistent, and user-friendly digital services. Organisations can extend Designsystemet themselves and develop components, patterns, and solutions tailored to their own needs. This allows them to test and validate ideas in their own services without having to wait for changes to be made in Designsystemet. Organisations that adopt Designsystemet often conduct their own user testing and share feedback with us when they identify opportunities for improvement. Relevant improvements can then be incorporated into Designsystemet, benefiting all current and future users.
We have also measured compliance with accessibility requirements before and after organisations adopted Designsystemet. The results are described in more detail in our socio-economic impact assessment.
We have several feedback loops. Designsystemet is developed through a cross-agency collaboration where designers and developers from different organisations contribute both insights and implementation work. We maintain open feedback channels through GitHub and Slack, as well as dedicated working groups for patterns. When developing new patterns, we involve representatives from multiple organisations to ensure that the solutions address shared needs across the public sector.