Een proefaccount start maar bereikt de eerste stap niet

Begin niet bij het scherm maar bij de taak. Wat moet een gebruiker doen om te zien dat je proefaccount waarde heeft? Dat kan het importeren van een eerste lijst zijn, het aanmaken van een eerste item of het uitvoeren van een eerste actie. Formuleer die primaire taak in één zin.

Een geopend account, een ingelogde sessie of een bezochte startpagina zijn tussenstappen, geen succes. Ze tonen dat de toegang werkt, niet dat de gebruiker is gekomen waarvoor hij kwam. Leg daarom vooraf vast welke gebeurtenis je als succes aanmerkt en welke je alleen als stap registreert. Zo voorkom je dat je meetcijfer aangeeft dat het goed gaat terwijl niemand de taak afrondt.

Beperk je tot wat je zelf kunt waarnemen. Een test met één testgebruiker toont of een traject technisch en begrijpelijk werkt, niet hoe vaak echte gebruikers vastlopen.

Gebruik geen bestaand beheerdersaccount. Dat heeft rechten, instellingen en gegevens die een nieuwe gebruiker niet heeft, en verbergt dus precies de breukpunten die je zoekt. Maak een nieuw e-mailadres aan dat je beheert en gebruik dat voor de test. Doe dit bij voorkeur in een testomgeving. Test je in de echte omgeving, gebruik dan een duidelijk herkenbaar testadres en spreek vooraf af hoe je het testaccount achteraf verwijdert of blokkeert, en of er meldingen of facturen aan gekoppeld zijn.

• Gebruik een schone browser of een privévenster, zonder opgeslagen sessies of ingevulde gegevens.
• Zet bij voorkeur geen extensies aan die formulieren of cookies beïnvloeden.
• Leg het begin van de test vast: tijdstip, toestel en browser.
• Test indien mogelijk op zowel een computer als een mobiel toestel, want formulieren gedragen zich daar anders.

Laat de test liefst uitvoeren door iemand die het product niet kent, of voer hem zelf uit en doe alsof je niets weet. Noteer alles wat je moet raden. Wat jij als vanzelfsprekend ervaart, is dat voor een nieuwe gebruiker vaak niet.

1. Uitnodiging of aanmelding versturen. Meld de testgebruiker aan via de normale route. Noteer wanneer je het formulier verzendt en wat je daarna ziet: een bevestigingsscherm, een foutmelding of niets. Verstuur het formulier niet opnieuw zolang je niet hebt gecontroleerd of het account al is aangemaakt (bijvoorbeeld via de beheerlijst of een ontvangen mail). Een foutmelding of time-out kan namelijk ook optreden nadat de gegevens al zijn opgeslagen.
2. E-mail ontvangen. Controleer of de uitnodigingsmail aankomt, in welke map, hoe snel en met welk afzenderadres. Controleer ook of de link in de mail correct werkt en niet verlopen is.
3. Account activeren of wachtwoord instellen. Doorloop de stap als nieuwe gebruiker. Let op eisen aan het wachtwoord, een zichtbare uitleg ervan en het gedrag bij een foutieve invoer.
4. Eerste login. Meld je af en daarna opnieuw aan met de nieuwe gegevens. Dit toont of de login ook zonder het activatiepad werkt.
5. Eerste scherm na login. Is meteen duidelijk wat de volgende stap is, of staat de gebruiker voor een leeg scherm zonder richting?
6. Primaire taak uitvoeren. Probeer de taak te voltooien zonder hulp en noteer elke aarzeling, foutmelding en elke keer dat je externe uitleg nodig hebt.

Registreer bij elke stap wat je verwachtte en wat je zag. Een stap telt pas als geslaagd wanneer de gebruiker zonder extra hulp verder kan.

Bij formulieren komt veel neer op validatie en toegankelijkheid. MDN legt uit (https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation) dat client-side validatie een eerste controle is die de gebruiker meteen laat corrigeren, maar dat de server de gegevens altijd zelf moet controleren. Een formulier dat in de browser geslaagd lijkt, kan dus alsnog door de server geweigerd worden.

Dit is een fictief voorbeeld dat alleen de werkwijze toont. Het beschrijft geen echt product en voorspelt geen resultaat.

Invoer: je maakt een nieuw e-mailadres aan, meldt je aan, ontvangt de mail, activeert het account en probeert de eerste taak: een eerste item aanmaken.

• Stap 1, aanmelding: het formulier toont een bevestiging. Genoteerd als geslaagd.
• Stap 2, e-mail: de mail komt aan. Genoteerd als geslaagd, met vermelding van de map.
• Stap 3, activatie: de link opent, maar de gebruiker ziet geen uitleg bij het wachtwoordveld. Genoteerd als aandachtspunt.
• Stap 4, login: lukt.
• Stap 5, eerste scherm: leeg zonder richting. Genoteerd als breukpunt.
• Stap 6, taak: niet bereikt zonder hulp. Genoteerd als niet geslaagd.

Verwachte technische controles na een aanpassing: het wachtwoordveld toont de eisen vooraf, het eerste scherm wijst op de eerste taak, en een nieuwe testgebruiker bereikt de primaire taak zonder hulp. Of echte gebruikers daardoor vaker doorstromen, zegt deze test niet. Meet dat apart.

Pas na de diagnose kies je maatregelen. Houd je aan wat je kunt aantonen. Het W3C beschrijft in zijn formuliertutorial (https://www.w3.org/WAI/tutorials/forms/) dat het labelen van velden, het groeperen van velden, duidelijke instructies, validatie met bruikbare foutmeldingen en een goede opbouw formulieren makkelijker te gebruiken maken, ook voor mensen met een beperking. Gebruik dat als checklist voor je eigen formulieren. Zo'n controle bewijst geen volledige WCAG-conformiteit.

• Geef elk veld een zichtbaar label en koppel het technisch aan het veld.
• Toon wachtwoordeisen vooraf, niet pas na een fout.
• Zet foutmeldingen bij het veld waar het misgaat, in leesbare taal.
• Toon na login altijd een duidelijke eerste stap.
• Vermijd tijdslimieten waar mogelijk. Is een limiet nodig, bijvoorbeeld om beveiligingsredenen, laat de gebruiker die dan uitschakelen of verlengen.

Meet vervolgens het succes zoals je het vooraf definieerde: het afronden van de primaire taak, niet het aantal accounts of logins. Vergelijk dezelfde stappen voor en na je aanpassing met een nieuwe testgebruiker. Wil je ook zien welke publieke signalen je website toont, bekijk ze dan via Marketing Scan. Een publieke scan ziet wat zichtbaar is en kan niet bewijzen dat je interne traject werkt.