Hoe je een design review-sessie inricht zodat stakeholders daadwerkelijk nuttige feedback geven — en geen nee zeggen omdat ze het niet snappen.
Stakeholders zeggen “mooi ontwerp” of geven vage feedback. Developers wachten op duidelijke input. Ontwerpers voelen zich niet begrepen. Het is een klassieke miscommunicatie die je makkelijk kan voorkomen.
Het verschil zit in voorbereiding. We’re niet alleen over schetsen praten — we’re een gestructureerde feedback-sessie opbouwen waar iedereen begrijpt wat ze zien en waarom je bepaalde keuzes maakt. Dit artikel laat zien hoe dat werkt in de praktijk.
Je moet stakeholders voorbereiden voordat ze je wireframes zien. Dat klinkt overdreven, maar het scheelt uren discussie later. We zeggen altijd: een slechte voorbereiding leidt tot drie feedback-ronden in plaats van één.
Begin met context. Waarom bouwen we dit scherm? Welke problemen lost het op? Wat zijn de gebruikers aan het doen? Dit kost vijf minuten uit te leggen, maar zorgt ervoor dat feedback gaat over het probleem, niet over je lettertype-keuze.
Een goede design review voelt niet als een presentatie. Het voelt als een discussie waar je leidt, maar niet domineert. Your job isn’t to defend your design — it’s to understand what people don’t understand about it.
Start altijd met: “Wat zie je op dit scherm?” Laat iemand anders antwoord geven. Als ze het niet goed beschrijven, weet je dat je wireframe niet duidelijk is. Dat’s waardevolle informatie. Don’t argue — noteer het op.
Na drie minuten, vraag je: “Werkt deze flow voor jullie use case?” Nu krijg je werkelijke feedback, niet oppervlakkige opmerkingen over kleuren of spacing. Je zit nog in de wireframe-fase — details komen later.
Je krijgt feedback op drie niveaus. Als je die door elkaar haalt, verdwijn je in details en mist je de grote problemen.
“Deze flow werkt niet voor onze use case.” Dit zijn show-stoppers. Je gaat terug naar tekentafel.
“Kunnen we stap 2 en 3 samenvoegen?” Dit aanvaarden of verwerpen op basis van je onderzoek.
“Dit knopje zou groter kunnen zijn.” Noteer het, maar dit is voor later — niet nu.
De review is voorbij, maar het werk begint nu. Alles wat je hebt besproken, gaat in je design file. Versies krijgen nummers. Feedback wordt gelinkt aan specifieke onderdelen. Niemand moet later raden wat afgesproken was.
In Figma kan je comments toevoegen aan specifieke elementen. We usually create a “Review v1” frame met alle feedback-punten uitgewerkt. Stakeholders kunnen live meekijken hoe je feedback verwerkt. That’s waar echte buy-in ontstaat.
De volgende review — en die is veel korter — kunnen jullie precies zien welke feedback je hebt overgenomen, welke je hebt verworpen (en waarom), en waar je nog twijfel hebt. Veel professioneler dan “ik heb wat dingen veranderd.”
Design reviews zijn niet voor perfectie — ze zijn voor alignment. Stakeholders begrijpen je keuzes, developers weten wat ze bouwen, en jij krijgt feedback die je daadwerkelijk kunt gebruiken. That’s the goal.
De drie stappen zijn simpel: voorbereiding (context geven), facilitatie (vragen stellen, luisteren), documentatie (alles vastleggen). Doe dit goed, en je bespaart jezelf weken herwerk en frustratie.
En ja, het eerste keer voelt raar om als facilitator te werken in plaats van te presenteren. Maar stakeholders voelen zich betrokken, en feedback wordt veel beter. Probeer het volgende keer — je zult het verschil zien.
Dit artikel is informatief en bedoeld als gids voor design review-praktijken. Elke organisatie werkt anders — de stappen die hier beschreven staan, zijn uitgangspunten. Pas ze aan op jouw situatie, team en projectvereisten. Dit is geen officieel advies of methode, maar best practices die in Nederlandse designteams goed werken.
