Selected Work · 04

Making of:
Design System.

In deze showcase laat ik zien hoe ik tijdens mijn stage een design system heb opgebouwd.

Design Systems Typografie Visual Design Rebranding

Docentweergave (Criteria & Verantwoording)

Zet deze modus aan om de beoordelingscriteria in de tekst te highlighten en mijn verantwoording per criterium te zien.

BC 1.1

Je maakt bij de opdracht duidelijk wat er van je gevraagd wordt en welke doelen jouw bijdragen dienen te bereiken.

BC 1.2

Je zet relevante theorie over mensgerichte ontwerpmethodes in om jouw keuzes te onderbouwen.

BC 3.1

Je verzamelt bij je ontwerpactiviteiten methodisch inzichten met betrekking tot de te behalen doelen en beoordeelt de toegevoegde waarde daarvan voor het beantwoorden van de ontwerpvraag.

BC 3.2

Je formuleert heldere conclusies waar bruikbare verbetersuggesties uit voortvloeien.

BC 4.2

Je verantwoordt de gemaakte keuzes en resultaten en communiceert dit pro-actief en helder met de belanghebbenden én begeleiders.

Verantwoording

Hieronder onderbouw ik per criterium waarom ik eraan voldoe. Ik link steeds direct naar het bewijsmateriaal op deze pagina.

Introductie

In dit datapunt laat ik zien hoe ik voor de rebranding van mijn voormalige stagebedrijf aan het design system heb gewerkt.

Dit gaat over het design system dat ik heb gemaakt voor de rebranding van 'Digitale Staat' (nu nog Grafische Republiek). Dat was de opdracht tijdens mijn eerdere stage. Inmiddels loop ik stage bij Like Bamboo.

Die stage is afgelopen en het project lag daarna even stil. Maar voor mijn portfolio heb ik het weer opgepakt om het alsnog af te ronden.

Het bureau had een nieuwe website nodig die hun werk beter laat zien en nieuwe klanten aantrekt. Dat betekent: een site die er professioneel uitziet en vertrouwen wekt.

Er was al een ruw concept van de homepage, maar dat was puur op gevoel gemaakt, zonder vaste regels. Ik heb daar de systematische basis voor gebouwd en getest. Het doel was dat alle toekomstige componenten op vaste afspraken worden gebouwd, niet op losse aannames.

Doelen BC 1.1

Dit is wat ik moest bereiken:

  • Dat de hele website aanvoelt als één geheel, niet als losse pagina's.
  • Een logisch systeem waar developers meteen mee kunnen werken, zonder te hoeven gokken.
  • Dat het systeem makkelijk herbruikbaar is voor nieuwe pagina's en voor mobiel.

Het doel voor het bedrijf: een strakke website die vertrouwen geeft aan nieuwe klanten.

Ik hoefde de site niet zelf te bouwen. Maar ik moest en wilde het zo opzetten dat de front-enders er later zonder gedoe mee konden beginnen.

Meetbare succescriteria BC 8.3.1

Criteria afgeleid uit geobserveerde problemen.

Om te kunnen meten of het design system ook echt werkt, heb ik van tevoren toetscriteria opgesteld voor consistentie, overdraagbaarheid en schaalbaarheid.

Die criteria heb ik niet zomaar bedacht. Ze komen direct uit problemen die ik zag in de bestaande homepage, en ik heb ze daarna onderbouwd met theorie en input vanuit de praktijk.

Typografie
Meetbaar

Typografische keuzes zijn onderling consistent en herleidbaar naar een onderliggend systeem, zonder dat per component losse, niet-onderbouwde keuzes ontstaan.

Resultaat

Er ontstaat een samenhangend typografisch geheel waarin hiërarchie herkenbaar en reproduceerbaar is.

Line height
Meetbaar

Line heights volgen een consistente logica die aansluit op de typografische keuzes en worden niet willekeurig toegepast.

Resultaat

Tekst blijft leesbaar en visueel samenhangend over verschillende secties en componenten.

Mobile versus desktop
Meetbaar

De overgang tussen mobiele en desktopweergaven is logisch opgebouwd en voorkomt abrupte, onvoorspelbare veranderingen in layout of typografie.

Resultaat

Een vloeiende responsive ervaring waarbij de visuele hiërarchie ongeacht het beeldscherm behouden blijft.

Grid
Meetbaar

Lay-outs zijn opgebouwd volgens een consistente en herkenbare structuur, waarbij uitlijning niet willekeurig afwijkt.

Resultaat

Componenten kunnen zonder herinterpretaties opnieuw worden toegepast op andere pagina's en schermformaten.

Design tokens en consistentie
Meetbaar

Herhalende elementen zoals kleuren, lettertypes en spacing worden uitsluitend beheerd via centrale design tokens. Componenten wijken niet af van deze afgesproken fundering.

Resultaat

Een voorspelbaar, makkelijk onderhoudbaar systeem: developers kunnen waarden één-op-één overnemen zonder giswerk, wat zorgt voor feilloze uniformiteit.

Ontwerpvraag BC 1.1

Hoe vertaal ik een bestaande visuele richting naar een samenhangend design system dat consistente ontwerpkeuzes afdwingt?

En hoe zorg ik dat dit systeem schaalbaar is over verschillende pagina's en apparaten, en helder overdraagbaar naar development?

Onderzoeksvragen BC 1.1
  • Welke ontwerpvariabelen bepalen de consistentie van het systeem?
  • Welke keuzes werken wel en niet bij typografie, spacing, grid en mobiel?
  • Hoe onderbouw ik keuzes met praktijkinput en theorie?
Context BC 8.1.1

Structuur versus los zand.

Er was al een ruw ontwerp voor de homepage, maar daar zat geen enkele regel in.

En dat merk je meteen, want dan krijg je dingen als:

  • Tekst groottes die op de ene pagina ineens groter zijn dan op de andere.
  • Een rommelige weergave en een onrustig gevoel op de pagina.
  • En het ergste: developers die niet snappen waarom hier x padding staat en daar y.
Hoe ik dit heb aangepakt BC 8.3.1

Testen zonder echte klanten.

Ik ben niet zomaar begonnen met ontwerpen, ik heb alles stap voor stap doorgenomen samen met mijn begeleider.

De afstand tussen twee blokken test je moeilijk met gewone gebruikers, want die merken het niet eens. Dus moest ik het anders aanpakken. Ik knipte het ontwerp op in losse onderdelen (grid, lettertypes, spacing) en besprak die met mijn stagebegeleider.

Mijn aanpak per module:
  • 1. Eén onderdeel pakken (bijv. Grid).
  • 2. Bedenken wat ik verwachtte dat ging werken. (Hypothese)
  • 3. Dat verwerken in Figma.
  • 4. Feedback vragen aan mijn begeleider, en aanpassen.
  • 5.Bijsturen (leren van weerlegde hypotheses)
  • 6.Resultaat vergelijken met theorie en vastleggen
Praktijkinput BC 1.2

Vanuit mijn stagebegeleider kreeg ik randvoorwaarden:

  • 1Mobiel moet hetzelfde gevoel houden als desktop
  • 2Ontwerpen beoordelen op 100% schaal
  • 3Eén systeem voor alle devices
  • 4Eerst systeem, daarna schermen
  • 5Geen willekeurige letterspacing
De begeleider bepaalde randvoorwaarden. Ik dirigeerde het eindresultaat.
Variabelen en experimenten

Variabele 1 — Typografie

Mijn gedachte vooraf

Een vaste wiskundige verhouding voor lettergroottes werkt beter dan elke keer maar wat intypen.

Het probleem destijds

Eerder werden lettergroottes gewoon op gevoel gekozen. Dat zorgde ervoor dat de hiërarchie vervaagde en het geheel er rommelig uitzag.

Testen met de stagebegeleider BC 8.3.1

Samen met mijn begeleider heb ik in Figma vier rekenschalen naast elkaar gezet. De Minor Third (×1.200) groeide te langzaam: titels leken qua grootte te veel op gewone tekst. De Perfect Fourth (×1.333) gaf precies het contrast dat we zochten, zonder dat het op telefoons lelijk ging breken.

Resultaat

We kozen voor de 1.333-verhouding. Dat leverde deze vaste formaten op:

  • 16px — Navigations, Buttons, Input Text
  • 21px — Paragraphs
  • 28px — Small headings
  • 38px — Headings
  • 50px — Headings
  • 67px — Headings & Payoff
Wat inzicht opleverde

Mensen lezen webpagina's niet echt; ze scannen. Omdat deze formaten wiskundig flink uit elkaar liggen, herkent je brein direct wat de hoofdtitel is en wat ondersteunende tekst. En doordat er geen tussenmaten bestaan in het systeem, blijft de hiërarchie altijd helder (NN/g Scanning).

Gekoppelde theorie BC 1.2 Scanning & Visual Hierarchy (NN/g)

Bezoekers scannen meer dan dat ze lezen. Door een vaste ratio als 1.333 te gebruiken, ontstaat er binnen een fractie van een seconde onbewust structuur in het hoofd van de bezoeker.

Typografie Simulator

Variabele 2 — Line height

Mijn gedachte vooraf

Grote titels hebben veel minder tussenruimte nodig dan gewone leestekst.

Het probleem

Eerst had alles gewoon een line-height op gevoel.

Experimenten BC 8.3.1

Ik pakte de zes typografische formaten erbij en testte handmatig wat er gebeurde bij verschillende line-height waarden, van 1.0 tot 1.6.

Resultaat & Het inzicht

Kort gezegd: gewone paragrafen (16px) kregen ruime tussenruimte (1.5). Maar bij grote titels trok ik de regels steeds dichter naar elkaar toe (1.1 tot 1.0).

Want als je dat niet apart instelt, kan een lezer niet goed zien dat twee regels van een grote titel bij elkaar horen.

  • 1.50 — Body (16px) - Optimale leesbaarheid
  • 1.30 — Sub-heading (21px) - Open karakter
  • 1.20 — Heading S (28px) - Groepering start
  • 1.10 — Heading M (38px) - Compact blok
  • 1.0 — Display (50px) - Maximale impact
  • 1.0 — Display (67px) - Maximale impact
Gekoppelde theorie BC 1.2 Proximity & Readability (Gestalt & WCAG)

De 'Law of Proximity' zegt dat dingen die dicht bij elkaar staan als één geheel worden gezien. Daarom trek je grote titels strak naar 1.0. Maar kleine leesteksten hebben juist lucht nodig, volgens WCAG (toegankelijkheid) worden ze onleesbaar bij zo'n krappe line-height, omdat regels dan in elkaar overlopen. Die moeten dus 1.4 tot 1.6 krijgen.

Bronnen:
W3C. (2018). Web Content Accessibility Guidelines (WCAG) 2.1. Bezoek W3.org
Wertheimer, M. (1938). Laws of organization in perceptual forms. In W. D. Ellis (Ed.), A source book of Gestalt psychology (pp. 71-88). Routledge & Kegan Paul.
Line Height Tester

Line Height Ratio1.5
Gekozen

Variabele 3 — Desktop vs Mobile

Mijn gedachte vooraf

Op school had ik altijd geleerd: "Neem niet zomaar alles één-op-één over van desktop naar mobiel. Speel met de layout." Dus ging ik flink experimenteren met de mobiele weergave.

Het probleem destijds

Maar die experimenten werden door mijn begeleider helemaal niet gewaardeerd. Doordat ik voor mobiel allerlei custom uitsnedes en layout-trucjes ging verzinnen, liepen desktop en mobiel steeds verder uit elkaar.

Experimenten BC 3.1

Hiernaast staan drie iteraties naast elkaar. Je ziet hoe het experimenteren misliep en wat het eindresultaat moest worden. Versie 1 was mijn eerste poging, versie 2 een volgende iteratie, en versie 3 het logische, definitieve resultaat.

Resultaat

In de iteraties hiernaast zie je wat die experimenten visueel deden, en waarom we bij versie 3 teruggingen naar dezelfde componenten als op desktop, maar dan afgeschaald.

Gekoppelde theorie BC 1.2 Jakob's Law & Mental Models

Jakob's Law zegt: gebruikers verwachten dat jouw product zich gedraagt zoals andere producten. Door geen rare uitzonderingen te maken en één schaal aan te houden voor elk apparaat, sluit je aan bij wat de gebruiker verwacht.

Bronnen:
Nielsen, J. (2000). Jakob's Law of the Internet User Experience. Nielsen Norman Group. Raadpleeg op nngroup.com
Interactieve Vergelijking: Versies 1, 2, 3

Variabele 4 — Grid

Mijn gedachte vooraf

Een vast grid werkt veel beter dan blokken zomaar op gevoel op de pagina zetten.

Het probleem destijds

Zonder grid ontstonden er constant kleine, slordige foutjes in Figma. Een tekstblok stond net 5 pixels verder naar links dan het andere. Dat maakte de pagina onrustig.

Hoe ik dit testte BC 3.1

Ik testte drie opties: (A) helemaal geen grid en gewoon op gevoel werken, (B) het klassieke 12-koloms grid, en (C) een 10-koloms grid.

Resultaat

Het 12-koloms grid was zonder twijfel de beste oplossing. Het is makkelijk op te delen: twee blokken van 6, of drie van 4 op mobiel. Elke layout past er netjes in.

  • Desktop Breedte1512px canvas
  • Desktop Gutter12px (tags) · 18px (cards) · 75px (secties)
  • Desktop PaddingsVariabel (bijv. 60px tot 125px)
  • Mobiel Breedte390px (iPhone basis)
  • Mobiel Margins24px links en rechts
  • Mobiel Content342px
  • Mobiel GapCompact (24px, 32px)
Wat inzicht opleverde

Zonder een strak grid wordt digitaal design al snel een rommeltje. Door het overal toe te passen bleef alles consistent en overzichtelijk.

Gekoppelde theorie BC 1.2 Responsive Grid Systems (Material Design & Dieter Rams)

Google's Material Design laat zien dat een 12-koloms grid heel goed werkt als je later responsive moet gaan bouwen (tablet en mobiel). Het schaalt gewoon mee. En zoals Dieter Rams zei: "Goed design is zo min mogelijk design." Een grid helpt om het scherm overzichtelijk in te delen, zonder dat je steeds elke pixel handmatig moet plaatsen.

Bronnen:
Rams, D. (1995). Less but better (Weniger, aber besser). Jo Klatt Design+Design Verlag.
Google. (2018). Material Design 3: Responsive layouts. Raadpleeg op material.io
Grid Overlay Visualizer
12-koloms grid · Desktop 1512px Selecteer een layout

Variabele 5 — Design Tokens & Consistentie

Mijn gedachte vooraf

Iets wordt pas herkenbaar als je het consequent vastlegt. Elke kleur, elke schaduw die moeten ergens centraal staan.

Het probleem destijds

Iedereen werkte op zijn eigen manier. Kleuren werden rechtstreeks in Figma ingetikt, waardoor we achteraf merkten dat een knop op de ene pagina net een andere ronding had dan op de andere.

Resultaat

Dit is wat er uiteindelijk uit kwam:

  • Kleurenpalet4 achtergrond · 4 accent · 4 neutrale kleuren
  • FontGeist (Google Fonts / Vercel)
  • Border-radius2px · 4px · 8px
  • Borders & Lines1px divider · Card stroke rgba(30,58,138,0.3)
  • ComponentenSolid & Outline Buttons / Tags
Consistentie Evaluatie BC 3.1

Het systeem draait om een donkerblauw (Navy) basispalet met opvallende neon-accenten (Teal en Cyan). Op mobiel wordt de beschikbare breedte benut met een vaste padding van 24px, op desktop met asymmetrische blokken en ruime gutters. Actie-elementen hebben vaste border-radii (4px voor knoppen, 8px voor tags) die op elk scherm gelijk blijven.

Wat inzicht opleverde

Een systeem werkt pas als je alles centraal vastzet in tokens (variabelen). Dat haalt twijfel weg en voorkomt eindeloze discussies tussen designers en developers.

Bewijsmateriaal Figma Documentatie Figma Text Styles Proof

Dit screenshot toont aan hoe de afgesproken typography properties keihard zijn vastgeschroefd als Figma Styles.

Gekoppelde theorie BC 1.2 Design Tokens (Salesforce) & Atomic Design (Brad Frost)

Dit noem je Atomic Design, bedacht door Brad Frost. Er zijn atomen: de kleinste bouwstenen, zoals één specifieke kleur. Combineer je die, dan krijg je moleculen, bijvoorbeeld een knop. Bundel je dat weer samen, dan krijg je organismen: de webpagina. Door die kleinste atomen foutloos vast te leggen (Design Tokens, een term van Salesforce) bouw je een systeem dat zichzelf veilig kan opschalen.

Bronnen:
Salesforce. (2015). Lightning Design System: Design Tokens. Raadpleeg op lightningdesignsystem.com
Frost, B. (2016). Atomic Design. Brad Frost Web. Raadpleeg het boek
Design Token Explorer
Primaire Achtergronden
#000048
Navy Deep
#000252
Navy Base
#000D5A
Navy Light
#001666
Navy Soft
Accenten & Acties
#45E8CF
Teal Action
#4DF1C5
Teal Muted
#00D4FF
Cyan Action
#004BEA
Blue Border
Neutrale Kleuren
#FFFFFF
White
#E6E8F0
Light Grey
#000839
Dark Ink
#000454
Ink
4px
Buttons

Actieknoppen (Solid/Outline)

8px
Tags & Borders

Tags, kleine kaarten en outline-elementen

2px / 8px
Cards (Mobiel)

Zeer lichte afronding of juist harde hoeken

Borders & Lines
Card Stroke rgba(30,58,138,0.3)
Divider Line white (1px)
Knoppen
Teal — Webapplicaties Cyan — Websites
Specs: py-8px · px-16px · border-radius 4px · Geist Light 16px · lowercase · lh 24px
Tags / Badges
Digitale platforms Webwinkels Corporate websites Campagne
Specs: py-8px · px-12px · border-radius 8px · 1px border · Geist Light 16px · lh 24px
Navigatie — Tekst-links (desktop)
Werk Oplossingen Kennisbank Vacatures De Staat Contact
Nav item: Geist Light · 16px · lh 24px · white · geen hover-state zichtbaar in design
Visueel Bewijs

Van een losse flodder naar een strak systeem.

Hieronder zie je de homepage: links het concept dat op gevoel was gemaakt, en rechts hoe het eruitziet nadat we de wiskundige regels van het design system eroverheen legden.

Op het eerste gezicht lijkt het bijna hetzelfde. Maar onder de motorkap is nu alles logisch uitgelijnd. Geen losse tekstformaten meer, alles staat keurig op het grid. Dat scheelt developers straks een hoop hoofdpijn.

Het Eindproduct

Eindontwerp mobiel en desktop.

Conclusies en verbeteringen BC 8.3.2

Hoe nu verder?

Ik heb eerlijk gekeken naar waar front-end developers straks tegenaan lopen. Welke afspraken ontbreken er nog? De knelpunten heb ik benoemd en vertaald naar concrete actiepunten voor de nabouwfase.

Zo weten ze precies welke valkuilen ze moeten vermijden.

1. Frictie in Naming Conventions

Conclusie

Bij de overdracht naar development ontstond verwarring over de namen van variabelen. Ik had ze beschrijvend gedocumenteerd (bijvoorbeeld 'Dark Blue'). Maar zulke namen werken niet als je later theming of dark modes wilt toevoegen.

Bruikbare Verbetersuggestie

Directe oplossing: Gebruik semantische namen voor alle tokens (bijvoorbeeld color-background-primary). Koppel die één-op-één aan de CSS-variabelen van het dev-team, in plaats van hexcodes. Dat voorkomt dat iedereen het anders interpreteert en maakt het systeem schaalbaar.

2. Edge Cases in Responsieve Typografie

Conclusie

De vaste typografische schaal (×1.333) werkte prima op desktop. Maar op mobiel (390 pixels breed) ging het mis: koppen braken af op plekken waar je het niet verwacht. Het scherm was simpelweg te smal voor de grote formaten.

Bruikbare Verbetersuggestie

Taak voor de developers: Gebruik fluid typography via CSS clamp(). Laat de lettergroottes meeschalen met het scherm, van een minimum (Minor Third, 1.200) tot het originele doel (Perfect Fourth, 1.333). Zo blijft de hiërarchie intact zonder dat je per breakpoint aparte waarden hoeft in te stellen.

Overdraagbaarheid BC 4.2

De Hand-off.

Doordat ik alles in Figma netjes heb dichtgetimmerd, hoeven developers niet meer te gokken. Ze kunnen elke afspraak direct overnemen in hun code.

Het Figma-bestand is bewust gestructureerd op A4-formaat, met duidelijke naamconventies per token en beschrijvingen bij elk component. Het lettertype waarin alles is opgemaakt is hetzelfde als het lettertype van het ontwerp, zodat het bestand niet alleen documentatie is maar ook visueel klopt. Zo kan iemand die het bestand opent direct zien welke tokens er zijn, hoe componenten zijn opgebouwd en waarom bepaalde waarden zijn gekozen.

Design System · Digitale Staat
Design Tokens
Volledige token-referentie voor development hand-off
Versie 1.0
Geist Sans + Mono
A4 Reference
Font Families
Geist Sans
Geist Sans Bold
font-family: 'Geist', system-ui, -apple-system, sans-serif;
Weights: 300 (Light) · 700 (Bold)
Gebruik: alle UI-tekst, koppen, paragrafen, knoppen
Geist Mono
Geist Mono Bold
font-family: 'Geist Mono', ui-monospace, monospace;
Weights: 400 (Regular) · 700 (Bold)
Gebruik: labels, badges, metadata, code, specs
Typography · Element Mapping
Ratio: Perfect Fourth (×1.333) · Base: 16px
Element Size Weight Line-H Kleur Voorbeeld
Hero / Payoff 67px 700 Bold 1.0 #FFFFFF Digitale Staat
Display Heading 50px 700 + 300 1.0 #FFFFFF Bold Light
Section Heading 38px 700 + 300 1.1 #FFFFFF Bold Light
Card / Sub Heading 28px 700 Bold 1.2 #FFFFFF Subkop voorbeeld
↳ text-transform: lowercase op buttons · uppercase + letter-spacing: 0.08-0.15em op labels
Color Palette · Gebruik per Context
Token HEX / Value Waar gebruikt
Achtergronden
bg-primary #000048 Hoofdachtergrond website, navbar, footer, cards
bg-elevated #000252 Verhoogde elementen, hoverstates achtergrond
bg-card #000D5A Card-achtergronden, interactieve panelen
bg-soft #001666 Subtiele secties, alternerende achtergronden
Tekst
text-primary #FFFFFF Koppen, navigatie, lead-teksten, bold elementen
text-secondary rgba(255,255,255,0.6) Lopende tekst (paragraphs, body copy)
text-muted rgba(255,255,255,0.35) Metadata, timestamps, bijschriften, footer
Accenten & Acties
accent-teal #45E8CF Primaire CTA-knoppen, actieve tags, section labels, links
accent-teal-muted #4DF1C5 Hover-state teal buttons, subtiele accenten
accent-cyan #00D4FF Secundaire CTA-knoppen, secundaire tags
accent-blue #004BEA Card borders, decoratieve lijnen
Borders & Dividers
border-card rgba(30,58,138,0.3) Card strokes, paneel randen (1px solid)
divider #FFFFFF · 1px Horizontale scheidingslijnen tussen secties
Button Tekst
button-text #000048 Tekst op teal/cyan buttons (donker op licht)
Spacing System
8px
Button py, icon gap 12px
Tag px, label spacing 16px
Button px, nav gap 18px
Artikel card items 24px
Mobile side margins 30px
Card gutter (desktop) 32px
Card padding (mobile) 36px
Desktop tag card py 40px
Button height 42px
Article card px 48px
Section padding-top 60px
Section padding-bottom 75px
Section gap (large) 126px
Grid unit / Hero top
Component Layout Section
Grid System
Desktop
Canvas1512px
Columns12
Gutters12 / 18 / 75px
Paddings60 – 125px
Mobiel
Canvas390px
Columns4
Margins24px L/R
Content342px
Gap24 / 32px
Border Radius
2px
Cards
4px
Buttons
8px
Tags
Borders & Lines
Card Stroke
rgba(30,58,138,0.3)
Divider Line
white · 1px
Component Tokens
Buttons (Solid)
py-8px · px-16px · radius-4px
Geist Light 16px · lh-24px · lowercase
Tags / Badges (Outline)
Digitale platforms Corporate
py-8px · px-12px · radius-8px · 1px border
Geist Light 16px · lh-24px
Navigation · Desktop Text Links
Werk Oplossingen Kennisbank Vacatures De Staat Contact
Geist Light · 16px · lh-24px · white · geen hover-state zichtbaar in design
Effects & Interactions
Property Waarde Waar toegepast
Shadows
box-shadow (card) 0 4px 24px rgba(0,0,0,0.2) Hover-state cards, verhoogde panelen
box-shadow (hero) 0 20px 60px rgba(0,0,0,0.5) Interactieve vensters, hero-elementen
Transitions
transition (standaard) all 0.2s ease Buttons, tags, links (hover/focus states)
transition (smooth) all 0.3s cubic-bezier(0.16,1,0.3,1) Panelen, modals, scroll-animaties
transform (hover card) translateY(-4px) Project cards hover lift-effect
transform (hover swatch) scale(1.05) – scale(1.1) Kleur-swatches, radius-demo's
Scroll & Reveal
scroll-behavior smooth html element (anchor-navigatie)
reveal animation opacity 0→1 · translateY(30px→0) Alle .reveal elementen bij scroll-in-view
CSS Custom Properties · Quick Reference
/* ── Achtergronden ── */
--bg: #141820;
--surface: #1C2030;
--surface-2: #252A3A;
--border: rgba(200,210,230,0.08);

/* ── Tekst ── */
--text: #e8eaed;
--text-muted: #6b7280;
--text-dim: #3b3f4a;
--accent: #7eb8da;
--accent-dim: rgba(126,184,218,0.1);

/* ── Fonts ── */
--font: 'Geist', system-ui, -apple-system, sans-serif;
--mono: 'Geist Mono', ui-monospace, monospace;

/* ── Type Scale (×1.333 Perfect Fourth) ── */
--step-0: 1rem; /* 16px */
--step-1: 1.333rem; /* 21px */
--step-2: 1.777rem; /* 28px */
--step-3: 2.369rem; /* 38px */
--step-4: 3.157rem; /* 50px */
--step-5: 4.209rem; /* 67px */

/* ── Easing ── */
--ease-out: cubic-bezier(0.16, 1, 0.3, 1);
Digitale Staat · Design System Token Reference · Joran Kooij
Ratio ×1.333 · 12-col grid · Geist Sans + Mono · v2.0
Samenvattende conclusie

Een systeem wat met de klant meegroeit.

De website is gegaan van 'een gevoel' naar een set stevige, onbreekbare funderingen. Iets wat het development team in één keer kan oppikken.

Doordat elke marge, lettergrootte en kleur vastzit in logische variabelen, gaat er aan de achterkant veel minder mis.

Methodische Reflectie (STARR) BC 3.1

Waar de waarde van een systeem écht zit.

Hieronder kijk ik volgens de STARR-methodiek terug op wat ik heb geleerd bij het bouwen van dit design system.

Situatie

Toen ik begon met mijn stage, moest ik een overkoepelend digitaal fundament maken voor de website van Grafische Republiek. Tot dat moment was ik gewend om per los scherm te werken: als het er goed uitzag, was het af.

Taak

Het ging er niet om mooie schermen te maken, maar om strikte, herbruikbare bouwblokken vast te leggen (tokens en atomen). Die moesten wiskundig kloppen en zo opgebouwd zijn dat developers ze konden overnemen zonder dat er onverwachte dingen misgingen.

Actie

Ik heb mijn werkwijze behoorlijk omgegooid. Ik dwong mezelf om elk font-weight, elke rand en spacing vast te leggen. Als een knop of marge in Figma 'net iets lekkerder' zou vallen met 2 pixels verschil, paste ik het niet zomaar lokaal aan. Ik checkte eerst of het via de globale variabelen opgelost kon worden, en of dat ook voor alle andere componenten zou werken.

Resultaat

Eerlijk gezegd: in het begin voelde dit alsof ik mijn eigen creatieve vrijheid aan het inperken was. Maar door diezelfde structuur verdwenen in de eerste sprints bijna alle nutteloze discussies met developers over pixelafstanden. Ik bouwde sneller en de visuele ruis ging flink omlaag. Het eindresultaat was consistenter en toegankelijker dan alles wat ik op school 'op gevoel' had gemaakt.

Reflectie (BC 3.1)

Als ik terugkijk snap ik nu het verschil tussen mooie plaatjes maken en echt digitaal design neerzetten. De waarde zit niet in hoe het eruitziet, maar in de overdraagbare logica erachter. Mijn valkuil was dat ik me blindstaarde op visuele perfectie in mijn eigen Figma-bestand. Bij volgende opdrachten stap ik eerder uit het canvas en denk ik vanuit de developer: eerst de logica vastleggen, dan pas ontwerpen.

Literatuur & Referenties BC 8.1.2

Bronnenlijst

De theorie en de fundamenten achter de structuur en kaders die ik heb gebruikt:

Nielsen Norman Group (NN/g): Jakob's Law

Onderbouwing voor de focus op hiërarchie: gebruikers brengen de meeste tijd door op ándere sites, dus best-practices en herkenbare interactiepatronen zijn altijd de veiligste keuze.
Bekijk het NN/g artikel over Jakob's Law ↑

Gestaltpsychologie: Law of Proximity

Objecten die dicht bij elkaar staan worden door het brein als één groep gezien. Dit principe stuurt de marge-tabellen aan (bijv. 8px voor een knop vs. 75px voor witruimte tussen secties).
Lees over the Law of Proximity ↑

Web Content Accessibility Guidelines (WCAG 2.1)

Richtlijn 1.4.12 over Text Spacing. Hierin staan de minimale afstanden (zoals line-height van minimaal 1.5x de font size) die nodig zijn voor leesbare en toegankelijke tekst.
Raadpleeg WCAG 1.4.12 Text Spacing ↑

Material Design (Google)

Het grid-framework dat de wiskundige onderbouwing geeft voor 4-koloms (mobiel) en 12-koloms (desktop) indelingen, vloeiende schaalfuncties en consistente marges.
Bekijk het Material Design Layout Grid ↑

Next project

Hallo Buur