Gå til sidens indhold

Om designsystemet

Gennemgang af designsystemet

Vi står på skuldrene af andre store designsystemer

Det Fælles Designsystem er særligt inspireret af to andre velrenommerede offentlige open source designsystemer, nemlig:

Designsystemet bygger dermed på et fundament af internationalt anerkendte standarder og bedste praksis for design af løsninger, og vi anbefaler, at du også henter inspiration fra disse to, når behovet opstår.

Det Fælles Designsystem anviser et minimalt og fleksibelt design. Komponenterne er nøje udvalgt til selvbetjeningsløsninger. Systemets frontendarkitektur afspejler vores ønske om at der bygges selvbetjeningsløsninger med høj performance, hvor kun det nødvendige hentes ind i løsningen.

Designsystemet giver lette og stabile selvbetjeningsløsninger. Med sin ensartede funktionalitet og design skaber det genkendelighed for brugerne på tværs af selvbetjeningsløsningerne. Det gør det nemmere for brugerne at navigere i og anvende løsningerne, da den samlede brugerrejse på tværs af offentlige selvbetjeningsløsninger bliver mere ensartet.

På de underliggende sider finder du en beskrivelse af principper og valg af løsninger bag designsystemet.

Frontend arkitektur

Det Fælles Designsystem er en simpel samling af grundlæggende funktioner og design, der skaber et solidt grundlag for udviklingen af selvbetjeningsløsninger på borger.dk og Virk.

Designsystemets arkitektur af brugergrænseflade bygger på princippet om en minimal, modulær og skalerbar opbygning, som kan forgrene sig yderligere i takt med øget behov.

I takt med at US Web Design System og Gov.uk bliver udvidet og forbedret, vil disse ændringer af hensyn til integriteten af designsystemet blive gennemgået og vurderet af en teknisk redaktion, før de bliver implementeret.

Grafik der viser Det Fælles Designsystems frontend arkitektur
Det Fælles Designsystems frontend arkitektur

Komponenterne i Det Fælles Designsystem

Hvad mener vi med minimal?

Med minimal mener vi, at designsystemets kompleksitet og funktioner er holdt på et minimum.

En sides kompleksitet og komponentvalg afgør hvilke ressourcer, der er behov for.

Hvad mener vi med modulær?

Med modulær mener vi, at opbygningen af designsystemet består af en kerne (dkfds_core.css), der danner det grundlæggende fundament for brugergrænsefladen. Kernen udtaler sig udelukkende om layout, typografi, farver og grundlæggende funktioner.

Kernen indlæses på alle hjemmesider, der anvender designsystemet – uanset om løsningen er udviklet til borger.dk eller Virk.

Udover kernen kan der tilføjes fx myndighedsspecifik styling og diverse funktionsudvidelser.

Hvad mener vi med skalerbar?

Med skalerbar mener vi, at designsystemet løbende kan skaleres i takt med nye udvidelser.

Designsystemet er således konstrueret omkring det modulære princip, der gennem af- og tilkobling af udvidelser muliggør en løbende skalering af de tilbudte funktioner.

Selvbetjeningsløsninger kan fx have et interaktionsbehov (behov for interaktion med brugerne), der ikke bliver understøttet af designsystemet. De kan i stedet blive udviklet som udvidelser, som du kan til- eller afkoble efter behov.

Borger og Virk.dk

For at opnå den ønskede myndighedsbranding fra borger.dk eller Virk på dokumentationssitet skal du sørge for at indlæse enten dkfds_borger.css eller dkfds_virk.css parallelt med dkfds_core.css.

Hver af de to CSS-filer tilføjer myndighedens brand-styling, dvs. logo og styling, der skaber myndighedens genkendelighed.

Tilgængelighed

Selvbetjeningsløsninger og alle andre offentlige hjemmesider skal overholde den danske lovgivning omkring tilgængelighed på WCAG 2.1 (2019) niveau AA. Du skal derfor teste alle selvbetjeningsløsninger og deres funktioner op imod disse krav, som ikke blot øger tilgængeligheden for brugere med særlige behov, men for alle brugere.

Designsystemet lever op til lovkravene om at understøtte WCAG 2.1 (2019) på AA niveau.

Læs mere om webtilgængelighed

Layout

Det Fælles Designsystem ønsker at hjælpe dig med at skabe en god oplevelse for dine brugere: Når de bruger din selvbetjeningsløsning skal de opleve et visuelt og funktionelt design og layout, der er neutralt, simpelt og fleksibelt.

12 kolonner (horisontalt)

Det Fælles Designsystem baserer sit responsive layout på en opdeling af siden i 12 lige bredde kolonner med 24 px afstand mellem hver kolonne. Det giver ro, overskuelighed og forudsigelighed, når man placerer sidens komponenter indenfor et grid og får en side og dens søskendesider til at fremtræde sammenhængende. Det har positiv betydning for billedstørrelser og andre elementer.

I tablet- og mobilvisninger folder layoutet sammen til respektivt 8- og 4-grid. På den måde følges proportionerne ad fra størst til mindst.

Responsivt med break points

Det Fælles Designsystem er responsivt og tilpasser sig således automatisk det tilgængelige vinduesareal.

Sidens break points – de værdier, hvorefter siden automatisk tilpasser sig arealet – er:

  • Desktop/stor skærm: 1200px
  • Desktop/middel skærm: 992px
  • Tablet: 768px
  • Mobil: 576px

Typiske grid-layouts

Du kan kombinere de 12 kolonner og flette dem sammen, så du ender med layout varianter, der fx består af 3/9, 4/8, 4/4/4 osv. Alle sider bygger på den måde på det samme fundament, som bidrager til at skabe ro og overblik.

Grafik der viser Det Fælles Designsystems grid-inddelinger Grafik der viser Det Fælles Designsystems grid-inddelinger Grafik der viser Det Fælles Designsystems grid-inddelinger Grafik der viser Det Fælles Designsystems grid-inddelinger Grafik der viser Det Fælles Designsystems grid-inddelinger
Ovenstående er eksempler på mulige kombinationer af kolonner inden for Det Fælles Designsystems 12-grid layout.

Baseline grid (8px vertikalt)

I designsystemet går alle vertikale dimensioner og afstande op med en faktor 8. Gennem gentagelsen af værdier opstår der en ro og balance på tværs af det visuelle layout og mellem sidens lodrette elementer.

Læs mere om 8pt grid

Font

Det Fælles Designsystem anvender en typografi baseret på skrifttypen IBM Plex Sans (som er en webfont), en farveskala og specificeringer til blandt andet hjørner, streger og skygger.

IBM Plex Sans er valgt som font, da det er en æstetisk og læsbar open source font, der kan anvendes gratis under SIL Open Font License.

IBM Plex Sans er en alsidig sans serif font, der egner sig godt til brugergrænseflader. Fonten har de karakteristika, som designsystemet promoverer. Den er simpel og neutral i sit udtryk og yderst skalerbar grundet de mange variationer (typer, vægte, sprog, m.m.), som fonten understøtter.

Læs mere om fonten

Koden

Det Fælles designsystem er kodet i HTML5/CSS3 og det er tilstræbt, at al kode lever op til standarden.

Vanilla JS

For at øge ydeevnen gennem færre forespørgsler, der skal behandles, overhead og - ikke mindst - mindske afhængigheden til tredjepartsleverandører og deres potentielle tekniske gæld, er det besluttet, at designsystemet anvender Vanilla JS (Plain JS). Det vil sige, at designsystemet og de integrerede udvidelser ikke anvender framework som fx jQuery eller andet.

Læs mere om Vanilla JS her

Styling og temaer

Læs mere om styling her

CSS og JS arkitektur

Det Fælles Designsystem har en tilsvarende opbygning som US Web Design Standards.

Læs mere om CSS og JS arkitektur her

Det Fælles Designsystem giver framework-frihed

Det Fælles Designsystem er en UX reference med en simpel, valgfri kodeløsning og ikke et endegyldigt teknologivalg. Designsystemet er en række anbefalinger, der understøtter en mere ensartet brugeroplevelse af offentlige selvbetjeningsløsninger.

De enkelte anbefalinger er suppleret af en løsningsmodel i kode, som er rettet imod den bredest mulige anvendelse. Den er altså ikke cutting-edge eller nyeste framework. Til gengæld bestræber designsystemet sig på at være minimalt, modulært og skalerbart og dermed enkelt og nemt at anvende.

I praksis kan du altså anvende designsystemet direkte - uden yderligere kode.

Komponenterne i designsystemet vil løbende blive opdateret. Men ønsker du her og nu at anvende en anden kodeløsning som fx en dedikeret React-løsning eller en Single Page Application (SPA), Progressive Web Application (PWA), Web Component eller lignende, så kan du det.

Designsystemet anbefaler nemlig ikke en specifik model eller framework: Det centrale er, at brugeroplevelsen er ensartet - ikke at koden er det.

Udvidelser

Brugeren af en typisk selvbetjeningsløsning har ofte behov for yderligere interaktion end blot layout og typografi. Derfor har vi tilføjet en række funktioner i form af udvidelser til dkfds_core.css samt et anbefalet udvidelseskatalog med ekstra funktionalitet.

En udvidelse kan være alt lige fra en spinner, der viser at en løsning er under indlæsning til et avanceret tabel-system som Data Tables.

Visse funktionsudvidelser er meget generelle og derfor placeret i dkfds_core.css. Udvidelser, der på denne måde bliver del af kernen, vil altid være bygget af teamet bag designsystemet. Det drejer sig om:

Andre udvidelser er valgfrie, og det er derfor op til udvikleren i samarbejde med sin forretning at vurdere, hvad der er nødvendigt for den enkelte løsning.

Det Fælles Designsystem anbefaler følgende udvidelser:

Ikoner

Ikoner betragtes ikke som en reel udvidelse, selvom de bliver hentet udefra. Vi har udvalgt ikoner fra Material Design i .svg (Scalable Vector Graphic) format. De ligger som en samlet “pakke” af symbol efter body. På denne måde sparer vi et større antal forespørgsler for den enkelte side. Koden for ikoner fylder ganske lidt.

Ikonerne er angivet som symbol med tilføjet title og desc og de kaldes i html koden vha use, fordi det er den mest effektive anvendelse af svg-ikoner, hvor man via shadow DOM dynamisk opretter kopier af det oprindelige symbol.

Læs mere om ikoner her

Det Fælles Designsystem stiller krav til udvidelser

For at sikre sammenhæng og ensartethed i designsystemet har vi opstillet en række minimumskrav til udvidelser af systemet:

Dokumenteret behov

Hvis du har forslag til udvidelser, skal du dokumentere dem ud fra et påviseligt brugerbehov, som ikke på forhånd kan løses af de allerede inkluderede udvidelser. Det er den person, som stiller forslaget, der skal dokumentere behovet.

Dokumenteret test

Udvidelser skal være gennemtestede, før de kan blive en del af udvidelseskataloget. Du skal således have gennemført og dokumenteret succesfulde test af både kode, funktionalitet og brugervenlighed, såfremt du ønsker at få en udvidelse optaget som mulig tilkobling til designsystemet.

Gradueret indfasning

Der er tre niveauer for udvidelser til designsystemet af hensyn til både stabilitet og drift:

  • Sandbox
  • Anbefalet udvidelse
  • Integreret udvidelse
Sandbox
  • Har ufuldstændig dokumentation
  • Er ikke fuldt kompatibel (kræver ændringer i løsningen udover tilføjelsen)
  • Unik løsning
  • Ikke del af komponentoversigten på dokumentationssiden
  • Ikke del af designsystemets releases
Definition af "sandbox" udvidelse
  • En udvidelse, der opfylder et eller flere krav til brugeroplevelse eller tekniske krav, men ikke er nævnt på dokumentationssiden, og som heller ikke er en del af designsystemets offentliggørelser.
  • En udvidelse, hvis anvendelse i en løsning designsystemets team er opmærksom på, og som teamet kan vælge at placere i ”Sandbox” af orienteringshensyn.
Anbefalet udvidelse
  • Anvendt af en eller flere løsninger
  • Opfylder alle UX-krav og tekniske krav
  • Fuldstændig dokumentation
  • Godkendt test
  • Opdateret
  • Del af komponentoversigten
  • Theming er del af designsystemets releases
Definition af "anbefalet" udvidelse
  • En udvidelse, der er anvendt på en eller flere løsninger og er gennemtestet for sin integritet.
  • Udvidelsen optræder i komponentoversigten på dokumentationssiden, men er markeret med et ”Anbefalet udvidelse” badge samt en Alert, der forklarer overstående princip.
  • Eventuelle betragtninger om brugeroplevelser og anbefalinger omkring anvendelse af udvidelsen står på dokumentationssiden.

Det Fælles Designsystem tilbyder styling (theme), eksempelløsning som reference og en package.json med reference til den anbefalede version hos tredjepartsleverandøren, hvor udvikleren selv skal hente koden. Alle supporthenvendelser omkring udvidelsen skal rettes direkte til tredjepartsleverandøren.

Integreret udvidelse
  • ”Home grown”
  • HTML5, CSS, Vanilla JS
  • Opfylder alle UX krav og fremstår som en ”naturlig” del af designsystemet
  • Ingen binding til tredjeparts-leverandør
  • Fuldstændig dokumentation
  • Godkendt test
  • Optræder i komponentoversigten på dokumentationssiden
  • Koden er del af designsystemets releases
Definition af "integreret" udvidelse
  • ”Home grown” udvidelse, der ligger som del af designsystemets kerne.
  • En integreret udvidelse kan tage udgangspunkt i en ”anbefalet udvidelse”. På grund af udbredelse på tværs af løsninger, har vi valgt at lave vores egen tilsvarende komponent og gøre den til en kernefunktionalitet i designsystemet.

Performance

Browsere

Designsystemet udtaler sig ikke om bestemt browser-understøttelse, som derimod bør være afhængig af brugernes behov, krav og forventninger til selvbetjeningsløsningen.

Dog skal du altid sikre bredest mulig understøttelse. Fravalg eller manglende understøttelse skal du skrive som del af dokumentationen for løsningen.

Asynkron indlæsning af ressourcer

Preload indlæser en ressource asynkront, så browseren ikke skal vente på, at CSS eksempelvis skal indlæses, før den kan rendere siden.

Det Fælles Designsystem anvender preconnect og preload i head-delen til preload af CSS og til fonte.

Når browseren først åbner forbindelse til en given server, og derefter laver en tidlig indlæsning af en ressource, kan den senere hurtigt beregne eksempelvis layout. Bemærk, at browseren ikke anvender ressourcerne på dette tidspunkt, men kun gør dem klar. Det kaldes også ”lazy load”.

Læs mere om preload her

Fonte

Indlæsning og beregning af web-fonte kontra system-fonte kan potentielt være omkostningstungt for både leverandør og bruger. Ved at anvende preconnect, preload samt font-display:swap understøtter designsystemet brugerens behov for hurtig adgang til løsningens indhold.

IBMPlexSans-Regular er en del af den primære Font Stack, der anvendes i designsystemet. Den Fallback Font Stack, der indlæses, hvis den primære er utilgængelig, er "System". ”System” refererer til fonte fra de respektive styresystemer og anvendes af browseren indtil den primære Font Stack er indlæst.

Deklarationen font-display:swap får browseren til at anvende en system-font - hvis den ikke får fat i IBM Plex Sans indenfor 1/100 sekund - svarende til, at IBM Plex Sans ligger i brugerens cache. Når IBM Plex Sans er indlæst, skifter browseren sin fallback-font ud med den korrekte.

Det tager maksimalt ~3 sekunder for browseren at loade IBM Plex Sans og genberegne siden. Browserens brug af font-display:swap og fallback font kan dog afføde et lille blink (også kaldet FOUT), når den første side genberegnes med IBMPlexSans – derefter ligger fonten i browserens cache. Dette vurderes at være et mindre problem. Det er forventeligt, at mange brugere allerede har IBM Plex Sans liggende i deres cache, da fonten hurtigt bliver udbredt på grund af dens anvendelse på tværs af mange offentlige selvbetjeningsløsninger.

Bemærk

Font-display er endnu ikke implementeret i IE/Edge. Løsningen er ikke desto mindre valgt, da den generelt set tilbyder det bedste alternativ.

Læs mere om font-stack her

Favicon

Et favicon er en lille grafik, der vises i browserens fane – eksempelvis som desktop-ikon, bogmærke eller lignende. Der skal være et favicon til stede på serveren af hensyn til et default browser-forespørgsel, som ellers vil få indlæsningen til at føles langsom og generere en 404-fejl i loggen.

Det er nødvendigt at generere en lang række varianter af favicons af hensyn til de mange platforme, brugere i dag benytter sig af.

I Det Fælles Designsystem har vi valgt at anvende Real Favicon Generator og favicon-filerne er placeret i en undermappe.

Bemærk

Det har tidligere været et problem for iframes, at deres indhold også skulle have et favicon for ikke at generere en 404. Det har ikke været muligt at teste og bekræfte denne opførsel i moderne browsere.

Læs mere om favicon her

Versioner og releases via Github og NPM

Det Fælles Designsystems kode distribueres via Github.

GitHub er et online versionsstyringssystem og en samling af koder (kode-repositorie), hvor organisationer, firmaer og enkeltpersoner opbevarer og udstiller deres kode. Andre kan herefter anvende den som den er, eller oprette en kopi (fork), som de bygger videre på selv og senere udstiller til potentiel inklusion i ophavet.

Alle interesserede i designsystemet kan dermed få adgang til at anvende koden ved at hente den på GitHub.