User Experience (UX) Process is Literally the Scientific Method

There’s lots of discussions and diagrams about the UX process, including the double diamond, design thinking activities, and even sprints.
What I’ve found that all of these have in common is the scientific method.
- Problem Statement (purpose/question)
- Understanding the user (research)
- Creating solution (hypothesis)
- Usability testing/validation (experiment)
- Analysis (understanding results)
- Conclusion
Considering that User Experience (UX) is a social science, it makes sense that we follow the same methods those sciences follow.
So what does that look like in the product/tech world?
Step 1: Purpose / Question
Our first job as UX designers is to take the business question (ex: how do we increase sales) into a user question (ex: what do I need from this product to meet my end goals?)
Step 2: Research
Like any good scientist, you look at the data that is already there (so you’re not starting from scratch each time).
- What is the current state?
- What does the system analytics tell us about user behavior?
- Are there mental models and patterns already established for this type of product?
Then in many cases, you must also ask your user what they’re goals and tasks are for this product or task flow.
We have to look at the whole picture to understand what variables need to be tested to confirm or deny the hypothesis we create.
Failing Fast
Some teams want to move quickly and fail fast, so they skip this research. Which means they don’t learn from the projects/products who have already made mistakes they can learn from. They repeat experiments or put out not-great products to learn about already established research. All these failed experiments leads to tech debt…which leads to not being able to move or fail fast in the future.
Step 3: Hypothesis
Our hypothesis is our design.
It’s us saying, “I think this is our solution to the problem.”
Like with many scientific hypothesis, we may have a few variables to test to ensure it is the correct hypothesis, but overall the previous research should get us to the point where we know what the user needs, and we are figuring out if we’ve met them correctly.
Step 4: Experiment
We test the different designs and/or variables to understand what makes the most effective, efficient, and engaging solution.
This could also be the ‘measure’ part of a ship + measure solution – as long as we are collecting comparable data for the before and afters.
Step 5: Data/Analysis
After looking at all the data collected, UX can say this solution will work.
Then the team must analyze the cost / benefits of the proposed design against budget and technical difficulty to see how many of the variables can be built – or you find that it can’t be done, so you have to move back to the hypothesis step.
A Quick Note
It’s important to understand the systems and developing before the hypotheses, but not to design around them, as this stifles innovation (and usually customer satisfaction).
I’ve found creating for the customer first can sometimes be easier to build because it may not even touch the tech debt or we already have the data and just need to show it. Don’t say ‘no’ to possibilities without knowing what goes into it.
Step 6: Conclusion
And like any good scientist, you keep track of your metrics so you know when (or how) to update your hypothesis in the future.
Similar Posts
When Customers Want ‘Faster Horses’ That Means We Need More User Research (Not Less)
When customers say they’d want ‘Faster Horses’, do more research, not less.
Information Design: Keep it Short and Simple (KISS)
How to write for designs that include a lot of information.
Improv-ing Your Public Speaking Skills
A few tips on public speaking for the next time you have to pitch an idea or defend your business case.


