Auteur
Francesca Vonk MSc - Senior UX Designer
Vereniging voor Nederlandse Gemeenten
- 1. E-formulieren en notificaties en de Wet modernisering bestuurlijk verkeer
- 2. Inhoudsopgave
- 3. Introductie
- 4. Wet Modernisering Elektronisch Bestuurlijk Verkeer
- 5. Theorie: Ontwerpcriteria voor het ontwerpen en toetsen van e-formulieren en notificaties
- 5.1. Digitale Toegankelijkheid en Gebruikersvriendelijkheid
- 5.2. Rechtsgeldigheid en Authenticatie
- 5.3. Privacybescherming
- 5.4. Veiligheid
- 5.5. Aanpasbaarheid en Responsiviteit
- 5.6. Duidelijke Instructies en Hulpfuncties
- 5.7. Notificatie-Inhoud en Timing
- 5.8. Testen met Gebruikers
- 5.9. Ontwerpcriteria samengevat
- 6. Praktijk: Ontwikkeling van generiek e-formulier op basis van NL Design System
- 7. Bronnen en overige informatie
Deze handreiking is tot stand gekomen in opdracht van de Vereniging van Nederlandse Gemeenten Realisatie (VNGR) in samenwerking met NL Design System. Voor de handreiking zijn verschillende bronnen gebruikt. Naast desk-research is er een generiek e-formulier op basis van het NL Design System ontworpen en ontwikkeld. Het generieke e-formulier en de bijbehorende scenario's zijn ontwikkeld om inzage te geven in hoe enerzijds omgegaan zou kunnen worden met producten die nog niet beschikken over een e-formulier en anderzijds om te laten zien hoe met het gebruik van NL Design System binnen een relatief korte tijd gekomen kan worden tot een gebruikersvriendelijk en toegankelijk e-formulier. Het e-formulier en de bijbehorende vervolgschermen, en daarmee dus het scenario, zijn voorgelegd aan experts binnen de VNG, de NL Design System Community en tevens getoetst door Stichting Accessibility zodat deze handreiking in de praktijk gevalideerd is.
De doel van deze handreiking is om inzichten te delen betreft het ontwerpen en ontwikkelen van een generiek e-formulier op basis van NL Design System zodat deze voldoet aan de wet modernisering bestuurlijk verkeer (Wmebv). Tevens wordt gekeken naar wat de Wmebv betekent voor notificaties. De volgende onderwerpen worden in deze handreiking behandeld:
- Wmebv in het kort
- Ontwerpcriteria voor het maken van Wmebv proof e-formulieren en notificaties
- Het ontwerpen en ontwikkelen van een generiek formulier met behulp van NL Design System voor een brede generieke inzet.
- Implementatieadviezen met betrekking tot het Wmebv proof maken van e-formulieren en notificaties.
Deze handreiking is bestemd voor ieder die meer te weten wil komen over het Wmebv proof maken van e-formulieren en notificaties.
Deze handreiking en de bijbehorende schermvoorbeelden zijn een samenwerking van VNGR met het NL Design System kernteam, (UX) designers uit de NL Design System Community en met name de UX designer van Gemeente Den Haag, waar al veel onderzoek gedaan is naar de gebruikersvriendelijkheid van notificaties.
In de Handreiking van Het Ministerie van Binnenlandse Zaken in samenwerking met Logius wordt het doel van deze wet helder benoemd:
De regering wil in het kader van de digitaal werkende overheid komen tot de implementatie van het wetsvoorstel modernisering elektronisch bestuurlijk verkeer. Met name de huidige regel dat een bestuursorgaan verkeer via de elektronische weg moet toestaan en dus ook kan uitsluiten, wordt als verouderd ervaren. Kabinetsbeleid is daarom dat bedrijven en burgers zaken die ze met de overheid doen – zoals het aanvragen van een vergunning – digitaal moeten kunnen afhandelen. Elektronisch bestuurlijk verkeer kan bijdragen aan de vermindering van administratieve lasten van burgers en bestuurlijke lasten van bestuursorganen. De wet neemt belemmeringen weg en stelt enkele randvoorwaarden aan de modernisering en digitalisering van de werkprocessen binnen de publieke sector. Burgers en bedrijven krijgen het recht (niet de plicht) om ieder formeel bericht elektronisch aan de overheid te zenden. Bij gebruik van de elektronische weg gelden er nieuwe waarborgen, waardoor nog meer rechtsbescherming wordt gerealiseerd. Tegelijkertijd houden bestuursorganen ruimte om digitale processen af te stemmen op de eigen organisatie. Om een compacte, efficiënte overheid te realiseren met hoogwaardige dienstverlening, is digitalisering een vereiste en is het digitale kanaal het voorkeurskanaal. Het uitgangspunt is: digitaal waar het kan. Het doel van de Wmebv is om regels over elektronisch bestuurlijk verkeer te moderniseren en burgers en bedrijven het recht te geven om elektronisch zaken te doen met de overheid. Degenen die dat willen moeten voor het digitale kanaal kunnen kiezen in hun contact met de overheid. Om te waarborgen dat iedereen met de overheid kan (blijven) communiceren, is het van belang dat communicatie langs de papieren weg mogelijk blijft. En dat de provincie een inclusief beleid voor ondersteuning van bepaalde doelgroepen gaat uitvoeren.
Bron: Handreiking implementatie Wet modernisering elektronisch bestuurlijk verkeer (Awb) 2023.
De Wmebv is een belangrijk element in de bredere digitale transformatie van overheidsdiensten in Nederland en het is ontworpen om de overgang naar een meer digitaal georiënteerd bestuurlijk verkeer te vergemakkelijken.
- Wmebv is een wijziging van de Algemene Wet Bestuursrecht
- Wmebv geeft het recht op digitaal communiceren met bestuursorganen
- Wmebv stelt het openstellen van digitale kanalen verplicht, voor ieder formeel bestuurlijk bericht gericht aan het bestuursorgaan
- Wmebv resulteert in het aanpassen van digitale kanalen zodat het aan de wettelijk gestelde eisen voldoet.
Voordat er iets dieper ingegaan wordt over de Wmebv, is het belangrijk om aan te geven om wat voor berichtenverkeer het gaat in de Wmebv. In de diverse documentatie betreft de Wmebv wordt er op verschillende manieren gerefereerd naar het 'Elektronisch Bestuurlijk Verkeer''. Dit verkeer, in de vorm van digitale berichten, wordt in diverse documentatie ook wel 'Officiële berichten', 'Formele berichten' en 'Formeel officiële berichten' genoemd. In alle gevallen wordt hetzelfde bedoeld. In deze handreiking wordt de term 'formele berichten' aangehouden. Met het 'elektronisch bestuurlijk verkeer' worden dus de 'formele berichten' bedoeld en deze verwijzen doorgaans naar officiële communicatie tussen verschillende bestuurlijke niveaus binnen een overheid. Deze berichten bevatten vaak belangrijke mededelingen, beslissingen, of andere informatie van juridische of bestuurlijke aard. Enkele veelvoorkomende voorbeelden:
- Berichten die deel uit maken van een procedure of besluit (zoals bijvoorbeeld: een aanvraag, zienswijze, ingebrekestelling of bezwaarschrift)
- een klacht
- anders krachtens wettelijk voorschrift voorgeschreven bericht. Bijvoorbeeld een melding.
Niet-officieel bestuurlijke berichten zijn alle andere berichten zoals informele contacten.
Het exacte bereik en de aard van formele berichten kunnen sterk variëren, dus het is belangrijk om de specifieke wetgeving en bestuurlijke structuren in overweging te nemen om een vollediger beeld te krijgen van welke producten onder deze term vallen. Voor deze handreiking is het echter van belang het verschil tussen niet formele berichten en formele berichten aan te duiden, om zo duidelijk te maken dat de Wmebv niet voor alle processen/producten geldt maar enkel voor de formele berichten. Voor meer verdieping in de juridische aspecten wordt verwezen naar de video-opname van Kennissessie 1: Juridisch Aspecten van 9 oktober 2023, die te vinden is op de website: VNG webinars en kennissessies
Om toch in deze handreiking een idee te geven van de strekking van de Wmebv, wat veel verder strekt dan enkel e-formulieren en notificaties, worden de belangrijkste aspecten op een rij gezet. Zie echter voor een zeer uitgebreide toelichting op de Wmebv de Handreiking implementatie Wet modernisering elektronisch bestuurlijk verkeer (Awb) 2023. van het Ministerie van Binnenlandse Zaken.
Allereerst is het belangrijk om te weten dat de Wmebv over processen of beter gezegd, communicatiestromen gaat. Communicatiestromen tussen burger en overheidsinstantie. De stroom van een formeel bericht kent een begin en een eind. De stroom verloopt in verschillende fasen. Een formeel bericht wordt geïnitieerd (Zie het schema: 'Voor ontvangst') en vervolgens verstuurd. Als het goed gaat, wordt het bericht ontvangen door de overheidsinstantie (Zie het schema: 'Na ontvangst'). Vervolgens wordt het bericht in behandeling genomen en tijdens de behandeling kunnen vervolgacties voor de burger of instantie voortvloeien. Deze acties worden uitgevoerd, gelogd en er wordt over gecommuniceerd (zie het schema: 'Uitgaande formele berichten'), net zolang tot de behandeling van de initiële vraag of de daaruit voortgevloeide vragen of acties afgehandeld zijn. Naast de ze digitale communicatiestroom van formele berichten tussen burger en instantie, regelt de Wmebv een zorgplicht die stelt dat er voor passende ondersteuning gezorgd moet worden voor de mensen die minder goed mee kunnen komen in de digitale wereld.
Afbeelding: Schematische weergave Wmebv
De aspecten van de Wmebv zijn op te delen in onder andere een aantal blokken met daarin fasen waarin een formeel bericht zich bevindt:
Blok 1 - Binnenkomende formele berichten:
Dit blok is onder te verdelen in twee fasen:
Fase 1 - Voor ontvangst:
Een formeel bericht kan op verschillende manieren binnenkomen, afhankelijk van het gekozen/aangeboden digitale kanaal. Denk aan:
- Een generiek contactformulier met upload mogelijkheid. (Later in deze handreiking wordt een voorbeeld behandeld van een generiek formulier.)
- E-mailkanaal (Echter, de meningen zijn nog verdeeld over hoe veilig dit medium is.)
- Specifiek webformulier met DigiD / e-Herkenning
- Via een MijnOmgeving
- Via een Berichtenbox (Bijvoorbeeld MijnOverheid)
De Wmebv regelt dat instanties de wijze van indienen bekend maken door kanalen aan te wijzen en dit bijvoorbeeld vast te leggen in een aanwijzingsbesluit en de burgers te informeren over het aangewezen digitale kanaal. Er zijn een aantal belangrijke punten voordat een officieel bericht ontvangen kan worden:
- De digitale weg veilig moet veilig zijn. Belastende of onveilige berichten worden geweigerd.
- Er mogen geen technische eisen gesteld worden die onnodig belemmerend zijn.
- Er mogen geen gegevens afgedwongen worden zonder grondslag. Alleen noodzakelijke gegevens mogen worden uitgevraagd.
- De gemeente heeft de bevoegdheid tot het verlengen van de indieningstermijn bij storing en dient dit bekend te maken op bijvoorbeeld de website.
Fase 2 - Na ontvangst:
De Wmebv regelt dat er ontvangstbevestiging verstuurd moet worden. Indien berichten intern doorgeleid zijn of afgewezen zijn, dient dit medegedeeld te worden.
Intern doorgeleiden is verplicht als:
- het bericht zonder nadere bewerking behandeld kan worden
- het bezwaarschrift of beroepsschrift is
- voor het type bericht geen wijze van verzending is aangewezen.
- de aanvang wettelijke behandeltermijn opschuift naar tijdstip van het intern doorleiden
- mededelingen aan de afzender van het doorgeleiden en tijdstip waarop de termijn aanvangt
De Wmebv regelt ook dat indien een bericht verkeerd is ingezonden, en om die reden is afgewezen, dat er een mededeling aan de afzender gezonden moet worden waarin vermeld wordt wat de juiste wijze van indiening is.
De Wmebv regelt dat ingevulde gegevens van een e-formulier terug-getoond moeten worden. Hetzij via:
- een download mogelijkheid tijdens het aanvraagproces
- inzage via een MijnOmgeving
- het toezenden van het afschrift
Wmebv-ontwerpadvies:
Denk bij het ontwerpen van deze communicatie aan de hierboven genoemde punten. Bijvoorbeeld op deze manier:
Afbeelding: Mogelijkheid tot printen en downloaden.
Tot slot dient de gemeente bewijslast te hebben, dat betekent dat een systeem moet zijn waarin gegevens gelogd worden.
Blok 2 - Uitgaande formele berichten:
Dit blok is niet verder onderverdeeld in fasen. Bij dit blok geld dat de Wmebv regelt dat als er genotificeerd wordt, dat er met een aantal zaken rekening gehouden moeten worden, namelijk:
- de afzender moet worden vermeld
- de aard van het bericht moet worden vermeld (Bijv. ontvangstbevestiging, beschikking, betalingsverplichting etc.)
- en een reactietermijn
- Indien een bericht of notificatie niet bezorgd kan worden (een bounce) dan moet het minimaal eenmaal opnieuw verzonden worden.
- De gemeente heeft een inspanningsverplichting om het juiste e-mailadres te achterhalen
- Notificaties moeten op andere wijze verzonden kunnen worden
In het volgende hoofdstuk wordt nog iets dieper ingegaan op notificaties.
Wmebv-ontwerpadvies:
Denk bij het ontwerpen van deze communicatie aan de hierboven genoemde punten Voor meer gedetailleerde informatie over notificaties wordt verwezen naar de bijdrage over notificatie en Wmebv door Logius. Waar onder andere toelichting gegeven wordt op de nieuwe notificatie templates die door hen ontwikkeld zijn het meest recente UX onderzoek naar communicatie templates vond plaats in oktober 2023, de resultaten zullen naar verwachting spoedig beschikbaar zijn. Ook worden nieuwe technische mogelijkheden zoals een nieuwe variabele voor een 'einddatum handelingstermijn' in meer detail besproken.\
De gemeente heeft tevens een bewijslast en moet het volgende kunnen bewijzen:
- Het tijdstip van verzending of ontvangst
- De verzending met de samenhangende ontvangstbevestiging of notificatie
- Tijdstip inlog geadresseerde om kennis te nemen van een aan hem gezonden bericht
- Ontvangen meldingen van formele berichten die niet konden worden bezorgd
Voor meer verdieping in de juridische aspecten wordt verwezen naar de video-opname van Kennissessie 1: Juridisch Aspecten genoemd in paragraaf 4.2
Blok 3 - Zorgplicht:
Tot slot staat in het schema de zorgplicht genoemd.
De Wmebv regelt tevens een zorgplicht voor passende ondersteuning bij communicatie.
Denk hierbij aan:
- Passende ondersteuning is afgestemd op de doelgroepen en hun vaardigheden (lezen, schrijven, omgaan met digitale apparaten)
- Passende ondersteuning is generiek (zoals informatie op een website) en persoonlijk (zoals hulp aan de telefoon of balie)
- Bij Passende ondersteuning is maatwerk niet verplicht
- Beleid over passende ondersteuning opstellen en publiceren op de website (bijvoorbeeld regels of een (uiteraard toegankelijke) handreiking)
Voor een uitgebreide toelichting op de Zorgplicht wordt verwezen naar de video-opname van 11 oktober 2023, Kennissessie 3: Zorgplicht
Bij het toetsen van formulieren en notificaties Wmebv is het van belang om te zorgen dat deze voldoen aan de eisen van de wet, met een focus op digitale toegankelijkheid en gebruiksvriendelijkheid. Hier zijn enkele specifieke punten waaraan aandacht besteed zou moeten worden:
Zorg ervoor dat formulieren en notificaties voldoen aan de richtlijnen voor digitale toegankelijkheid, zoals vastgesteld in de Web Content Accessibility Guidelines (WCAG). De meest voor de hand liggende punten om rekening mee te houden:
-
De structuur van het formulier zowel in de frontend als de backend moet goed in elkaar zitten, vermijd hierbij, indien mogelijk, een horizontale layout. Voorzie alle inputvelden van een label en stapel de velden bijvoorbeeld:
Afbeelding: Gestapelde labels en velden.Advies onderzoeksvraag:
Wordt het formulier met een screen reader in de juiste volgorde voorgelezen? -
Maak foutmeldingen visueel en tekstueel duidelijk. Leid de gebruiker naar de plek waar de fout opgelost moet worden
Afbeelding: Foutmeldingen in een e-formulierAdvies onderzoeksvraag:
Kunnen gebruikers met diverse niveaus van geletterdheid en visueel, auditieve en fysieke beperkingen, zonder in de stress te raken, de fouten in het formulier vinden en oplossen? -
Zorg ervoor dat formulieren met het toetsenbord bediend kunnen worden.
-
Houdt rekening met tijdslimieten waarin een formulier ingevuld moet worden, niet iedereen kan dit in een vergelijkbaar tempo.
Advies onderzoeksvraag:
Kunnen gebruikers met diverse niveaus van geletterdheid en visueel, auditieve en fysieke beperkingen, zonder muis en met een toetsenbord eenvoudig door het formulier navigeren binnen een eventueel gestelde tijd?
- Vertrouw niet alleen op kleur en zorg voor leesbare tekst op B1 niveau en test het formulier en de website op het kleurcontrast in verband met de vele vormen en gradaties van kleurenblindheid.
Afbeelding: Screenshot van kleurenfilter test.
Bron: https://www.toptal.com
Naast toegankelijk formulieren is het ook belangrijk de eventuele bijlagen in de vorm van documenten digitaal toegankelijk te maken. Zoals digitaal toegankelijke pdf's of afbeeldingen die voor mensen die blind of slechtziend is niet te ontcijferen zijn.
- Overweeg om in plaats van pdf's, toegankelijke HTML te gebruiken indien de inhoud enkel bekeken dient te worden
- Overweeg om OpenDocument te gebruiken voor pdf-formulieren die aanpasbaar moeten zijn.
- Als er toch pdf gebruikt moet worden, zorg ervoor dat Pdf's zo digitaal toegankelijk mogelijk zijn en overweeg dan een digitaal toegankelijke versie van de inhoud, in bijvoorbeeld HTML, ernaast aan te bieden.
- Onthoudt dat het makkelijker is om digitaal toegankelijke HTML of OpenDocument te maken dan een digitaal toegankelijke pdf.
Zorg ervoor dat de taal eenvoudig en duidelijk is en dat gebruikers gemakkelijk door het formulier of de notificatie kunnen navigeren. Voor meer informatie wordt verwezen naar de aanbevolen richtlijnen voor taalgebruik van Dienst Publiek en Communicatie van het Ministerie van Algemene Zaken.
- Vul invulvelden waar mogelijk vooraf in
- Geef voorwaarden, uitleg, benodigde informatie, documenten aan
- Gebruik duidelijke taal en begrippen
- Licht vragen en termen toe, waar nodig
- Test de formulieren en notificaties op algemene gebruiksvriendelijkheid. Zijn ze intuïtief en gemakkelijk te begrijpen voor de gebruiker?
Note: NL Design System werkt ten tijde van dit schrijven, aan vernieuwde richtlijnen voor e-formulieren, naar verwachting zijn deze vernieuwde richtlijnen medio januari 2024 beschikbaar op de pagina voor richtlijnen voor formulieren van NL Design System.
Controleer of de gebruikte elektronische handtekeningen en authenticatiemethoden voldoen aan de wettelijke vereisten voor rechtsgeldigheid. Zorg ervoor dat er passende maatregelen zijn genomen om de identiteit van de gebruiker te verifiëren.
Wees alert op privacykwesties bij het verzamelen en verwerken van persoonsgegevens. Zorg ervoor dat de formulieren en notificaties voldoen aan de Algemene Verordening Gegevensbescherming (AVG) en andere relevante privacywetgeving. Raadpleeg hiervoor de uitgebreide informatie over privacybescherming op de website van de Rijksoverheid.
Controleer of er voldoende beveiligingsmaatregelen zijn genomen, met name bij het verzenden van gevoelige informatie. Beveiligde verbindingen (HTTPS) en versleuteling van gegevens zijn hierbij belangrijk.
Zorg ervoor dat formulieren en notificaties goed werken op verschillende apparaten en schermformaten. Zorg ervoor dat de formulieren ook goed werken op mobiele apparaten zoals telefoons en tablets. Houdt hierbij extra rekening met dat het juiste mobile toetsenbord wordt aangeboden bij de bijbehorende velden. Qwerty bij tekstvelden, nummerriek bij nummervelden etc. Uit het recent uitgevoerde usability onderzoek dat verderop in dit document wordt toegelicht, kwam naar voren dat het merendeel van de participanten gebruikmaken van hun mobile telefoon of tablet om dergelijke formulieren in te vullen. Daarbij zijn ze vaak geholpen met de woordsuggesties die het mobile apparaat toont, om zo sneller een tekst te kunnen produceren.
Afbeelding: Mobiel toetsenbord met woordvoorspelling mogelijkheid.
Responsiviteit of adaptiviteit is essentieel voor een goede gebruikerservaring op zowel desktops als mobiele apparaten. Hierbij een interessant artikel over het verschil tussen Responsive en Adaptive ontwerp.
Bied duidelijke instructies bij het invullen van formulieren en zorg voor eventuele hulpfuncties indien nodig. Gebruikers moeten gemakkelijk de benodigde informatie kunnen vinden en begrijpen hoe ze het formulier moeten invullen. Nielsen Norman Group schreef een helder artikel over Help en Documentation.
Bij notificaties is het belangrijk dat de inhoud relevant, begrijpelijk en tijdig is. Vermijd overbodige informatie en zorg ervoor dat de notificatie op het juiste moment wordt verstuurd. Hierbij geldt voor de Wmebv dat de notificatie binnen 48 uur na plaatsing van het formele bericht in het systeem voor gegevensverwerking aan de geadresseerde van het bericht worden gestuurd en dat de inhoud aan een aantal eisen moet voldoen, zoals:
- De aard en rechtsgevolg van de boodschap moet vermeld worden.
- Er moet duidelijk vermeld worden dat er een reactie van de geadresseerde verwacht wordt (bijvoorbeeld: betalen, informatie verstrekken).
- Wanneer een bericht een termijn bevat waarbinnen de geadresseerde moet reageren, moet deze termijn ook vermeld worden in de notificatie.
Dit en meer is uitgebreid terug te lezen is in de bijdrage over notificaties en de Wmebv van Logius.
Voer usability-tests uit met gebruikers om inzicht te krijgen in hun ervaring en eventuele pijnpunten te identificeren. Dit kan helpen bij het verbeteren van de algehele gebruikerservaring. Goed om te weten is dat al met vijf participanten al een groot deel van de pijnpunten aan het licht komen. Het is aan te raden gebruik te maken van instanties die gespecialiseerd zijn in het uitvoeren van Usability tests, zoals Stichting Accessibility of Valsplat.
In de paragraaf hiervoor is uitgebreid stilgestaan bij ontwerpcriteria voor e-formulieren en notificaties waarmee in het algemeen en Wmebv specifiek rekening gehouden moet worden. Hieronder worden de punten voor het gemak nog even op een rijtje gezet. een praktische lijst met ontwerpcriteria waarmee rekening gehouden dient te worden tijdens het ontwerp van e-formulieren en notificaties.
Algemene e-formulier ontwerpcriteria:
Let op, de vetgedrukte een met (**) gemarkeerde punten zijn ook van toepassing op de Wmebv.
- Vul invulvelden waar mogelijk vooraf in
- Geef voorwaarden, uitleg, benodigde informatie, documenten aan
- Gebruik duidelijke en eenvoudige taal en begrippen **
- Licht vragen en termen toe, waar nodig
- Zorg voor toegankelijke bijlagen zoals toegankelijke pdf's of HTML.
- Vraag alleen noodzakelijke gegevens en informatie **
- Geef aan welke vragen/velden verplicht zijn
- Geef foutmeldingen duidelijk en gebruikersvriendelijk aan
- Geef processtap in formulier aan tijdens het invulproces
- Ondersteun de bezoeker bij het invullen en afronden, door duidelijke knoppen
- Zorg voor tussentijdse opslag van informatie
AVG-regels waar rekening mee moet worden gehouden:
- Wees transparant
- Verzamel zo min mogelijk persoonsgegevens **
- Vraag toestemming
- Gebruik eenvoudige taal
- Verzend e-formulieren over versleutelde verbindingen **
- Registreer verwerking in verwerkingsregister **
Wmebv e-formulier ontwerpcriteria:
Naast de de met (**) gemarkeerd punten zijn er nog twee punten die in het achterhoofd gehouden moeten worden. Op zich zijn onderstaande punten niet perse e-formulier ontwerpcriteria, echter moet er wel rekening mee gehouden worden tijdens het ontwerp van de communicatiestroom waar het e-formulier of notificatie onderdeel vanuit maakt.
- Toon of verstuur (indien mogelijk) een ontvangstbevestiging
- Maak ingevulde gegevens toegankelijk voor de indiener.
Deze lijst is onder andere geput uit de door de VNG aangeboden Toolkit Meten en Verbeteren van Webformulieren. het A11Y project en het World Wide Web Consortium (W3C).
Zoals eerder aangegeven in dit document: NL Design System werkt ten tijde van dit schrijven, aan vernieuwde richtlijnen voor e-formulieren, naar verwachting zijn deze vernieuwde richtlijnen medio januari 2024 beschikbaar op de pagina voor richtlijnen voor formulieren van NL Design System.
Voor meer gedetailleerde informatie over notificaties wordt verwezen naar de bijdrage over notificatie en Wmebv door Logius. Waar onder andere toelichting gegeven wordt op de nieuwe notificatie templates die door hen ontwikkeld zijn en nieuwe technische mogelijkheden zoals een nieuwe variabele voor een 'einddatum handelingstermijn'.
Om een praktisch voorbeeld te kunnen geven van een generiek e-formulier is er samengewerkt met NL Design System om binnen een relatief korte tijd te kunnen komen tot een generiek formulier waar niet alleen code van de gebruikte NL Design System componenten beschikbaar wordt gesteld maar ook inzage geeft in het ontwerpproces en de bouw met behulp van NL Design System componenten. Er is gekozen voor het generieke formulier "Vraag aan uw gemeente", omdat dit het meest laagdrempelige formulier is wat wellicht initieel ingezet kan worden om een digitaal kanaal open te kunnen zetten voor met name die processen die nog niet over een (specifiek) formulier beschikken, maar die wel gecategoriseerd zijn als processen waar het berichtenverkeer geldt als formeel bericht. Het "Vraag uw gemeente"-formulier kan als initieel digitale contactformulier gebruikt worden, indien er onvoldoende tijd is voordat de Wmebv van kracht gaat om een goed, veilig, Digitaal toegankelijk en Wmebv-proof specifiek formulier voor bepaalde producten te kunnen ontwikkelen. Let wel, dat de behandeling van een degelijk generiek formulier omslachtiger zal zijn dan wanneer er gebruik gemaakt zou worden van een bijvoorbeeld een specifiek formulier in combinatie met een achterliggend zaaksysteem, denk hierbij aan de Omnichannel kanaalstrategie en de bijbehorende kennissessie van 10 oktober 2023: Video - Kennissessie 2: Omnichannel
NL Design System is een methodiek van samenwerken. NL Design System is een community van ontwerpers en ontwikkelaars met allerlei expertise, van UX-, UI-, toegankelijkheidsexperts tot programmeurs, die samenwerken aan de totstandkoming van een grote verzameling Open Source componenten, denk aan bijvoorbeeld een button, een invoerveld of een combinatie van componenten die een hele header vormen. Deze componenten worden voorzien van een consistente huisstijl en richtlijnen. Denk bijvoorbeeld aan richtlijnen voor het ontwerpen van e-formulieren of een hele MijnOmgeving met componenten van NL Design system of het schrijven van toegankelijke teksten. Het werken met en aan componenten van NL Design System resulteert in een steeds grote groeiende bibliotheek van digitaal toegankelijke componenten waaruit geput kan worden bij het ontwerpen en ontwikkelen van digitale overheidsproducten zoals websites en e-formulieren.
Samen maken we de digitale dienstverlening van de overheid toegankelijk, inclusief en gebruiksvriendelijk.
Een design system lijkt op basis van de naam vooral over ontwerp te gaan, maar het is eigenlijk een brede aanpak om makkelijker consistente, toegankelijke en gebruiksvriendelijke websites en applicaties te maken.
Dat doet het kernteam niet alleen, maar samen met ontwerpers, ontwikkelaars, content schrijvers en andere experts uit verschillende organisaties.
- Gebouwd en gebruikt door de community
- Platform en huisstijl onafhankelijk
- Uitbreidbaar en publiek beschikbaar
Bron: website NL Design System
Om de NL Design System componenten te voorzien van huisstijl wordt gebruik gemaakt 'thema's' waarin de ontwerpkeuzes voor de honderden NL Design Tokens staan. Uiteraard hoeven niet alle honderden aangepast te worden, maar het geeft de mate van flexibiliteit aan. Zo zijn er design tokens voor de verschillende lettertypes, kleuren van knoppen, randjes van knoppen, border-radius van knoppen en nog veel meer. Met een thema zijn de componenten dus te voorzien van hun eigen stijl, zodat deze aansluit op de huisstijl van de organisatie en zonder afbreuk te doen aan de digitaal toegankelijke werking ervan, mits uiteraard gehouden wordt aan de richtlijnen, denk bijvoorbeeld aan kleurcontrast, waarover werd toegelicht in paragraaf 5.1. Om nog iets dieper in te gaan op de samenwerking tussen ontwerpers en ontwikkelaars is het interessant om te weten dat met behulp van de design tool genaamd Figma in combinatie met de Token Studio plugin er een naadloze samenwerking ontstaat tussen het ontwerpen in Figma en de daadwerkelijke styling van de geprogrammeerde schermen. Waar vroeger een stijlgids overgenomen moest worden door frontend developers, kan de ontwerper nu zelf styling aandragen en updaten rechtstreeks vanuit Figma. Voor meer over deze magie wordt verwezen naar een interessante video presentatie over design tokens tijdens het jaarlijkse Design Systems Week en de tekstuele toelichting op design tokens op NL Design System. Tot slot is het interessant om te zien hoe verschillende gemeenten al hun eigen thema's beginnen op te bouwen en bijhouden in het NL Design System Storybook.
Afbeelding: Het effect op styling middels design tokens.
Bron: website NL Design System
De NL Design System richtlijnen, patronen en componenten (vanaf nu: 'onderdelen') ontstaan vanuit de community. Als deze onderdelen worden ontworpen en ontwikkeld, bewegen ze zich door het zogenaamde 'Estafettemodel'. Onderdelen worden tijdens hun estafettereis door de community aangedragen, ontworpen en ontwikkeld volgens de NL Design System richtlijnen om uiteindelijk de Hall of Fame status te kunnen bereiken, wat inhoud dat een onderdeel voldoet aan de Definition of Done van NL Design System.
Onderdelen worden tijdens hun Estafettereis Open Source gedeeld met iedereen in de community. Op Slack (een berichten applicatie voor communities) en tijdens de wekelijks Design Open Hour en twee wekelijke Heartbeat sessies wordt iedereen uitgenodigd ontwerpenvraagstukken aan te dragen, ontwerpen te presenteren en/of feedback te geven. Op deze manier leert de community van elkaar en worden de componenten steeds eenduidiger verder doorontwikkeld, wat uiteindelijk resulteert in steeds groter groeiende bibliotheek van onderdelen die door iedereen gebruikt kunnen worden en wat leidt tot een eenduidig en consistente User Experience van overheidsproducten. Een mooi voorbeeld is het GOV.UK Design System van het Verenigd Koninkrijk.
Voor het ontwerp en de ontwikkeling van het generieke e-formulier is er nauw samengewerkt met UX designers, accessibility experts en developers vanuit het NL Design System kernteam en UX designers uit de NL Design system community. Met name een UX Designer van gemeente Den Haag, die al veel ervaring heeft met het ontwerpen in Figma op basis van NL Design System en ook veel onderzoek heeft gedaan naar gebruikersvriendelijkheid van generieke services binnen de MijnOmgeving. Er heeft ten tijde van het ontwerp een grote ontwerpworkshop plaatsgevonden in de NL Design System community waarin onder andere over ontwerppatronen, styling en tekst collectieve besluiten zijn genomen. Deze besluiten zijn doorgevoerd in de schermontwerpen om deze mee te kunnen nemen in de usability test. Tevens is het ontwerp onder ander gedeeld tijdens de de Heartbeat sessie van 31 oktober 2023 van NL Design System en een e-formulieren sessie van Gebruikers Centraal.
Afbeelding: Heartbeat sessie van NL Design System
Ter voorbereiding is initieel gestart met deskresearch door de ontwerper. Er zijn ontwerpcriteria verzameld en er is specifiek gekeken naar de impact van de Wmebv op deze ontwerpcriteria. Deze ontwerpcriteria zijn in hoofdstuk 5 besproken.
Vervolgens is er onderzoek gedaan om te komen tot een prototype in Figma op basis van NL Design System. Er is besloten om het "Vraag aan uw gemeente" e-formulier inclusief de user journey wat hoort bij dit e-formulier van Gemeente Den Haag te nemen als uitgangspunt voor het generieke e-formulier, omdat dit formulier eveneens genoemd wordt in de bijlage (pagina 72 in de footnote) over Generieke e-formulieren van het rapport over de Implementatiepilot Wet modernisering elektronisch bestuurlijk verkeer (Wmebv).
Voor het ontwerp is gebruik gemaakt van de NL Design System 'Voorbeeld'-bibliotheek met het paars-witte 'Voorbeeld'-thema voor Figma. Met behulp van deze bibliotheek kon er in relatief korte tijd een schermflow gebouwd worden. Het scheelt enorm veel tijd als er gebruik gemaakt wordt van de Voorbeeld-bibliotheek omdat het opzetten van een bibliotheek al is gedaan. Stel dat er voor een ander thema van de Voorbeeld-thema gekozen zou worden dan hoeven enkel de design tokens voorzien te worden van het eigen thema. Voor meer informatie over hoe dit in zijn werk gaat binnen Figma wordt verwezen naar de pagina voor designers met NL Design System.
Om de use case van dit generieke formulier te ondersteunen en te kunnen testen is nagedacht over een scenario waarin dit formulier gebruikt zou kunnen worden. Om het scenario aan te laten sluiten bij op de Wmebv, is in overleg met een jurist gekomen tot een situatie waarbij de fictieve burger (een persona) Jeroen van Drouwen de gemeente waarin hij woonachtig is (Gemeente Voorbeeld) in gebreken stelt. Het in gebreken stellen heeft een juridisch gevolg, dus valt deze 'vraag aan de gemeente'in de categorie 'Formele berichten' en is de Wmebv dus van toepassing.
Om te komen tot een prototype schermflow, is een user journey uitgewerkt en uitgebreid besproken in de NL Design System community.De bijbehorende Figma schermen can deze user journey worden in de volgende paragraaf getoond en zijn eveneens beschikbaar in de VNG Wmebv Figma omgeving, waar een gratis Figma account voor aangemaakt moet te worden.
Afbeelding: Schematische weergave van de user journey.
A.
Jeroen van Drouwen heeft een 8 weken geleden een Bijstandsuitkering aangevraagd en nog geen reactie gehad van de Gemeente.Jeroen vindt dit niet leuk en denkt dat de gemeente inmiddels al te laat is met reageren en besluit een vraag aan de gemeente hierover te willen stellen.Jeroen komt via de Homepage van Gemeente Voorbeeld op de Contactpagina uit.
Hier kan hij kiezen wat hij wil doen. Jeroen besluit een Vraag te willen stellen en start het Contactformulier.
B.
Jeroen Komt op de intro-pagina van het ‘Vraag aan de gemeente’-formulier uit.Daar kan hij een aantal punten lezen. Hoelang het formulier ongeveer duurt, dat hij verplichte en optionele velden kan aantreffen, dat hij het tussentijds kan opslaan en later verder gaan en dat er een bevestiging-email gestuurd gaat worden. Tot slot kan hij lezen dat het ingevulde formulier gedownload en geprint kan worden.Jeroen klikt op Doorgaan
C.
Vervolgens moet Jeroen een keuze maken. Wil hij inloggen of niet. Beide paden worden ondersteund in het ontwerp en in de uiteindelijke ontwikkeling. Echter, zal er het DigiD-gedeelte worden overgeslagen omdat dit buiten de scope van dit project ligt.
D.
Indien Jeroen ervoor kiest om in te loggen, zal er een zeer eenvoudig scherm verschijnen met "Doe alsof u inlogt met DigiD" om zo tijdens de usability test zeer duidelijk te maken dat er niet werkelijk wordt ingelogd met DigiD.
E stap 1/4.
Nadat Jeroen al dan niet is ingelogd komt hij op de eerste pagina van het generieke e-formulier.
Jeroen typt:
Beste meneer of mevrouw, Ik heb meer dan 8 weken geleden een aanvraag voor bijstandsuitkering gedaan maar ik heb nog steeds niets gehoord. Volgens mij had u allang op mijn aanvraag moeten beslissen.\
Met vriendelijke groet,Jeroen van Drouwen
Jeroen upload niets en Jeroen klikt op ‘Volgende stap’
E stap 2/4.
Als Jeroen niet is ingelogd via DigiD, zijn al zijn gegevens nog niet vooringevuld. Als Jeroen wel is ingelogd zijn zijn gegevens wel voor ingevuld en hoeft hij ze enkel te controleren. Hij heeft geen optie om zijn gegevens te kunnen wijzigen behalve voor zijn telefoonnummer en e-mailadres. Jeroen vult zijn gegevens in, indien mogelijk met behulp van de Autocomplete functie van de computer.
_Jeroen van Drouwen
Laan der voorbeelden 99
1024 VP Voorbeeld
[email protected]
06006118346
Jeroen klikt op 'Volgende stap'
Note: Tijdens de Usability test vragen we de mensen hun eigen autocomplete te gebruiken en leggen we uit dat we in dit scenario doen alsof Jeroen zijn gegevens dan worden ingevuld. Ook benadrukken we dat hun gegevens niet worden opgeslagen.
E stap 3/4.
Controleer de ingevulde gegevens en verzend het formulier (E 4/4).
Na het verzenden zou je een e-mailnotificatie moeten ontvangen waarin wordt bevestigd dat de gemeente jouw vragen en opmerkingen heeft ontvangen. Bekijk de e-mail en vertel ons wat je ervan vindt.
E stap 4/4.
Op dit scherm staat groot 'Uw vraag is met succes verstuurd'. Het In het scenario waarin Jeroen niet inlogt, wordt er op dit scherm een opsomming gegeven waarin staat dat er een bevestigingsmail naar Jeroen zijn e-mailadres gestuurd is en dat afdeling 'Vraagbaak'met de vraag aan de slag gaat. In het scenario waarin Jeroen wel gaat inloggen staat er als extra punt bij dat hij de voortgang in de MijnOmgeving kan volgen.
Vervolg het scenario buiten de Gemeente Voorbeeld omgeving:
Deze laatste taken zijn tijdens de usability test met behulp van Gmail en Figma uitgevoerd. In het kader van de tijd was het niet mogelijk een MijnOmgeving in code klaar te zetten, daarom is er gebruik gemaakt van een Figma scherm, die niet met een screen reader of anderszins op accessibility getest kan worden. Tijdens de Usability tests zijn deze schermen voorgelegd en toegelicht door de onderzoeker om op die manier nog waardevolle feedback te kunnen ontvangen.
Gmail.
In het korte scenario, waarin Jeroen niet via DigiD inlogt opent hij Gmail en ziet daar de ontvangstbevestiging staan met een digitaal toegankelijke, met Markdown gegenereerde pdf met zijn ingevulde vraag en contactgegevens. Indien er via de ingelogde route is gegaan, dan luidt het scenario dat er binnen 48 uur een reactie is binnen gekomen via Gmail. Jeroen van Drouwen open zijn email en ziet een mailtje van gemeente Voorbeeld staan waarin aangegeven wordt dat hij via zijn MijnOmgeving de reactie van de gemeente kan inzien.
MijnOmgeving.
In de MijnOmgeving beland Jeroen op het overzicht-scherm kan hij kan via 'Mijn zaken', de reactie van de gemeente op zijn vraag vinden.
Stichting Accessibility heeft met 8 participanten de usability test uitgevoerd op 16 en 17 november 2023. De test vond plaats op locatie bij Stichting Accessibility in Utrecht Overvecht. Er was mogelijkheid om zowel op locatie als online mee te kijken middels een MS Teams meeting. Tevens was er mogelijkheid om via de chat vragen te kunnen stellen. Het onderzoeksteam bestond uit twee mensen, een facilitator en een observator.
De samenstelling van de participanten was als volgt:
- 6 laaggeletterden
- 1 fysiek beperkt
- 1 visueel beperkt
Het onderzoek bestond uit de volgende onderdelen:
- pre-interview
- specifieke taakopdrachten en vragen gebruikmakend van de live omgeving waar de e-formulieren beschikbaar waren, Gmail en een Figma prototype voor de mijnOmgeving
- post-interview
Het is noemenswaardig dat alle participanten beide scenario's van begin tot het einde hebben kunnen doorlopen, waarbij het formulier-gedeelte voldoende gebruikersvriendelijk en toegankelijk bleek. Uiteraard is er ruimte voor verbetering, hieraan zal in de volgende paragraaf aandacht besteed worden. Per scherm zullen de belangrijkste bevindingen, adviezen en suggesties voor vervolgonderzoek genoemd worden.
Tot slot zal het onderzoeksrapport van Stichting Accessibility beschikbaar gesteld worden op de website van gebruikersonderzoeken.nl
De volgende schermen kunnen ook in de VNG Wmebv Figma omgeving bekeken worden, hiervoor dient echter een gratis Figma account aangemaakt te worden. Bij elk scherm zijn de ontwerpadviezen aangegeven. Deze adviezen zijn voortgekomen uit het usability onderzoek dat heeft plaatsgevonden op 16 en 17 november 2023.
Scherm A - Contact: Een scherm met verschillende opties om contact te leggen met de gemeente.
Ontwerpadvies 1: Dit scherm is onderverdeeld in een aantal verschillende onderwerpen: 'Vraag', 'Klacht','Melding openbare ruimte en overlast' en een 'Idee of voorstel'. Door te proberen de vraag in een vroeg stadium van de berichtenstroom te categoriseren als formeel of niet-formeel bericht, kunnen deze processen in een vroeg stadium herkend en behandeld worden met in acht name van de Wmebv. Er zijn overigens gemeenten die adviseren het onderscheid niet maken en alles behandelen als formeel bericht om zo ten alle tijden te voldoen aan de Wmebv. Gemeente Barneveld licht dit bijvoorbeeld toe in de Kennissessie Juridische Aspecten van 9 oktober 2023.
Scherm B - Uitleg over het formulier: Een scherm met uitleg over wat de gebruiker te wachten staat, tijdens het invullen van het 'Vraag aan de gemeente' e-formulier.
Ontwerpadvies en suggesties voor vervolgonderzoek 2: Op dit scherm worden een aantal punten over wat de gebruiker kan verwachten toegelicht. In dit ontwerp staat dat het 'ongeveer 5 minuten zal duren' echter bleek uit het usability onderzoek dat deze hoeveelheid tijd niet voor iedereen geldt. Uit nader onderzoek moet blijken hoe de hoeveelheid werk, om het formulier in te vullen, inclusiever kan worden uitgedrukt.
Ontwerpadvies en suggesties voor vervolgonderzoek 3: Op dit scherm wordt aan gegeven 'Vul alle velden in. Als een veld niet verplicht is, staat dit erbij.'. In dit ontwerp is gekozen voor de benadering van het GOV.UK Design System, waar bij optionele velden gemarkeerd worden hanteert waarbij gesteld wordt dat verplichte velden niet met een * gemarkeerd moeten worden maar juist optionele velden gemarkeerd worden met 'Optional' wat wij in B1 vertaald hebben naar 'Niet verplicht'. Echter bleek uit de usability studie dat mensen dit niet duidelijk vonden en dat de 'Niet verplicht'gemarkeerde velden sneller overgeslagen werden, terwijl ze wel degelijk van belang kunnen zijn. Denk bijvoorbeeld aan een huistoevoeging. Iot nader onderzoek moet blijken of het markeren van verplichte velden niet toch een betere manier is. Het merendeel van de respondenten gaf aan het verwarrend te vinden.
Scherm C - Inloggen: Keuzescherm om in te loggen
Ontwerpadvies en suggesties voor vervolgonderzoek 4 Uit het usability onderzoek bleek dat sommige mensen het formulier hadden verwacht in plaats van een scherm met de mogelijkheid om in te loggen. Uit nader onderzoek moet blijken of dit inlogscherm op een andere plek in de user journey moet zitten of misschien op een andere visuele manier gepresenteerd moet worden. In dit ontwerp was gekozen voor radio buttons met ja en nee, maar misschien zijn mensen meer gebaat bij een andere weergave waarbij de voordelen van inloggen nog duidelijker benoemd staan. De voordelen staan in dit ontwerp maar merendeel van de participanten las de tekst niet omdat ze veel bezig waren met een keuze te maken om wel of niet in te loggen met 'het moeilijke 'of het 'enge' DigiD.
Scherm E Formulier stap 1 (E 1/4): Vraag aan de gemeente invoeren
Ontwerpadvies en suggesties voor vervolgonderzoek 5: Uit het usability onderzoek kwam naar voren dat mensen veel hun mobiele apparaten gebruiken waarbij zij baat hebben van de suggestiewoorden die bij een mobieltoetsenbord getoond worden. Dit maakt het, vooral voor de laaggeletterde doelgroep, makkelijker om hun vraag goed te kunnen invoeren. Uit nader onderzoek moet blijken of er een invulhulp bedacht en aangeboden kan worden. Een vertaaloptie zou ook een meerwaarde kunnen bieden voor mensen die de Nederlandse taal niet voldoende beheersen. Een ander idee zou kunnen zijn om mensen bij de scherm B te informeren dat zij dit formulier ook op een mobiel apparaat kunnen invullen en wat de voordelen daarvan zijn. Een nadeel daarvan zou zijn, dat zij niet bij documenten kunnen doe wellicht op hun computer staan.
Formulier stap 2 (E 2/4): Contactgegevens invoeren
Ontwerpadvies 6: ...
Formulier stap 3 (E 3/4): Controleer gegevens en verzend
Ontwerpadvies 7: ...
Formulier stap 4 (E 3/4): Uw vraag is met succes verstuurd
Ontwerpadvies 8: ...
Figma schermen van de Gmail omgeving voor scenario E_kort:
Gmail inbox (niet ingelogd scenario): Ontvangstbevestiging in de Inbox
Ontwerpadvies 9: ...
Gmail berichtdetail (niet ingelogd scenario): Ontvangstbevestiging inhoud emailtje
Ontwerpadvies 10: ...
Gmail PDF (niet ingelogd scenario): Pdf met ingevulde gegevens
Ontwerpadvies 11: ...
Figma schermen met een nagebooste Gmail omgeving voor scenario E_lang:
Gmail inbox (wel ingelogd scenario) Ontvangstbevestiging in de inbox
Ontwerpadvies 12: ...
Gmail berichtdetail (wel ingelogd scenario) Een email met een een notificatie dat er een reactie van de gemeente in de MijnOmgeving staat.
Ontwerpadvies 13: ...
MijnOmgeving overzichtscherm MijnOmgeving Overzicht-scherm waar een zaak klaarstaat.
Ontwerpadvies 14: ...
MijnOmgeving Mijn zaken Overzicht van alle zaken, in dit geval maar een.
Ontwerpadvies 15: ...
MijnOmgeving zaakdetail Scherm waarin de reactie van de gemeente te lezen is.
Ontwerpadvies 16: ...
Bekijk de uitgewerkte ontwerpen in detail in Figma. en bekijk de live demo van de geprogrammeerde schermen
Voor meer informatie over een mogelijke aanpak voor de implementatie van de Wmebv wordt verwezen naar dit Stappenplan wet Wmebv ter ondersteuning bij de implementatie van de Wmebv binnen uw organisatie, waarin de volgende onderwerpen behandeld worden:
Digitalisering van de dienstverlening:
- Wat vraagt de Wmebv?
- Hoe kan ik het aanpakken?
- Slim digitaliseren met de omnichannelaanpak.
- Analyse huidige digitale kanalen met behulp van de Uniforme Productnamen Lijst
- Besluit en communiceer de gekozen kanalen.
- Bepaal uw beleid t.a.v. een (Omnichannel) kanaalstrategie.
- Aan de gang met implementeren.
Kijk voor meer informatie over de Omnichannel strategie naar de video-opname van 10 oktober 2023, Kennissessie 2: Omnichannel
Zorgplicht bij de dienstverlening:
- Bepaal welke belemmeringen inwoners ervaren
- Bepaal hoe u belemmeringen kunt wegnemen.
- Leg uw keuzes voor zorgplicht vast in een beleidsdocument.
- Communiceer hoe uw gemeente ondersteunt bij de dienstverlening.
(Gesorteerd op chronologische volgorde in het document.)
-
Handreiking implementatie Wet modernisering elektronisch bestuurlijk verkeer (Awb) 2023.
-
Pagina voor richtlijnen voor formulieren van NL Design System
-
Onderzoek naar gebruikersvriendelijkheid van generieke services
-
Implementatiepilot Wet modernisering elektronisch bestuurlijk verkeer (Wmebv)
- Openformulieren noemen | VNG Wmebv website | Forum Wmebv | Kennissessie e-formulieren en notificaties |
- ...