De essentiële UX-checklist: bekijk je website door de ogen van je klanten

Je website is net opnieuw ontworpen. Op de grote monitor in de vergaderruimte ziet die er geweldig uit; iedereen kent het aanbod en kan geblinddoekt een bestelling plaatsen. Maar een klant komt binnen via een telefoon, weet niets van het bedrijf en vertrekt bij de eerste verwarring. Daarom is controleren of een website er mooi uitziet niet genoeg.

We gebruikten de oorspronkelijke versie van deze checklist als brede lijst voor websites en webshops. In de loop der tijd kwamen er tools en afzonderlijke regels bij die niet universeel waren. Deze versie keert terug naar de essentie: wat iemand moet kunnen doen, wat je moet controleren en hoe je een probleem herkent voordat je geld in verkeer gaat investeren.

Identificeer eerst de drie belangrijkste klantreizen

Een UX-audit van een volledige website kan gemakkelijk uitmonden in honderd opmerkingen. Voordat ik analytics open, kies ik daarom de drie klantreizen die voor het bedrijf het belangrijkst zijn. Meestal zijn dat:

• een nieuwe bezoeker begrijpt het aanbod en stuurt een aanvraag,
• een klant vindt een product, voegt het toe aan de winkelwagen en betaalt,
• een bestaande klant vindt ondersteuning, een document of contactgegevens.

Noteer voor elke klantreis het startpunt, het verwachte einde en het belangrijkste obstakel. Dan doorloop je de checklist niet mechanisch. Je controleert of de website een specifieke beslissing ondersteunt.

1. Het aanbod moet duidelijk zijn voor iemand die niet bij de vergadering was

• Is op het eerste scherm duidelijk wat je aanbiedt en voor wie?
• Beschrijft de hoofdkop een resultaat of probleem in plaats van een bedrijfsslogan?
• Is de volgende stap zichtbaar zonder dat je in het menu hoeft te zoeken?
• Kunnen bezoekers afzonderlijke diensten of opties onderscheiden?
• Noem je de voorwaarden en beperkingen die de beslissing echt beïnvloeden?

Test dit met iemand die het bedrijf niet kent. Geef die persoon een paar seconden, sluit de pagina en vraag wat het bedrijf doet en wat die vervolgens zou doen. Dit is geen wetenschappelijk onderzoek, maar het legt snel taal bloot die alleen mensen binnen het bedrijf begrijpen.

2. Navigatie moet werken zonder nadenken en zonder muis

• Komen de namen van menu-items overeen met waar bezoekers naar zoeken?
• Werken links, het logo en de terugkeer naar de vorige stap?
• Is het mobiele menu leesbaar en kan het worden gesloten, en wordt er geen belangrijke inhoud bedekt?
• Is bij een langere structuur duidelijk waar iemand zich bevindt?
• Is elke belangrijke bediening bereikbaar met de Tab-toets?
• Is de focus zichtbaar bij gebruik van een toetsenbord en kan de focus normaal worden verplaatst zonder dat de gebruiker vast komt te zitten?

Toegankelijkheid is geen speciale modus voor een paar mensen. Voldoende contrast helpt ook op een telefoon in de zon en een duidelijk formulier helpt iemand die haast heeft. Voor een snelle controle kun je Easy Checks van W3C gebruiken. Dit is een eerste controle, geen bevestiging van volledige WCAG-naleving.

3. Content moet zowel het oog als de beslissing sturen

• Is er één hoofdkop en een logische structuur van verdere koppen?
• Zijn alinea’s leesbaar en is belangrijke informatie tijdens het scannen gemakkelijk te vinden?
• Beschrijven links en knoppen het resultaat van een klik?
• Hangt de betekenis alleen af van kleur, een afbeelding of een hover-effect?
• Hebben informatieve afbeeldingen betekenisvolle alternatieve tekst?
• Leiden animaties af van het aanbod en worden de voorkeuren van gebruikers voor minder beweging gerespecteerd?

Een sterke kleur alleen creëert geen conversieknop. Eerst moet duidelijk zijn wat er na de klik gebeurt. ‘Verzenden’ is een technische beschrijving. ‘Plan een kennismakingsgesprek’ vermindert onzekerheid.

4. Een formulier moet alleen vragen wat het bedrijf daadwerkelijk gebruikt

• Heeft elk veld een zichtbaar, programmatisch gekoppeld label?
• Is duidelijk welke gegevens verplicht zijn en waarom ze nodig zijn?
• Kan de gebruiker het formulier op een telefoon en met een toetsenbord invullen?
• Legt een foutmelding zowel het probleem als de oplossing uit?
• Blijven correct ingevoerde gegevens na een fout behouden?
• Ontvangt de gebruiker na verzending een duidelijke bevestiging en informatie over wat er daarna gebeurt?

In zijn handleiding voor toegankelijke formulieren adviseert W3C alleen te vragen naar gegevens die nodig zijn om het proces af te ronden. Elk extra veld kost aandacht en vergroot het werk rond gegevensverwerking. Als het bedrijf de informatie niet gebruikt, verwijder die dan.

5. Een webshop moet de volledige aankoop afhandelen, niet alleen een mooie productpagina

Categorieën en zoeken

• Komen filters overeen met hoe mensen kiezen en kunnen ze eenvoudig worden gewist?
• Is een toestand zonder resultaten nuttig en biedt die een alternatief pad?
• Bevat een productkaart een naam, prijs, beschikbaarheid en een goed leesbare afbeelding?
• Blijven sorteren en filteren bruikbaar op een telefoon?

Productdetail

• Worden opties, prijs, btw, beschikbaarheid en levering uitgelegd voordat je het product aan de winkelwagen toevoegt?
• Laten foto’s zien wat de klant moet kunnen beoordelen?
• Is de knop om iets aan de winkelwagen toe te voegen zichtbaar zonder de content te blokkeren?
• Biedt een uitverkocht of niet langer leverbaar product een alternatief en een logische weg terug?

Winkelwagen en bestelling

• Kunnen artikel, optie en aantal worden gewijzigd zonder andere gegevens te verliezen?
• Is de eindprijs, inclusief levering en kosten, op tijd bekend?
• Vermijd je registratie verplicht te stellen zonder zakelijke reden?
• Brengt een mislukte betaling de persoon terug naar een duidelijke situatie?
• Is de orderbevestiging ondubbelzinnig en voorkomt die een onbedoelde herhaalaankoop?

De regel ‘er mag geen navigatie in de winkelwagen staan’ is niet altijd geldig. Bij een eenvoudige aankoop kan het verminderen van afleiding helpen. Bij een complex aanbod moet de klant echter voorwaarden of productdetails kunnen vinden. Test gedrag, niet een vuistregel.

6. Een website moet mobiel, een trage verbinding en een fout aankunnen

• Laadt de hoofdcontent snel, zonder grote verschuivingen in de lay-out?
• Reageert de pagina zonder merkbare vertraging op klikken en typen?
• Hebben afbeeldingen de juiste afmetingen en laden ze alleen in de benodigde kwaliteit?
• Kan een defect extern script een bestelling of formulier blokkeren?
• Werken belangrijke klantreizen in actuele gangbare browsers en op echte telefoons?
• Monitor je beschikbaarheid en fouten in belangrijke stappen?

Een labscore is een richtlijn, geen bedrijfsresultaat. Bekijk ook echte gebruikers en de belangrijkste klantreis. Een advertentiepixel mag niet belangrijker zijn dan de knop ‘Kopen’.

7. Controleer metingen met een test, niet door te kijken of de code bestaat

Maak voor elke belangrijke klantreis een testaanvraag of -bestelling. Controleer of de gebeurtenis één keer wordt verzonden, met de juiste naam, waarde, valuta en transactie-ID. Controleer vervolgens of het doelsysteem die ziet en of die overeenkomt met de echte bestelling.

• Wordt een aankoop alleen verzonden door een bedank-URL te openen?
• Wordt de gebeurtenis gedupliceerd wanneer de pagina wordt vernieuwd?
• Respecteren tags de toestemmingsstatus?
• Bevat de datalaag persoonsgegevens die daar niet thuishoren?
• Bevat de container alleen diensten die het bedrijf gebruikt?
• Is er een eigenaar voor metingen en een registratie van de laatste controle?

Zie voor de implementatie Google Tag Manager correct instellen; voor de betekenis van gebeurtenissen de Google Analytics 4-handleiding. Sessieopnamen of heatmaps kunnen blinde vlekken onthullen, maar gebruik ze doelgericht, met afgeschermde gevoelige velden en volgens de toestemmingsregels. Alles ‘voor het geval dat’ opnemen is geen onderzoeksplan.

De checklist gebruiken zonder een maandelijkse workshop

1. Kies de belangrijkste klantreis en doorloop die op een telefoon.
2. Doe hetzelfde met alleen een toetsenbord.
3. Laat iemand van buiten het bedrijf de taak uitvoeren en stuur die persoon niet.
4. Leg vast waar die persoon aarzelde, niet wat jouw voorgestelde oplossing is.
5. Verifieer het probleem in analytics, bij support of met verdere tests.
6. Los één obstakel op en doorloop daarna de volledige klantreis opnieuw, inclusief de metingen.

Probeer niet om een website in één ronde ‘UX-voltooid’ te verklaren. Het aanbod, apparaten en verwachtingen van mensen veranderen. Het doel van de checklist is regelmatig de duurste frictie te vinden en te beslissen wat je eerst oplost.

Als je de website in een bredere zakelijke context wilt beoordelen, gebruik dan ook de online-marketingchecklist. Als je UX, metingen en acquisitie wilt prioriteren, beschrijf dan je belangrijkste klantreis via de contactpagina.