Op dinsdag 25 mei was de 3e werksessie over formulieren. Tijdens deze laatste en afrondende sessie in de reeks hebben we nog 1 keer met de aanwezigen de formulierenreis doorgelopen. We hebben voornamelijk stilgestaan bij de voorbereiding van een formulier en de validatie en foutpreventie.
Dit was wederom een interactieve sessie waarbij we gebruik maakten van Miro.
Hieronder volgt in detail een terugkoppeling van de punten die opgehaald en besproken zijn. Deze punten pakken we als kernteam op en worden verwerkt in de algemene documentatie en richtlijnen. Heb je vragen of behoefte aan meer uitleg? Mail Rogier via rogier.barendregt@ictu.nl.
Oproep
Waar we tegenaanlopen voor de vulling van het NL Design System is dat we nog te weinig (goede, maar ook juist slechte formulieren) praktijkvoorbeelden en case-studies hebben. Omdat de richtlijnen voor een breed scala aan formulieren inzetbaar moet zijn, willen we deze gebruiken om de richtlijnen te voorzien van praktijkillustraties. Daarom doen we graag nogmaals de oproep om deze vooral door te sturen.
Waar we tegenaanlopen voor de vulling van het NL Design System is dat we nog te weinig (goede, maar ook juist slechte formulieren) praktijkvoorbeelden en case-studies hebben. Omdat de richtlijnen voor een breed scala aan formulieren inzetbaar moet zijn, willen we deze gebruiken om de richtlijnen te voorzien van praktijkillustraties. Daarom doen we graag nogmaals de oproep om deze vooral door te sturen.
Onderwerp 1: Voorbereiden van een formulier
De stappen binnen dit onderdeel:
- Inventariseer en formuleer vragen die je aan de gebruiker wilt stellen.
- Ga na of informatie al beschikbaar is (binnen de organisatie).
- Stel alleen de strikt noodzakelijke vragen.
- Maak direct duidelijk wat de functie van het formulier is.
- Maak zo snel mogelijk duidelijk of het formulier van toepassing is op de specifieke gebruiker.
- Informeer wat de gebruiker nodig heeft om het formulier in te vullen.
- Geef uitleg bij een eventuele tijdslimiet voor het invullen van het formulier.
Aandachtspunten
Wat is het onderwerp? Pas daar de hulpfunctie of pagina’s op aan.
Gebruik de juiste succescriteria als leidraad.
Maak een functioneel ontwerp en leg dit vast.
Wat wil je vragen? Wat zijn conditionele vragen? Kan ik het formulier zo bouwen? Denk daarbij aan:
- Inventariseer of bepaalde informatie de vragen in het formulier wijzigt en bepaal waar deze conditionele vragen dan passen.
- Hoe bepaal je welke vragen ‘strikt noodzakelijk’ zijn? Kunnen we dat naar een checklist vertalen?
- Is de informatie ook binnen de keten beschikbaar? Basisregistratie Personen (BRP) Vragen en antwoorden in volgordelijkheid van uitvraag privacy-gevoeligheid.
- Bereid de volgorde van een formulier voor en maak de afweging: wat wil je als eerste doen? Is een gedeelte van de voorbereiding volgordelijk?
1. Inventariseer je doel, de gebruiker en vragen.
2. Kijk of je voor die gebruiker sommige antwoorden al uit de keten kan halen.
3. Bepaal of de overgebleven vragen echt nodig zijn om het doel van je formulier te halen.
4. Mag je deze vragen wel stellen? Is het juridisch verantwoord om deze informatie wel opvragen? - Houd bij een functioneel ontwerp ook rekening met wat mag je uitvragen? (de juridische kant)
Doelgroep: hoe weet de gebruiker dat het formulier voor hen relevant is?
- Zorg dat je weet wie je doelgroep is.
- Taalgebruik en niveau (headers, labels).
- Zet ook op de website duidelijk informatie over wat er in het formulier verwacht wordt. En onderzoek welke koppelvlakken nodig zijn om benodigde ‘prefill’ te kunnen doen.
- Gedelegeerd invullen formulier (namens iemand anders): een standaard te onderkennen stap?
Bij punt 5: niet alleen benoemen vooraf, maar ook conditionele vragen inbouwen of dan aangeven, dat dit formulier niet voor hen is / blokkade + melding.
Toegankelijkheid:
- Hoe maak je het formulier duidelijk voor de gebruiker?
- Inventariseer het gebruik van screen readers, inzoomen (tot 200%) en toetsenborden.
- Stepper / progressie.
- Welke feedback geeft een invoerveld bij active, hover, filled en foutmelding?
- Groepeer vragen, zet onderwerpen bij elkaar, 1 onderwerp per pagina.
- Beschikbare information (auto complete) -> 1 groep.
Techniek:
- Is het proces al aanwezig om het formulier te kunnen verwerken?
- Waar moet de aanvraag naar toe?
- Welk achterliggende systeem wordt gebruikt?
- Zijn er soortgelijke formulieren gebruikt? Zo ja, dan kun je dit formulier gebruiken of verbeteren.
- Samenwerking designers en developers: ‘Figma low fid prototypes’ (overdraagbaarheid).
Goede en slechte voorbeelden uit de praktijk:
- Utrecht Inkomensloket: Zo min mogelijk uitvragen.
Onderwerp 4: Validatie en foutpreventie
De stappen binnen dit onderdeel:
- Voorkom invoerfouten.
- Accepteer antwoorden in verschillende vormen. Bijvoorbeeld: postcode met en zonder spatie tussen getallen en letters.
- Kies het moment van valideren van ingevoerde gegevens (in zowel simpele als complexe formulieren).
- Toon validatie feedback.
Aandachtspunten
Tips voor schrijvers van content:
- De foutmelding moet gemakkelijk op te merken en te begrijpen zijn.
- Gebruik help-tekst, invoervoorbeeld, placeholders en duidelijke labels.
- Schrijf niet alleen “Dit is verplicht”, maar geef een specifieke foutmelding: “De voornaam is verplicht”.
Extra vriendelijke formulieren:
- Gebruik masks tijdens invoeren (keyup). Bijvoorbeeld: bij 000 000 000 de spaties toevoegen tijdens de invoer.
- Laat meerdere formaten toe. Bijvoorbeeld: voor postcode 0000AA en 0000 AA, dus met en zonder spatie.
- Verwijder automatisch niet gewenste karakters in bijvoorbeeld telefoonnummers of postcodes.
Tips voor niet-technische ontwerpers van formulieren:
- Conditional logic.
- Verberg niet nodige velden totdat ze nodig zijn.
- Business logic in forms is een no-go.
Interactieve foutmeldingen:
- Wat je direct aan feedback kunt geven, geef dat ook. Bijvoorbeeld: een leeg wachtwoord-veld versus een verkeerd ingevuld wachtwoord.
- Valideer geen velden voordat de invoer is voltooid.
- Zorg dat de foutieve velden goed zichtbaar zijn.
- Valideer bij korte formulieren na het verlaten van het focusveld. Valideer bij lange formulieren als je naar volgende stap gaat.
- Gebruik validatie-samenvattingen (bovenaan) niet als de enige indicatie van een fout.
- Streef waar mogelijk naar inline validatie.
Tips voor designers:
- Gebruik kleur om fouten te onderscheiden van normale states.
- Geef niet verplichte velden duidelijk met tekst aan.
- Maak voor lange selectboxen gebruik van de datalist ‘combobox’.
- Voorkom de mogelijkheid van fouten.
- Structureer tekstvelden zodat ze overeenkomen met de invoer.
- Bied alleen invoer aan die acceptabel is.
Tips voor developers:
- Test ook zonder JavaScript.
- Valideer ook op de back-end.
- Autocomplete / autofill.
- Autocomplete attributen, voorbeelden voor Nederlandse NAW-formulieren.
- Aria-describedby voor foutmeldingen.
- Rj: voor accessibility uitleg voor de invoer in domtree met aria-labelledby en aria-requiredby.
- Rj: validatie na submit en na blur nadat submit geweest is ( dirty ) bv: name.invalid && (name.dirty || name.touched).
- Aria-invalid voor velden met foutmelding.
- Required attribute voor verplichte velden.
- Gebruik niet RegExp validatie wanneer een atlernatief beschikbaar is, zoals maxlength, zodat er betere foutmeldingen worden getoond.
- Submit button niet disabled maken, maar toon eventueel foutmelding bij klik.
• Client-side versus back-end validatie.
• Valideren vanuit de back-end?
• Vanuit een back-end systeem een formulieren genereren ipv met een formbuilder handmatig een form maken.
Deze punten pakken we als kernteam op en worden verwerkt in de algemene documentatie en richtlijnen. Heb je vragen of behoefte aan meer uitleg? Mail Rogier via rogier.barendregt@ictu.nl.
