hypothesis statement ux

Hypothesis statement

• Introduction to Hypothesis statement
• Essential characteristics

Introduction to hypothesis statements

Brainstorming solutions is similar to making a hypothesis or an educated guess about how to solve the problem.

In UX design, we write down possible solutions to the problem as hypothesis statements. A good hypothesis statement requires more effort than just a guess. In particular, your hypothesis statement may start with a question that can be further explored through background research.

How do you write hypothesis statements? Unlike problem statements, there's no standard formula for writing hypothesis statements. For starters, let's try what's called an if-then statement.

It looks like this: If (name an action), then (name an outcome).

Hypothesis statements don't have a standard formula. Instead of an if-then statement, you can formulate this hypothesis statement in a more flexible way.

Essential characteristics of a hypothesis statement

To formulate a promising hypothesis, ask yourself the following questions:

Is the language clear and purposeful?

What is the relationship between your hypothesis and your research topic?

Is your hypothesis testable? If so, how?

What possible explanations would you like to explore?

You may need to come up with more than one hypothesis for a problem. That's okay! There will always be multiple solutions to your users' problems. Your job is to use your creativity and problem-solving skills to decide which solutions are best for each user you are designing for.

• #ClearLanguage
• #HypothesisVSResearchTopic
• #PossibleExplanations

Previous article • 5min read

Create, define problem statements, next article • 8min read, understand human factors, table of contents, esc hit escape to close, introduction to ux, what is user experience.

User experience, definition of a good design, lifecycle product development

UX Design Frameworks

Key frameworks.

User-Centered Design, the five elements of UX Design, Design Thinking, Lean UX, Double Diamond

Equity and Accessibility

Designing for all.

Universal design, inclusive design, and equity-focused design

The importance of Accessibility

Motor disabilities, deaf or hard of hearing, cognitive disabilities, visual disabilities

Design for the Next Billion User (Google)

Majority of people that gets online for the first time

Design for different platforms

Responsiveness, Call-to-actions, navigation and more

The 4Cs of princples of design

Consistency, Continuity Context and Complementary principles

Assistive Technology

Voice control and switch devices, screen readers, alternative text and speech

Impostor Syndrome/Biases

Overcome the impostor syndrome.

Impostor Syndrome is the feeling that makes you doubt that you actually earn your accomplishments.

Most common Biases

Learn about favoring or having prejudice against something based on limited information.

Prevent Biases

Recognize your own biases and prevent them from affecting your work.

Design Sprint

Introduction to design sprint.

Introduction to the framework, benefits and advantages

Plan a Design Sprint

Tips and tricks about design sprint planning

Write a Design Sprint brief

Insights and free canvas about making a design sprint brief.

Design Sprint retrospective

What went well? What can be improved?

UX Research

Introduction to ux research.

Learn techniques of research for designing better products

Foundational Research

Easily center on a problem or topic that's undefined in your project's scope

Design Research

Find stories, engage in conversations, understand the users motivations

Post-Launch Research

Know the impact of pre- and post-launch publicity and advertising on new product sales

Choosing the right Research method

Learn which research method to pick depending on the questions you still have unanswered

Benefits and drawbacks

Learn how to create an optimal product for the user

Recruit interview participants

Learn how to determine interview goals and write questions

Conduct user interviews

Insights on how to be prepared before speaking with real users

Create interview transcripts

Discover new topics of interest through a written transcript

Empathize with users

Master ability to fully understand, mirror a person's expressions, needs, and motivations

Consider a11y when empathizing

Learn why empathizing and accessibility go hand in hand

Empathy Maps

Learn how to empathize and synthesise your observations from the research phase

Identify pain points

Identify a specific problem that your users are experiencing

Understand personas

Learn how to shape product strategy and accompany it the usability testing sessions

User stories

Learn how to base your user stories on user goals and keep the product user focused

Create a user journey map

Learn how to make a visual representation of the customer experience

Determine value propositions

Set and explain why a customer should buy from you

Create and define a problem statement

Learn how to focus on the specific needs that you have uncovered yet

Learn how to predict the behavior of a proposed solution

Learn how people interact with technology

Competitive Audits

Introduction to competitive audits, limits to competitive audits, steps to conduct competitive audits, present a competitive audit, design ideation, understand design ideation, business needs during ideation, use insights from competitive audits to ideate, use "how might we" to ideate, use crazy eights to ideate, use journey map to ideate, goal statements, build a goal statement, introduction to user flows, storyboarding user flows, types of storyboards, wireframing, introduction to wireframes, paper wireframes, transition from paper to digital wireframes, information architecture, ethical and inclusive design, identify deceptive patterns, role as a ux designer, press shift to trigger the table of contents.

• Arrow Down Resources
• Envelope Subscribe
• Cookies Policy
• Terms & Conditions

Integrations

What's new?

In-Product Prompts

Participant Management

Interview Studies

Prototype Testing

Card Sorting

Tree Testing

Live Website Testing

Automated Reports

Templates Gallery

Choose from our library of pre-built mazes to copy, customize, and share with your own users

Browse all templates

Financial Services

Tech & Software

Product Designers

Product Managers

User Researchers

By use case

Concept & Idea Validation

Wireframe & Usability Test

Content & Copy Testing

Feedback & Satisfaction

Content Hub

Educational resources for product, research and design teams

Explore all resources

Question Bank

Maze Research Success Hub

Guides & Reports

Help Center

Future of User Research Report

The Optimal Path Podcast

User Research

Mar 21, 2024

Creating a research hypothesis: How to formulate and test UX expectations

A research hypothesis helps guide your UX research with focused predictions you can test and learn from. Here’s how to formulate your own hypotheses.

Armin Tanovic

All great products were once just thoughts—the spark of an idea waiting to be turned into something tangible.

A research hypothesis in UX is very similar. It’s the starting point for your user research; the jumping off point for your product development initiatives.

Formulating a UX research hypothesis helps guide your UX research project in the right direction, collect insights, and evaluate not only whether an idea is worth pursuing, but how to go after it.

In this article, we’ll cover what a research hypothesis is, how it's relevant to UX research, and the best formula to create your own hypothesis and put it to the test.

Test your hypothesis with Maze

Maze lets you validate your design and test research hypotheses to move forward with authentic user insights.

What defines a research hypothesis?

A research hypothesis is a statement or prediction that needs testing to be proven or disproven.

Let’s say you’ve got an inkling that making a change to a feature icon will increase the number of users that engage with it—with some minor adjustments, this theory becomes a research hypothesis: “ Adjusting Feature X’s icon will increase daily average users by 20% ”.

A research hypothesis is the starting point that guides user research . It takes your thought and turns it into something you can quantify and evaluate. In this case, you could conduct usability tests and user surveys, and run A/B tests to see if you’re right—or, just as importantly, wrong .

A good research hypothesis has three main features:

• Specificity: A hypothesis should clearly define what variables you’re studying and what you expect an outcome to be, without ambiguity in its wording
• Relevance: A research hypothesis should have significance for your research project by addressing a potential opportunity for improvement
• Testability: Your research hypothesis must be able to be tested in some way such as empirical observation or data collection

What is the difference between a research hypothesis and a research question?

Research questions and research hypotheses are often treated as one and the same, but they’re not quite identical.

A research hypothesis acts as a prediction or educated guess of outcomes , while a research question poses a query on the subject you’re investigating. Put simply, a research hypothesis is a statement, whereas a research question is (you guessed it) a question.

For example, here’s a research hypothesis: “ Implementing a navigation bar on our dashboard will improve customer satisfaction scores by 10%. ”

This statement acts as a testable prediction. It doesn’t pose a question, it’s a prediction. Here’s what the same hypothesis would look like as a research question: “ Will integrating a navigation bar on our dashboard improve customer satisfaction scores? ”

The distinction is minor, and both are focused on uncovering the truth behind the topic, but they’re not quite the same.

Why do you use a research hypothesis in UX?

Research hypotheses in UX are used to establish the direction of a particular study, research project, or test. Formulating a hypothesis and testing it ensures the UX research you conduct is methodical, focused, and actionable. It aids every phase of your research process , acting as a north star that guides your efforts toward successful product development .

Typically, UX researchers will formulate a testable hypothesis to help them fulfill a broader objective, such as improving customer experience or product usability. They’ll then conduct user research to gain insights into their prediction and confirm or reject the hypothesis.

A proven or disproven hypothesis will tell if your prediction is right, and whether you should move forward with your proposed design—or if it's back to the drawing board.

Formulating a hypothesis can be helpful in anything from prototype testing to idea validation, and design iteration. Put simply, it’s one of the first steps in conducting user research.

Whether you’re in the initial stages of product discovery for a new product, a single feature, or conducting ongoing research, a strong hypothesis presents a clear purpose and angle for your research It also helps understand which user research methodology to use to get your answers.

What are the types of research hypotheses?

Not all hypotheses are built the same—there are different types with different objectives. Understanding the different types enables you to formulate a research hypothesis that outlines the angle you need to take to prove or disprove your predictions.

Here are some of the different types of hypotheses to keep in mind.

Null and alternative hypotheses

While a normal research hypothesis predicts that a specific outcome will occur based upon a certain change of variables, a null hypothesis predicts that no difference will occur when you introduce a new condition.

By that reasoning, a null hypothesis would be:

• Adding a new CTA button to the top of our homepage will make no difference in conversions

Null hypotheses are useful because they help outline what your test or research study is trying to dis prove, rather than prove, through a research hypothesis.

An alternative hypothesis states the exact opposite of a null hypothesis. It proposes that a certain change will occur when you introduce a new condition or variable. For example:

• Adding a CTA button to the top of our homepage will cause a difference in conversion rates

Simple hypotheses and complex hypotheses

A simple hypothesis is a prediction that includes only two variables in a cause-and-effect sequence, with one variable dependent on the other. It predicts that you'll achieve a particular outcome based on a certain condition. The outcome is known as the dependent variable and the change causing it is the independent variable .

For example, this is a simple hypothesis:

• Including the search function on our mobile app will increase user retention

The expected outcome of increasing user retention is based on the condition of including a new search function. But, what happens when there are more than two factors at play?

We get what’s called a complex hypothesis. Instead of a simple condition and outcome, complex hypotheses include multiple results. This makes them a perfect research hypothesis type for framing complex studies or tracking multiple KPIs based on a single action.

Building upon our previous example, a complex research hypothesis could be:

• Including the search function on our mobile app will increase user retention and boost conversions

Directional and non-directional hypotheses

Research hypotheses can also differ in the specificity of outcomes. Put simply, any hypothesis that has a specific outcome or direction based on the relationship of its variables is a directional hypothesis . That means that our previous example of a simple hypothesis is also a directional hypothesis.

Non-directional hypotheses don’t specify the outcome or difference the variables will see. They just state that a difference exists. Following our example above, here’s what a non-directional hypothesis would look like:

• Including the search function on our mobile app will make a difference in user retention

In this non-directional hypothesis, the direction of difference (increase/decrease) hasn’t been specified, we’ve just noted that there will be a difference.

The type of hypothesis you write helps guide your research—let’s get into it.

How to write and test your UX research hypothesis

Now we’ve covered the types of research hypothesis examples, it’s time to get practical.

Creating your research hypothesis is the first step in conducting successful user research.

Here are the four steps for writing and testing a UX research hypothesis to help you make informed, data-backed decisions for product design and development.

1. Formulate your hypothesis

Start by writing out your hypothesis in a way that’s specific and relevant to a distinct aspect of your user or product experience. Meaning: your prediction should include a design choice followed by the outcome you’d expect—this is what you’re looking to validate or reject.

Your proposed research hypothesis should also be testable through user research data analysis. There’s little point in a hypothesis you can’t test!

Let’s say your focus is your product’s user interface—and how you can improve it to better meet customer needs. A research hypothesis in this instance might be:

• Adding a settings tab to the navigation bar will improve usability

By writing out a research hypothesis in this way, you’re able to conduct relevant user research to prove or disprove your hypothesis. You can then use the results of your research—and the validation or rejection of your hypothesis—to decide whether or not you need to make changes to your product’s interface.

2. Identify variables and choose your research method

Once you’ve got your hypothesis, you need to map out how exactly you’ll test it. Consider what variables relate to your hypothesis. In our case, the main variable of our outcome is adding a settings tab to the navigation bar.

Once you’ve defined the relevant variables, you’re in a better position to decide on the best UX research method for the job. If you’re after metrics that signal improvement, you’ll want to select a method yielding quantifiable results—like usability testing . If your outcome is geared toward what users feel, then research methods for qualitative user insights, like user interviews , are the way to go.

3. Carry out your study

It’s go time. Now you’ve got your hypothesis, identified the relevant variables, and outlined your method for testing them, you’re ready to run your study. This step involves recruiting participants for your study and reaching out to them through relevant channels like email, live website testing , or social media.

Given our hypothesis, our best bet is to conduct A/B and usability tests with a prototype that includes the additional UI elements, then compare the usability metrics to see whether users find navigation easier with or without the settings button.

We can also follow up with UX surveys to get qualitative insights and ask users how they found the task, what they preferred about each design, and to see what additional customer insights we uncover.

💡 Want more insights from your usability tests? Maze Clips enables you to gather real-time recordings and reactions of users participating in usability tests .

4. Analyze your results and compare them to your hypothesis

By this point, you’ve neatly outlined a hypothesis, chosen a research method, and carried out your study. It’s now time to analyze your findings and evaluate whether they support or reject your hypothesis.

Look at the data you’ve collected and what it means. Given that we conducted usability testing, we’ll want to look to some key usability metrics for an indication of whether the additional settings button improves usability.

For example, with the usability task of ‘ In account settings, find your profile and change your username ’, we can conduct task analysis to compare the times spent on task and misclick rates of the new design, with those same metrics from the old design.

If you also conduct follow-up surveys or interviews, you can ask users directly about their experience and analyze their answers to gather additional qualitative data . Maze AI can handle the analysis automatically, but you can also manually read through responses to get an idea of what users think about the change.

By comparing the findings to your research hypothesis, you can identify whether your research accepts or rejects your hypothesis. If the majority of users struggle with finding the settings page within usability tests, but had a higher success rate with your new prototype, you’ve proved the hypothesis.

However, it's also crucial to acknowledge if the findings refute your hypothesis rather than prove it as true. Ruling something out is just as valuable as confirming a suspicion.

In either case, make sure to draw conclusions based on the relationship between the variables and store findings in your UX research repository . You can conduct deeper analysis with techniques like thematic analysis or affinity mapping .

UX research hypotheses: four best practices to guide your research

Knowing the big steps for formulating and testing a research hypothesis ensures that your next UX research project gives you focused, impactful results and insights. But, that’s only the tip of the research hypothesis iceberg. There are some best practices you’ll want to consider when using a hypothesis to test your UX design ideas.

Here are four research hypothesis best practices to help guide testing and make your UX research systematic and actionable.

Align your hypothesis to broader business and UX goals

Before you begin to formulate your hypothesis, be sure to pause and think about how it connects to broader goals in your UX strategy . This ensures that your efforts and predictions align with your overarching design and development goals.

For example, implementing a brand new navigation menu for current account holders might work for usability, but if the wider team is focused on boosting conversion rates for first-time site viewers, there might be a different research project to prioritize.

Create clear and actionable reports for stakeholders

Once you’ve conducted your testing and proved or disproved your hypothesis, UX reporting and analysis is the next step. You’ll need to present your findings to stakeholders in a way that's clear, concise, and actionable. If your hypothesis insights come in the form of metrics and statistics, then quantitative data visualization tools and reports will help stakeholders understand the significance of your study, while setting the stage for design changes and solutions.

If you went with a research method like user interviews, a narrative UX research report including key themes and findings, proposed solutions, and your original hypothesis will help inform your stakeholders on the best course of action.

Consider different user segments

While getting enough responses is crucial for proving or disproving your hypothesis, you’ll want to consider which users will give you the highest quality and most relevant responses. Remember to consider user personas —e.g. If you’re only introducing a change for premium users, exclude testing with users who are on a free trial of your product.

You can recruit and target specific user demographics with the Maze Panel —which enables you to search for and filter participants that meet your requirements. Doing so allows you to better understand how different users will respond to your hypothesis testing. It also helps you uncover specific needs or issues different users may have.

Involve stakeholders from the start

Before testing or even formulating a research hypothesis by yourself, ensure all your stakeholders are on board. Informing everyone of your plan to formulate and test your hypothesis does three things:

Firstly, it keeps your team in the loop . They’ll be able to inform you of any relevant insights, special considerations, or existing data they already have about your particular design change idea, or KPIs to consider that would benefit the wider team.

Secondly, informing stakeholders ensures seamless collaboration across multiple departments . Together, you’ll be able to fit your testing results into your overall CX strategy , ensuring alignment with business goals and broader objectives.

Finally, getting everyone involved enables them to contribute potential hypotheses to test . You’re not the only one with ideas about what changes could positively impact the user experience, and keeping everyone in the loop brings fresh ideas and perspectives to the table.

Test your UX research hypotheses with Maze

Formulating and testing out a research hypothesis is a great way to define the scope of your UX research project clearly. It helps keep research on track by providing a single statement to come back to and anchor your research in.

Whether you run usability tests or user interviews to assess your hypothesis—Maze's suite of advanced research methods enables you to get the in-depth user and customer insights you need.

Frequently asked questions about research hypothesis

What is the difference between a hypothesis and a problem statement in UX?

A research hypothesis describes the prediction or method of solving that problem. A problem statement, on the other hand, identifies a specific issue in your design that you intend to solve. A problem statement will typically include a user persona, an issue they have, and a desired outcome they need.

How many hypotheses should a UX research problem have?

Technically, there are no limits to the amount of hypotheses you can have for a certain problem or study. However, you should limit it to one hypothesis per specific issue in UX research. This ensures that you can conduct focused testing and reach clear, actionable results.

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption

How to create a perfect design hypothesis

A design hypothesis is a cornerstone of the UX and UI design process. It guides the entire process, defines research needs, and heavily influences the final outcome.

Doing any design work without a well-defined hypothesis is like riding a car without headlights. Although still possible, it forces you to go slower and dramatically increases the chances of unpleasant pitfalls.

The importance of a hypothesis in the design process

Design change for your hypothesis, the objective of your hypothesis, mapping underlying assumptions in your hypothesis, example 1: a simple design hypothesis, example 2: a robust design hypothesis.

There are three main reasons why no discovery or design process should start without a well-defined and framed hypothesis. A good design hypothesis helps us:

• Guide the research
• Nail the solutions
• Maximize learnings and enable iterative design

A design hypothesis guides research

A good hypothesis not only states what we want to achieve but also the final objective and our current beliefs. It allows designers to assess how much actual evidence there is to support the hypothesis and focus their research and discovery efforts on areas they are least confident about.

Research for the sake of research brings waste. Research for the sake of validating specific hypotheses brings learnings.

A design hypothesis influences the design and solution

Design hypothesis gives much-needed context. It helps you:

• Ideate right solutions
• Focus on the proper UX
• Polish UI details

The more detailed and robust the design hypothesis, the more context you have to help you make the best design decisions.

A design hypothesis maximizes learnings and enables iterative design

If you design new features blindly, it’s hard to truly learn from the launch. Some metrics might go up. Others might go down, so what?

With a well-defined design hypothesis, you can not only validate whether the design itself works but also better understand why and how to improve it in the future. This helps you iterate on your learnings.

Components of a good design hypothesis

I am not a fan of templatizing how a solid design hypothesis should look. There are various ways to approach it, and you should choose whatever works for you best. However, there are three essential elements you should include to ensure you get all the benefits mentioned earlier of using design hypotheses, that is:

• Design change
• The objective
• Underlying assumptions

The fundamental part is the definition of what you are trying to do. If you are working on shortening the onboarding process, you might simply put “[…] we’d like to shorten the onboarding process […].”

The goal here is to give context to a wider audience and be able to quickly reference that the design hypothesis is concerning. Don’t fret too much about this part; simply boil the problem down to its essentials. What is frustrating your users?

In other words, the objective is the “why” behind the change. What exactly are you trying to achieve with the planned design change? The objective serves a few purposes.

Over 200k developers and product managers use LogRocket to create better digital experiences

First, it’s a great sanity check. You’d be surprised how many designers proposed various ideas, changes, and improvements without a clear goal. Changing design just for the sake of changing the design is a no-no.

It also helps you step back and see if the change you are considering is the best approach. For instance, if you are considering shortening the onboarding to increase the percentage of users completing it, are there any other design changes you can think of to achieve the same goal? Maybe instead of shortening the onboarding, there’s a bigger opportunity in simply adjusting the copy? Defining clear objectives invites conversations about whether you focus on the right things.

Additionally, a clearly defined objective gives you a measure of success to evaluate the effectiveness of your solution. If you believed you could boost the completion rate by 40 percent, but achieved only a 10 percent lift, then either the hypothesis was flawed (good learning point for the future), or there’s still room for improvements.

Last but not least, a clear objective is essential for the next step: mapping underlying assumptions.

Now that you know what you plan to do and which goal you are trying to achieve, it’s time for the most critical question.

Why do you believe the proposed design change will achieve the desired objective? Whether it’s because you heard some interesting insights during user interviews or spotted patterns in users’ behavioral data, note it down.

Even if you don’t have any strong justification and base your hypothesis on pure guesses (we all do that sometimes!), clearly name these beliefs. Listing out all your assumption will help you:

• Focus your discovery efforts on validating these assumptions to avoid late disappointments
• Better analyze results post-launch to maximize your learnings

You’ll see exactly how in the examples of good design hypotheses below.

Examples of good design hypotheses

Let’s put it all into practice and see what a good design hypothesis might look like.

I’ll use two examples:

• A simple design hypothesis
• A robust design hypothesis

You should still formulate a design hypothesis if you are working on minor changes, such as changing the copy on buttons. But there’s also no point in spending hours formulating a perfect hypothesis for a fifteen-minute test. In these cases, I’d just use a simple one-sentence hypothesis.

Yet, suppose you are working on an extensive and critical initiative, such as redesigning the whole conversion funnel. In that case, you might want to put more effort into a more robust and detailed design hypothesis to guide your entire process.

A simple example of a design hypothesis could be:

Moving the sign-up button to the top of the page will increase our conversion to registration by 10 percent, as most users don’t look at the bottom of the page.

Although it’s pretty straightforward, it still can help you in a few ways.

First of all, it helps prioritize experiments. If there is another small experiment in the backlog, but with the hypothesis that it’ll improve conversion to registration by 15 percent, it might influence the order of things you work on.

Impact assessments (where the 10 percent or 15 percent comes from) are another quite advanced topic, so I won’t cover it in detail, but in most cases, you can ask your product manager and/or data analyst for help.

It also allows you to validate the hypothesis without even experimenting. If you guessed that people don’t look at the bottom of the page, you can check your analytics tools to see what the scroll rate is or check heatmaps.

Lastly, if your hypothesis fails (that is, the conversion rate doesn’t improve), you get valuable insights that can help you reassess other hypotheses based on the “most users don’t look at the bottom of the page” assumption.

Now let’s take a look at a slightly more robust assumption. An example could be:

Shortening the number of screens during onboarding by half will boost our free trial to subscription conversion by 20 percent because:

• Most users don’t complete the whole onboarding flow
• Shorter onboarding will increase the onboarding completion rate
• Focusing on the most important features will increase their adoption
• Which will lead to aha moments and better premium retention
• Users will perceive our product as simpler and less complex

The most significant difference is our effort to map all relevant assumptions.

Listing out assumptions can help you test them out in isolation before committing to the initiative.

For example, if you believe most users don’t complete the onboarding flow , you can check self-serve tools or ask your PM for help to validate if that’s true. If the data shows only 10 percent of users finish the onboarding, the hypothesis is stronger and more likely to be successful. If, on the other hand, most users do complete the whole onboarding, the idea suddenly becomes less promising.

The second advantage is the number of learnings you can get from the post-release analysis.

Say the change led to a 10 percent increase in conversion. Instead of blindly guessing why it didn’t meet expectations, you can see how each assumption turned out.

It might turn out that some users actually perceive the product as more complex (rather than less complex, as you assumed), as they have difficulty figuring out some functionalities that were skipped in the onboarding. Thus, they are less willing to convert.

Not only can it help you propose a second iteration of the experiment, that learning will help you greatly when working on other initiatives based on a similar assumption.

Closing thoughts

Ensuring everything you work on is based on a solid design hypothesis can greatly help you and your career.

It’ll guide your research and discovery in the right direction, enable better iterative design, maximize learning, and help you make better design decisions.

Some designers might think, “Hypotheses are the job of a product manager, not a designer.”

While that’s partly true, I believe designers should be proactive in working with hypotheses.

If there are none set, do it yourself for the sake of your own success. If all your designs succeed, or worse, flunk, no one will care who set or didn’t set the hypotheses behind these decisions. You’ll be judged, too.

If there’s a hypothesis set upfront, try to understand it, refine it, and challenge it if needed.

Most senior and desired product designers are not just pixel-pushers that do what they are being told to do, but they also play an active role in shaping the direction of the product as a whole. Becoming fluent in working with hypotheses is a significant step toward true seniority.

Header image source: IconScout

LogRocket : Analytics that give you UX insights without the need for interviews

LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.

See how design choices, interactions, and issues affect your users — get a demo of LogRocket today .

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• #ux research

Stop guessing about your digital experience with LogRocket

Recent posts:.

Crafting an ideal UX designer job description: Get specific

Specificity is essential in job descriptions for any level. This blog will guide you in crafting an ideal UX designer job description.

Tips for better ecommerce UX design

There’s little to no room for innovation and creativity in ecommerce. But by nailing every step of the sales funnel, you can greatly impact the company’s sales.

Creating a low-fidelity prototype in UX design

Use a low-fidelity prototype for your design whenever you need to experiment with ideas in the UX research analysis stage.

Applying the elaboration likelihood model (ELM)

The elaboration likelihood model (ELM) is a theory that describes how people process information and its impact on their attitudes.

Leave a Reply Cancel reply

InVisionApp, Inc.

Inside Design

5 steps to a hypothesis-driven design process

  •   mar 22, 2018.

S ay you’re starting a greenfield project, or you’re redesigning a legacy app. The product owner gives you some high-level goals. Lots of ideas and questions are in your mind, and you’re not sure where to start.

Hypothesis-driven design will help you navigate through a unknown space so you can come out at the end of the process with actionable next steps.

Ready? Let’s dive in.

Step 1: Start with questions and assumptions

On the first day of the project, you’re curious about all the different aspects of your product. “How could we increase the engagement on the homepage? ” “ What features are important for our users? ”

Related: 6 ways to speed up and improve your product design process

To reduce risk, I like to take some time to write down all the unanswered questions and assumptions. So grab some sticky notes and write all your questions down on the notes (one question per note).

I recommend that you use the How Might We technique from IDEO to phrase the questions and turn your assumptions into questions. It’ll help you frame the questions in a more open-ended way to avoid building the solution into the statement prematurely. For example, you have an idea that you want to make riders feel more comfortable by showing them how many rides the driver has completed. You can rephrase the question to “ How might we ensure rider feel comfortable when taking ride, ” and leave the solution part out to the later step.

“It’s easy to come up with design ideas, but it’s hard to solve the right problem.”

It’s even more valuable to have your team members participate in the question brainstorming session. Having diverse disciplines in the room always brings fresh perspectives and leads to a more productive conversation.

Step 2: Prioritize the questions and assumptions

Now that you have all the questions on sticky notes, organize them into groups to make it easier to review them. It’s especially helpful if you can do the activity with your team so you can have more input from everybody.

When it comes to choosing which question to tackle first, think about what would impact your product the most or what would bring the most value to your users.

If you have a big group, you can Dot Vote to prioritize the questions. Here’s how it works: Everyone has three dots, and each person gets to vote on what they think is the most important question to answer in order to build a successful product. It’s a common prioritization technique that’s also used in the Sprint book by Jake Knapp —he writes, “ The prioritization process isn’t perfect, but it leads to pretty good decisions and it happens fast. ”

Related: Go inside design at Google Ventures

Step 3: Turn them into hypotheses

After the prioritization, you now have a clear question in mind. It’s time to turn the question into a hypothesis. Think about how you would answer the question.

Let’s continue the previous ride-hailing service example. The question you have is “ How might we make people feel safe and comfortable when using the service? ”

Based on this question, the solutions can be:

• Sharing the rider’s location with friends and family automatically
• Displaying more information about the driver
• Showing feedback from previous riders

Now you can combine the solution and question, and turn it into a hypothesis. Hypothesis is a framework that can help you clearly define the question and solution, and eliminate assumption.

From Lean UX

We believe that [ sharing more information about the driver’s experience and stories ] For [ the riders ] Will [ make riders feel more comfortable and connected throughout the ride ]

4. Develop an experiment and testing the hypothesis

Develop an experiment so you can test your hypothesis. Our test will follow the scientific methods, so it’s subject to collecting empirical and measurable evidence in order to obtain new knowledge. In other words, it’s crucial to have a measurable outcome for the hypothesis so we can determine whether it has succeeded or failed.

There are different ways you can create an experiment, such as interview, survey , landing page validation, usability testing, etc. It could also be something that’s built into the software to get quantitative data from users. Write down what the experiment will be, and define the outcomes that determine whether the hypothesis is valids. A well-defined experiment can validate/invalidate the hypothesis.

In our example, we could define the experiment as “ We will run X studies to show more information about a driver (number of ride, years of experience), and ask follow-up questions to identify the rider’s emotion associated with this ride (safe, fun, interesting, etc.). We will know the hypothesis is valid when we get more than 70% identify the ride as safe or comfortable. ”

After defining the experiment, it’s time to get the design done. You don’t need to have every design detail thought through. You can focus on designing what is needed to be tested.

When the design is ready, you’re ready to run the test. Recruit the users you want to target , have a time frame, and put the design in front of the users.

5. Learn and build

You just learned that the result was positive and you’re excited to roll out the feature. That’s great! If the hypothesis failed, don’t worry—you’ll be able to gain some insights from that experiment. Now you have some new evidence that you can use to run your next experiment. In each experiment, you’ll learn something new about your product and your customers.

“Design is a never-ending process.”

What other information can you show to make riders feel safe and comfortable? That can be your next hypothesis. You now have a feature that’s ready to be built, and a new hypothesis to be tested.

Principles from from The Lean Startup

We often assume that we understand our users and know what they want. It’s important to slow down and take a moment to understand the questions and assumptions we have about our product.

After testing each hypothesis, you’ll get a clearer path of what’s most important to the users and where you need to dig deeper. You’ll have a clear direction for what to do next.

by Sylvia Lai

Sylvia Lai helps startup and enterprise solve complex problems through design thinking and user-centered design methodologies at Pivotal Labs . She is the biggest advocate for the users, making sure their voices are heard is her number one priority. Outside of work, she loves mentoring other designers through one-on-one conversation. Connect with her through LinkedIn or Twitter .

Collaborate in real time on a digital whiteboard Try Freehand

Get awesome design content in your inbox each week, give it a try—it only takes a click to unsubscribe., thanks for signing up, you should have a thank you gift in your inbox now-and you’ll hear from us again soon, get started designing better. faster. together. and free forever., give it a try. nothing’s holding you back..

UX Research: Objectives, Assumptions, and Hypothesis

by Rick Dzekman

An often neglected step in UX research

Introduction

UX research should always be done for a clear purpose – otherwise you’re wasting the both your time and the time of your participants. But many people who do UX research fail to properly articulate the purpose in their research objectives. A major issue is that the research objectives include assumptions that have not been properly defined.

When planning UX research you have some goal in mind:

• For generative research it’s usually to find out something about users or customers that you previously did not know
• For evaluative research it’s usually to identify any potential issues in a solution

As part of this goal you write down research objectives that help you achieve that goal. But for many researchers (especially more junior ones) they are missing some key steps:

• How will those research objectives help to reach that goal?
• What assumptions have you made that are necessary for those objectives to reach that goal?
• How does your research (questions, tasks, observations, etc.) help meet those objectives?
• What kind of responses or observations do you need from your participants to meet those objectives?

One approach people use is to write their objectives in the form of research hypothesis. There are a lot of problems when trying to validate a hypothesis with qualitative research and sometimes even with quantitative.

This article focuses largely on qualitative research: interviews, user tests, diary studies, ethnographic research, etc. With qualitative research in mind let’s start by taking a look at a few examples of UX research hypothesis and how they may be problematic.

Research hypothesis

Example hypothesis: users want to be able to filter products by colour.

At first it may seem that there are a number of ways to test this hypothesis with qualitative research. For example we might:

• Observe users shopping on sites with and without colour filters and see whether or not they use them
• Ask users who are interested in our products about how narrow down their choices
• Run a diary study where participants document the ways they narrowed down their searches on various stores
• Make a prototype with colour filters and see if participants use them unprompted

These approaches are all effective but they do not and cannot prove or disprove our hypothesis. It’s not that the research methods are ineffective it’s that the hypothesis itself is poorly expressed.

The first problem is that there are hidden assumptions made by this hypothesis. Presumably we would be doing this research to decide between a choice of possible filters we could implement. But there’s no obvious link between users wanting to filter by colour and a benefit from us implementing a colour filter. Users may say they want it but how will that actually benefit their experience?

The second problem with this hypothesis is that we’re asking a question about “users” in general. How many users would have to want colour filters before we could say that this hypothesis is true?

Example Hypothesis: Adding a colour filter would make it easier for users to find the right products

This is an obvious improvement to the first example but it still has problems. We could of course identify further assumptions but that will be true of pretty much any hypothesis. The problem again comes from speaking about users in general.

Perhaps if we add the ability to filter by colour it might make the possible filters crowded and make it more difficult for users who don’t need colour to find the filter that they do need. Perhaps there is a sample bias in our research participants that does not apply broadly to our user base.

It is difficult (though not impossible) to design research that could prove or disprove this hypothesis. Any such research would have to be quantitative in nature. And we would have to spend time mapping out what it means for something to be “easier” or what “the right products” are.

Example Hypothesis: Travelers book flights before they book their hotels

The problem with this hypothesis should now be obvious: what would it actually mean for this hypothesis to be proved or disproved? What portion of travelers would need to book their flights first for us to consider this true?

Example Hypothesis: Most users who come to our app know where and when they want to fly

This hypothesis is better because it talks about “most users” rather than users in general. “Most” would need to be better defined but at least this hypothesis is possible to prove or disprove.

We could address this hypothesis with quantitative research. If we found out that it was true we could focus our design around the primary use case or do further research about how to attract users at different stages of their journey.

However there is no clear way to prove or disprove this hypothesis with qualitative research. If the app has a million users and 15/20 research participants tell you that this is true would your findings generalise to the entire user base? The margin of error on that finding is 20-25%, meaning that the true results could be closer to 50% or even 100% depending on how unlucky you are with your sample.

Example Hypothesis: Customers want their bank to help them build better savings habits

There are many things wrong with this hypothesis but we will focus on the hidden assumptions and the links to design decisions. Two big assumptions are that (1) it’s possible to find out what research participants want and (2) people’s wants should dictate what features or services to provide.

Research objectives

One of the biggest problem with using hypotheses is that they set the wrong expectations about what your research results are telling you. In Thinking, Fast and Slow, Daniel Kahneman points out that:

• “extreme outcomes (both high and low) are more likely to be found in small than in large samples”
• “the prominence of causal intuitions is a recurrent theme in this book because people are prone to apply causal thinking inappropriately, to situations that require statistical reasoning”
• “when people believe a conclusion is true, they are also very likely to believe arguments that appear to support it, even when these arguments are unsound”

Using a research hypothesis primes us to think that we have found some fundamental truth about user behaviour from our qualitative research. This leads to overconfidence about what the research is saying and to poor quality research that could simply have been skipped in exchange for simply making assumption. To once again quote Kahneman: “you do not believe that these results apply to you because they correspond to nothing in your subjective experience”.

We can fix these problems by instead putting our focus on research objectives. We pay attention to the reason that we are doing the research and work to understand if the results we get could help us with our objectives.

This does not get us off the hook however because we can still create poor research objectives.

Let’s look back at one of our prior hypothesis examples and try to find effective research objectives instead.

Example objectives: deciding on filters

In thinking about the colour filter we might imagine that this fits into a larger project where we are trying to decide what filters we should implement. This is decidedly different research to trying to decide what order to implement filters in or understand how they should work. In this case perhaps we have limited resources and just want to decide what to implement first.

A good approach would be quantitative research designed to produce some sort of ranking. But we should not dismiss qualitative research for this particular project – provided our assumptions are well defined.

Let’s consider this research objective: Understand how users might map their needs against the products that we offer . There are three key aspects to this objective:

• “Understand” is a common form of research objective and is a way that qualitative research can discover things that we cannot find with quant. If we don’t yet understand some user attitude or behaviour we cannot quantify it. By focusing our objective on understanding we are looking at uncovering unknowns.
• By using the word “might” we are not definitively stating that our research will reveal all of the ways that users think about their needs.
• Our focus is on understanding the users’ mental models. Then we are not designing for what users say that they want and we aren’t even designing for existing behaviour. Instead we are designing for some underlying need.

The next step is to look at the assumptions that we are making. One assumption is that mental models are roughly the same between most people. So even though different users may have different problems that for the most part people tend to think about solving problems with the same mental machinery. As we do more research we might discover that this assumption is not true and there are distinctly different kinds of behaviours. Perhaps we know what those are in advance and we can recruit our research participants in a way that covers those distinct behaviours.

Another assumption is that if we understand our users’ mental models that we will be able to design a solution that will work for most people. There are of course more assumptions we could map but this is a good start.

Now let’s look at another research objective: Understand why users choose particular filters . Again we are looking to understand something that we did not know before.

Perhaps we have some prior research that tells us what the biggest pain points are that our products solve. If we have an understanding of why certain filters are used we can think about how those motivations fit in with our existing knowledge.

Mapping objectives to our research plan

Our actual research will involve some form of asking questions and/or making observations. It’s important that we don’t simply forget about our research objectives and start writing questions. This leads to completing research and realising that you haven’t captured anything about some specific objective.

An important step is to explicitly write down all the assumptions that we are making in our research and to update those assumptions as we write our questions or instructions. These assumptions will help us frame our research plan and make sure that we are actually learning the things that we think we are learning. Consider even high level assumptions such as: a solution we design with these insights will lead to a better experience, or that a better experience is necessarily better for the user.

Once we have our main assumptions defined the next step is to break our research objective down further.

Breaking down our objectives

The best way to consider this breakdown is to think about what things we could learn that would contribute to meeting our research objective. Let’s consider one of the previous examples: Understand how users might map their needs against the products that we offer

We may have an assumption that users do in fact have some mental representation of their needs that align with the products they might purchase. An aspect of this research objective is to understand whether or not this true. So two sub-objectives may be to (1) understand why users actually buy these sorts of products (if at all), and (2) understand how users go about choosing which product to buy.

Next we might want to understand what our users needs actually are or if we already have research about this understand which particular needs apply to our research participants and why.

And finally we would want to understand what factors go into addressing a particular need. We may leave this open ended or even show participants attributes of the products and ask which ones address those needs and why.

Once we have a list of sub-objectives we could continue to drill down until we feel we’ve exhausted all the nuances. If we’re happy with our objectives the next step is to think about what responses (or observations) we would need in order to answer those objectives.

It’s still important that we ask open ended questions and see what our participants say unprompted. But we also don’t want our research to be so open that we never actually make any progress on our research objectives.

Reviewing our objectives and pilot studies

At the end it’s important to review every task, question, scenario, etc. and seeing which research objectives are being addressed. This is vital to make sure that your planning is worthwhile and that you haven’t missed anything.

If there’s time it’s also useful to run a pilot study and analyse the responses to see if they help to address your objectives.

Plan accordingly

It should be easy to see why research hypothesis are not suitable for most qualitative research. While it is possible to create suitable hypothesis it is more often than not going to lead to poor quality research. This is because hypothesis create the impression that qualitative research can find things that generalise to the entire user base. In general this is not true for the sample sizes typically used for qualitative research and also generally not the reason that we do qualitative research in the first place.

Instead we should focus on producing effective research objectives and making sure every part of our research plan maps to a suitable objective.

Hypotheses are assumptions about the future. They should have a strong point of view (POV) and be in direct response to your how might we (HMW) statement.

Hypotheses are: ✨ informed by research ( qualitative & secondary) ✨ inspired by market & technology trends ✨ backed by your experience and intuition as a designer.

Use hypotheses to frame research and experimentation—then be excited when research proves it right or wrong or asks you to build on it.🙃

When ideating around the hypothesis, consider:

✨ Method: how do you intend to carry out your hypothesis? ✨ Output: What do you need to design to prove out your hypothesis?

Included is a 1/2 sheet for scribbling down hypotheses for your project.

Pro tip: Keep track of what hypothesis is in response to which HMW statement using a labelling convention like, A1= A(HMW)1(Hypothesis). You'll have a red thread from idea to hypothesis to HMW statements.

Make sense of mess and get that spark, faster.

A resource to find and share frameworks for design research, synthesis, and ideation.

🚀 We've just released our new subscription model.

Design 101 /

Whether you want to redesign your digital product or create a new one from scratch, the UX research and discovery phase is fundamental when learning more about users' pains and gains. Research hypothesis helps you validate your assumptions and guides you through the whole process . It can discover what should be the next actionable steps in the design process, based on scientifically-proven statements and facts.

Table of contents:

What is a hypothesis in ux research, how to structure the hypothesis, hypothesis-driven design process, what are the benefits of research hypotheses in digital product design.

A hypothesis in UX design is a statement about how you think users will behave and what kind of solutions will fit and respond to their needs. In other words, a hypothesis defines how you think something works based on your research, knowledge, and experience. You can use this tool to guide the rest of your user research process and find a factual answer you can support with numbers, and appropriate probes with users whose actions, reflections, and feelings are tested and analyzed.

A hypothesis is a testable form of an assumption that, through experiments, can be proved or disproved. One can test it with experiments using qualitative or quantitative research methods. Defining a hypothesis helps you determine what data you need to collect from your users and how to interpret it.

A hypothesis formulates how two or more variables are related.

For example:

- "Elderly people use mobile devices less often than young people do."

- Or: "If we make our website accessible for people with low vision, they will have a better experience on our site."

Hypothesis for redesign and new product design

If you implement a new design to an old one, created hypotheses can relate to how you expect the user's behavior will change. In this case, you can formulate a hypothesis by asking questions like:

"What do I expect users to do once they have access to this feature?"

For instance, if you think about adding to your online learning platform app the feature of downloading courses for offline mode, you can ask questions like:

• How do learners usually use offered courses?
• Where and when do they prefer to learn?
• Are there additional values for students to download offered classes and materials?
• What would students do when they had an opportunity to download courses?

Revised assumptions and tested even in the primary way can help you formulate a research hypothesis that can look, for instance:

We believe that creating the feature of downloading courses by XYZ app students will increase their engagement in taking classes and finishing them earlier.

If you offer the user a completely new product, a hypothesis will relate to more fundamental issues, and you can formulate it through questions like:

• What are the most effective ways of online learning?
• What motivates people to do new courses and finish them?
• How do people search for new courses and classes?
• What encourages people to learn new skills?

Those questions can help you formulate a research hypothesis that usually should be based on previous research on this topic and then lead to the next steps. The hypothesis formulated in this case would sound, for instance:

We believe that certificates given to students of courses on the XYZ platform will encourage them to take classes and complete them.

To formulate a hypothesis, you need to clearly understand the problem you are trying to solve and what your users want . The best way to find a research hypothesis is by brainstorming with a team.

1. Formulate research questions

When we see a problem, it is natural to immediately try to find the solution. This works the same in the product design. Therefore, before you jump directly into solutions, it is crucial to consider what you don't know and for which issues you don't have answers to. Note assumptions as well. Write them down, individually or together with your team during the workshop. Categorize them later, organize them into groups and prioritize.

Then, focus on the most important and ask yourself:

"What do I think is the best solution for this problem?".

To formulate research questions and turn them into assumptions, you can use the How Might We technique by IDEO. This technique helps to frame the question in an open-ended way without imposing answers. For example, using the previous model, you want to encourage students to finish their courses on your online learning platform successfully. So, you can ask the question:

How might we encourage students to finish the course once taken successfully?

2. Structure research hypothesis

Once you have prepared a prioritized list of questions, you can formulate a research hypothesis. It combines a prioritized set of questions with well-thought-out solutions. The solutions that we will list now can be based both on experience, previous research done by you, or by other people. Try to think about how you would answer the asked questions.

If the question is, “How might we encourage students to finish the course once taken successfully?”

In our example, we can answer, for instance:

• Giving certificate after completing the course
• Providing free access to the software and books related to the course
• Offering 1:1 mentoring with the professional after completing the course

With the question and solution combined, you can formulate a hypothesis. This way, you can eliminate assumptions and clearly define the question and answer important from your product and project perspective.

You can formulate it in several ways, but the most common and profound is a format of hypothesis statement proposed in the book Lean UX by Jeff Gothelf and Josh Seiden:

We believe [this statement is true]. We will know we’re [right/wrong] when we see the following feedback from the market: [qualitative feedback] and/or [quantitative feedback] and/or [key performance\nindicator change]. Jeff Gothelf and Josh Seiden

This form shows that the hypothesis has to be testable and the data that constructs it, measurable. But, you can also create a hypothesis that is linked to the features. In this case, you need to collect information as:

- The business outcomes you are trying to achieve - The users you are trying to service - The user outcomes that motivate them - The features you believe might work in this situation Jeff Gothelf and Josh Seiden

Business outcomes

It is a measure of your business success. You have to define what you want to achieve . Is it:

• more visitors to the website?
• more sign ups for the newsletter?
• encouraging people to have discussions with each other?

Create a list of possible outcomes, and check which one has the most prominent result you seek.

You have to remember that you are not an end user. You should not think about yourself as a user to avoid wrong assumptions. Users chosen for the hypothesis should be based on the proto-persona or persona, defined carefully during the brainstorming with the team.

User outcomes

Designers should be a kind of empathetic advocates of the user. In creating hypotheses, they should think about what would be the outcome for the user. They can find out that by asking questions such as:

• What are our users trying to accomplish?
• How do they want to feel during and after this process?
• How can we help them reach their goals?

This is one of the most popular parts of the designer's work, as they often can work directly on solutions and features. It is important to remember that designers should also focus as well on:

• research and investigation of the problem
• who our users are,
• what would be the tangible outcome for us as a company
• what would be the outcome for the users.

We often start with solutions; however, the order should be different. Together with the team, we should analyze what feature would be crucial and help to achieve user outcomes.

By putting together previously collected data and insights, we can start to structure the research hypothesis accordingly to this template:

We believe this [business outcome] will be achieved if [these users] successfully achieve [this user outcome] with [this feature]. Jeff Gothelf and Josh Seiden

In the analyzed context of the online learning platform, we can formulate, for example, this hypothesis statement: We believe this growth in the number of platform class participants will be achieved if students complete the course with the certificate approved by well-known professionals and companies.

3. Testing hypothesis

In UX research, you should test every hypothesis and, this way, validate it or invalidate it. We always should check if the hypothesis statement formulated by us is right or wrong. If you want to test whether your hypothesis is correct, you need to conduct experiments to help you answer this question: "Does what I think is happening actually happen?"

Conduct an experiment to test your hypothesis. Ensure you follow the scientific method by collecting empirical and measurable evidence to obtain new knowledge. Outcomes should be measurable to determine whether your hypothesis has succeeded or failed.

There are many different ways to test your hypothesis. You can both use:

• Quantitative research methods like surveys, usability testing, A/B testing
• Qualitative research methods like in-depth interviews focus groups, ethnographic research, diary accounts

Combining quantitative and qualitative methods can help us get more reliable results and ensure we revise the hypothesis in the best way possible.

Qualitative insight helps us to understand the emotional aspects of product design. It provides the “why” to give context to the quantitative “what” insights provided by analytics tools. It gives us a sense of what’s driving the behavior and provides guidance for design improvements that improve the experience. This makes our customers as well as our business more successful. By balancing qualitative and quantitative insights, we are using data to inform rather than dictate our design decisions. Jeff Gothelf and Josh Seiden

We can also formulate when we assume that the experiment is valid. To do it, we can use other kinds of formats, for instance:

We will run X studies to show more information about students (experience, education, previously finished courses, motivations, needs, frustrations), and ask follow-up questions to identify the students emotions associated with the learning process (difficulties, grit, pleasure, engagement, goals etc.). We will know the hypothesis is valid when we get more than 70% identifying the certificate as an important motivational factor for learning.

The next step is to run appropriate tests with chosen research methods , prepare their scenarios and scopes, set a timeframe, formulate questions, and recruit users.

Once you conduct the test, you should be able to check if your hypothesis was true or false . With this knowledge, you can start to implement checked and validated hypothetical solutions or reject false ones. In both cases, there is always the possibility to formulate new hypotheses that can be tested because the design is a never-ending process.

The hypothesis-driven design process is a user research method that helps product teams focus on the most critical areas of their product. It involves testing a hypothesis about how users interact with a product and then iterating based on the results of that test. The goal is to keep refining the hypothesis until what needs to be done next is clear to ensure your product meets its users' needs.

The hypothesis-driven design process starts with identifying a problem you want to solve. This could be something like:

• "How can we make this website easier for our customers?"
• or "How can we improve engagement on our app?"

Next, you'll need to gather data from users about how they currently do things so that you can compare them with how they would do something if you implemented your solution. After collecting this data, you can test hypotheses about which changes will significantly impact user behavior by creating prototypes and then collecting feedback from users who have tried them out.

After each round of testing, follow up with more interviews and other research methods until you find out what people need from your product or service. This way, you'll know exactly where to focus your efforts in future iterations of development!

There are many benefits of research hypotheses, among others:

• They allow you to make better decisions about the direction of your product because you're basing those decisions on accurate data about people's actual needs and behaviors.
• You can validate or invalidate your assumptions .
• They help you evaluate your designs before implementation.
• They allow you to test features as they're being developed.
• While designing a new product, you can check if the target audience would be interested in it and its proposed features.
• You can reduce risk and increase the certainty you have in assumptions and understanding relative importance.

The value of the research hypothesis is that it provides a framework for user research to follow. It provides direction for what you're looking for and shows you how to interpret your findings.

Usually, we already propose the solution when we see the problem. This works as well in the case of digital products and their users. Based on our experience, we often believe that we know everything about our users. But we are not the end user of the designed product, and often we can be surprised that our solutions don't work and don't respond to other people's needs.

Hypotheses in UX research and hypothesis-driven design process show that it is essential to slow down, hide our assumptions, beliefs, expectations, experience, and ready answers for everything, and conduct deep research into what we, in reality, don't know.

After testing hypotheses, you can build a clear path and see scientifically-proven steps that allow us to achieve our business goals while providing the best user experience that responds to the real needs of our customers.

Gothelf Jeff and Seiden Josh, Lean UX, 2016

Daniel Kahneman, Thinking, Fast and Slow , 2013

Lai Sylvia, 5 steps to a hypothesis-driven design process , 22 Mar 2018

Levitt Debbie, UX Research Without a Hypothesis and for Products That Don’t Exist Yet , April 2015

Hypothesis statement , Uxspot.io

Lenneville Christie, How to write a strong hypothesis , GitLab

Holliday Ben, Everything is hypothesis driven design , Sep 27, 2017

Was it helpful?

What's next?

We work on those topics:

• Bounce rate
• Design sprint
• Competitors analysis
• Customer experience
• ...and more!

Stay in the loop.

Skip navigation

World Leaders in Research-Based User Experience

Problem statements in ux discovery.

August 22, 2021 2021-08-22

• Email article
• Share on LinkedIn
• Share on Twitter

Running discoveries can be challenging. Many teams start discovery research with little direction as to what problem they want to solve. When this happens, discoveries meander and result in dwindling team and stakeholder morale. Worse still, some discoveries begin with investigating solutions, rather than the problems those solutions are intended to solve. (Remember: if you’re investigating only solutions in a discovery, you’re not doing a true discovery! )

To avoid these issues, spend time upfront to identify and frame the problem . If you don’t know the problem, you’re not going to have much luck solving it! The better a problem is articulated, the easier and more effectively it can be solved. One device that help teams to frame a problem is a problem statement.

In This Article:

What’s a problem statement, how to write a problem statement, problem statements don’t need to be negative, how to use problem statements.

Problem statement: A concise description of the problem that needs to be solved.

It’s a helpful scoping device, focusing the team on the problem it needs to explore and subsequently solve. A problem statement makes clear what needs to be done in discovery and what’s out of scope. Problem statements are also great communication tools; well-written ones can be used to gain buy-in from stakeholders on why it’s important to explore and solve the problem.

Here are some examples of problem statements.

• Users of our newspaper app often export content from our app, rather than sharing content through our app. This is a problem because target audiences are less likely to know that the content came from our app, leading to lower conversion rates. This is also a problem for app users, as exporting content is time-consuming and could lead to a decrease in app usage.
• Sales reps spend a long time planning which leads to visit each month. Because planning is done manually — using Excel spreadsheets and printed paper lists — sales reps find it difficult to meet their targets. Many have complained that keeping track of which leads to visit takes away from the time they can spend with them. This is a problem because, when targets are not met, the business risks losing revenue.
• Each year, many applicants call the contact center seeking an update on their application. Applicants often spend a long time waiting to speak to an agent. Because contact-center staff members lack access to case information, they are unable to answer queries from applicants. This situation causes frustration for both applicants and customer-contact staff and represents an avoidable cost to the department.

It's a good idea to write a problem statement as early as possible in your discovery, as it can help set discovery goals and objectives. Many teams will compose their problem statement in a discovery kick-off workshop.

A problem statement should include:

• The background of a problem. Which organization or department has the problem and what is the problem? Why has the problem arisen? Note that in some cases you may not know the exact causes of the problem. This is what discoveries are for: to uncover root causes. (In this case, you may add this aspect once you’ve done your research)
• The people affected by the problem. There could be multiple user groups affected by a specific problem in different ways. In the problem statement, you should call out how the problem affects users. In some cases, internal employees (particularly customer-support staff) can be affected by a problem, as they often bear the brunt of poor user experiences –- for example, by handling disgruntled customers.
• The impact of the problem on the organization. If the problem is not fixed, what will be the effect on the organization? Reputational damage? Paying unavoidable costs? Losing out-of-market share? In some cases, you may want to quantify the impact in order to convince your organization to fix the problem. Your discovery could involve working out how much this problem costs the organization, and this information could end up in your problem statement.

To gather the relevant facts for your problem statement, you can use a simple technique called the 5 Ws , which involves answering the questions below. This activity can be included in a discovery kick - off workshop with your team and stakeholders.

• Who is affected by the problem?
• What is the problem?
• Where does this problem occur?
• When does the problem occur?
• Why does the problem occur? Why is the problem important?

If you don’t have all the answers to the above, don’t panic! While you should know what the problem is, you may not know exactly why it came about. This is what your discovery should tackle. Throughout the discovery process, you can return to your problem statement and add to it.

It’s important that problem statements are written well to serve their purpose. A problem statement should :

• Not be a laundry list of unrelated problems . A discovery effort should have one problem statement, and the problem statement should be focused on one problem. Of course, a single problem could cause further problems, and those related problems can be added to your problem statement. But listing many unrelated problems is a sign that you’re tackling too much.
• Not contain a solution . Leave solutions out of your problem statement. At the beginning of discovery, there are too many unknowns, so the the best solution is not obvious. At the end of your discovery, you’ll be in a good position to confidently put forward solution ideas that address the problem and take into account what you’ve learned.
• Be brief . Problem statements are effective when they’re concise. If you can condense your problem statement down to a few sentences, others will quickly understand what you focus on and why, and what’s out of scope. Spend some time to draft and redraft the problem statement with your team.

The examples I’ve given so far are negative — talking about something that needs fixing. However, problem statements can also capture opportunities (in which case they are sometimes referred to as opportunity statements instead of problem statements, although they are written and used in the same way).

Here’s an example of a problem statement that highlights an opportunity, rather than a problem that needs to be fixed:

The process of purchasing a newly built home can take a long time and requires many offline activities. This means sales often take a long time to close. There’s an opportunity to make home buying quicker and easier, and thus improve customer-satisfaction ratings and sales.

In an opportunity statement, we need to highlight the gap between where we are now (the present state) and where we want to be in the future (the desired state). A good question to ask to highlight this gap is: What do we want to achieve?

Your problem statement can be used as the starting point for structuring your discovery work. For example, if the problem statement was about improving the home-buying process, the goal for the discovery should be to learn about opportunities to make home buying quicker and easier. Once we have a discovery goal, it becomes easier to know what unknowns need research. For example, in this case, we probably want to know things like:

• Which activities do homebuyers perceive as difficult or time-consuming?
• Which activities or use cases can slow down the home-buying process and why?
• What does the end-to-end journey currently look like?

As you begin discovery, you can return to your problem statement and refine it — particularly if you’ve learned root causes or how much a problem costs your organization. Another reason to update your problem statement is if the discovery changes direction — which can happen when new areas of interest are highlighted through exploratory research. Finally, at the end of the discovery process, the problem statement can be communicated alongside your findings and recommendations to provide the full narrative of the discovery process.

A problem statement is a concise description of the problem to be solved. Writing problem statements at the beginning of the discovery process can create alignment and buy-in around the problem to be solved and provide direction in subsequent discovery activities. To construct problem statements, focus on who the problem affects, how it does so, and why it’s important to solve the problem.

Related Courses

Discovery: building the right thing.

Conduct successful discovery phases to ensure you build the best solution

Effective Ideation Techniques for UX Design

Creative solutions for any UX design challenge

Interaction

Personas: Turn User Data Into User-Centered Design

Create, maintain, and utilize personas throughout the UX design process

Related Topics

• Design Process Design Process

Learn More:

MVP: Why It Isn't Always Release 1

Sara Paul · 4 min

Discovery Kick Off Workshops

Maria Rosala · 4 min

Stop Solutioneering (UX Slogan # 18)

Maria Rosala · 3 min

Related Articles:

How Well Discovery Phases Are Performed in UX Projects

Maria Rosala · 9 min

Discovery: Definition

Maria Rosala · 8 min

Using “How Might We” Questions to Ideate on the Right Problems

Design Thinking: Study Guide

Kate Moran and Megan Brown · 4 min

Three Levels of Pain Points in Customer Experience

Sarah Gibbons · 6 min

Discovery in Agile

Anna Kaley · 7 min

Jeff Gothelf

Your cart is currently empty!

The Hypothesis Prioritization Canvas

(Want to get this article in your inbox? I publish one article a month and share it in my newsletter first. You can sign up here and join 40k other subscribers .)

Over the past 10 years we’ve been lucky to have a tremendous amount of content, practice and experience shared to help us build and design better products, services and businesses.  One of the core concepts being adopted broadly from this body of work is the hypothesis — a tactical, testable statement used to help us frame our ideas in a way that encourages experimentation, learning and discovery. The idea is that we write our ideas, not as requirements, but as our best guesses for how to deliver value and with clear success criteria to tell us whether our idea was valuable and we delivered it in a compelling way.

While there are many templates, the one I’ve been teaching for the past few years looks like this:

We believe [this outcome] will be achieved if [these users] attain [a benefit] with [this solution/feature/idea].

I like this template because the act of filling it out is the first test of the hypothesis. If you and your team can’t complete this template in a way that you believe that’s a good indication you shouldn’t be working on that idea. But, assuming you’ve come up with some good ideas, you end up creating a new challenge for the team.

So many hypotheses, so little (discovery) time

If you only have one hypothesis to test it’s clear where to spend the time you have to do discovery work . If you have many hypotheses, how do you decide where your precious discovery hours should be spent? Which hypotheses should be tested? Which ones should be de-prioritised or just thrown away? To help answer this question I’ve put together the Hypothesis Prioritisation Canvas. This relatively simple tool and a companion to the Lean UX Canvas can help facilitate an objective conversation with your team and stakeholders to determine which hypotheses will get your attention and which won’t. Let’s take a closer look at the canvas.

When should we use this canvas?

If you’re familiar with the Lean UX Canvas, the Hypothesis Prioritisation Canvas (HPC) comes into play between Box 6 (writing hypotheses) and Box 7 (choosing the most important thing to learn next). If you’re not familiar with it, the HPC comes into play once you’ve assembled a backlog of hypotheses. You’ve identified an opportunity or problem to solve, declared your assumptions and have come up with ideas to capitalise on the opportunity or solve the problem.

What kinds of hypotheses work with this canvas?

The HPC is designed to work with any hypothesis you come up with. It can work with tactical, feature-level hypotheses as well as business model hypotheses and everything in between.

How do we use the canvas?

The canvas is a simple matrix. The horizontal axis measures your assessment of the risk of each hypothesis. This is a team activity and is the collective best guess of the people assembled of how risky this idea is to the system, product, service or business.  The challenge with assessing risk is that every hypothesis is different. Because of this, your risk assessment will be contextual to the hypothesis you’re considering. For example, you may have to integrate modern technology with a legacy back end system. In this case the risk is technical. You may be reimagining how consumers shop in your store which is risky to your customer’s experience. Maybe you’re considering moving into an adjacent market after years focusing on a different target audience. The risk here is market viability and sustainability. Every hypothesis needs to be considered individually.

The vertical axis measures perceived value. The key word here is “perceived.” Because this is a hypothesis, a guess, the value we imagine our ideas will have is exactly that, imagined. It won’t be until a scalable, sustainable version of the idea launches that we’ll know whether it lives up to our expectations. At this point we can only guess the impact the idea will have on our business if we design and implement it well.

We take each hypothesis we’ve created to solve a specific business problem and map it onto the HPC’s matrix. Once we’ve completed this process, we assess where each hypothesis landed.

Box 1 — Test

Any hypothesis that falls into this box is one we should test. Based on what we know right now this is a hypothesis with the chance of having significant impact on our business. However, if we get it wrong it also stands the chance of doing damage to our brand, our budget or our market opportunity. Our discovery time is always precious. These are the hypotheses that deserve that time, attention, experimentation and learning.

Box 2 — Ship & Measure

High value, low risk hypotheses don’t require discovery work. These are ideas that have a high level of confidence and, based on our experience and expertise, stand a good chance of impacting the business in a positive way. We build these ideas. However, we don’t just set and forget these solutions. We ship them and then measure their performance. We want to ensure they live up to our expectations.

Box 3 — Don’t test. Usually don’t build.

This is, perhaps, the least clear quadrant because there are ideas that may fall here that have value despite the “low value” indication on the matrix. To be clear, hypotheses in Box 3 don’t get tested. In most cases they don’t get built either however there will be times where ideas land in this box that we need to build a successful business but that won’t differentiate us in the market. For example, if you’re going to do any kind of commerce online you’ll need a payment system. In most cases, how you collect payment is not going to differentiate you in the market. These types of ideas often end up in Box 3. They’re table stakes. We have to have them to operate but they won’t make us successful on their own. In these cases we build them, ensure they work well for our customers but don’t do extensive discovery on them prior to launch.

Box 4 — Discard

Hypotheses that we deem to have low value and high risk are thrown away. Not only do we not do discovery on them, we don’t build them either. These are ideas that came up in our brainstorm that we’ve not realised won’t add the value we’re seeking.

Ultimately the value of the HPC will be realised if and how your team uses it. Take it out for a spin. It’s intended to be a team activity. Let me know how it works for you, where it can be improved and whether you find it useful or not.

I’m excited to hear your feedback.

P.S. — Lots of new events posted on the Events page now. Join me in person in 2020.

Jeff Gothelf’s books provide transformative insights, guiding readers to navigate the dynamic realms of user experience, agile methodologies, and personal career strategies.

Who Does What By How Much?

Sense and Respond

Lean vs. Agile vs. Design Thinking

Forever Employable

One response to “The Hypothesis Prioritization Canvas”

This is really helpful (as always) – thank you.

I wonder if there would be any merit in adding a line to the end of you hypothesis template along the lines of.. “because [of this evidence and scientific theory]

This grounds the hypothesis in existing evidence and established social scientific theory. It might also help avoid the potential pitfall that I’ve seem some business fall in to i.e. assuming that clients are rational actors driven by clear interests, when it might be more helpful to think of them as complex emotional people driven by instincts.

Hypothesis Testing in the User Experience

It’s something we all have completed and if you have kids might see each year at the school science fair.

• Does an expensive baseball travel farther than a cheaper one?
• Which melts an ice block quicker, salt water or tap water?
• Does changing the amount of vinegar affect the color when dying Easter eggs?

While the science project might be relegated to the halls of elementary schools or your fading childhood memory, it provides an important lesson for improving the user experience.

The science project provides us with a template for designing a better user experience. Form a clear hypothesis, identify metrics, and collect data to see if there is evidence to refute or confirm it. Hypothesis testing is at the heart of modern statistical thinking and a core part of the Lean methodology .

Instead of approaching design decisions with pure instinct and arguments in conference rooms, form a testable statement, invite users, define metrics, collect data and draw a conclusion.

• Does requiring the user to double enter an email result result in more valid email addresses?
• Will labels on the top of form fields or the left of form fields reduce the time to complete the form?
• Does requiring the last four digits of your Social Security Number improve application rates over asking for a full SSN?
• Do users have more trust in the website if we include the McAfee security symbol or the Verisign symbol ?
• Do more users make purchases if the checkout button is blue or red?
• Does a single long form generate higher form submissions than the division of the form on three smaller pages?
• Will users find items faster using mega menu navigation or standard drop-down navigation?
• Does the number of monthly invoices a small business sends affect which payment solution they prefer?
• Do mobile users prefer to download an app to shop for furniture or use the website?

Each of the above questions is both testable and represents real examples. It’s best to have as specific a hypothesis as possible and isolate the variable of interest. Many of these hypotheses can be tested with a simple A/B test , unmoderated usability test , survey or some combination of them all .

Even before you collect any data, there is an immediate benefit gained from forming hypotheses. It forces you and your team to think through the assumptions in your designs and business decisions. For example, many registration systems require users to enter their email address twice. If an email address is wrong, in many cases a company has no communication with a prospective customer.

Requiring two email fields would presumably reduce the number of mistyped email addresses. But just like legislation can have unintended consequences, so do rules in the user interface. Do users just copy and paste their email thus negating the double fields? If you then disable the pasting of email addresses into the field, does this lead to more form abandonment and less overall customers?

With a clear hypothesis to test, the next step involves identifying metrics that help quantify the experience . Like most tests, you can use a simple binary metric (yes/no, pass/fail, convert/didn’t convert). For example, you could collect how many users registered using the double email vs. the single email form, how many submitted using the last four numbers of their SSN vs. the full SSN, and how many found an item with the mega menu vs. the standard menu.

Binary metrics are simple, but they usually can’t fully describe the experience. This is why we routinely collect multiple metrics, both performance and attitudinal. You can measure the time it takes users to submit alternate versions of the forms, or the time it takes to find items using different menus. Rating scales and forced ranking questions are good ways of measuring preferences for downloading apps or choosing a payment solution.

With a clear research hypothesis and some appropriate metrics, the next steps involve collecting data from the right users and analyzing the data statistically to test the hypothesis. Technically we rework our research hypothesis into what’s called the Null Hypothesis, then look for evidence against the Null Hypothesis, usually in the form of the p-value . This is of course a much larger topic we cover in Quantifying the User Experience .

While the process of subjecting data to statistical analysis intimidates many designers and researchers (recalling those school memories again), remember that the hardest and most important part is working with a good testable hypothesis. It takes practice to convert fuzzy business questions into testable hypotheses. Once you’ve got that down, the rest is mechanics that we can help with.

You might also be interested in

UX Design: Hypothesis Statements (Define stage)

Home › Forums › UI / UX › UX Design: Hypothesis Statements (Define stage)

• This topic is empty.
• Creator Topic

In UX (User Experience) design , hypothesis statements are used to articulate assumptions about user behavior or the impact of design changes. These statements help guide the design process and provide a basis for testing and validation. A UX design hypothesis statement typically follows a structured format and includes the following components:

• User Segment/Persona: Identify the specific group of users or personas for whom the hypothesis is relevant. For example, “For first-time users of a mobile banking app…”
• Behavior or Problem Statement: Clearly state the behavior or problem you are addressing. This sets the context for the hypothesis. For example, “…who struggle to understand the process of transferring money between accounts.”
• Design Change or Solution: Present the proposed design change or solution that you believe will address the identified behavior or problem. This could be a new feature, a redesigned interface, or a modification to an existing element. For example, “…introducing a step-by-step tutorial with interactive guidance.”
• Expected Outcome: Clearly articulate the expected positive impact of the design change on user behavior or problem resolution. This should be measurable and specific. For example, “We expect that users will successfully complete the money transfer process 20% faster with the tutorial in place.”
• Timeframe for Validation: Specify the timeframe or conditions under which you plan to validate the hypothesis. This could be based on a specific period, user feedback milestones, or other relevant criteria. For example, “We will validate this hypothesis through A/B testing over a four-week period.”

Here’s an example of a complete UX design hypothesis statement:

“For first-time users of a mobile banking app who struggle to understand the process of transferring money between accounts, introducing a step-by-step tutorial with interactive guidance will lead to a 20% faster completion of the money transfer process. We will validate this hypothesis through A/B testing over a four-week period.”

By clearly defining these elements, UX designers can set a framework for testing their assumptions, learning from user feedback, and iteratively improving the user experience. It’s important to note that hypotheses should be revisited and revised based on real-world data and user insights.

• Guides Design Decisions: Hypothesis statements provide a clear framework for making design decisions by articulating specific user needs, problems, and proposed solutions.
• Measurable Outcomes: By including an expected outcome in the hypothesis, designers can create measurable success criteria, making it easier to assess the effectiveness of the proposed design change.
• Testable Assumptions: Hypotheses provide a basis for testing assumptions through methods like usability testing, A/B testing, or other user research techniques, helping to validate or invalidate design choices.
• Focuses on Users: UX design hypotheses center around user behaviors and experiences, ensuring that design decisions are driven by a user-centric approach.
• Iterative Improvement: The hypothesis-driven approach encourages an iterative design process where designers can learn from user feedback, refine their assumptions, and continuously improve the user experience.
• Uncertain Predictions: Predicting user behavior and the impact of design changes can be challenging, and there’s a risk that the hypothesis may not accurately reflect user reactions in the real world.
• Limited Scope: Hypotheses may not capture the full complexity of user experiences or account for all possible variables influencing user behavior.
• Resource Intensive: Testing hypotheses, especially through methods like A/B testing, can require significant resources in terms of time, personnel, and technology.
• Biased Assumptions: Designers might unintentionally introduce biases into their hypotheses based on their own perspectives and assumptions about users, leading to inaccurate predictions.
• Inflexibility: Rigid adherence to a hypothesis can be problematic if it discourages designers from adapting to unforeseen insights or changes in user needs during the design process.
• You must be logged in to reply to this topic.

5 rules for creating a good research hypothesis

UserTesting

A hypothesis is a proposed explanation made on the basis of limited evidence. It is the starting point for further investigation of something that peaks your curiosity.

A good hypothesis is critical to creating a measurable study with successful outcomes. Without one, you’re stumbling through the fog and merely guessing which direction to travel in. It’s an especially critical step in  A/B and Multivariate  testing. 

Every user research study needs clear goals and objectives, and a hypothesis is essential for this to happen. Writing a good hypothesis looks like this:

1: Problem : Think about the problem you’re trying to solve and what you know about it.

2: Question : Consider which questions you want to answer. 

3: Hypothesis : Write your research hypothesis.

4: Goal : State one or two SMART goals for your project (specific, measurable, achievable, relevant, time-bound).

5: Objective : Draft a measurable objective that aligns directly with each goal.

In this article, we will focus on writing your hypothesis.

Five rules for a good hypothesis

1: A hypothesis is your best guess about what will happen. A good hypothesis says, "this change will result in this outcome. The "change" meaning a variation of an element. For example manipulating the label, color, text, etc. The "outcome" is the measure of success or the metric—such as click-through rate, conversion, etc.

2: Your hypothesis may be wrong—just learn from it. The initial hypothesis might be quite bold, such as “Variation B will result in 40% conversion over variation A”. If the conversion uptick is only 35% then your hypothesis is false. But you can still learn from it. 

3: It must be specific. Explicitly stating values are important. Be bold, but not unrealistic. You must believe that what you suggest is indeed possible. When possible, be specific and assign numeric values to your predictions.

4: It must be measurable. The hypothesis must lead to concrete success metrics for the key measure. If you choose to evaluate click through, then measure clicks. If looking for conversion, then measure conversion, even if on a subsequent page. If measuring both, state in the study design which is more important, click through or conversion.

5: It should be repeatable. With a good hypothesis you should be able to run multiple different experiments that test different variants. And when retesting these variants, you should get the same results. If you find that your results are inconsistent, then revaluate prior versions and try a different direction. 

How to structure your hypothesis

Any good hypothesis has two key parts, the variant and the result. 

First, state which variant will be affected. Only state one (A, B ,or C) or the recipe if multivariate (A & B). Be sure that you’ve recorded each version of variant testing in your documentation for clarity. Also, ensure to include detailed descriptions of flows or processes for the purpose of re-testing.

Next,   state the expected outcome. “Variant B will result in a 40% higher rate of course completion.” After the hypothesis, be sure to specifically document the metric that will measure the result - in this case, completion. Leave no ambiguity in your metric. 

Remember, always use a "control" when testing. The control is a factor that will not change during testing. It will be used as a benchmark to compare the results of the variants. The control is generally the current design in use. 

A good hypothesis begins with data. Whether the data is from web analytics, user research, competitive analyses, or your gut, a hypothesis should start with data you want to better understand.

It should make sense, be easy to read without ambiguity, and be based on reality rather than pie-in-the-sky thinking or simply shooting for a company KPI or objectives and key results (OKR). 

The data that results from a hypothesis is incremental and yields small insights to be built over time. 

Hypothesis example

Imagine you are an eccomerce website trying to better understand your customer's journey. Based on data and insights gathered, you noticed that many website visitors are struggling to locate the checkout button at the end of their journey. You find that 30% of visitors abandon the site with items still in the cart. 

You are trying to understand whether changing the checkout icon on your site will increase checkout completion. 

The shopping bag icon is variant A, the shopping cart icon is variant B, and the checkmark is the control (the current icon you are using on your website). 

Hypothesis: The shopping cart icon (variant B) will increase checkout completion by 15%. 

After exposing users to 3 different versions of the site, with the 3 different checkout icons. The data shows... 

• 55% of visitors shown the checkmark (control), completed their checkout. 
• 70% of visitors shown the shopping bag icon (variant A), completed their checkout. 
• 73% of visitors shown the shopping cart icon (variant B), completed their checkout.

The results shows evidence that a change in the icon led to an increase in checkout completion. Now we can take these insights further with statistical testing to see if these differences are statistically significant . Variant B was greater than our control by 18%, but is that difference significant enough to completely abandon the checkmark? Variant A and B both showed an increase, but which is better between the two? This is the beginning of optimizing our site for a seamless customer journey.

Quick tips for creating a good hypothesis

• Keep it short—just one clear sentence
• State the variant you believe will “win”  (include screenshots in your doc background)
• State the metric that will define your winner  (a download, purchase, sign-up … )
• Avoid adding  attitudinal  metrics with words like  “because”  or  “since”  
• Always use a control to measure against your variant

Get started with experience research

Everything you need to know to effectively plan, conduct, and analyze remote experience research.

In this Article

Get started now

About the author(s)

With UserTesting’s on-demand platform, you uncover ‘the why’ behind customer interactions. In just a few hours, you can capture the critical human insights you need to confidently deliver what your customers want and expect.

Related Blog Posts

Continuous discovery: all your questions answered

5 tips for retailers preparing for the 2024 holiday shopping season

How and why you should test your product description pages

Human understanding. Human experiences.

Get the latest news on events, research, and product launches

Oh no! We're unable to display this form.

Please check that you’re not running an adblocker and if you are please whitelist usertesting.com.

If you’re still having problems please drop us an email .

By submitting the form, I agree to the Privacy Policy and Terms of Use .