Episode 6: From Educated Guess to Evidence: How to Test Design Decisions

Most design arguments end the same way. The loudest voice wins, or the most senior one does, and everyone calls it an educated guess. Sometimes the guess is right. The problem is you can't tell which times, because nothing was ever tested.

Jonathan Kokké has spent his career closing that gap. He trained as a graphic designer, moved through UX consulting and a design leadership role at FTSE 100 firm RS Group, and now heads user experience at De Montfort University. On the sixth episode of Research Secrets, he made the case for designing on evidence instead of opinion, and walked through how to actually do it.

Why the educated guess isn't good enough

An educated guess feels safe because it comes from experience. Jonathan's point is that experience should shape the hypothesis. It shouldn't settle the question. You still have to check.

The shift he describes is from deciding what will work to finding out what does. Once you can put a design in front of real users and watch what happens, you're reporting a result instead of defending a preference. That changes the conversation in the room: instead of two people arguing taste, you have data showing which version got people through.

Start with who you're designing for

Evidence only means something if you know who it's coming from. Jonathan starts every project with the user, and he has a story that shows why it matters.

He once worked with a baby-product company whose e-commerce site looked childish, all bright and babyish, because the product was for babies. But babies don't shop. The buyers were parents, grandparents, and people choosing a gift, and the product was premium, so the design needed to feel more serious and higher quality.

"That's not actually the people who are buying the experience."

The company had the data to see this. Jonathan used it to argue for a more sophisticated design, they made the change, and sales moved up. The lesson underneath it: design for the person actually using the system, not the thing the product is about. You can't test your way to a good result if you've aimed the whole experience at the wrong audience.

Get something testable in front of people

You can't gather evidence on an idea that lives in your head, so the first job is to make the idea real. Jonathan borrows a line from his grandfather, a Flemish-trained painter, about making a mark on the canvas. The moment you put something down, you have an artifact to react to, even if it tells you you're wrong.

That barrier has dropped a long way. He still sketches on paper, then photographs it and turns it into a wireframe. Tools like Figma, Lovable, and Base44 let you assemble an idea quickly enough to test it. What you want at this stage is something concrete enough that a real person can try it and show you where it breaks. Polish can wait.

Test, measure, adjust

This is the loop Jonathan keeps coming back to, and he's blunt that the loop itself is the hard part, not the tools.

At small scale, you test a prototype or live code and watch what people do. Move a button above another button, and you might get a better response rate. At larger scale, you release a different experience to a percentage of your users and measure the real outcome. He's run conversion-rate experiments exactly this way. Blending the two matters, because something that tests well in a lab doesn't always translate when it ships, and running both takes a lot of the risk out of the decision.

The discipline is to keep going. Jonathan's recurring warning is that teams stop once something looks good enough, when that's the moment the continuous-improvement cycle should kick in. People change, technologies change, and a design that delighted users last year can frustrate them now.

Usable first, then measure the feeling

Evidence covers more than whether a task completes. Jonathan reframes the usual "minimum viable product" into something he calls a minimum usable product, and the distinction tells you what to measure.

A usable product has two sides: can the person reach their desired outcome, and how do they feel getting there? His De Montfort example is student registration. The university needs students to finish onboarding, so the test isn't only whether someone can move from A to B, but whether the experience is frustrating enough to make them drop out before they enroll. If it's confusing to join, that signals what being a student there will feel like. So he measures both completion and the experience around it, and uses analytics to read where people get stuck, what they like, and what they avoid.

Make the evidence persuade

Collecting the proof is only half the job. Jonathan is clear that the work won't speak for itself, and that communicating it is a skill in its own right.

A test result only changes a product if someone acts on it, which means you have to bring stakeholders along and win buy-in, including from the users you want in your research in the first place. The researchers and designers who get traction are the ones who can turn a finding into a case that a decision-maker understands and trusts.

Put it together and the method is simple to say and hard to practice. Know exactly who you're designing for, get something testable in front of them fast, and run the test-measure-adjust loop without stopping at good enough. Measure whether the task works and how it feels, then communicate the evidence well enough that the organization acts on it. Do that, and design decisions stop being a matter of whose guess wins.

Jonathan goes deeper on minimum usable products, Kano theory, and where AI should and shouldn't lead design work in the full conversation. Watch the full episode on Research Secrets.

About the guest

Jonathan Kokké heads user experience at De Montfort University. He was the sixth guest on Research Secrets, BlockSurvey's podcast about uncovering real user insights to build better products.