How to Turn a Design Assumption Into Something You Can Test

Designers make assumptions every day. We have to. There is rarely enough time or information to validate every small decision before putting something on the canvas.

I hear assumptions constantly in design reviews, including from myself:

“Users will notice this first.” “They’ll understand what this icon means.” “This version feels easier.” “People will probably go here next.” Most of the time, these are perfectly reasonable hypotheses based on experience, patterns, product knowledge, and what we know about the audience.

Problems start when those hypotheses quietly become facts.

One of the most useful habits I’ve learned is to catch those moments early and ask whether the assumption can be turned into something users can actually show us. Once you do that, choosing what to test becomes much easier.

Listen for predictions about what users will do

A lot of design assumptions reveal themselves through very ordinary language. Whenever someone predicts what a user will notice, understand, choose, expect, find, or do, there is usually a testable question hiding underneath.

Imagine a team reviewing a new settings screen and someone says, “Users will immediately know that integrations are under Account.”

That sounds like a design opinion, but it already contains a prediction about behavior. A research question could simply be: Where would users look first if they wanted to connect another tool?

Now the conversation has somewhere useful to go. Instead of debating whether the navigation feels intuitive, you can observe where people actually go.

The same applies to comments such as “the primary CTA is obvious” or “people will understand this new feature straight away.” Those statements give you clues about the behavior or understanding you need to investigate.

Turn the assumption into something you can observe

The easiest assumptions to test are usually tied to an observable outcome.

Take “users will notice the main action.” You could ask participants to complete a realistic task and see where they click first. A First Click Test can show whether the design is directing people toward the intended starting point or sending them somewhere else.

Now take “users will prefer the new version.” That points toward a comparison. A Preference Test can help you compare the directions around a specific quality such as clarity, confidence, or ease of scanning.

Other assumptions need a little more work. “This flow feels simple” is too broad to test directly. I would break that down into things I can observe: Can users complete the task? Where do they hesitate? Do they go backwards? Are there steps they misunderstand? A prototype test gives you much more useful evidence around those questions.

The wording changes, but the principle stays fairly consistent. Try to replace words such as intuitive, obvious, clean, or easy with the behavior you would expect to see if the assumption were true.

Be clear about what would change your mind

Before running the study, I like knowing what kind of result would actually make us reconsider the design.

Suppose we believe users will understand a new filtering interaction. If nearly everyone completes it quickly without hesitation, that gives us useful confidence. If people repeatedly open the wrong control, pause for a long time, or interpret the labels differently, we have something concrete to work with.

This also protects teams from testing something and then explaining away every unexpected result afterward.

You do not need a rigid pass/fail rule for every study. Qualitative research rarely works that neatly. You should still have some idea of what evidence would support the direction, what would make you question it, and what you want to pay attention to during the sessions.

That little bit of thinking before the test often makes the analysis much sharper afterward.

Match the method to the assumption

Once the assumption has become a clear question, method choice usually gets simpler.

If you are asking where users expect to begin, first click testing may be enough. If you are comparing two design directions, preference testing can give you a focused comparison. If the question is whether someone can move through a multi-step interaction, you probably need a usability test with an interactive prototype.

You may also discover that the original assumption contains several questions.

“We think this onboarding works well” could mean users understand the purpose of the feature, know where to begin, complete the setup successfully, and feel confident about what happens next. Trying to answer all of that with one vague question will give you vague findings.

This is where a platform such as Useberry becomes useful in the design process. Different methods can answer different parts of the uncertainty rather than forcing every design question into the same type of test.

Test while the assumption is still cheap to change

I would much rather challenge an assumption while we are looking at a prototype than after development has spent two weeks implementing it.

You do not need a finished experience to learn something useful. If the uncertainty is around hierarchy, direction, comprehension, or a key interaction, an earlier version may already contain enough detail to put the assumption in front of users.

Early tests can also be deliberately narrow. Maybe you only need to find out whether people understand where a flow begins. You can test that without validating every step behind it. If the issue is which design direction communicates the idea more clearly, you can compare those directions before polishing all the surrounding states.

The point is to test at the moment when the answer can still influence what you are designing. Research becomes much less useful when everyone is already too committed to the outcome to respond to what users show them.

Bring the result back to the original assumption

After a study, I like going back to the sentence that started it.

We assumed users would find the setting under Account. What did they actually do?

Maybe most participants went there immediately. Great, that assumption now has some evidence behind it. Maybe they repeatedly looked under Integrations instead. Now we have a pattern worth considering in the next iteration.

Sometimes the result is less tidy. Half the participants may succeed while the others hesitate between two options. That does not make the study unsuccessful. It tells us the design is communicating something, but perhaps not consistently enough yet.

Research rarely hands designers a replacement screen. What it can do very well is show us which assumptions survived contact with users and which ones deserve another look. The design work then continues from a much better starting point.

Make assumptions visible before they become decisions

Assumptions are a normal part of designing products, and I do not think the goal should be to eliminate them. The more useful habit is simply noticing when we are making one.

When someone says users will understand something, find something, prefer something, or behave a certain way, write it down. Turn it into a question. Decide what you would need to observe. Then choose the smallest useful test that can give you that evidence.

Over time, this changes design conversations too. Instead of spending twenty minutes arguing about which person in the room has the better intuition, you get much better at recognizing which questions users are in a better position to answer.

And for a design team, that is a pretty healthy place to be.

Turn the next “users will probably…” into something users can actually show you.

Test design assumptions with real user behavior before they become expensive decisions.

Start testing with Useberry