Ga direct naar de inhoud

UX checklist herzien: Structuur, diepgang en impact

workflow · Leestijd 8 minuten leestijd - 18 augustus 2026

Ik ben gek op checklists en to-do lijsten. Ze geven structuur, zorgen dat ik niets vergeet, en helpen me om gefocust te blijven. Eens in de zoveel tijd is het ook goed om je checklist-templates te herzien. Wat kan beter? Wat mist er? En hoe sluit het aan bij de laatste ontwikkelingen in het vakgebied? En wat kan ik toepassen op basis van mijn laatste twee NN/g workshops! Omdat ik kortgeleden ben begonnen aan een nieuwe opdracht, werd het tijd om mijn checklist voor nieuwe UX-projecten onder de loep te nemen.

Wat ik heb toegevoegd

1. Uitbreiding: Stakeholderslijst bij kick-offs

Een goede kick-off is het fundament van elk project. Maar wie zijn eigenlijk alle betrokkenen? Vaak vergeten we partijen die indirect invloed hebben op het project, zoals juridische afdelingen, marketing, of externe partners.

Tip van Tai:

Maak een uitgebreide stakeholderslijst en categoriseer ze op basis van hun rol en invloed:

  • Primair: Direct betrokken (bijv. product owner, ontwikkelteam).
  • Secundair: Indirect betrokken (bijv. klantenservice, sales).
  • Extern: Partijen buiten de organisatie (bijv. leveranciers, regelgevende instanties).

Waarom? Zo zorg je dat je vanaf dag 1 alle belangen in kaart hebt en voorkom je verrassingen later in het proces.

2. RACI-Matrix

Een RACI-matrix (Responsible, Accountable, Consulted, Informed) brengt helderheid in wie wat doet en wie verantwoordelijk is. Dit is vooral handig in complexe projecten met veel betrokkenen.

  • Responsible (R): Wie voert de taak uit?
  • Accountable (A): Wie is eindverantwoordelijk?
  • Consulted (C): Wie moet je raadplegen?
  • Informed (I): Wie moet je op de hoogte houden?

3. ODESC (Open, Describe, Express, Specify, Consequence)

ODESC is een krachtige methode om open vragen te structureren en dieper in te gaan op gebruikersbehoeften. Het helpt om vaagheid te vermijden en concrete, actiegerichte inzichten te verkrijgen.

Waarom en hoe?

ODESC zorgt voor diepgaandere gesprekken en helpt om verborgen pijnpunten bloot te leggen.

  • Open: Begin met een open vraag. (Hoe ervaar je momenteel het proces van X?).
  • Describe: Vraag om een beschrijving. (Kun je dat proces stap voor stap uitleggen?).
  • Express: Laat de gebruiker emoties en meningen uiten. (Wat vind je frustrerend aan deze stap?).
  • Specify: Vraag om specifieke voorbeelden. (Kun je een situatie noemen waarin dit misging?).
  • Consequence: Onderzoek de impact. (Wat zijn de gevolgen als dit niet verbetert?).

4. Overdracht: Zorg dat kennis blijft hangen

Een project is pas echt afgerond als het team zelfstandig verder kan. Niets is frustrerender dan een prachtig ontwerp dat na overdracht in de la verdwijnt omdat niemand weet hoe ermee om te gaan.

  • Documentatie als basis: Zorg voor centrale, toegankelijke documentatie (bijv. in Confluence, Notion of een gedeelde map). Denk aan design decisions, user flows, wireframes en een stijlgids.
  • Kennisoverdrachtssessies: Organiseer workshops voor het team, waarbij je het ontwerpproces uitlegt en praktische oefeningen doet.
  • Evaluatie & feedback: Sluit af met een retrospective waarin je lessons learned deelt en openstaande vragen bespreekt.

Waarom?

Overdracht is geen eenmalige actie, maar een doorlopend proces. Door kennis te borgen, voorkom je dat projecten “verstommen” na afronding en zorg je voor continuïteit.

5. Succesmetrieken: Meet wat ertoe doet

UX-werk is pas waardevol als je kunt aantonen dat het impact heeft. Maar hoe meet je iets als “gebruikerservaring”? Door concreet en meetbaar te maken wat succes betekent voor jouw project.

Kwalitatieve metrieken:

  • Gebruikerstevredenheid (bijv. Net Promoter Score of System Usability Scale).
  • Kwalitatieve feedback uit gebruikerstests of support tickets.
  • Adoptie: Hoeveel gebruikers maken daadwerkelijk gebruik van de nieuwe functionaliteit?

Kwantitatieve metrieken:

  • Efficiëntie: Tijdsbesparing (bijv. “Gebruikers voltooien taak X 40% sneller”).
  • Foutenreductie: Aantal fouten of supportvragen (bijv. “Aantal klachten over navigatie daalt met 25%”).
  • Conversie: Als het project gericht is op een specifieke actie (bijv. “Aantal aanmeldingen voor de nieuwsbrief stijgt met 15%”).

Tip van Tai:

Koppel metrieken altijd aan de doelstellingen van het project. Als het doel was om “de gebruikerservaring te verbeteren”, meet dan niet alleen tevredenheid, maar ook gedragsverandering.

Wat al in mijn oude lijst zat (en nog steeds relevant is)

Mijn oude checklist bevatte al een aantal essentiële punten, zoals:

  • Antwoorden vinden op de productdefinitie en doelen. Waarom? Zonder duidelijke doelen loop je het risico om een product te bouwen dat niet aansluit bij de behoeften van gebruikers of het bedrijf. Toepassen Golden Circle en Requirements Engineering.
  • Hoe verhoudt het product zich tot de rest van het landschap en de eindgebruikers? Maak een ecosysteemmap om te visualiseren hoe het product past in het grotere geheel (bijv. andere systemen, processen, of gebruikersgroepen).
  • Zijn er persona’s beschikbaar die een aardig beeld van de eindgebruikers representeren? Als persona’s ontbreken of verouderd zijn, plan dan gebruikersinterviews in om ze bij te werken.
  • Welke stakeholders zijn betrokken en zijn ze op de hoogte? Organiseer een stakeholder alignment workshop om verwachtingen af te stemmen en commitment te verkrijgen.

Waarom deze aanvulling op de checklist werkt

Een goede checklist is dynamisch: hij groeit mee met je ervaring en de behoeften van je projecten. Door regelmatig te evalueren en aan te passen, zorg je dat je altijd een praktische, actiegerichte gids hebt die je helpt om efficiënter en effectiever te werken. Met de toevoeging van overdracht en succesmetrieken sluit je de cirkel: van start (kick-off) tot eind (impact meten) en daarna (kennis borgen).

Terug naar overzicht