Hoe geef je een link op een logo in de header een goede toegankelijke naam? We geven twee opties voor het toevoegen van de toegankelijke naam: via het alt-attribuut van een afbeelding of via een aria-label op de link. Welke optie je kiest is afhankelijk van het framework, CMS, of Design System dat je gebruikt.

Stappenplan voor de ontwikkeling van een toegankelijk webproject met het NL Design System. We nemen je aan de hand mee in het hele proces van begin tot eind, en vertellen je hoe het NL Design System in combinatie met de richtlijnen voor toegankelijkheid je hierbij kan helpen.

Vorig jaar ging het design system team van Logius, de organisatie die achter onder andere DigiD en MijnOverheid zit, samenwerken met de NL Design System community. We spraken met Aline Nap en Raoul Wittenberns over hun ervaringen.

“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.

Hoe geef je een gebruiker nuttige informatie over wat er niet goed gaat bij het invullen van een formulier? Wanneer je zorg besteedt aan het voorkomen en aangeven van fouten, is de kans dat een gebruiker het formulier verzendt veel groter.

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.

Met NL Design System community blocks wordt het nog makkelijker om NL Design System-componenten te gebruiken in WordPress. De grote aanjager van deze plug-in is de gemeente Den Haag, die hier met hun leverancier Acato aan werkten. We spraken Tom Dekker van Acato over het proces.

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 in het #nl-design-system-developers kanaal in de Code for NL Slack.

Gisteren was er weer een samenwerkdag met ontwerpers uit de NL Design System community. De ochtend stond in het thema van het estafettemodel, waarin we een eerste component hebben gecheckt op onze aangescherpte ‘definition of done’.

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!

Veel online aanvragen verlopen niet direct soepel. Denk hierbij aan foutmeldingen, onvolledig ingevulde vergunningsaanvragen en ontbrekende bijlagen. Dit is niet alleen vervelend voor de aanvrager, maar ook voor degene die de aanvraag moet behandelen. Daarom deed de gemeente Den Haag onderzoek naar een nieuw ontwerp voor de vergunningsaanvraag voor ondernemers. Onderzoeker Margo Welling en UX-designer Ananta Mulyono vertellen over het onderzoek en delen hun belangrijkste inzichten.

Je ziet het steeds vaker staan op overheidswebsites: ‘Stuur ons een WhatsApp-bericht’. Maar contact opnemen met een gemeente of bedrijf is meer dan een appje sturen. Niet iedereen kan namelijk bellen, WhatsAppen of langskomen op het stadskantoor. Als er dan geen alternatief is, laat je je bezoek in de steek. Daarom is het beter om meerdere contactmanieren aan te bieden, zodat mensen een keuze hebben. Ga uit van je bezoeker in plaats van je eigen werkwijze of gemak.

Bij NL Design System hebben we er heel bewust voor gekozen om alles open source beschikbaar maken. Zo kunnen we niet alleen makkelijker samenwerken, het maakt ook onze code echt herbruikbaar. De manier waarop we dat doen: licenties!

Vanaf 2024 gaat NL Design System verder als zelfstandig project. We spreken Victor Zuydweg (initiatiefnemer Gebruiker Centraal) en Peter Berrevoets (projectleider NL Design System) over toen en nu.

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.

Op donderdag 7 december kwam de Community Online Formulieren van Gebruiker Centraal bij elkaar. Francesca Vonk en Rian Rietveld waren uitgenodigd om meer te vertellen over de richtlijnen voor formulieren én over het testen met gebruikers.

In de afgelopen maanden werkte het NL Design System kernteam samen met VNG aan generieke formulieren. Vorige week testten we ze met gebruikers bij Stichting Accessibility in Utrecht.

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.

Vorige week kwamen designers van Gemeente Utrecht, Gemeente Den Haag en OpenGemeenten bij elkaar om te spreken over design tokens voor spacing: de ruimte tussen de verschillende componenten. Designer Jeroen du Chatinier van de Gemeente Utrecht vertelde erover in de Design Open Hour.

In zo’n 20-25 minuten leren over design systems van experts van bijvoorbeeld GOV.UK, GitHub en Kamer van Koophandel? Net als vorig jaar organiseert het NL Design System-kernteam een Design Systems Week.

Al vanaf het begin gebruikt Gebruiker Centraal de lettertypes Montserrat en League Gothic. Dat gaat veranderen, te beginnen bij NL Design System. We leggen je graag uit waarom.

Eind vorig jaar hebben we samen met de community stilgestaan bij de plannen en werkzaamheden voor 2022. Nu het jaar er bijna op zit, is het dan ook tijd om terug te blikken en te kijken naar wat er allemaal gedaan is. Eén ding is zeker; 2022 was een druk jaar.

Een dag als ontwerper bij het NL Design System ziet er heel anders uit dan bij andere design systems. Dit komt mede doordat het NL Design System geen ‘traditioneel’ design system is met slechts een enkele huisstijl. In dit artikel leg ik als ontwerper uit hoe de werkzaamheden bij het NL Design System eruit zien.

Front-end developer Bryan de Jong werkte 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.

Het was weer een bijzonder jaar. Zeker ook voor NL Design System. En we zijn blij dat we zoveel hebben kunnen bereiken en trots op de mooie resultaten die we hebben geboekt. We blikken graag terug op het afgelopen jaar.

Alles over Figma, de tool voor het ontwerpen van de componenten en patronen, en waarom we dat bij NL Design System gebruiken.

NL Design System is 1 van 20 projecten die een bijdrage uit het Innovatiebudget Digitale Overheid 2021 ontving. We kregen dat voor de pilot ‘Samenwerkingsmodel herbruikbare basisonderdelen voor overheidsbrede dienstverlening’ waarmee we de inrichting van samenwerking over overheidsorganisaties heen binnen 1 centraal (design) systeem beproeven.

2 teams bij verschillende organisaties werken deze periode voor hun eigen doeleinden aan NL Design System-componenten. De ontwikkelingen zijn ver genoeg gevorderd dat ze de komende 2 weken gebruik gaan maken van elkaars componenten. Binnenkort sluiten meer teams aan.

Samenwerken naar één overheidsbeleving voor de burger, dat is waar het NL Design System om draait. Carina Palumbo en Sjef van Leeuwen van Wigo4it draaien er niet omheen; in de toekomst hoor je er als overheidsinstantie niet meer bij zonder een gezamenlijke implementatie van het NL Design System! In deze blog vertellen zij vanuit hun technische en UX-ervaring over de realisatie van het designsysteem.

In een (online) bijeenkomst op 3 november presenteerden we een aantal goede voorbeelden van contentricthtlijnen en gingen we met de deelnemers aan de slag om met elkaar te verzinnen hoe dit in het Nederlandse designsysteem zou passen. Tijdens deze bijeenkomst is er gesproken over de verschillende content-aspecten in een designsysteem. We hebben de algemene conclusies voor je op een rij gezet.

We hebben met het NL Design System een aanvraag gedaan voor het Innovatiebudget 2020. En we kunnen met trots melden dat we 1 van de 24 projecten zijn waarvan de aanvraag is gegund! Het innovatiebudget wordt elk jaar door BZK uitgereikt aan innovatieve projecten, die bijdragen aan de verbetering van de digitale dienstverlening van de overheid.

Tijdens de International Design in Government conferentie vroegen we de aanwezige deelnemers of ze een vragenlijst over design systemen wilden invullen. Omdat wij bezig zijn met de ontwikkeling van een centraal design systeem voor de Nederlandse overheid: het NL Design System, willen we gebruikmaken en leren van bestaande kennis en ervaring.

Update over de stand van zaken rondom het traject NL Design System, geïnitieerd door Gebruiker Centraal. In samenwerking met medewerkers van diverse overheidsorganisaties.

We zijn uit de startblokken met de werkgroepen van het NL Design System! Woensdag 24 april hebben twintig ontwerpers, UX experts en ontwikkelaars met elkaar nagedacht over principes, criteria en concrete componenten.

Eén overheid - Practise what you preach. Een gezamenlijk design system voor de overheid.

Doe mee! Samen werken aan één design system voor Nederland. Sluit je aan, doe mee via bijeenkomsten, praat mee via Slack.

De mensen achter GOV.UK zijn in 2017 gestart met een internationale community van designers en ontwikkelaars. Op 23 april 2018 organiseerden ze een call over design systems, waaraan 42 deelnemers uit alle hoeken van de wereld deelnamen.