Mijn aanpak voor UX-projecten: van chaos naar richting

Na jarenlang aan digitale producten te hebben gewerkt, ben ik ervan overtuigd geraakt dat UX-design zelden over schermen gaat.

De meeste lastige projecten zijn niet moeilijk vanwege het design. Ze zijn moeilijk omdat niemand het probleem nog volledig begrijpt.

De grootste fout die ik teams zie maken, is dat ze direct in wireframes, UI-inspiratie of discussies over features duiken voordat ze begrijpen wat ze eigenlijk proberen op te lossen.

Dus voordat ik het over processen of tools heb, wil ik het hebben over hoe ik denk.

De Mindset

Begin bij het zakelijke probleem

Wanneer ik bij een nieuw project instap, open ik Figma niet direct. Ik probeer eerst een paar vragen te beantwoorden:

• Waarom bestaat dit project?

• Wat is het werkelijke probleem achter de aanvraag?

• Welk zakelijk resultaat proberen we te behalen?

• Hoe weten we of het een succes is?

De meeste projecten beginnen met een verzoek dat klinkt als een oplossing:

"We hebben een nieuw dashboard nodig." 

"We hebben een mobiele app nodig." 

"We hebben AI-functies nodig."

Dat zijn antwoorden op een probleem dat nog niemand hardop heeft uitgesproken.

Soms is het echte probleem een lage conversie. Soms is het operationele inefficiëntie. Soms is het een slechte retentie. Het vinden van het werkelijke probleem verandert meestal de richting van het hele project, inclusief de vraag of dat dashboard of die app überhaupt wel het juiste idee was.

Breng het probleem vanuit drie perspectieven in kaart

Zodra ik de zakelijke doelstelling begrijp, bekijk ik het project vanuit drie hoeken:

• Business: interne workflows, verwachtingen van stakeholders

• Gebruiker: doelen, pijnpunten, bestaand gedrag, motivaties

• Technisch: bestaande systemen, beschikbaarheid van data, ontwikkelingsbeperkingen, tijdlijn

Ik houd één kader in gedachten: Businessdoelen × Gebruikersbehoeften × Technische Realiteit.

De sterkste oplossingen bevinden zich bijna altijd op het snijvlak van deze drie. Een oplossing die een van deze factoren negeert, sneuvelt meestal ergens tussen de pitch en de productie.

Waar projecten echt lastig worden

De moeilijkste projecten zijn alignment-problemen, geen design-problemen

De meest uitdagende projecten waar ik aan heb gewerkt, waren niet de grootste. Het waren de projecten waarbij iedereen met een andere aanname binnenkwam.

Marketing wilde het één. Kitar wilde iets anders. Developers hadden beperkingen die niemand naar boven had gebracht. De klant had een tijdlijn die ervan uitging dat al het bovenstaande al was opgelost.

In die situaties stopt mijn werk als "schermen ontwerpen" en wordt het "alignment creëren".

Mijn rol draait dan minder om het ontwerpen van schermen en meer om het creëren van afstemming. Ik besteed tijd aan het faciliteren van gesprekken, het valideren van aannames en het helpen van teams om het eens te worden over prioriteiten voordat we overgaan tot de uitvoering van het design.

Dat soort momenten is de reden waarom ik alignment zie als een design-deliverable, niet als een noodzakelijk kwaad van vergaderen.

Hoe werk ik eigenlijk? Een proces dat herhaalt

Ik heb een proces. Op papier ziet dat er zo uit:

1. Discovery: interviews met stakeholders, zakelijk inzicht, productreview, data

2. Define: probleemstellingen, gebruikersbehoeften, succesmetrieken, prioritering

3. Structure: user flows, informatiearchitectuur, sitemap

4. Design: wireframes, validatie, high-fidelity

5. Iterate: feedback, testen, verbetering

Maar de nette versie is een leugen. In de realiteit overlappen de fasen en herhalen ze zich. Een wireframe in stap 4 legt een ontbrekende pagina bloot die me terugstuurt naar stap 3. Gebruikerstesten in stap 5 herformuleren een probleemstelling uit stap 2.

Het duidelijkste voorbeeld hiervan is de oude vraag: eerst de sitemap of eerst de wireframes?

In theorie komt de structuur eerst. Een sitemap definieert pagina's, relaties en hoe informatie is georganiseerd. Maar in de praktijk begin ik vaak eerder met mid-fidelity wireframes dan de meeste designers zouden verwachten.

De reden is simpel: stakeholders begrijpen schermen beter dan diagrammen. Vraag een klant om te reageren op een sitemap en het blijft stil. Laat ze een ruw scherm zien en ze vertellen je direct wat er ontbreekt.

Dat betekent niet dat ik de informatiearchitectuur oversla. Terwijl ik wireframes maak, valideer ik tegelijkertijd welke pagina's nodig zijn, welke informatie waar thuishoort, hoe gebruikers door het product bewegen en of de structuur standhoudt.

Voor mij zijn de sitemap en wireframes geen afzonderlijke fasen: ze evolueren samen, hand in hand. Wireframes leggen ontbrekende pagina's en onduidelijke flows bloot; de sitemap houdt het geheel verbonden. Het doel is niet om een tekstboek-volgorde aan te houden. Het doel is om stakeholders te helpen het product snel genoeg te begrijpen om goede beslissingen te kunnen nemen.

Het Ambacht

De tools die ik gebruik

Mensen vragen vaak welke tools ik gebruik. Het eerlijke antwoord is dat ik het grootste deel van mijn tijd besteed aan een kleine set hulpmiddelen.

• Figma: waar het meeste werk gebeurt: exploratie, user flows, wireframes, high-fidelity UI, design systems, prototypes en developer handoff. Voor mij is het minder een designtool en meer de plek waar ideeën tastbaar worden en discussies besluiten worden.

• FigJam: wanneer ik de structuur moet doordenken voordat ik ga ontwerpen, of een vaag project weer op de rails moet krijgen. Ik breng hier user flows, sitemaps, informatiearchitectuur en end-to-end journeys in kaart. Ik gebruik het niet bij elk project — vooral wanneer er veel pagina's, complexe journeys of onduidelijke vereisten zijn.

• ChatGPT / Gemini / Claude: een denkpartner, geen designtool. Ik gebruik ze om aannames uit te dagen, ideeën vanuit andere hoeken te verkennen, UX-copy te schrijven, onderzoeksvragen te structureren en grote hoeveelheden informatie samen te vatten. Ze versnellen het denkproces; de beslissingen vereisen nog steeds menselijk oordeel.

• Google Docs: voor alles wat duidelijk gecommuniceerd moet worden: briefs, aantekeningen, vereisten, onderzoeksverslagen. Schrijven legt vaak gaten in mijn denken bloot voordat ze problemen worden in het design.

• Pen en papier: nog steeds een van de tools die ik het meest gebruik. Schetsen haalt de druk van de afwerking weg en laat me puur op het denken focussen. Soms is de snelste manier om een designprobleem op te lossen een pen pakken en beginnen met tekenen.

Waar ik inspiratie vind

Er schuilt een gevaar in het zoeken naar inspiratie: je neemt stijlen over in plaats van na te denken. Mijn oplossing is om twee aparte sporen aan te houden.

Structurele / UX-inspiratie, om beslissingen te begrijpen:

• Mobbin: echte UI-patronen van echte apps, gecategoriseerd per flow. Handig om te zien hoe de industriestandaard er in productie echt uitziet.

• UX Archive: volledige flows van producten zoals Airbnb en Spotify. Ik bestudeer deze voor de logica achter de patronen, niet alleen de patronen zelf.

Visuele inspiratie, om een richting te bepalen, voorzichtig gebruikt:

• Dribbble / Behance: goed voor visuele richting, maar mooi betekent niet direct bruikbaar. Referenties voor de sfeer, geen modellen om te kopiëren.

• Awwwards / Godly: bekroonde sites, handig om mijn grenzen te verleggen van wat ik denk dat mogelijk is met lay-out en interactie.

Design systems: Apple HIG, Material Design, Atlassian. Ik lees de documentatie, niet alleen de componenten. Begrijpen waarom iets op een bepaalde manier is ontworpen, is waardevoller dan kopiëren hoe het eruitziet.

Off-screen: boeken, tijdschriften, architectuur, fysieke ruimtes. Sommige van de beste UX-inzichten die ik heb opgedaan, kwamen voort uit het kijken naar hoe fysieke ruimtes beweging sturen. Hiërarchie, bewegwijzering en informatiedichtheid bestaan overal, niet alleen op schermen.

Wat ik zou meegeven

Als ik een junior designer zou moeten opleiden

Ik ben waarschijnlijk niet de juiste persoon om de definitieve gids te schrijven. Ik leer zelf ook nog elke dag bij. Maar terugkijkend waren een paar dingen belangrijker dan de rest.

• Focus op het begrijpen van het probleem. In het begin was ik geobsedeerd door schermen. Ik realiseerde me dat het begrijpen van het probleem meestal belangrijker is dan het ontwerpen van de oplossing. Hoe beter ik de business, gebruikers en beperkingen begrijp, hoe makkelijker elke designbeslissing wordt.

• Leer je beslissingen uit te leggen. Een van de meest waardevolle vaardigheden die ik heb ontwikkeld, is niet het maken van ontwerpen, maar het uitleggen waarom een ontwerp bestaat. Het koppelen van designkeuzes aan gebruikersbehoeften en businessdoelen is waardevoller geweest dan welke trend dan ook.

• Begin niet met high-fidelity. Mijn grootste fouten kwamen voort uit het te snel in de UI duiken. Het is veel makkelijker om een schets aan te passen dan om een voltooid scherm opnieuw te ontwerpen.

• Blijf nieuwsgierig. De designers die ik het meest bewonder, zijn niet degenen met alle antwoorden. Het zijn degenen die steeds betere vragen blijven stellen.

Hoe langer ik in UX werk, hoe minder ik geloof dat design draait om het maken van schermen.

Goede UX gaat over het verminderen van onzekerheid en het zo duidelijk begrijpen van het probleem dat de juiste oplossing vanzelfsprekend wordt.