The method behind every product decision I make for clients

1. I start with existing data

During a strong kickoff, where the project gets properly scoped, I ask what quantitative behavioral data the client already has on hand, so I can check whether it lines up with the problems they've flagged.

2. I talk to stakeholders

Interviewing key people surfaces individual perspectives and perceived issues that often diverge from the official narrative.

3. I go to real users, depending on the project

Not to run classic usability tests, but to watch how people actually interact with a client's tools and understand the pain points underneath. I'm deliberate about who I talk to: different user segments, not just power users or whoever's easiest to reach, and I make sure edge cases and accessibility needs are represented too.

4. I validate qualitative findings quantitatively

A handful of interviews tells me why something is happening, not how many users it actually affects. I follow up with a survey or another quantitative check before treating a pattern from a small sample as representative. Same triangulation principle I apply to data in general.

5. I look outward, not just inward

Competitive and industry context matters. Clients are often too close to their own product to spot certain blind spots, and benchmarking against how others solve the same problem surfaces things internal data and interviews alone won't.

6. I align before I build

Once insights are mapped, I run a readout with stakeholders to socialize the findings and get explicit buy-in before moving into solutioning. People get attached to their own ideas, and the earlier that alignment happens, the less resistance I run into later.

7. Then I build forward

Mapping insights, service mapping when the project calls for it, prototyping, iterating, presenting, and eventually handing off to UI and development.

INSIDE KENNETH'S UX BRAIN

The trap isn't skipping research outright. It's pseudo-research: clients dictating that research should happen "then and there, and in this way." It's a form of design by committee, and it quietly eliminates genuine problem identification while introducing bias before the project has even started.

The same pattern shows up later, in how decisions get made from data. One of my biggest pet peeves is a call made off a single metric, something like "CTR is low, we should change the button," without asking why. My rule is to always triangulate. No single source of insight is unbiased, so I lean on multiple before drawing conclusions.

For me, measuring impact starts with agreeing, early on, which numbers we are going to track, the KPIs worth tracking. This can be anything from click-through rates and customer satisfaction. At the beginning of a project it’s meaningful to ask what success looks like, but throughout the problem definition it could be that the more important trackers are different than the ones we assumed at the start. Then we monitor how those evolve over the course of the project.

But not all improvement shows up in a dashboard. Some of it is visible right away: in usability testing, I often see gains in user satisfaction and delight at a small scale, well before the bigger numbers catch up.

Not every meaningful project is the biggest one. My work with Club Brugge, which went on to earn a Webby Award nomination, is one of the projects I'm most proud of, for a few reasons. As a football fan, seeing it recognized on that stage meant something personal. As a UX designer, it validated the process behind it. And on a human level, it came down to the team. It was one of the best groups I've worked with. That mix of meaningful work, solid craft, and good people is what makes a project stay with me.

"The process can feel slow at the start, because research doesn't bring immediate change. But building a solution based on assumptions is like gambling your budget on a roulette wheel. Rebuilding the whole thing afterward is far more painful and costly, and people get attached to their built solutions, which makes it even harder to pivot later. Good insights lead to good decisions. Good decisions lead to good products."

Discover Kenneth's profile

The method behind every product decision I make for clients

1. I start with existing data

2. I talk to stakeholders

3. I go to real users, depending on the project

4. I validate qualitative findings quantitatively

5. I look outward, not just inward

6. I align before I build

7. Then I build forward

INSIDE KENNETH'S UX BRAIN

The most common mistakes I see companies do

What 'improvement' actually looks like

A project I'm particularly proud of

What I tell every client