Hypothesis in UX: Keys to designing research that delivers value
In any UX design project, research hypotheses are the starting point that helps us focus the work. When we formulate a hypothesis, we are putting in writing what we believe happens in the user experience or what we think could improve it.
Having these hypotheses clear allows us to better organize research activities, design tests that truly serve a purpose, and obtain conclusions that can be concretely applied to design. That said, it’s not always easy to formulate them well. That’s why in this article we share how we do it at the Studio, some common mistakes we try to avoid, and how we connect these hypotheses with research methodologies.
What a research hypothesis is and how we formulate it
A hypothesis in UX is a grounded statement that describes a possible behavior, expectation, or experience of users in relation to a digital product or service. It is an idea we want to contrast through research: it is posed as a statement we seek to validate or refute through observation and analysis.
When we formulate them at the Studio, we follow some basic guidelines:
- They must be affirmative (not written as questions).
- They have to be relevant to the problem or aspect of the experience we are investigating.
- They need to be testable, meaning during research we must be able to observe behaviors or collect metrics that indicate whether the hypothesis holds or not.
- They should be consistent with the project context and any prior data we have.
A good hypothesis gives us focus. It prevents us from going blindly and helps ensure that research is not just exploratory, but also actionable.
Common mistakes when creating hypotheses and how to avoid them
Over time, we have seen some frequent pitfalls worth keeping in mind:
1. Formulating hypotheses that are too broad or vague
When the hypothesis is very general, it becomes difficult to evaluate whether it holds. To avoid this, we recommend relying on the SMART methodology (specific, measurable, achievable, relevant, and time-bound). This provides clarity and facilitates analysis.
2. Confusing hypotheses with solutions
Another common error is writing the hypothesis as if it were already a solution. To avoid this, it is useful to use verbs like “we believe”, “we think”, which make it clear that we are in the exploration phase, not validating a closed solution. It is also helpful to detail the context or interaction we want to observe.
3. Basing hypotheses on unvalidated assumptions or team biases
It is important that the hypothesis has backing in prior data or in insights obtained in earlier project phases. Otherwise, we risk building hypotheses on untested internal perceptions.
4. Including too many variables in a single hypothesis
When a hypothesis combines several factors, it becomes hard to evaluate. In exploratory projects we recommend having one main hypothesis and a maximum of 2–3 secondary ones. In validation phases (for example, prototype tests or A/B), we focus on 2–3 specific hypotheses. This keeps the focus and facilitates decision-making.
How we connect hypotheses with the design of research activities
When designing research, we choose the most appropriate methodologies for each type of hypothesis. Here are some examples of how we combine them:
Think Aloud
As we have mentioned, Think Aloud is especially useful for validating hypotheses related to the user’s mental process. It is not just about seeing if the task is completed, but understanding how the user approaches that task, what doubts arise, and which elements feel intuitive or confusing.
Semi-structured interviews
Perfect for exploring hypotheses about motivations, prior behaviors, or frictions affecting the experience. Through open questions we obtain rich and nuanced information.
Card Sorting
Ideal for hypotheses about information architecture and users’ mental categorization. It helps us understand how users expect to find content.
Tree Testing
Very useful in navigation design phases, to validate changes before prototyping. Hypotheses focus on how users understand the structure and locate content without visual design interference.
See also: Guide to conducting tree testing.
How we apply it in real projects
At the Studio we have worked on multiple projects where we structured research around well-defined hypotheses.
One example is the work done for a fintech app. In this case, we conducted a remote test with users to evaluate onboarding and the sign-up process in the app. We started from hypotheses aimed at identifying possible barriers to conversion and the overall experience.
Through the Think Aloud method we were able to detect moments of doubt in the process, interface elements that generated friction, and opportunities for simplification. This allowed us to formulate concrete recommendations and propose usability metrics to continue measuring the experience after adjustments.
Formulating well-planned hypotheses saves us time, avoids biases, and makes our research more useful. Instead of going aimlessly, we start with clear questions that allow us to obtain answers applicable to design.
This is a translation of the following article from our corporate website:
