Het is een veelvoorkomend patroon om een logo in de header te gebruiken als een link naar de homepage. Maar wat moet de toegankelijke naam van de link zijn? "Gemeente Voorbeeld", "homepage" of "Logo gemeente Voorbeeld"? Maakt het überhaupt uit?

De toegankelijke naam wordt voorgelezen door screenreaders zodat blinde en slechtziende bezoekers ook weten waar de link naartoe gaat.

Het probleem met het linken van een logo is dat het twee doelen dient:

• een logo, dat aangeeft welke site je bezoekt;
• een link, die naar de homepage leidt.

Leg dus uit dat dit een logo is en waar de link naartoe leidt: "Sitenaam logo, naar de homepage." Je kunt er ook voor kiezen 'homepage' te wijzigen in 'voorpagina'.

Let op: Begin de toegankelijke naam altijd met de zichtbare tekst, zodat de link gemakkelijker te selecteren is voor mensen die spraakherkenningssoftware gebruiken.

Optie 1: De toegankelijke naam in het alt-attribuut van een afbeelding

Gebruik je een afbeelding zoals een .gif, .png, .jpg of .svg, dan kun je het alt-attribuut gebruiken om de link een toegankelijke naam te geven. De inhoud van het alt-attribuut, de alt-tekst van een afbeelding binnen een link, wordt dan toegevoegd aan de linktekst.

Laten we NL Design System als voorbeeld nemen.

In de code (vereenvoudigd):

<a href="https://nldesignsystem.nl/">
  <img alt="NL Design System logo, naar de homepage" src="logo-nlds.svg" />
</a>

Gegenereerde HTML:

Hoe lezen screenreaders dit voor?

• VoiceOver in Safari: 'Link, afbeelding, NL Design System logo, naar de homepage'.
• NVDA in Firefox : 'NL Design System logo, naar de homepage, afbeelding, link'.

Alle informatie is aanwezig.

Er is een voordeel van het gebruik van het alt-attribuut in plaats van een aria-label oplossing. Wanneer de verbinding traag is, zal de alt-tekst al verschijnen voordat de afbeelding wordt geladen en informeert het alle gebruikers al over de naam van de site en het linkdoel. Het is behoorlijk robuust.

Optie 2: De toegankelijke naam in een aria-label bij de link.

Bij een afbeelding

Wanneer de toegankelijke naam met een aria-label in het <a>-element staat, overschrijft dit alle inhoud binnen de link, dus de inhoud van het alt-attribuut van de afbeelding wordt ook niet voorgelezen. Geef de afbeelding zelf wel een goede alt-tekst mee, zeker als je de afbeelding vaak hergebruikt op de website.

In de code (vereenvoudigd):

<a aria-label="NL Design System logo, naar de homepage" href="https://nldesignsystem.nl/">
  <img alt="NL Design System logo" src="logo-nlds.svg" />
</a>

Bij een inline SVG

Het voordeel van een aria-label bij de SVG gebruiken in plaats van <title> en aria-labelledby, is dat er geen tooltip verschijnt als je over het logo hovert met de muis.

Ook hier: logo moet op zichzelf kunnen staan als het herbruikbaar is en krijgt daarom een role="img" mee en aria-label="NL Design System logo" als toegankelijke naam. Begin hier weer met de zichtbare tekst.

In de code (vereenvoudigd):

<a aria-label="NL Design System logo, naar de homepage" href="https://nldesignsystem.nl/">
  <svg aria-label="NL Design System logo" role="img">[...]</svg>
</a>

Gegenereerde HTML:

Hoe lezen screenreaders dit voor?

• VoiceOver in Safari: 'Link, afbeelding, NL Design System logo, naar de homepage'.
• NVDA in Firefox : 'NL Design System logo, naar de homepage, link'.

Discussie

Disclaimer: Dit artikel gaat alleen over het toekennen van de toegankelijke naam. Bij de implementatie op een website komt meer kijken, zoals de weergave van de focus-stijl, de exacte locatie en het toekennen van aria-current="page" of het verwijderen van de link op de voorpagina.

Heb ik het woord 'logo' nodig? Is dat niet overbodig, zoals het woord 'afbeelding' of 'foto'?

Ja, in dit geval geeft het feit dat dit een logo is belangrijke informatie.

Niet alleen voor blinde gebruikers, maar voor alle screenreadergebruikers. Als je visueel beperkt bent, maar niet volledig blind, kun je de afbeelding vaag zien. Door het woord 'logo' toe te voegen, weet je ook wat de afbeelding is. Een logo is een beeldmerk, en dat voegt legitimiteit toe aan een site.

De naam van de site is vereist, maar het woord logo biedt extra context.

Is dit geen overtreding van 2.5.3 Label in naam?

Het WCAG-succescriterium 2.5.3 Label in naam stelt: Voor bedieningselementen met een zichtbaar label, moet de zichtbare labeltekst aanwezig zijn in of overeenkomen met de toegankelijke naam.

Dus nee, deze constructie is geen overtreding. De zichtbare naam staat in de alt-tekst of in het aria-label, die de toegankelijke naam van de link wordt. Het toevoegen van extra context aan de link is gebruikelijk.

Vergelijk dit met de beruchte "Lees meer"-link. Een veelvoorkomend patroon is om een sr-only CSS-class (of gelijkwaardig) te gebruiken met extra tekst:

<a href="url">
  Lees meer
  <span class="sr-only"> over de eikenprocessierups</span> </a
>.

• Je ziet "Lees meer".
• Je hoort "Lees meer over de eikenprocessierups".

In ons geval:

• Je ziet de naam van de site en het logo; de visuele positie geeft het linkdoel aan.
• Je hoort de naam van de site, het feit dat het een logo is, en het linkdoel.

De hele zichtbare tekst moet in de toegankelijke naam staan, maar extra informatie, zoals de betekenis van de afbeelding en het linkdoel, kan voor context worden toegevoegd. Zo wordt het doel van de link uitgelegd.

Note: Deze blogpost bevat een groot deel van de inhoud van het Engelstalige artikel A link on a logo in the header, what should the alt-text be? en is overgenomen met toestemming van de auteur.

Het doel is om de zogenaamde A-status voor je website te halen in het Register van toegankelijkheidsverklaringen voor jouw website. Maar ook om de website gebruiksvriendelijk en voorbereid op de toekomst te bouwen.

Dus, ook als je de website niet voor een overheidsinstelling ontwikkelt, ook dan is het zinvol om deze stappen te volgen om je bezoekers een toegankelijke en gebruiksvriendelijke website aan te bieden.

Stap 1: Van tevoren op orde hebben

Een goede voorbereiding is het halve werk en voorkomt verrassingen tijdens het proces.

Alle neuzen dezelfde kant op

Wil je de toegankelijkheid waarborgen? Zorg ervoor dat iedereen in het project hiervan weet en het belang ervan inziet. Iedereen is verantwoordelijk voor het eigen werk, wat je oplevert moet goed zijn.

Iedereen is verantwoordelijk voor de kwaliteit van het project. Voor de snelheid, veiligheid, leesbaarheid, gebruiksvriendelijkheid en ook voor de toegankelijkheid. Al bij de start van het project moeten alle neuzen dezelfde kant op wijzen.

Iedereen doet mee, van product owners, product- en projectmanagers, ontwerpers, programmeurs, contentmanagers, webschrijvers en iedereen die inhoud aanlevert voor de website.

Heeft de organisatie een wettelijke verplichting om een toegankelijke website te hebben? Maak dit duidelijk binnen het team en het management.

WCAG en NL Design System richtlijnen

Met de Web Content Accessibility Guidelines (WCAG) meten we de toegankelijkheid van een website voor mensen met een beperking. Leg van tevoren vast dat je wilt gaan voldoen aan WCAG, versie 2.2, niveau AA. Dan ben je voor de komende jaren verzekerd dat het project voldoet aan de meest recente richtlijnen voor toegankelijkheid.

Zijn er uitzonderingen op deze richtlijnen, zoals het gebruik van een navigatiekaart? Leg dit ook van tevoren vast en denk alvast na over toegankelijke alternatieven.

Het NL Design System schrijft richtlijnen die uitleggen hoe te voldoen aan WCAG, maar ze gaan ook een stapje verder. Bevindingen uit gebruikersonderzoek zijn ook meegenomen bij onze richtlijnen.

De combinatie WCAG en de NL Design System richtlijnen helpen je om een toegankelijke en gebruiksvriendelijke website op te leveren die de A-status verdient.

Stel je team samen

Wie gaat de website maken of aanpassen? Komen de teamleden uit de organisatie zelf? Huur je externe krachten in via een leverancier? Of wordt het een combinatie? We noemen deze mensen hier voor het gemak 'het team'.

Huur je een extern webbureau in, onderzoek dan of ze voldoende kennis en ervaring hebben in het maken van een toegankelijke website. Janita Top schreef hier een goede checklist voor: Welke vragen stel je aan een webbouwer over toegankelijkheid? Vraag de leverancier ook hoe het team kennis over toegankelijkheid bijhoudt, welke opleidingen en trainingen ze volgen.

Train je team

Zorg voor goede training van het hele team, inclusief de ontwerpers, programmeurs, contentmanagers en de tekstschrijvers. Ook als eenmaal de website online staat is het belangrijk het team getraind te houden. Contentmanagers komen en gaan. Garandeer dat iedereen die content op de website plaatst vooraf een goede training krijgt.

We geven je hier een aantal gerenommeerde opleiders: The Internet Academy, The A11Y Collective, Swink, Stichting Accessibility en Deque University.

Bereid gebruikersonderzoek voor

Een belangrijk onderdeel van de ontwikkeling van een toegankelijke website is feedback van gebruikers. We doen allemaal aannames, maar kloppen die ook? Er is maar één manier om dat uit te vinden en dat is door met anderen in gesprek te gaan.

Het liefst ga je met mensen in gesprek die jouw website waarschijnlijk zullen gebruiken, je doelgroep. Maar je kunt ook laagdrempelig starten door mensen van de straat te plukken of uit je omgeving of organisatie te vragen.

Zorg er in ieder geval voor dat je ook mensen met een beperking mee laat doen in het onderzoek. We noemen dit ervaringsdeskundigen.

Denk daarbij aan mensen met een visuele, motorische of cognitieve beperking. Of mensen die laaggeletterd of minder digitaal vaardig zijn. Kortom, een doorsnede van de samenleving.

Er zijn organisaties die je kunnen helpen met het opzetten en uitvoeren van gebruikersonderzoek. Inclusief het werven van gebruikers, zoals:

• Oogvereniging
• Stichting Accessibility
• Valsplat

Beschik over een specialist webtoegankelijkheid

Beschik je over iemand met expertise over webtoegankelijkheid voor begeleiding in het hele project? Het kan nuttig zijn om een specialist webtoegankelijkheid in te huren of intern op te leiden voor consultancy.

Voor training van het team, als vraagbaak en voor tussentijdse beoordeling van het werk. Dat voorkomt dubbel werk, dus hogere kosten en verrassingen bij de WCAG-audit aan het einde van het traject.

Stap 2: Bepaal wat je gaat maken

Wat is het doel van je website? Wees hierin heel concreet. Wat is essentieel, wat zou leuk zijn maar is niet echt nodig. En zet je ego en persoonlijke voorkeur opzij, denk puur vanuit de gebruiker.

Mensen komen op je website met een doel en niet om zich te verbazen over de prachtige animaties en sliders. Hou altijd het doel op de eerste plaats en je hoeft niets steeds het wiel opnieuw uit te vinden.

Onderzoek welke functionaliteit je nodig hebt en wat je wilt maken. Ook mensen met een beperking moeten je website kunnen gebruiken. Less is more. Als het heel moeilijk te gebruiken is voor mensen met een beperking, is het waarschijnlijk voor iedereen te moeilijk.

• Welke informatie wil je aanbieden?
• Op welke manieren kan de gebruiker met je communiceren?
• Welke formulieren zijn er nodig, en wat gebeurt er met de gegevens die mensen insturen?
• Bevat de website video en audio? Hoe ga je de ondertiteling en transcriptie regelen? Is hier capaciteit en budget voor?
• Hoe publiceer je digitale documenten? Zijn deze documenten toegankelijk of heb je een alternatief als webtekst?
• Ben je afhankelijk van functionaliteit die wordt geleverd door andere partijen, bijvoorbeeld formulieren of een afsprakensysteem? Zorg er dan voor dat deze partijen kunnen aantonen dat hun product toegankelijk is.

Onderzoek of er al voorbeelden zijn van wat je wilt gaan maken, is hier al onderzoek naar gedaan? Op Gebruikersonderzoeken.nl staan verschillende onderzoeken, bijvoorbeeld voor ‘Mijn Omgevingen’ en ‘Online Meldingen’.

Hoewel het werk hier in losse stappen is opgeschreven, is het belangrijk om als team continu met elkaar af te stemmen.

Daarnaast kunnen teamleden ook 'los' van elkaar e.e.a. uitzoeken. Bijvoorbeeld: de interactie-ontwerper onderzoekt de eerste opzet van de navigatie structuur, de visueel ontwerper maakt typografische keuzes, en de programmeur zoekt alvast goede componenten voor de specifieke functionaliteit.

Stap 3: Interactie-ontwerp

Heb je wat je wilt gaan maken goed op een rij? Dan kun je starten met het interactie-ontwerp. Hoe zorg je ervoor dat de benodigde functionaliteit uit stap 2 samenkomt in een bruikbare website?

In het interactie-ontwerp hebben we het nog niet over huisstijlelementen zoals kleur, typografie of fotografie, maar puur over de functionaliteit.

Werk nauw samen met de visueel ontwerper, de programmeur en de specialist toegankelijkheid. Zijn plannen goed en ook toegankelijk te realiseren? Of kunnen er beter andere keuzes worden gemaakt? Goed overleg scheelt in het latere proces heel veel tijd.

In het interactie-ontwerp neem je op hoe gebruikers door de website kunnen navigeren, wanneer je bepaalde informatie aanbiedt en hoe men met jouw organisatie kan communiceren'. Wat komt er in de hoofd- of subnavigatie? Zijn er verschillende manieren om inhoud te vinden, bijvoorbeeld via de hoofdnavigatie en de zoekfunctionaliteit? Hoe zijn de tekstpagina's opgebouwd? Hoe zijn de formulieren samengesteld?

Bij onze richtlijnen voor formulieren is al veel uitgewerkt. Bijvoorbeeld over de plaatsing van labels, invoervelden en knoppen. Hoe je een meerstappenformulier op kan zetten en hoe feedback te geven op fouten.

Denk na over alternatieven voor ontoegankelijke functionaliteit. Hoe vergroot je een kaart of versleep je een element? Moet je een mobiel schudden voor een refresh? Niet iedereen heeft twee vingers of kan een hand gebruiken.

Onze WCAG-pagina's beschrijven wat van belang is bij het interactie-ontwerp, zoals onder andere:

• Maak de inhoud een logisch verhaal als je van boven naar beneden leest.
• Zet de navigatie op dezelfde plek op elke pagina, en de onderdelen in dezelfde volgorde.
• Zorg ervoor dat componenten die dezelfde functie hebben binnen een website in naamgeving consistent zijn, er hetzelfde uitzien en ook hetzelfde werken.
• Denk na hoe het ontwerp er in verschillende weergaven en op verschillende apparaten eruitziet.
• De webpagina moet in landscape- en in portrait weergave goed leesbaar zijn.
• Voorkom vaste groottes van een tekstkader, zorg ervoor dat de tekst makkelijk vergroot kan worden.
• Besteed zorg aan het voorkomen en aanduiden van fouten bij formulieren.
• Reserveer plek voor foutmeldingen en descriptions en statusberichten.
• Denk na over tijdslimieten bij het invullen van formulieren, hoe geef je die aan.
• Voorkom onverwacht gedrag, bijvoorbeeld bij filters of formulieren.
• Zorg voor meerdere manieren om content te vinden, bijvoorbeeld via een hoofdnavigatie, de zoekfunctionaliteit, informatie en links in de footer, een broodkruimelpad of een sitemap.
• Help de gebruiker zo goed als het kan de taak te vervullen op je website. Zorg ervoor dat ze gemakkelijk om hulp kunnen vragen als ze er niet uitkomen.
• Maak het makkelijk om veilig in te loggen. Voorkom captcha's en rekensommen. Sta copy/paste van een wachtwoord toe, zodat een gebruiker een wachtwoordmanager kan gebruiken.

De programmeurs kunnen met dit ontwerp eigenlijk al aan de slag, het geeft de grote lijnen aan van de opbouw en functionaliteit van de website. Het NL Design System biedt hiervoor herbruikbare componenten, bij onze componenten is al veel functionaliteit uitgewerkt.

Hoe het er dan precies uitziet kan later, in stap 5, worden toegevoegd nadat het visueel ontwerp is gemaakt.

Gebruikerstesten op het interactie-ontwerp

Voordat de visueel ontwerper aan de slag kan, is het noodzakelijk om het interactie-ontwerp door gebruikers te laten testen. Zijn de aannames van het team juist. Wat is goed en wat kan beter.

Geef gebruikers een gerichte taak. Bijvoorbeeld: "Er zit een stoeptegel los bij jou in de straat, ga het melden bij je gemeente", "Bestel 6 flessen bronwater, kies een bezorgadres en reken af met iDEAL". Observeer dan welk pad ze nemen, wat lukt en waar ze tegenaan lopen.

Stap 4: Visueel ontwerp

Nu gaat de visueel ontwerper aan de slag en werkt het interactie-ontwerp uit tot een mooie visuele weergave van de website. Dit is de fase waar huisstijlelementen zoals kleur, typografie of fotografie worden bepaald. De look-and-feel, de uitstraling. Toegankelijke websites hoeven zeker niet lelijk en saai te zijn.

Bij onze richtlijnen voor stijl zijn de onderwerpen typografie, kleuren, ruimte en iconen uitgewerkt.

Belangrijk om in het visueel ontwerp aan WCAG te voldoen is onder andere:

• Zorg voor een voldoende kleurcontrast tussen tekst en achtergrond zodat je ook je bezoek ouder dan 50 jaar de tekst kan lezen.
• Zorg voor voldoende kleurcontrast tussen de achtergrondkleur en de kleur van componenten die visuele betekenis hebben. Zoals formulierelementen en iconen.
• Zorg ervoor dat kleur niet het enige visuele middel is om informatie over te brengen, blinde en kleurenblinde mensen kunnen deze betekenis missen.
• Ontwerp naast een stijl voor hover ook een stijl voor de toetsenbordfocus.
• Zorg ervoor dat ook mensen met dikke vingers een knop kunnen aanklikken.

Stap 5: Bouw

Goede betekenisvolle HTML-code is essentieel voor toegankelijkheid. Alleen dan werkt een website echt goed met de verschillende soorten hulpmiddelen.

Zo kunnen mensen met een beperking een website gebruiken met:

• alleen een toetsenbord;
• een toetsenbord met een screenreader;
• een toetsenbord met een screenreader en een brailleregel;
• spraakbesturing;
• een aanwijsstok.

Voor al deze hulpmiddelen geldt: de website moet te bedienen zijn met het toetsenbord. En dat is door het gebruik van goede HTML goed mogelijk. Daarnaast is het belangrijk dat een screenreadergebruiker de informatie goed voorgelezen krijgt.

Bij de richtlijnen voor formulieren en bij de WCAG-pagina's staan codevoorbeelden over wat belangrijk is en hoe je wel en niet moet bouwen.

WCAG-succescriteria voor toetsenbordbediening zijn onder andere:

• Zorg dat alle functionaliteit met een toetsenbord te bedienen is.
• Pas op voor een toetsenbordval.
• Maak geen extra sneltoetsen aan die bestaan uit één letter.
• Zorg voor een skiplink, die het menu overslaat
• Maak de tabvolgorde logisch en voorspelbaar.
• Zorg ervoor dat een element dat de toetsenbordfocus heeft niet volledig bedekt is door andere inhoud.
• Zorg dat het goed zichtbaar is welk element de toetsenbordfocus heeft.

Er zijn meer WCAG-succescriteria die op de code betrekking hebben. We leggen bij elk WCAG-succescriterium wat belangrijk is en uit hoe hiervoor te testen. En bij de componenten staan acceptatiecriteria waaraan een component moet voldoen om toegankelijk te zijn.

De beste tijd en manier om te testen is tijdens het bouwen in de browser. Naast je eigen toetsenbord zijn er ook browser tools die helpen. De bekendste is de gratis axe DevTools voor Chrome, Firefox en Edge.

Componenten

Programmeurs en ontwerpers kunnen gebruikmaken van het NL Design System om een website toegankelijk te bouwen.

De documentatie bij de componenten van het NL Design System beschrijft hoe een component is opgebouwd en aan welke acceptatiecriteria deze moet voldoen. Kijk bijvoorbeeld bij de component "button".

Veel van onze componenten zijn nu (2025) nog in volop ontwikkeling, maar je kunt al meekijken in de keuken. Samen met onze community ontwikkelen we componenten die herbruikbaar, functioneel en toegankelijk zijn en ondersteund worden door gebruikersonderzoek.

Het doel is om alle componenten volgens het estafettemodel stap voor stap in de 'Hall of Fame' te krijgen, waarna ze voor iedereen te gebruiken zijn. Zodat jouw team het wiel niet opnieuw hoeft uit te vinden.

Stap 6: Inhoud vullen

Zorg ervoor dat de contentmanagers en webschrijvers een goede training hebben gehad, en dat elke nieuwkomer een training krijgt voordat deze aan de slag gaat. Een website kan volledig goed ontworpen en gebouwd zijn, toegankelijke content is zeker net zo belangrijk.

De contentmanagers moeten het mandaat hebben om plaatsing van ontoegankelijke digitale documenten te weigeren. Ook al staat de burgemeester er persoonlijk op. Alles wat op de website komt, moet toegankelijk zijn.

WCAG-succescriteria voor de content zijn bijvoorbeeld:

• Beschrijf met koppen de inhoud die eronder staat, maak de koppenstructuur betekenisvol. Gebruik koppen niet alleen om tekst vet en groot te maken.
• Geef afbeeldingen een goede alternatieve tekst.
• Voeg je video toe? Zorg dan voor ondertiteling zodat dove en slechthorende bezoekers de inhoud ook kunnen volgen.
• Schrijf duidelijk, betekenisvolle linkteksten en vermijdt 'klik hier'.

Stap 7: Eindtest met gebruikers

Is je website gebouwd en gevuld met inhoud? Test dan nogmaals met gebruikers. Betrek mensen met en zonder beperking

Het is een misverstand dat testen met gebruikers met een beperking hetzelfde is als testen op toegankelijkheid. Je kunt pas testen met deze gebruikers als de site helemaal toegankelijk is en voldoet aan de WCAG-richtlijnen. Een blind persoon ziet niet wat ze mist. Een beperking komt niet met een handleiding. Ook deze mensen worstelen, net als iedereen, met het web.

In deze fase testen we of men een opdracht van begin tot eind succesvol kan afronden. Denk daarbij aan het opzoeken van een telefoonnummer, een melding doen, een klacht indienen of een zwarte wollen trui in de maat M bestellen én afrekenen.

Pas de website aan naar aanleiding van je bevindingen.

Heb je gebruikersonderzoek gedaan en wil je dat delen? Overweeg de resultaten te plaatsen op gebruikersonderzoeken.nl

Stap 8: Toegankelijkheidsverklaring

Alles af? Gebruikerstesten verwerkt? Inhoud helemaal gevuld. Alle formulieren werken? Laat dan een officiële WCAG-EM audit doen. Liefst door een onafhankelijke partij en niet door je eigen specialist toegankelijkheid. Dit voorkomt het 'Wij van WC-eend' effect.

Deze audit is maximaal 3 jaar geldig. Als er grote functionele veranderingen zijn is het aan te raden om eerder een nieuwe audit te laten doen.

In Nederland is er een aantal onderzoeksbureaus die officiële audits verzorgen. Verwerk eventuele punten die nog uit de audit komen.

Overheidsinstellingen kunnen een toegankelijkheidsverklaring aanmaken op het Register van toegankelijkheidsverklaringen.

Als je dan een mooie toegankelijke website hebt opgeleverd wil je dat natuurlijk aan iedereen vertellen. Dit kan op een speciale pagina op je website 'Toegankelijkheid'.

Vermeld hierin:

• Hoe de website getest is, met een verwijzing naar het WCAG-EM rapport of met een link naar het Register van toegankelijkheidsverklaringen.
• Welke problemen er eventueel nog zijn en wanneer die worden opgelost.
• Hoe bezoekers contact kunnen opnemen als ze een probleem hebben bij het gebruik van de website.

Let op: Zorg ervoor dat de klantenservice (of andere ontvanger van de klacht) ook weet wat te doen als er een melding over de toegankelijkheid van de website binnenkomt.

Stap 9: Onderhoud

Een website is nooit af en verandert voortdurend, dit betreft in ieder geval de webteksten. Blijf de toegankelijkheid bewaken. Zorg ervoor dat de contentmanagers en webschrijvers getraind blijven. Want plaatjes zonder alternatieve tekst, onduidelijke links of een verkeerde koppenstructuur sluipen er zo in. Leg een procedure voor onboarding vast, ook op het gebied van toegankelijkheid.

Laat regelmatig, bijvoorbeeld één keer per jaar, een controle uitvoeren door een specialist webtoegankelijkheid. Is de website nog in orde, is het team nog steeds goed getraind? Is er nieuwe functionaliteit bij gekomen en is deze ook toegankelijk?

Tot slot

Iedereen van het team is verantwoordelijk voor de kwaliteit van het project. Voor de snelheid, veiligheid, leesbaarheid, gebruiksvriendelijkheid en ook voor de toegankelijkheid.

We maken een website niet voor onszelf maar voor de gebruiker. Als iedereen goed met je website overweg kan, dan pas is je doel bereikt.

“Kijken hoe verschillende producten bij elkaar gebracht kunnen worden, daar was ik eigenlijk altijd wel mee bezig. Denk aan het samenbrengen van design, zodat alles meer in 1 lijn is”, zegt Aline Nap. Als UX-designer werkt zij samen met haar collega’s aan een eigen design system voor Logius: LUX (afkorting van Logius User eXperience). Raoul Wittenberns is als architect betrokken bij de opzet van LUX en richt zich voornamelijk op het goed laten landen van het nieuwe design system binnen Logius. De inspiratie voor het ontwikkelen van LUX halen ze onder andere uit de community van NL Design System. Aline en Raoul vertellen over de ontwikkeling en plannen met LUX én blikken voorzichtig vooruit.

Interesse in NL Design System

Aline vertelt dat ze altijd al interesse had in design systems. 3 jaar geleden is Logius gestart met het opnieuw bouwen van de producten rondom authenticatie en machtigen. Denk hierbij aan de DigiD inlogschermen, digid.nl en machtigen.digid.nl. Maar ook de interface voor de helpdeskmedewerkers. “Voor deze herbouw had ik de kans om samen met mijn collega’s een design system te bouwen voor DigiD. Welke componenten en patronen zijn herbruikbaar in de verschillende producten van DigiD?”

Machtigen, DigiD homepage en DigiD inlogscherm

Aline: “Met mijn UX-collega’s keek ik ook naar andere producten die Logius maakt. Hoe sluiten de interactiepatronen en stijl op elkaar aan? Daarnaast ben ik mij gaan verdiepen in NL Design System. Ik was benieuwd welke kennis daar te halen was. De magie van design tokens greep mij direct. Het is fijn om direct veel informatie te vinden én gelijkgestemde mensen binnen de community.”

Toestemming van ‘hogerop’ nodig

Componenten en patronen inventariseren, best practices uitzoeken om vervolgens tot een gezamenlijk ontwerp te komen kost tijd. Zeker als het gaat om meerdere producten. Deze tijd wordt vaak onderschat of niet geprioriteerd, waardoor het werk blijft liggen. Zo ook bij Logius. Als designers keken wij met een schuin oog naar elkaars werk, maar tijd om hierop door te ontwerpen is schaars. Om vervolgens deze aanpassingen in de code te krijgen is helemaal een uitdaging.

Daarom begonnen we met het voeren van de nodige gesprekken om aan te sluiten op NL Design System. Denk aan gesprekken tussen designers en architecten om te bedenken hoe het maken van 1 gezamenlijk design system gerealiseerd kan worden. Aline: “Eigenlijk was er van ‘hogerop’ toestemming nodig om mensen vrij te maken, zodat zij moeite én tijd erin kunnen steken. Uiteindelijk ontstond er een groep van enthousiaste mensen die zich hard hebben gemaakt om budget te krijgen, zodat we verder konden werken aan het Logius Design System (later dus LUX).”

De uitdagingen van Logius

De grootste uitdaging van LUX is dat het over meerdere producten gaat. Denk aan MijnOverheid, Digitoegankelijk en DigiD. Deze producten hebben momenteel allemaal een eigen Storybook en Figma-bibliotheek. LUX is een soort mini community binnen NL Design System. Hierdoor kunnen wij veel leren en hergebruiken van de werkwijze van NL Design System. Maar ook van de design tokens voor meerdere thema’s, hoe je elkaars componenten kunt hergebruiken of zelf een community component opbouwt.

Componenten in verschillende thema's

De meeste partijen die aansluiten bij NL Design System hebben 1 huisstijl. Logius heeft er meerdere, daarom is de indeling van de tokens voor ons heel belangrijk. De kennis die wij hierover op doe delen we graag weer met de community.

“Het is een puzzel hoe we samen met zoveel teams en afdelingen kunnen werken aan een gezamenlijk design system", zegt Raoul. “Gelukkig is er enorm veel enthousiasme en helpt het dat we nu een toegewijd team hebben die de andere collega’s hier in kunnen helpen.

‘We willen beginnen met een component dat echt waarde levert’

Momenteel staat het project nog in de opstartfase, zegt Aline. “We zijn begonnen met het bouwen van een community component, zodat we als team bekend zijn met de stappen die daarvoor nodig zijn en zo de werkwijze van NL Design System leren kennen.

Het gaat hier om de Button login. Vanuit Logius is er beschreven hoe de inlogknoppen van DigiD, eHerkenning en European login eruit moeten zien. Als LUX bieden wij dit component aan, zodat een organisatie eenvoudig aan de Stijlhandleiding aansluiten Toegang kan voldoen. Het is een uniek component. Zo zijn updates aan de teksten, logo’s of opmaak gemakkelijk te doen.

Het button login component in Figma

De community van NL Design System is voor Aline dé plek om hun ideeën te toetsen en te testen. Aline: “Het is zo fijn dat mensen vanuit de community er echt mee aan de slag gaan. Het is een makkelijke manier om gelijkgestemde professionals te vinden die willen helpen en feedback geven. Het kernteam begeleidt ons hierbij, zodat de component door het estafettemodel van het NL Design System gaat. Uiteindelijk is het de bedoeling om de component ‘overheidsbreed’ te kunnen gebruiken.”

Componenten en gebruikersonderzoeken

Momenteel hebben we een aantal community componenten voorbereid voor de verschillende producten binnen Logius met design tokens. Deze gaan we de aankomende periode beschikbaar stellen in code zodat developers binnen Logius de community componenten kunnen gebruiken in hun project.

Raoul benadrukt dat Logius ook graag een bijdrage levert aan het NL Design System zodat andere overheidsorganisaties daar uiteindelijk ook van kunnen profiteren: “We doen bij Logius regelmatig gebruikersonderzoeken. Met producten als MijnOverheid en DigiD zijn we ook erg zichtbaar. We krijgen daarom regelmatig de vraag of we de onderzoeksresultaten en onze designs kunnen delen. We zien het NL Design System als de geschikte plek om dat te kunnen doen.” Raoul ziet voor zich dat in de toekomst kennis en componenten vanuit de NL Design System community in Lux gebruikt worden, en vanuit Lux weer kennis en componenten in de community gedeeld worden.

Wil je op de hoogte blijven van alles rondom NL Design System? Meld je dan aan voor onze nieuwsbrief.

In dit artikel ga ik stap voor stap in op het voorkomen, aanduiden en het geven van hulp bij foutmeldingen in een formulier voor verschillende soorten gebruikers.

Stel jezelf de volgende vragen:

• Wat wil ik echt weten?
• Hoe ga ik deze informatie uitvragen?
• Welke informatie kan ik vooraf geven om de gebruiker te helpen?
• Hoe geef ik aan welke velden verplicht zijn?
• Wanneer controleer ik op fouten?
• Hoe geef ik aan of een vraag niet of niet goed is ingevuld?
• Wat zijn goede teksten voor foutmeldingen?
• Hoe geef ik aan of een formulier succesvol is verzonden?
• Hoe bied ik hulp als een gebruiker er niet uitkomt?

We geven per stap referenties naar de verschillende richtlijnen voor formulieren van het NL Design System die dieper ingaan op de verschillende onderwerpen.

Bij deze richtlijnen staat ook uitgelegd hoe het technisch werkt om foutmeldingen ook goed aan te geven voor hulpmiddelen zoals een screenreader.

Niemand vult een formulier graag in en alle hulp is nuttig, hou dat doel voor ogen. Jij wilt wat weten van je gebruiker of je gebruiker wil jou wat vertellen. Maak dit proces zo makkelijk mogelijk.

Wat wil ik echt weten?

Een goede foutafhandeling begint eigenlijk al bij de vragen die je wilt stellen. Sommige vragen zijn lastig te beantwoorden. Is het echt belangrijk of je weet of iemand man of vrouw is? Wil je alleen contact opnemen via de telefoon? Misschien wil de gebruiker wat anders invullen, kan geen keuze maken en stopt met invullen.

Vraag alleen uit wat je echt nodig hebt om de gegevens goed te verwerken. Hoe minder je vraagt, hoe lager de drempel is om een formulier in te vullen.

Leg ook goed uit waarom je privacygevoelige persoonlijke informatie nodig hebt, bijvoorbeeld een burgerservicenummer of medische gegevens.

Lees hierover de richtlijnen over Uit te vragen informatie in een formulier en de blogpost Ik wil je wat vragen maar heb geen WhatsApp.

Hoe ga ik deze informatie uitvragen?

Kies je voor een uniek ontwerp voor je formuliervelden of ga je voor bekende herkenbare patronen? Probeer niet het wiel opnieuw uit te vinden voor zoiets essentieels als formuliervelden.

Bijvoorbeeld: gebruikers herkennen radiobuttons als rondjes en checkboxes als vierkantjes, hou je aan deze conventie want radiobuttons en checkboxen werken verschillend met toetsenbordbediening.

Heydon Pickering zegt hierover in zijn presentatie Get Your Priorities Straight: Real people aren't looking to be delighted. People want to get the task done and get on with their lives. In het Nederlands: 'Echte mensen willen niet blij gemaakt worden. Mensen willen de taak voltooien en doorgaan met hun leven'.

Ga altijd uit van je gebruiker, doe gebruikersonderzoek in plaats van aannames te doen. Mensen vullen een formulier niet in voor hun plezier, bekende patronen zijn voor formulieren altijd het beste.

Sommige formuliervelden kun je beter niet gebruiken omdat ze lastig te bedienen zijn, zoals multiselect. Gebruik je date pickers? Check de gebruikerservaring voor mensen die alleen een toetsenbord of een screenreader gebruiken.

Een simpele oplossing kan voor iedereen fijn zijn, zoals de wijze van datumselectie die de KLM gebruikt voor het invullen van een datum. Simpel, eenduidig en voor iedereen makkelijk te snappen en te bedienen.

Lees hierover de richtlijnen op Wanneer welk element.

Welke informatie kan ik vooraf geven om de gebruiker te helpen?

Je kent het vast wel: je vult een nieuw wachtwoord in, drukt op verzenden en dan pas krijg je te weten wat de eisen zijn. Waarna je boos naar het scherm roept 'vertel me dit dan vooraf'!

De blogpost Blind people don't visit my website somt frustraties op van gebruikers van het web. Bijvoorbeeld: 'Error messages that come afterwards and eventually don't explain what you need to change'. In het Nederlands: 'Foutmeldingen die achteraf komen en uiteindelijk niet uitleggen wat je moet veranderen'.

Laat de bezoeker niet raden maar geef zo veel mogelijk hulp, in begrijpelijke taal.

Geef voor het invullen bijvoorbeeld aan welke documenten de gebruiker nodig heeft bij het invullen, leg uit wat al dan niet verplichte velden zijn. Voeg zo nodig een description (beschrijving) toe bij een formulierveld met extra uitleg.

Lees hierover de richtlijnen Descriptions in een formulier en Voorkom fouten, help de gebruiker.

Hoe geef ik aan welke velden verplicht zijn?

Als je uitgaat van het principe 'ik vraag alleen uit wat ik echt wil weten', dan zouden alle velden verplicht kunnen zijn. Maar dat hoeft natuurlijk niet.

Hoe geef je dat het beste aan?

Veel sites gebruiken 'verplicht', 'optioneel', 'niet verplicht' of alleen een asterisk (*). Maar wat is het duidelijkst?

Liever 'niet verplicht' in plaats van 'optioneel'.
Liever 'verplicht' in plaats van een asterisk.

'Optioneel' is voor laaggeletterde lezers lastig en een asterisk vereist voorkennis van de betekenis. Gebruik je toch een asterisk, leg dan boven het formulier de betekenis uit.

Verplichte velden of niet-verplichte velden aanmerken?

Wat heeft de voorkeur: verplichte velden aanmerken of niet-verplichte velden aanmerken? Het hangt ervan af … Welke van de twee je kiest, is afhankelijk van de functionaliteit van het formulier, het CMS of de formulieren-plugin die je gebruikt en van gebruikersonderzoek.

Een keuze kan zijn: zijn de meeste velden verplicht, markeer dan de niet-verplichte velden. En andersom: zijn de meeste velden niet verplicht, markeer dan de verplichte velden.

Wat je ook kiest, wees consequent binnen het formulier en ook binnen alle formulieren van de website en laat de gebruiker altijd boven het formulier weten hoe al dan niet verplichte velden zijn aangemerkt.

Bijvoorbeeld met de tekst 'Vul alles in. Als iets niet verplicht is, staat dat erbij.'

Lees hierover de richtlijn Vermeld duidelijk of een veld wel of niet verplicht is .

Wanneer controleer ik op fouten?

Websites controleren op foutmeldingen tijdens het typen van een antwoord, na het verlaten van een formulierveld of na het verzenden van het formulier. Wanneer controleer je zo gebruikersvriendelijk mogelijk?

Al tijdens het typen controleren kan heel verwarrend zijn. Je bent een e-mailadres aan het typen en al bij de eerste letter verschijnt de fout 'ongeldig e-mailadres'. Ja, natuurlijk, ik was nog niet klaar met typen!

De richtlijn Gebruik geen HTML-formuliervalidatie legt uit dat foutafhandeling door de browser onvoldoende informatie geeft. 'Dit veld is verplicht' is te vaag en wordt ook niet door alle screenreaders goed voorgelezen.

Dan blijven er twee opties over: na het verlaten van het veld of na het verzenden van het formulier. Het een hoeft het ander niet uit te sluiten. Voor sommige velden kan het handig zijn om meteen te checken, zoals een datum die in de toekomst moet zijn. Maar een check na verzenden moet natuurlijk altijd gebeuren.

De volgende richtlijnen leggen uit hoe dit op te zetten:

• Controleer op het juiste moment op fouten.
• Schrijf een duidelijke foutmelding.
• Zet een samenvatting van de foutmeldingen boven het formulier.

Hoe geef ik aan of een vraag niet of niet goed is ingevuld?

Geef fouten aan met meer dan alleen een kleur. De kans is groot dat een gebruiker, die slechtziend of kleurenblind is, een rood randje om een formulierveld mist.

Het gebruik van kleur is prima en kan voor goedziende gebruikers heel duidelijk zijn, maar voeg altijd ook een duidelijke foutmelding in tekst toe.

De richtlijnen Vermeld duidelijk of een veld wel of niet verplicht is, Geef fouten weer met meer dan alleen kleur en Schrijf een foutmelding uit in tekst leggen dit uit.

Een samenvatting van alle fouten boven het formulier geeft de gebruiker een goed overzicht van wat er nog moet worden aangepast.

Wat zijn goede teksten voor foutmeldingen?

Melden zoals 'Dit veld is verplicht' of 'Ongeldige waarde' bieden de gebruiker te weinig hulp. Schrijf eenduidige foutmeldingen die uitleggen wat er ontbreekt of anders moet.

Bijvoorbeeld: 'Vul je voornaam in' of 'Je gekozen wachtwoord is te kort, kies een wachtwoord van minimaal 8 karakters lang'. Deze informatie biedt veel meer houvast aan gebruikers dan een algemene tekst.

De richtlijn Schrijf een duidelijke foutmelding gaat hier op in.

Hoe geef ik aan of een formulier succesvol is verzonden?

Je drukt op versturen en er gebeurt niets. Of je gaat naar de voorpagina. Is je vraag nu verzonden of niet?

Geef de gebruiker duidelijkheid en zekerheid dat het formulier daadwerkelijk succesvol is verzonden, welke informatie is verstuurd en wat er hierna gebeurt.

Dit kan daarnaast ook in een bevestigingsmail waarin de ingevulde informatie wordt herhaald of een verwijzing naar de "Mijn Omgeving", waar de informatie is terug te vinden.

Op de pagina Bevestigingspagina van een formulier staan de richtlijnen die uitleggen hoe de gebruiker te informeren dat het formulier verzonden is, wat eventueel de vervolgacties zijn en hoe contact op te nemen bij vragen.

Hoe bied ik hulp als een gebruiker niet uitkomt?

Als een gebruiker vastloopt of vragen heeft tijdens het invullen van een complex formulier, moet het makkelijk zijn om hulp te vragen.

Zet de contactinformatie dan niet helemaal onderaan het formulier, maar bijvoorbeeld bovenaan in een kort zinnetje. Ook de footer is een geschikte plek om contactinformatie in op te nemen. Zorg altijd voor verschillende manieren om contact op te nemen. Niet iedereen kan opbellen.

Samenvatting

Help je gebruiker zo goed mogelijk om een formulier in te vullen. Stel geen overbodige vragen, bied de juiste keuzes, vertel hoe een veld moet worden ingevuld, zorg voor duidelijke foutmeldingen op het juiste moment en geef aan hoe contact op te nemen als iemand er niet uitkomt.

Hou in gedachten: mensen willen een formulier graag snel invullen en daarna doorgaan met hun leven. Maak die taak dan zo gemakkelijk mogelijk.

Op de hoogte blijven van het NL Design System?

Ben je benieuwd naar de ontwikkelingen van het NL Design System? Meld je dan aan voor de maandelijkse nieuwsbrief of schuif aan tijdens de 2-wekelijkse update (Heartbeat). Hierin delen we alle relevante updates.

Terwijl de gemeente Den Haag met hun leveranciers werkte aan de nieuwe DenHaag.nl, ontstond al snel de behoefte herbruikbare onderdelen open source beschikbaar te maken. Met deze vraag gingen zij naar hun leveranciers. Dat resulteerde in zogenaamde ‘community blocks'. Het team wilde graag terugleveren aan de maatschappij, en slim omgaan met design en code. Dat maakte de keuze voor het NL Design System eenvoudig.

Wat zijn de NL Design System community blocks precies?

NL Design System community blocks is een plug-in die je in een WordPress-omgeving kan installeren. De plug-in bevat blokken voor de Gutenberg-editor, zodat redacties pagina's kunnen opbouwen met NL Design System-componenten. Ze worden gebruikt door de gemeente Den Haag, maar kunnen in de basis juist ook in andere organisaties worden ingezet. De componenten maken namelijk van je NL Design System-thema, via design tokens. Goed om te weten: de gebruikte componenten worden nog getoetst op bijvoorbeeld toegankelijkheid volgens het estafettemodel.

Behoefte aan breed inzetbare componenten

Tom vertelt: “We merken dat er steeds meer vraag is naar breed inzetbare componenten. De ontwikkeling van deze community blocks is oorspronkelijk ontstaan vanuit de behoefte van de gemeente Den Haag. Want componenten voor de Gutenberg WordPress-editor waren er nog niet. We zien dat de WordPress-community ontzettend groot is, net als de groeiende community van het NL Design System. Deze community's brengen we graag samen.”

Inmiddels staat er een eerste versie klaar van 15 componenten. Ook zijn er 17 componenten gemaakt om verder te ontwikkelen. Volgens Tom is er ook steeds meer behoefte aan het hergebruiken van code.

Tom legt uit dat ze nauw samenwerken met andere leveranciers, zoals Yard en Draad: “Hoe kunnen we ervoor zorgen dat al die gemeenten die zijn aangesloten bij het Open Webconcept eenvoudig kunnen aanhaken op het NL Design System? En hoe zorgen we ervoor dat de beschikbare financiële middelen slim worden gebruikt door middel van hergebruik? Daar kijken we samen met deze andere leveranciers naar. Overkoepelend kun je de NL Design System community blocks zien als een schakel voor organisaties om aan te sluiten bij het NL Design System. Ook is deze plug-in vrij te gebruiken, omdat er is gekozen voor de EUPL 1.2 licentie.”

‘Hoe kunnen we er nou aan zorgen dat de plug-in beter wordt?’

Volgens Tom is de kracht van de NL Design System-community heel fijn: “Het leuke is dat het verder ontwikkelen van de community blocks echt een gezamenlijke inspanning is. Er was onlangs een samenwerkdag tussen Acato, Yard en Robbert en Yolijn vanuit het NL Design System-kernteam. Samen keken we naar wat er nu staat en vooral: hoe kunnen we zorgen dat de plug-in nóg beter wordt? Maar ook hoe het gebruikt kan worden door andere organisaties en leveranciers.”

Tom vertelt dat de ambitie er is om NL Design System, Open Webconcept én WordPress verder samen te brengen en met elkaar te verweven. “Voor dat zover is, willen we de plug-in eerst verder toetsen met andere partijen. Waar lopen zij tegenaan en vooral: wat zijn de wensen van andere organisaties? Daarom zijn die samenwerkdagen ook zo belangrijk. Op die manier komt er feedback vanuit de community en dus ook automatisch vanuit andere organisaties.”

Meer weten?

Ben je benieuwd naar de gehele presentatie mét demo die Tom onlangs gaf tijdens de Heartbeat van het NL Design System? Kijk de opname dan terug via ons YouTube-kanaal. Tip: abonneer je om op de hoogte te blijven van alle updates vanuit het NL Design System!

De community van het NL Design System is op zoek naar organisaties die hierover willen meedenken. Vind jij het leuk om jouw feedback te geven? Maak een issue aan op GitHub, of stel je vraag op Slack in het kanaal #nl-design-system-developers.

Met een groep van 10 mensen vanuit projecten bij verschillende gemeenten, een leverancier en een ministerie, kwamen we bij elkaar. De locatie was wederom het stadskantoor van de Gemeente Utrecht, dank voor hun gastvrijheid. We werkten samen aan een flow voor het uploaden van bijlagen, notificaties en een themamaker. En dus het estafettemodel.

We begonnen met het estafettemodel…

De administratie op orde

Het ‘estafettemodel’ is dè manier waarop we bij NL Design System samenwerken aan richtlijnen, componenten en patronen. Hierin krijgen onderdelen een status, waarbij elke status een eigen checklist heeft als ‘Definition of Done’. Zo zorgen we in de ‘Help wanted’ stap bijvoorbeeld dat onderdelen een duidelijk doel hebben, breed gedragen worden en goed zijn onderbouwd.

Er zijn al heel wat componenten aanwezig in de community (meer dan 150). Een deel wordt ook al in productie gebruikt, bij verschillende organisaties. We zien al veel hergebruik van elkaars werk. Hoewel de administratie achter loopt, voldoen deze componenten dus waarschijnlijk al aan veel checks. Maar ‘waarschijnlijk’ is niet goed genoeg, we willen zeker weten dat ze voldoen.

We zijn deze administratie daarom check voor check aan het inhalen. Dat betekent bijvoorbeeld screenshots verzamelen, gebruikersonderzoek nagaan en varianten inventariseren. Tijdsintensief werk, maar essentieel om voor alle onderdelen zeker te zijn van de doelmatigheid, draagvlak en onderbouwing.

Samen componenten nalopen

Jeffrey Lauwers, UX designer in het kernteam, is al sinds januari veel van het voorwerk aan het doen. Hij heeft zodoende al voor veel componenten een inventarisatie gedaan. Dat is waarom je hem in onze Slack-community regelmatig hoort vragen naar het gebruik van verschillende componenten.

Op de samenwerkdag praatte Jeffrey ons door de Paragraph component heen, en konden we als groep vinkjes zetten bij de verschillende criteria. Zo weten we nu bijvoorbeeld dat de Paragraph component volledig voldoet aan de Definition of Done voor ‘Help Wanted’, en grotendeels aan die van ‘Community’.

Checks per component op het projectbord

Voor veel andere componenten zijn deze checks ook al uitgevoerd, een volledig overzicht zie je op ons ‘Help Wanted’ projectbord voor componenten.

Het vervolg

Wil je meewerken om componenten te inventariseren en van status te veranderen? Wil je meehelpen met het verzamelen van screenshots of onderzoek? Graag! De komende tijd zullen we regelmatig samenwerkdagen organiseren om componenten na te lopen. Deze samenwerkdagen zijn openbaar toegankelijk, laat Jeffrey of iemand anders uit het kernteam weten als je mee wilt doen.

Ondertussen blijven we als kernteam meer voorbereidend werk doen, om zo te zorgen dat er steeds meer componenten, naast dat ze al gebruikt worden in sites en plug-ins, de juiste status krijgen. Wordt vervolgd!

In december 2023 nam het team Innovatie en Dienstverlening van de gemeente Den Haag gebruikerstesten af met ondernemers uit de Haagse regio. Ananta maakte een nieuw prototype van een formulier om een horecavergunning aan te vragen. Vervolgens testten ze dit formulier met de deelnemers. Ananta vertelt: “Het nieuwe formulier is gefocust op het begeleiden van ondernemers bij het correct opstellen en indienen van documenten. Daarnaast wilden we het belang van het aanleveren van de juiste documenten benadrukken.”

De volgende onderzoeksvragen stonden centraal:

• In hoeverre geeft dit ontwerp voldoende ondersteuning om de benodigde documenten op te kunnen stellen?
• In hoeverre stimuleert dit ontwerp ondernemers om de aanvraag volledig in te vullen én in te dienen?
• In hoeverre hebben ondernemers het vertrouwen dat ze aan de hand van dit ontwerp zelf een correcte aanvraag kunnen indienen?
• Hoe ervaren ondernemers de navigatie door het aanvraagproces?
• Is de informatie volledig en duidelijk?

Alle aanvragen worden behandeld, ook als ze foutief of onvolledig zijn

Ananta en Margo vertellen dat er nog te veel aanvragen via online formulieren fout gaan. Denk aan het foutief invullen of onvolledige aanvragen waarbij bijlagen missen. Ananta: “Het is goed om te realiseren dat alle aanvragen die binnenkomen worden behandeld. Ook als ze foutief of onvolledig zijn. Dit kost de behandelaars extra tijd én zorgt uiteindelijk voor irritatie bij de aanvrager. Want het moet opnieuw of er moeten aanvullende stukken worden verstuurd. Dit proberen we nu te voorkomen door aan het begin van het proces aan te geven welke formulieren nodig zijn voor de betreffende aanvraag.”

Margo vertelt: “Aan het begin van de aanvraag in het prototype zie je een opsomming, waarin alle benodigde bijlagen staan vermeld. Hierboven staat ‘Heeft u deze documenten?’ Het is handig dat mensen de kans hebben om de aanvraag op te slaan, zodat ze op een later moment verder kunnen gaan. Zeker bij aanvragen waar meerdere bijlagen worden gevraagd, geeft dit mensen de kans om ze op te zoeken zonder het hele proces opnieuw te moeten starten.”

Het blijft volgens Margo niet alleen bij deze opsomming: “We hebben ervoor gekozen om een extra uitleg bij de benodigde documenten toe te voegen. Zoals: een uitleg waarom de gemeente dit nodig heeft bij de aanvraag, maar ook voorbeelden van documenten. Er verschijnt ook een waarschuwing als er een document mist. We hopen dat deze extra uitleg zorgt voor meer bewustwording van de aanvrager, zodat ze begrijpen dat het ontbreken van bijlagen consequenties heeft voor de aanvraag.”

Gebruikerstest met ondernemers uit Den Haag en omstreken

Uiteindelijk is het team gaan testen met 6 ondernemers uit Den Haag en omstreken. Dit bestond uit het doorlopen van het prototype-aanvraagformulier in combinatie met het uitvoeren van verschillende opdrachten. Iedere test duurde 1 uur.

Margo: “Het viel ons op dat de meerderheid van de deelnemers (na het zien van de waarschuwing) aangaf dat ze niet verder zouden gaan met het aanvraagproces zonder de benodigde documenten die aan het begin worden genoemd. Ook vonden ze allemaal de optie om tussentijds op te slaan heel handig. Daarnaast werden de voorbeelden die we in het prototype noemen als heel positief ervaren. Denk hierbij aan een voorbeeld van het maken van een ondernemingsplan.”

Doel: alle formulieren overzetten naar het nieuwe ontwerp

Volgens Ananta is het uiteindelijk de bedoeling dat alle formulieren voor vergunningen worden omgezet naar het nieuwe ontwerp: “De eerste stap is om de verantwoordelijkheid hiervan over te dragen aan de betreffende afdelingen. Vervolgens moeten de afdelingen de realisatie hiervan afstemmen met onze afdeling Online, zodat zij de formulieren daadwerkelijk gaan aanpassen én begrijpen wat er precies moet gebeuren. Daarnaast is het ook handig om te kijken naar wat er nog meer geoptimaliseerd kan worden in de toekomst. We willen uiteindelijk meer met gebruikersdata doen, zoals het meten van de website. Dit kunnen we dan weer vergelijken met de inzichten uit gebruikersonderzoeken. Denk aan informatie als wanneer klikken mensen weg?”

Ananta vertelt: “Bij het nieuwe ontwerp willen we de ‘waarschuwingsfunctie’ (alert) gebruiken uit de NL Design System-community. Bij het gedeelte waar mensen formulieren moeten toevoegen zie je momenteel de optie om alle formulieren in 1 keer te uploaden. Deze splitsen we nu uit in individuele documenten en het is de bedoeling dat de waarschuwingsfunctie naar voren komt als de aanvrager niet alle benodigde documenten upload.”

Benieuwd naar deze gebruikerstest?

Onlangs gaven Margo en Ananta een presentatie over dit onderwerp tijdens de 2-wekelijkse Heartbeat van het NL Design System. Ben je benieuwd en wil je het terugkijken? Bekijk de presentatie op YouTube.

Maak contact opnemen niet het probleem van je bezoeker

Stel: de bezoeker van je website wil een vraag stellen. De enige manier om dit te doen is een berichtje sturen via WhatsApp. Voor jou handig, 1 plek om alles bij te houden en snel te reageren. En je reageert als het jou uitkomt.

Maar er zijn meer voorbeelden, zoals:

• Je vermeldt alleen het telefoonnummer van de helpdesk. Want het is fijn om alles op een centrale plek op dezelfde wijze bij elkaar te hebben. Past mooi in de workflow.
• Je biedt alleen een chatfunctie aan, met een robot waarvan je hoopt dat die de vraag alvast kan beantwoorden. Zo niet, dan verwijs je naar de "veelgestelde vragen”. Scheelt jou weer tijd!
• Je verplicht een inwoner altijd om naar het gemeentehuis te komen voor identificatie bij het verlengen van een identiteitsbewijs. Hoef je niemand de deur uit te sturen.
• Je biedt een ontoegankelijk of ingewikkeld formulier aan voor het melden van een klacht, omdat dat toevallig in je klantinformatiesysteem zit ingebouwd.

Op deze manier dwing je jouw bezoekers om zich aan te passen aan jouw manier van werken. Toch is het goed om je te realiseren dat die bezoekers er misschien helemaal geen gebruik van kunnen maken. Maar welke opties zijn er dan allemaal? En wat zijn de voor- en nadelen?

Opties voor contact opnemen

1. WhatsApp

WhatsApp voorziet wel degelijk in een behoefte, het wordt veel gebruikt, is laagdrempelig en je kunt snel een vraag stellen.

Bovendien zit iedereen op WhatsApp, toch? Nou nee, daar kun je niet vanuit gaan. Steeds meer mensen vermijden WhatsApp vanwege de overtredingen van de Europese privacywet van Meta en gebruiken bijvoorbeeld Signal. Of delen liever geen privacygevoelige informatie via WhatsApp.

Het is daarom goed om je te realiseren dat er een grote groep mensen is die niet actief is op dit medium.

2. Bellen

Veel mensen vinden bellen fijn, direct contact met een mens en je kunt meteen je vraag stellen. Bied het dan ook zeker aan als contactmogelijkheid.

Uit gebruikersonderzoek dat we met VNG deden rondom WMBEV formulieren blijkt dat laaggeletterde bezoekers een voorkeur voor bellen hebben: “Ik probeer eerst de telefoon, als dat niet lukt, dan zou ik de website gebruiken om toch in contact te komen om daarnaar te vragen.”

Dove, slechthorende, verlegen, autistische of stotterende bezoekers kunnen problemen hebben met telefoneren. Ook voor bezoekers die de Nederlandse taal niet goed beheersen is bellen lastig. En als je in een volle rumoerige trein zit, wil je ook liever geen gesprek voeren over privézaken.

Het komt voor dat er opgehangen wordt als een beller niet meteen uit zijn woorden komt of wat langer moet nadenken over een antwoord. Wouter Honselaar vertelt in een interview: Ik ben sterker dan het stotteren: “Het is 1 keer gebeurd dat een opdrachtgever het gesprek stopte omdat diegene dacht dat de verbinding haperde.”

Daarnaast is bellen tijdsafhankelijk. Je kunt alleen tijdens kantooruren bellen. Als je zelf tijdens die uren bijvoorbeeld werkt en dan geen persoonlijke telefoongesprekken kunt voeren, is bellen geen optie.

Een vraag op LinkedIn kan al inzichten geven. “Aan mijn dove en slechthorende volgers. Wat doe je als de enige manier om contact op te nemen in een website, een telefoonnummer is, en je moet echt een vraag stellen of een afspraak maken?”

Marie Van Driessche: Als een website alleen een telefoonnummer heeft en ik dringend contact moet opnemen, dan maak ik gebruik van mijn 'video relay service' (VRS). En ik heb de Nederlandse Tolkcontact-app op mijn telefoon. Ze bieden tolkdiensten aan via hun app. Dat betekent dat ik via Tolkcontact het bedrijf moet bellen. Het is een oplossing, maar toch moet ik mijn toegankelijkheid zelf regelen. Contact via e-mail of WhatsApp zou fijn zijn.

Meryl Evans zegt: Bied op tekst gebaseerde opties aan, zoals e-mail, sms, chat met een echte mens en een video relay optie. Geef bij formulieren de keuze welke contactgegevens mensen willen verstrekken. Maak het telefoonnummer niet verplicht.

3. E-mailen

Het voordeel van e-mailen is dat het laagdrempelig en niet tijdsgebonden is. Je kunt een vraag stellen wanneer je wilt.

Niet iedereen schrijft gemakkelijk een e-mail, bijvoorbeeld mensen die laaggeletterd zijn of waarvan Nederlands niet hun eerste taal is. Dan is een e-mail schrijven een hele opgave waar ze misschien wel hulp bij nodig hebben.

4. Contactformulier

Het voordeel van een contactformulier is dat de bezoeker gestructureerd een vraag of mededeling kan e-mailen. Alles wat je nodig hebt staat erin.

Een contactformulier kan een drempel zijn voor bezoekers die niet zo digitaal vaardig zijn. Vooral als het een complex formulier is. Doe voor uitgebreide formulieren altijd eerst een gebruikersonderzoek, ook met mensen met een beperking. Als je blind, slechtziend of niet vaardig bent op het internet kan een slecht opgebouwd formulier een hele klus zijn om in te vullen.

Zorg daarom ervoor dat het formulier goed toegankelijk is, ook voor mensen met een beperking. Het NL Design System heeft hiervoor richtlijnen opgesteld.

5. Chatbox

Even snel een vraag stellen zonder te hoeven bellen. Laagdrempelig en direct.

Maar dan antwoordt een robot. Die er niet uitkomt en je verwijst naar de “veelgestelde vragen” of zegt op te bellen. In plaats van hulp geven ben je alleen de bezoeker aan het afschepen.

Dove en slechthorende mensen geven aan dat een chatbox een goed alternatief is voor de telefoon. Mits ze kunnen chatten met een echt persoon.

Als je een chatbox aanbiedt, laat de bezoekers dan (eventueel na een voorselectie) chatten met een mens. En geef aan wanneer er iemand beschikbaar is om mee te praten.

6. Naar het stadskantoor

Persoonlijke identificatie door een ambtenaar is verplicht bij het aanvragen of verlengen van bijvoorbeeld een paspoort.

Als je lichaam het niet voor elkaar krijgt om naar het gemeentehuis of stadskantoor te komen, hoe verleng je dan je paspoort?

Zorg daarom dat je een alternatief aanbiedt. De gemeente Den Haag biedt huisbezoek aan om je identiteit te kunnen bevestigen.

7. Stuur een brief

Als bonusoptie: een vertrouwde papieren brief sturen is fijn als je niet goed overweg kunt met de computer. Als alternatief voor alle digitale communicatie behoort dit zeker tot de opties.

Zo kan het ook

Op de contactpagina van de website van de gemeente Utrecht staan veel verschillende mogelijkheden om contact op te nemen. Via de telefoon, Teletolk voor dove bezoekers, webformulieren, WhatsApp, een afspraak op het gemeentehuis, een postadres en een servicepunt waar je zonder afspraak langs kunt gaan met vragen. Hier staat niet de gemeente maar de bewoner centraal.

Samenvatting over communiceren

Realiseer je dat het belangrijk is om meerdere manieren aan te bieden om contact op te nemen of vragen te stellen. Vraag bijvoorbeeld aan de bezoeker: “Wil je worden teruggebeld of liever antwoord via de e-mail?”. Wees flexibel in de wijze van communicatie.

Als dat niet past in je huidige werkwijze of klantinformatiesysteem: ga met elkaar om de tafel zitten en zoek naar oplossingen. Uiteindelijk is het doel dat iedere bezoeker jouw organisatie kan bereiken op een manier die bij hen past.

Yolijn van der Kolk is kernteamlid van het NL Design System. Ze vertelt: “Toen we begonnen met het NL Design System moesten we nadenken over de licentiekeuze. Als je open source gaat werken, moet je goed afwegen welke licentie passend is. Want door open source te werken, kan iedereen componenten toevoegen én hergebruiken. Het is inzichtelijk en te gebruiken door iedereen die werkt voor en met de overheid. Met die licentie geef je aan op welke manier de componenten uit het design system hergebruikt mogen worden. We kwamen uiteindelijk uit bij de EUPL-licentie nadat kernteamlid Robbert deze licentie tegenkwam bij het design sytem UNO (dit is het design system van DUO). Want het is belangrijk om goed te checken welk effect zo’n licentie eigenlijk heeft.”

Meedoen zonder ‘gedoe’

Volgens Yolijn realiseert niet iedereen wat open source werken daadwerkelijk inhoudt. Sommige mensen zijn hier heel bewust mee bezig, maar anderen denken er niet zo over na. Ze noemt een voorbeeld: “Stel dat je componenten hebt gebruikt uit het NL Design System. Dan zouden wij jou met een virale licentie kunnen verplichten om alles wat je daarna maakt met deze componenten óók open source te maken. Dat wilden wij dus niet. Want er zijn nou eenmaal heel veel systemen in Nederland die niet open source (mogen) zijn.”

Yolijn legt vervolgens uit dat we willen dat iedereen open source onderdelen kan bouwen voor het NL Design System. “Maar we willen niet ‘eisen’ dat alles wat er daarna mee gebouwd wordt ook open source moet zijn.
Robbert voegt hieraan toe: “We praten in de praktijk vaak over open source of closed source. Maar stiekem zitten er nog heel veel opties tussenin. Denk bijvoorbeeld aan het nieuwe omgevingsloket dat wordt gebouwd met een eigen design system. De code van ‘DSO Toolkit’ is te bekijken op Github, maar hergebruik door andere teams is niet toegestaan. Dat komt omdat er geen open source licentie is gekozen. We noemen dit voor de grap wel eens ‘view source’. Dit heeft dus onder andere te maken met de licentiekeuze.”

Maar hoe zit het dan met het beschermen van huisstijlen?

“Het is heel makkelijk dat componenten voor huisstijlen beschikbaar zijn door open source te werken. Denk hierbij aan logo’s, lettertypes en kleuren. Maar we willen een eigen huisstijl natuurlijk wel beschermen. Daarom vind je in GitHub een map ‘proprietary’. In deze map staat alles wat uitgesloten is om te hergebruiken. Je vindt hier bijvoorbeeld thema’s rondom een huisstijl van een bepaalde gemeente. Dus de beslissing voor een lettertype en kleur. Anderen mogen zich hierdoor laten inspireren en ervan leren, maar dus niet hergebruiken” – zegt Yolijn.

No rights reserved

En dan hebben we binnen design systems ook nog te maken met auteursrechten. Denk bijvoorbeeld aan het schrijven van richtlijnen, waar vaak meerdere mensen aan werken. Yolijn: “Je moet je voorstellen hoe lastig het zou zijn als er veel verschillende mensen meeschrijven aan richtlijnen en we bij iedere zin moeten vermelden wie het geschreven heeft. Dat is bijna niet te doen. Daarom hebben we voor het opstellen van documentatie, zoals richtlijnen, gekozen voor ‘Creative Commons Zero’ (CC0). Dit houdt in dat je op geen enkele manier hoeft te vertellen waar je deze teksten vandaan hebt als je ze gebruikt voor jouw eigen website voorbeeld. Het doel is uiteindelijk om de de tips uit richtlijnen te delen op zoveel mogelijk plekken zonder gehinderd te worden door beperkingen. Uiteindelijk wordt ‘het web’ dan beter voor iedereen, zonder dat iedereen die meehielp overal in alle documentatie genoemd worden.”

Blijf op de hoogte van NL Design System

Vind je het leuk om op de hoogte te blijven van de dingen die het NL Design System doet? Dat kan op verschillende manieren. Ontvang onze nieuwsbrief of meld je aan voor onze ‘Heartbeat-sessies’. Op deze 2-wekelijkse online bijeenkomsten delen we de laatste updates. Ook komen leden uit de community aan het woord. Heb je vragen? Stuur ons dan een mail.

Ergens in 2018 begon het verschillende mensen in overheidsland op te vallen hoe verschillend overheidswebsites waren. Teams vonden opnieuw het wiel uit. Het resultaat was niet altijd gebruiksvriendelijk. De vraag was al snel: “Kunnen we niet beter samenwerken?”. Er ontstond een community rondom het plan om samen een design system op te zetten (zie: Wat is een design system?). Deze community kwam in 2019 als experiment onder de vleugels van Gebruiker Centraal en kreeg daar de kans te groeien.

Victor weet nog goed hoe hij en collega’s destijds overheidswebsites met elkaar vergeleken. Met name gericht op de meest generieke functies ervan. Hij vertelt: “Ik bekeek graag verschillende websites van de Rijksoverheid. Daarbij keek ik onder andere naar de verzendknoppen. Wat mij opviel? Dat er ontzettend veel verschillende knoppen te vinden waren. Terwijl je zou denken dat er bij 1 huisstijl voor de Rijksoverheid ook gekozen was voor 1 knop. Ik verzamelde er uiteindelijk meer dan 170!”

Volgens Victor staat iedere knop voor een team, bestaande uit ontwikkelaars en ontwerpers: “Je moet je realiseren dat iedere knop die je op een overheidswebsite ziet, een eigen verhaal heeft. Hier hebben meerdere experts samen aan gewerkt. En dat dus meer dan 170 keer in dit geval. Dat moet echt simpeler kunnen, dacht ik destijds. Waarom niet leren van elkaars expertise, lessen en testen? Zo ontstonden de eerste plannen om een design system voor de Nederlandse overheid te ontwikkelen.”

De verzameling knoppen van overheidswebsites

Van OBieb naar NL Design System

In 2018 bestonden er al op allerlei plekken design systems, ook bij de overheid. Zo had de Belastingdienst iBieb. Geïnspireerd op deze naam werden de plannen om een design system te ontwikkelen steeds concreter, en ontstond de OBieb. De ontwikkeling hiervan ontstond uit een samenwerking tussen Gebruiker Centraal en het programma Mens Centraal. Victor: “Onze toenmalige opdrachtgever vanuit het ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) was Raph de Rooij. Raph heeft zelf een lange historie op het gebied van digitale toegankelijkheid. Hij snapte de noodzaak van het project direct. Zijn enthousiasme heeft destijds zeker geholpen bij het realiseren van onze plannen.”

In 2019 werd de naam omgedoopt in NL Design System. Volgens Victor omdat de naam uiteindelijk gewoon zegt wat het is. Na een succesvol experiment volgde het toekennen van innovatiebudgetten. Daarmee werd het systeem doorontwikkeld, huisstijl-onafhankelijk met design tokens, de architectuur opgezet en een community gevormd voor samenwerking tussen verschillende overheden. Een vast kernteam met specialisten begon met bouwen.

“Iedereen draagt zijn steentje bij”

Het NL Design System is geen standaard design system, zoals je wellicht in andere organisaties ziet. Victor vertelt: ”Het unieke aan het NL Design System is dat het op een hele andere manier werkt. Er is geen eigen portaal, maar het bestaat uit een samenwerking tussen verschillende overheidsorganisaties en leveranciers. Iedereen draagt zijn steentje bij.”

Projectleider Angela Imhof stond samen met het kernteam, bestaande uit Yolijn van der Kolk en Robbert Broersma, al vanaf de start van het NL Design System project aan het roer. Fast forward naar 2023: Angela droeg het stokje over aan Peter Berrevoets, die haar rol als projectleider overnam.

Toen Peter begin 2023 aansloot, was hij gelijk enthousiast. “De naam van het programma 'Gebruiker Centraal' sprak me erg aan. Want dáár draait het natuurlijk om: we doen het voor de gebruiker, voor de inwoner, de burger. De mate waarin NL Design System bijdraagt aan de toegankelijkheidsopgave van veel overheidsorganisaties misschien nog wel meer! Dus ik stapte maar wat graag aan boord en het voelde gelijk goed om hier iets aan te mogen bijdragen.”

NL Design System gaat ‘op kamers’

Victor: “Gebruiker Centraal is een community. We zijn een platform om kennis te delen en elkaar te inspireren. Het NL Design System is daar een voorbeeld van. Het was nooit echt de bedoeling dat het NL Design System voor altijd verbonden zou blijven aan Gebruiker Centraal. De huidige omvang van het project maakt het logisch om het die ruimte als zelfstandig project te geven.”

Volgens zowel Peter als Victor is het dan ook de bedoeling dat de relatie tussen Gebruiker Centraal en het NL Design System standhoudt. “We gaan op kamers”, grapt Peter. Hij vervolgt: “We blijven een soort van familie van elkaar. En dat past ook bij het principe van het NL Design System: samenwerken naar een groter geheel, gericht op de gebruikers. In de toekomst blijven we elkaar versterken. Zo hebben we ook een nauwe samenwerking met het programma DigiToegankelijk TOP en de Vereniging van Nederlandse Gemeenten (VNG).”

Plannen en wensen voor de toekomst

Peter heeft veel zin om zelfstandig door te gaan met het NL Design System en heeft dan ook mooie plannen. Maar, zegt hij, er zijn ook uitdagingen: “Eén van die uitdagingen zit voor mij in het gecontroleerd laten groeien van het project. Steeds meer grote organisaties willen meedoen (zie: Wie doet er mee?, red.). Ook op het gebied van kennis delen op evenementen bijvoorbeeld. Ons team kan nou eenmaal niet overal tegelijk zijn. Wanneer je de balans tussen vraag en aanbod niet bewaakt, gaat dat ten koste van de kwaliteit van advies, begeleiding en regie vanuit het kernteam op de werking van de community, en daarmee op de kwaliteit van de bouwblokken.”

Peter heeft nog wel een tip voor organisaties die het NL Design System willen gebruiken: “Het is belangrijk dat organisaties niet alleen mee willen doen, maar er ook de middelen voor willen vrijmaken. Vooral dat stelt ontwerpers en ontwikkelaars in staat om deel te nemen in de NL Design System-community en de aandacht aan de implementatie te geven die nodig is. We willen het NL Design System aan iedere overheidsorganisatie aanbieden, maar op dit moment kost dit nog veel werk én tijd. We werken er ook hard aan om de ingebruikneming ervan ‘simpeler’ te maken. Daarom is het des te belangrijker om het echt als community te doen, zodat we kennis delen en van elkaar leren.”

In de ‘ideale wereld’ zou Victor graag zien dat de hele overheid automatisch gebruikt maakt van het NL Design System: “Leren van elkaars kennis en ervaring is zo belangrijk. Elke keer weer hetzelfde knopje maken en neerzetten kost zoveel tijd. Ik zou echt niet weten waarom niet iedereen ermee zou werken. Idealiter zou het implementeren van het NL Design System net zo makkelijk moeten gaan als het installeren van een standaard WordPress-website. Zover zijn we natuurlijk nog lang niet, maar ik heb goede hoop!”

Op de hoogte blijven van het NL Design System?

Ben je benieuwd naar de ontwikkelingen van het NL Design System? Meld je dan aan voor de maandelijkse nieuwsbrief of schuif aan tijdens de 2-wekelijkse update (Heartbeat). Hierin delen we alle relevante updates.

Francesca Vonk begint de bijeenkomst door uit te leggen wat Wmebv precies is. Naar verwachting zal deze nieuwe wet in juli 2024 ingaan. Iedere inwoner en ondernemer in Nederland heeft namelijk recht op het digitaal indienen van formele officiële berichten. Deze wet stelt echter wel eisen aan het uitwisselen van ‘elektronisch bestuurlijk verkeer’, oftewel berichten en meldingen tussen de indiener (inwoners en ondernemers) en de overheid. Onder andere het gebruik van formulieren is hier een belangrijk onderdeel van.

E-formulieren maken in samenwerking met het NL Design System

Francesca legt uit dat zij vanuit de VNG samenwerkt met het NL Design System kernteam en stagiairs van Frameless om een generiek formulier te maken dat voldoet aan alle eisen van de Wmebv. De opdracht: maak het, laat het testen en documenteer het.

Hierbij gingen ze uit van het volgende stappenplan:

• Ontwerp een generiek e-formulier
• De ontwikkeling van het generieke e-formulier
• Gebruikerstesten uitvoeren
• Resultaten delen van de gebruikerstesten

Eerder deelden we de eerste (en belangrijkste) lessen vanuit het testen met de Wmebv-formulieren.

‘Jij bent niet je gebruiker’

Vervolgens neemt Rian Rietveld het stokje over en gaat dieper in op de richtlijnen voor formulieren. Volgens Rian is het een belangrijke vuistregel om te onthouden dat jij niet je gebruiker bent. Denk dus niet dat wat voor jou duidelijk is, ook automatisch voor anderen duidelijk is. Ze vertelt dat alle geleerde lessen gedocumenteerd worden als richtlijnen voor formulieren.

Op dit moment zijn er al verschillende richtlijnen te vinden. Denk aan richtlijnen voor labels, beschrijvingen, links, buttons, placeholders en op te vragen informatie. Zie: Richtlijnen voor formulieren.

Richtlijnen voor labels uitgelicht

Rian gaat dieper in op de richtlijnen voor labels. Een label geeft aan welke gegevens de gebruiker bij een formulierveld in kan vullen. Hierbij is het belangrijk dat een label toegankelijk moet zijn voor iedere gebruiker. Daarbij zijn een aantal punten belangrijk, zoals:

• Geef een formulierveld een toegankelijke naam met een label.
• De zichtbare naam moet overeenkomen met de toegankelijke naam.
• Zet het label boven het formulierveld.
• Zorg ervoor dat het label altijd zichtbaar is.
• Zet alleen tekst in het label.
• Gebruik duidelijke labelteksten.

In de richtlijn Labels vind je voorbeelden hoe het wél moet, maar ook vooral hoe het niet moet. Rian: “Houd altijd in gedachten dat een beschrijving én uitleg bij formulieren heel belangrijk is. Mensen snappen beter waarom ze iets moeten invullen als je toelicht waarom. Maar ook waarvoor het vervolgens wordt gebruikt. Zo zorg je er niet alleen voor dat het toegankelijk is, maar ook nog eens gebruiksvriendelijk.”

Geef je feedback op onze nieuwe richtlijnen

We willen dat onze richtlijnen, net als de componenten, breed kunnen worden gedragen. Heb je gebruikersonderzoek gedaan en verschillen je inzichten van de huidige richtlijnen? Je feedback is van harte welkom, zowel vanuit overheid of daarbuiten. Open een issue op GitHub of mail ons op info@nldesignsystem.nl.

Waarom Wmebv-formulieren?

Om wat context te geven: we maakten deze formulieren specifiek vanwege de Wet modernisering elektronisch bestuurlijk verkeer (Wembv). Deze wet treedt volgend jaar in werking en geeft burgers en bedrijven het recht overheidszaken digitaal te regelen. Veel organisaties zijn hierdoor met hun formulieren bezig. Inclusief organisaties in de NL Design System community.

Francesca legt het generieke formulier uit tijdens de NL Design System Heartbeat van 31 oktober

In het kader van Wembv, werkte UX designer Francesca Vonk de afgelopen maanden aan een generiek formulier. Dit deed ze namens VNG Realisatie, en samen met het NL Design System kernteam, community-leden (in het bijzonder UX-collega Rozerin Ayerdem van de gemeente Den Haag), front-end stagiairs van Frameless en een jurist van VNG. Uiteindelijk zal ze voor VNG een handreiking schrijven met haar bevindingen.

De test

In Francesca's voorbeeldscenario's zoekt Jeroen van Drouwen, een (fictief) persoon, contact met zijn gemeente over de status van zijn aanvraag bijstandsuitkering. Hij had al iets moeten horen, en wil weten hoe het zit. Er waren twee scenario's: met en zonder DigiD. Deze situaties zijn grotendeels in front-end code gebouwd (uiteraard met NL Design System componenten). Er waren ook enkele schermen in Figma, en er was een heuse Gmail-omgeving opgezet met een tijdelijke nep-accounts, zodat het extra realistisch was.

In totaal deden met deze test 7 participanten mee, met uiteenlopende beperkingen (waaronder visueel, fysiek en cognitief). In een kantoorsituatie hebben ze op een laptop beide testscenario's uitgebreid doorlopen. Ons team keek via Teams mee.

Eerste lessen

Gebruikerstesten blijken altijd weer ontzettend leerzaam te zijn. De ene gebruiker is de ander niet, en er is veel verschil tussen hoe mensen hun computers willen en kunnen gebruiken. Dat bleek ook vorige week weer.

We zijn de punten nog uitgebreid aan het verwerken, maar hier zijn vast zes punten die ons opvielen:

• Voor ons was het formulier min of meer een gegeven, maar eigenlijk iedereen gaf aan liever te bellen met de vraag.
• De participanten waren vaak wel bekend met DigiD, maar waren er ook huiverig voor.
• Taalgebruik was vaak een barrière, uitdrukkingen als “melding openbare ruimte” leidden tot verwarring.
• De foutmeldingen werden heel goed begrepen.
• Meerdere participanten zeiden normaliter liever een telefoon of tablet te gebruiken dan de testlaptop (dit kunnen we in vervolgtesten beter faciliteren).
• De snelheid waarmee participanten door een formulier gingen verschilde enorm, en op de “5 minuten” die op de eerste pagina werden aangekondigd werd verschillend gereageerd (van “wat lang!“ tot “wat kort!”).

Er was veel feedback. Met post-it's op Miro verzamelden we wat ons opviel.

Het vervolg

We vonden het erg waardevol om te zien hoe dit formulier werkte voor mensen buiten ons eigen team. Met de bevindingen gaan we alvast aan de slag, en we zijn van plan ze te publiceren op gebruikersonderzoeken.nl. Alleen door gebruikersonderzoek te herhalen kunnen we onze aannames valideren, dus op termijn willen we zeker opnieuw gaan testen.

De belangrijkste reden voor deze samenkomst: op dit moment zijn er nog geen afspraken over de verticale ruimte tussen componenten. Dat zit gebruikersvriendelijkheid in de weg, doordat er onvoldoende relatie en hiërarchie tussen componenten bestaat.

De designers + enkele leden uit het kernteam (Rozerin, René, Martijn, Jeroen, Jeffrey, Yolijn en Robbert) kwamen bij elkaar om samen te werken aan twee doelen:

• een systeem voor verticale paddings en/of margins dat intuïtief en logisch is (met design tokens voor implementatie en documentatie)
• richtlijnen voor het gebruik van paddings en margins (waarin redeneringen en werking worden uitgelegd)

Relaties versus afstanden

Tijdens de workshop werden verschillende relaties tussen componenten bedacht: “vrienden” staan dicht bij elkaar, “besties” heel dicht en “kennissen” nemen wat meer afstand. Elk van deze relaties krijgt een bepaalde waarde, bijvoorbeeld:

onbekenden: 32px
kennissen: 24px
vrienden: 16px
besties: 8px

Natuurlijk hoeven de waarden niet in pixels te worden uitgedrukt. Het kunnen bijvoorbeeld ook relatieve waarden zijn, en die kunnen ook nog eens per viewport verschillen.

Het idee is dat de waarden instelbaar zijn met design tokens. Design systems kunnen hierin dus zelf een keuze maken. Of meerdere keuzes. Misschien is de afstand tussen “vrienden” bijvoorbeeld net anders in een Mijn Zaken-systeem dan in een contentwebsite. Het ene scherm is “information-dense”, met bijvoorbeeld veel tabellen, terwijl bij het andere leesbaarheid van tekst belangrijk is. Waarden van de design tokens kunnen per geval anders worden ingesteld.

Open vragen

In deze eerste sessie is al veel denkwerk verricht, liet Jeroen zien. In een spreadsheet had de groep al relaties uitgewerkt tussen een groot aantal componenten.

Er zijn ook nog wel wat open vragen:

• Hoeveel relaties zijn voldoende om de meeste scenario's af te dekken? Is er nog een relatie nodig na 'Onbekenden'?
• Hoe kan dit worden uitgewerkt in de front-end? (Er waren al wat eerste ideeën, door aanwezigheid van developers Yolijn en Robbert)
• Hoe zit het met verticale ruimte binnen componenten?
• Er zijn allerlei componenten waar de waarden op elkaar lijken, zoals buttons en links; kunnen we hier een groepering in aanbrengen?
• Hoe zou je deze spacing als designer willen toepassen in een ontwerptool als Figma? Als “spacer-blokje”? Met behulp van variabele? Wil je dit überhaupt wel allemaal in Figma doorvoeren?

Nog een hoop om over na te denken! Mocht je dit lezen en voor je eigen design system ook bezig zijn met spacing tokens, laat het ons weten! Bijvoorbeeld in het #nl-design-system-designers-kanaal op Slack.

Vervolg

We zijn bovenstaand systeem aan het uittesten in Figma, om te kijken hoe het in de praktijk werkt. Dat willen we ook gaan doen voor bijvoorbeeld formulier- en contentpagina's: the proof of the pudding is in the eating.

Ook gaan we verder met bijvoorbeeld bovenstaande vragen. Heb je vragen of ideeën, de designers zitten op Slack (kanaal: #nl-design-system-designers), daar kun je je ook melden voor de tweewekelijkse Design Open Hour, voor ontwerpers bij de overheid.

Tijdens Design Systems Week bieden we dagelijks 3 tot 4 presentaties, die kort genoeg zijn (20-25 minuten) om gedurende dag mee te pikken. Er zijn sessies voor managers, designers, developers en iedereen daar tussenin. In deze post gaan we bij wijze van voorpret vast wat dieper in op een aantal onderwerpen.

Het programma

Qua onderwerpen is er voor elk wat wils: van hoe design systems politiek werken tot een technische sessie over real-life ervaringen met Web Components. Meld je aan of lees in dit bericht meer over wat we voor je in petto hebben.

Overheden: Verenigd Koninkrijk, Taiwan en Estland

Ten eerste hebben we maar liefst drie overheden te gast:

• Bij GOV.UK hebben ze al een hoop front-endcomponenten. Maar componenten zijn pas waardevol als je ze samen op 1 pagina zet, dus hebben ze een manier gemaakt waarop ontwikkelaars makkelijk voorbeelden kunnen maken van pagina’s en realistische prototypes: de GOV.UK Prototype Kit. We hebben hun ontwerper Joe Lanman gevraagd om daar eens iets meer over te vertellen.
• In Taiwan is het bouwen van een design system onderdeel van een groter project rondom digital resilience. Hoe werkt dat, en hoe denken ze in Taiwan over het bouwen van digitale diensten? Head of design systems Mu-An Chiou vertelt erover in Design Systems as Public Infrastructure.
• Estland noemt zich met trots de eerste digitale samenleving. Hun design system wordt al door een aantal overheidsorganisaties gebruikt. Van UI Development Lead Aleksandr Beliaev krijgen we een kijkje in de keuken.

DesignOps

Hoe kunnen ontwerpers het best samenwerken met elkaar en anderen, zoals ontwikkelaars, om te zorgen dat de kwaliteit van ontwerp in brede zin beter wordt? Die vraag wordt beantwoord door wat Design Operations (Design Ops) wordt genoemd. Inayaili León van GitHub gaat in haar sessie in op hoe DesignOps de ontwerpdiscipline beter in de organisatie verankert, en specifiek hoe GitHub het aanpakt, in haar presentatie DesignOps: designing the API of design teams.

Web Components

Verschillende overheidsorganisaties (zoals Logius, Belastingdienst) werken met Web Components of zijn van plan dat te gaan doen. Het Nord Design System heeft Web Components al een paar jaar als basis, en hebben in die tijd veel geleerd over wat er wel en niet werkt. Design system team lead David Darnes vertelt ons meer over hun praktijk in Design Systems & Web Components: what works & what doesn’t.

Aanmelden

Je kunt deze sessies en meer gratis bijwonen. Als je je aanmeld krijg je de link in je mailbox. Dit kan zowel per sessie als voor de hele week tegelijk. Aanmelden voor de hele week Aanmelden per sessie

Al vanaf het begin gebruikt Gebruiker Centraal de lettertypes Montserrat en League Gothic. Dat gaat veranderen. De website van NL Design System is al over op de nieuwe lettertypes. De website van Gebruiker Centraal nu ook.

Goed om te weten: de tekst op deze pagina heeft nog de oude lettertypes. Op de projectwebsite van NL Design System kun je al wel de nieuwe lettertypes bewonderen. En sinds kort dus ook op de website van Gebruiker Centraal.

Lees waarom Gebruiker Centraal kiest voor nieuwe lettertypes

We kijken er vanuit het kernteam met een grote glimlach op terug! Er zijn namelijk weer meer teams aangesloten en meer mensen enthousiast over het NL Design System.

Op Slack heeft Yolijn beschreven wat we hebben gedaan met de doelen die we hadden gesteld voor 2022.

Een aantal hoogtepunten:

RVO die NL Design System voor een groter publiek bij de Rijksoverheid beschikbaar heeft gemaakt; Onze nieuwe documentatie-website; De drukbezochte Design Systems Week. Gemist? Geen nood: de sessies zijn terug te kijken.

Samenwerken in Figma

We zijn ook heel blij met onze nieuwe collega en UX-designer Jeffrey Lauwers die bij heeft gedragen aan een betere samenwerking tussen designers. Jeffrey zegt daar zelf het volgende over:

Vanaf oktober ben ik als designer onderdeel gaan uitmaken van het kernteam. Na een leuke kennismaking en het nodige inlezen ben ik gesprekken gaan voeren met andere designers uit de community.

Al snel werd duidelijk dat het in ontwerpprogramma Figma een behoorlijke uitdaging was om samen te werken. Inmiddels hebben we daar een mooie oplossing voor gevonden. Nu kunnen designers gebruik maken van een Figma-bibliotheek met NL Design System-componenten én daar de huisstijl van hun eigen organisatie eenvoudig op toepassen. Vooralsnog staan hier 5 componenten, maar ons doel is om daar in 2023 een behoorlijke set aan toe te voegen. Dit alles uiteraard ondersteund met de nodige documentatie.

Uiteraard kunnen we dit niet zonder input van de community dus blijf ons vooral volgen en laat van je horen!

Schakelen en focus verlegen

Alhoewel we in grote lijnen weten waar we naartoe werken, is het vaak onmogelijk om te weten hoe je dag er daadwerkelijk uit zal zien. Ook verleg je meerdere malen per dag focus van super-gedetailleerd naar een heel ruim vogelperspectief. Het ene moment help je bijvoorbeeld bij het ontwerpen van een websiteknop, terwijl je 5 minuten later overlegt wat de beste manier is om een groot formulier op te delen in meerdere stappen.

Strikte scheiding van visuele stijl en structuur

Waar je bij de meeste design systems slechts een enkel merk (of meerdere merken) bedient, is er geen vaste huisstijl voor het NL Design System. Componenten, patronen en documentatie moeten iedere denkbare huisstijl kunnen ondersteunen. Het is daarom belangrijk om altijd op zoek te blijven naar de kern van componenten, patronen en documentatie. Vervolgens moet je zorgen dat het aan te bieden is én bruikbaar is voor iedere huisstijl.

Ook werken we met een zogenaamd ‘white-label’. Dit is een visuele stijl waarmee we bijvoorbeeld toegankelijkheid kunnen waarborgen. Denk bijvoorbeeld aan alle benodigde combinaties (voor- én achtergrond) voor kleuren of een verplichte focus staat voor interactieve elementen. Vooral kleinere gemeenten hebben vaak niet het budget om zo’n uitgebreide visuele stijl te bekostigen.

Het opmaken van een huisstijl naar design tokens

Om een scheiding te maken tussen een huisstijl en de interactiestructuur, gebruiken we zogenaamde design tokens. Door deze scheiding is het mogelijk om solide herbruikbare componenten te maken die door iedere organisatie door hun eigen huisstijl te voorzien zijn.

Daarom is het belangrijk om de intentie van een visuele stijl terug te brengen naar de betekenis die deze visuele eigenschap heeft voor de gebruiker. Iedere visuele ontwerpkeuze wordt teruggebracht naar een design token. Zo heeft bijvoorbeeld iedere organisatie een kleur gekozen voor de broodtekst. Deze kleur kan per organisatie verschillen. De intentie achter de gekozen kleur echter niet. De kleur van de broodtekst moet bijvoorbeeld voldoende contrast hebben met de achtergrondkleur(en) waarop deze getoond wordt, of er dient een minimale tekst grootte te zijn. Design tokens kunnen hierdoor voorzien worden van eisen waaraan deze minimaal moeten voldoen.

Figma

Om ontwerpers van aangesloten organisaties goed bij te staan is het belangrijk om design tools door en door te kennen. Vragen over het maken van componenten, prototyping, naamgeving, bestand-architectuur en recente programma-updates moeten snel en duidelijk beantwoord worden.

Al vrij snel hebben we de keuze gemaakt voor Figma. De meeste aangesloten organisaties werken inmiddels ook met Figma, of gaan de overstap naar Figma maken. Het sluit ook bijzonder goed aan bij de belevingswereld van ontwikkelaars, waardoor het makkelijk is om eenzelfde taal met elkaar te praten. Omdat je samenwerkt met andere ontwerpers dien je zorgvuldig om te gaan met je ontwerp. Zorg altijd voor een naam die een semantische betekenis heeft en door iedereen (ontwerper én ontwikkelaar) begrepen wordt.

Het is belangrijk om bij alles wat je ontwerpt de vraag te stellen: “Kan dit hergebruikt worden en in welke context(en)?”. Dit geldt zeker voor componenten, maar meer nog voor patronen.

Samenwerken

Buiten het dagelijks communiceren via diverse kanalen zoals e-mail en Slack, organiseren we 1 keer per week een vast moment om centraal te overleggen met ontwerpers van diverse organisaties. Tijdens deze bijeenkomsten kan alles besproken worden waar je als ontwerper mee zit. Bij deze sessies worden niet alleen ontwerpers betrokken, maar ook tekstschrijvers, toegankelijkheidexperts en ontwikkelaars.

Toegankelijkheid

Heel veel toegankelijkheidsproblemen zijn in de eerste ontwerpfase al op te lossen. Niet iedere ontwerper is echter onderricht in alle toegankelijkheidsrichtlijnen. Door nauw met elkaar samen te werken en kennis over te dragen, merk je dat je elkaar als het ware naar een hoger niveau tilt; we onderwijzen elkaar.

Dit artikel is geschreven door Rogier Barendregt – ontwerper en voormalig kernteamlid bij het NL Design System.

Wat voor Bryan begon als student met een bijbaan bij Rent Your Student Scrum Team (RYST), eindigde met een resultaat om trots op te zijn. Front-end developer Bryan de Jong werkte namelijk mee aan het ontwikkelen van een nieuw design system voor de gemeente Den Haag, met behulp van het NL Design System. Inmiddels gaat hij zijn vleugels uitspreiden in het buitenland en blikt terug op de samenwerking met het team van het NL Design System.

Een volledig herbruikbare omgeving inrichten met het NL Design System

Het studententeam waar Bryan onderdeel van was, had de taak om de designs die aangeleverd werden om te bouwen naar herbruikbare componenten. Bryan vertelt: “We waren met de gemeente Den Haag 1 van de eersten die open source gingen werken in Github. Zo kon het team van het NL Design System meekijken, maar natuurlijk was dit ook te volgen door andere partijen. In het begin was het ook echt wel zoeken naar een goede manier om een bibliotheek van herbruikbare componenten te ontwikkelen. Maar door de nauwe samenwerking met het kernteam van het NL Design System is dit zeker gelukt.”

Bryan is trots dat de componenten inmiddels ook echt in de praktijk worden gebruikt: “Wat wij hebben ontwikkeld wordt nu bijvoorbeeld gebruikt in de nieuwe ‘mijn-omgeving’* van de gemeente Den Haag. De omgeving is volledig herbruikbaar ingericht, zodat andere organisaties dit ook kunnen gebruiken. Hierdoor zou bijvoorbeeld de gemeente Amsterdam dit compleet kunnen overnemen en alleen nog maar te hoeven voorzien van hun eigen rode huisstijl.”

Met de ‘mijn-omgeving’ wordt de online omgeving bedoeld waar mensen terechtkomen zodra ze inloggen bij hun gemeente.

Ontwikkelingen tijdens hackaton

Op de vraag welke mijlpalen Bryan het meest zijn bijgebleven, moet hij even nadenken. Want hij heeft aan zoveel mooie dingen meegewerkt zegt hij. Toch is de hackaton die onlangs plaatsvond hem zeker bijgebleven: “Pas geleden hebben we tijdens een hackaton een ‘product-dienst-status component’ ontwikkeld met behulp van componenten van het NL Design System. Hierdoor krijgen inwoners direct te zien wat de status is van hun productaanvraag, zodra ze inloggen in de ‘Mijn-omgeving’. Dit was zo’n succes dat de gemeente Buren het gelijk in gebruik kon nemen.”

De samenwerking met het NL Design System

Bryan zegt dat hij met zijn studententeam destijds in het diepe werd gegooid. “Wij kregen de opdracht om een heel design system op te zetten volgens de architectuur van het NL Design System. Het was daarom heel belangrijk om vaak te sparren met het kernteam, om te zorgen dat alles goed klopte, ook qua toegankelijkheid. Robbert en Yolijn hebben vaak meegekeken, wat makkelijk ging omdat we alles open source hebben ontwikkeld. Ondertussen werkte Rogier nauw samen met onze ontwerper Rozerin.”

Als laatste geeft Bryan aan dat hij trots is dat er daadwerkelijk iets is neergezet én in gebruik is genomen. “Ik denk dat we nu op een punt staan waar we echt naar centrale NL Design System-componenten gaan. Mede door de ‘Mijn-omgeving’ kunnen we laten zien dat het om herbruikbare componenten zijn die makkelijk aan te passen zijn naar de eigen huisstijl.”

Kernteam

Het kernteam bestaat uit Angela, Robbert, Yolijn en Rogier. We werken al sinds herfst 2019 met elkaar samen. Funfact: we hebben elkaar steeds niet gezien in real life!

Community

We doen het gelukkig niet alleen. Grote bergen werk zijn verzet door teams bij de gemeente Den Haag, Utrecht en Logius, en door alle deelnemers van werksessies, en deelnemers aan de Onboardingweek.

Kennismakingen met teams

Afgelopen jaar hebben we vele tientallen ontmoetingen gehad met teams die willen weten hoe NL Design System kan helpen bij hun projecten. En hoe zij NL Design System verder kunnen helpen.

Kennis uitwisselen met design system-teams

We hebben gesproken met diverse design system-teams bij overheden en in het bedrijfsleven, om te leren van elkaar over hoe je een design system effectief laat landen in een organisatie.

Slack

In 2021 meer dan 200 nieuwe leden bij #nl-design-system, nu bijna 450 geïnteresseerden!

NL Design System heartbeat

In 2021 vonden elke 2 weken ‘heartbeats’ (in totaal 24 keer) plaats. Een (online) bijeenkomst waarin het kernteam de voortgang presenteerde en er gelegenheid voor vragen was.

Interactieve werksessies

In de eerste helft van het jaar hebben we 3 keer een interactieve werksessie georganiseerd, met vele tientallen deelnemers. Heel veel dank dat jullie erbij waren en hebben geholpen de kennis samen te brengen, onder andere over goede formulieren.

E-mail nieuwsbrief

Voor iedereen die op zijn eigen tijd wilt meelezen, gaat elke 2 weken de nieuwsbrief eruit. Je kunt je voor de nieuwsbrief aanmelden als je dat nog niet gedaan hebt.

’The GIT sessions’

Afgelopen jaar elk vrijdag vaste prik: samenwerken met Utrecht aan nieuwe componenten voor het Utrecht Design System die gebouwd worden met de NL Design System-architectuur.

‘The Figma sessions’

Afgelopen jaar wekelijks vaste prik: samenwerken met designers van Utrecht, Den Haag en Mijn Overheid om bouwblokken en design tokens te bouwen die herbruikbaar zijn voor iedereen.

Sprint refinements

Het kernteam heeft tijdens ‘sprint refinements’ van de gemeente Den Haag regelmatig mee kunnen denken over hoe componenten aangepakt kunnen worden, op toegankelijke en herbruikbare wijze.

Code reviews

Wanneer mogelijk keken (en kijken) we mee met de ontwikkelingen in de community, en helpen we om nieuwe componenten in te zetten bij andere organisaties.

Kruisbestuiving

Dankzij de fantastische inzet van diverse teams worden steeds meer componenten van de ene organisatie ingezet bij diensten van een andere organisatie. Weer een stap dichterbij een centrale NL Design System-verzameling!

Onboardingweek

Begin november hebben we een week lang workshops voor product owners, developers en designers gegeven hoe je aan de slag kan met NL Design Systems.

Webinar ‘Toegankelijkheid en het NL Design System’

De gasten in de studio voor het webinar 'Toegankelijkheid en het NL Design System' Op dinsdag 22 juni vond het webinar plaats over toegankelijkheid en het NL Design System. Gespreksleider Peter van Grieken, adviseur digitale toegankelijkheid, ging in gesprek met 3 gasten aan tafel: onze Robbert, toegankelijkheidsexpert Jules Ernst en UX designer Rozerin Ayerdem van de gemeente Den Haag.

Wil je het webinar terugkijken? Of wil je de vragen en antwoorden uit de chat lezen? Je vindt alles op deze pagina. Inclusief de links die in het webinar en in de chat werden gedeeld en de presentaties.

Storybook template

Storybook met thema’s

Gedeelde design tokens

Componenten in Storybook

Componenten in Figma

Support in Slack

Afgelopen jaar hebben we in Slack honderden vragen beantwoord via direct messages in chat en via videobellen, zodat ontwikkelingen zonder problemen door kunnen.

Documentatie en code schrijven

Afgelopen jaar hebben zijn er honderden ‘pull requests’ voorbij gekomen zijn er meer dan 2.000 ‘commits’ gedaan bij NL Design System repositories.

Vragen of suggesties?

Wil je meer informatie over het NL Design System of graag meedoen? Of heb je ideeën voor volgend jaar? Neem contact met ons op via Slack.

Fijne feestdagen! Dan rest ons niets dan je hele fijne feestdagen te wensen. We kijken uit naar samenwerking in 2022!

Het kernteam, Angela, Robbert, Yolijn & Rogier

Tijdens de ontwikkeling van het NL Design System was het al snel duidelijk dat wij als kernteam met Figma (de tool voor het ontwerpen van de componenten en patronen) wilden werken. Het doel is dat we beproefde componenten en patronen aanbieden als een ‘white-label’ variant. Organisaties kunnen componenten aanleveren waar we vervolgens een white-label variant voor het NL Design System van maken. Andere organisaties kunnen deze variant gebruiken en voorzien van hun eigen huisstijl en merkbeleving. Inmiddels werken we door middel van Figma samen en delen we kennis met ontwerpers van de gemeente Utrecht, Den Haag, Haarlem en ook met de ontwerpers van Logius.

Waarom Figma?

Figma is een programma waarmee digitale producten zoals websites en interactieve prototypes ontworpen kunnen worden. Alhoewel het (Nederlandse) Sketch ook goed aansluit bij het ontwerpen, kwam Figma beter uit de verf bij de overdracht en communicatie met ontwikkelaars.

Bovendien was Figma destijds het enige volwassen ontwerpprogramma die het mogelijk maakte om direct samen te werken in dezelfde bestanden. De standaard beschikbare versie-geschiedenis bleek in de praktijk een aantal maal een echte ‘life-saver’. Ontwikkelaars kunnen bovendien met een (gratis) account de ontwerpbestanden bekijken en ontleden.

Onze voorkeur ging uit naar een open-source product. Toch bleek er nog geen geschikte versie beschikbaar die ‘volwassen’ genoeg was om samen te werken aan een designsysteem.

Samenwerking met ontwikkelaars

In Figma benaderen we (zoveel mogelijk) dezelfde naamgeving zoals we die ook op codeniveau aanhouden. Hierdoor verloopt de overdracht en communicatie naar ontwikkelaars heel gestroomlijnd. Door het gebruik van ‘design tokens’ praten beide disciplines dezelfde taal en kunnen we ontwerpeigenschappen, componenten en dergelijke bij dezelfde naam noemen.

Ook kijken we voor de naamgeving van lagen, frames en pagina’s naar benamingen zoals die binnen HTML, ARIA, BEM en SVG wordt aangehouden.

Design tokens in Figma

Om binnen Figma met design tokens te werken, hebben we meerdere tools uitgeprobeerd. Uiteindelijk hebben we gekozen voor de open source Figma Tokens plug-in van ontwikkelaar Jan Six. Niet alleen wordt deze plug-in continu onderhouden, ook is de ontwikkelaar makkelijk te benaderen en staat open voor suggesties en verbeteringen aan de plug-in.

‘Single source of truth’ voor zowel ontwikkelaars als ontwerpers

Met behulp van de design tokens kunnen we uit een ‘single source of truth’ putten. Bij een eerste proof of concept bleek ruim 90% al direct te werken! Hierbij vertaalden we design tokens uit de code van de gemeente Utrecht door middel van Style Dictionary naar het (JSON) formaat dat we in Figma gebruiken.

Zoals altijd zijn er ook enkele zaken die nog niet helemaal soepel verlopen, omdat ontwerpprogrammatuur nog niet helemaal voor het medium web is geschikt. Zo zijn relatieve afmetingen niet in een omgeving als Figma toe te passen en moeten we ‘flexibele’ eenheden zoals EM’s, REM’s, CH’s en EX’s (X-hoogte van het gekozen lettertype) converteren naar exacte eenheden.

Andere beproefde webconcepten (zoals het maken van een ‘modulaire‘ typografische schaal) zijn daarentegen goed voorzien in de plug-in. Een modulaire schaal op basis van één standaard lettergrootte (de broodtekst) definieert alle andere lettergroottes (kopteksten en secundaire teksten), zodat een flexibel typografisch systeem ontstaat.

Stel dat jij binnen jouw website al gebruikt maakt van een modulaire schaal binnen de stijl van jouw organisatie, kan deze een-op-een worden overgenomen in Figma.

Schakelen van visuele stijl

In de Figma-omgeving kunnen we meerdere token sets laden. Dit stelt ons in staat om op basis van een white-label ontwerp deze om te zetten in de stijl van andere organisaties. Het is hierbij belangrijk om wel goed op de naamgeving te letten. Ook hierbij komen design tokens weer om de hoek kijken.

Design token niveaus

We gebruiken voor onze design tokens een gelaagde benadering. Zo hebben we op het hoogste niveau ‘brand tokens’. Een organisatie is vrij om binnen deze merktokens invulling te geven aan hun eigen visuele stijl en merkbeleving.

Brand tokens

Een brand token is bijvoorbeeld: utrecht-kleur-blauw-500 of denhaag-kleur-primaire-actie. Eén niveau daaronder vind je de ‘common tokens’. In deze tokens krijgen visuele eigenschappen een eigen betekenis toegewezen. Hierbij refereren deze tokens altijd aan de brand tokens.

Common tokens

Common token zien er bijvoorbeeld zo uit: document-color: utrecht-kleur-zwart.

Hierbij is de eerste documentkleur de standaard (tekst-) voorgrondkleur, en utrecht-kleur-zwart is de kleur die de gemeente Utrecht als merkkleur heeft gedefinieerd (de standaardkleur). Common tokens worden gebruikt voor veel voorkomende visuele stijlen die een semantische betekenis hebben.

Component tokens

Component tokens zijn tokens die voor specifieke componenten gebruikt worden. Een voorbeeld van een component token is bijvoorbeeld: button-primary-action-background-color: denhaag-kleur-primaire-actie.