Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Defining goals, objectives, and hypotheses

How to define goals, objectives, and hypotheses

Conducting user research takes a significant amount of preparation before you even begin asking users anything. However, the time you spend creating alignment and developing a research plan pays off tremendously because it keeps you on track as you carry out your research.

Starting with a good question and the right question will ensure you end up with a useful answer. A good research question is specific, actionable, and practical. That means:

Only after you have identified your research question(s), can you select the best way to answer the question (i.e. which research method to use).

As the figure below shows, there are 5 main steps to creating research hypothesis, goals, and objectives.

5 Main Steps to Creating Research Hypothesis, Goals, and Objectives

Step 1 - Start thinking of a problem

Start thinking of a problem Questions we need answers to Hypothesis Goal Objectives
Let’s imagine that a hotel chain has noticed they have had a lower number of bookings in the last few quarters, but they are unsure why.        

Step 2 - Start populating ‘Questions we need answers to’

Start thinking of a problem Questions we need answers to Hypothesis Goal Objectives
Let’s imagine that a hotel chain has noticed they have had a lower number of bookings in the last few quarters, but they are unsure why. Are people not booking because they don’t like the hotels we have? Do we have issues with the website or app? Are our prices too high? Are we missing hotel amenities that customers are looking for?      

Step 3 - Fill out the hypothesis

Start thinking of a problem Questions we need answers to Hypothesis Goal Objectives
Let’s imagine that a hotel chain has noticed they have had a lower number of bookings in the last few quarters, but they are unsure why. Are people not booking because they don’t like the hotels we have? Do we have issues with the website or app? Are our prices too high? Are we missing hotel amenities that customers are looking for? We believe that by improving the experience of selecting and deciding which of our hotels to stay at for users of our website will result in an increased number of hotel bookings.    

Step 4 - State the goal(s) for the research

Start thinking of a problem Questions we need answers to Hypothesis Goal Objectives
Let’s imagine that a hotel chain has noticed they have had a lower number of bookings in the last few quarters, but they are unsure why. Are people not booking because they don’t like the hotels we have? Do we have issues with the website or app? Are our prices too high? Are we missing hotel amenities that customers are looking for? We believe that by improving the experience of selecting and deciding which of our hotels to stay at for users of our website will result in an increased number of hotel bookings. Understand how people make their travel plans.  

Step 5 - Create research objectives

Start thinking of a problem Questions we need answers to Hypothesis Goal Objectives
Let’s imagine that a hotel chain has noticed they have had a lower number of bookings in the last few quarters, but they are unsure why. Are people not booking because they don’t like the hotels we have? Do we have issues with the website or app? Are our prices too high? Are we missing hotel amenities that customers are looking for? We believe that by improving the experience of selecting and deciding which of our hotels to stay at for users of our website will result in an increased number of hotel bookings. Understand how people make their travel plans. Identify ways people start planning their travel and the tools they use. Understand what elements make it easy for people to plan travel and what elements make it difficult.

The chart below shows the relationship between your research goal and the tasks and questions you will ask your participants in usability tests.

The relationship between your research goal and your tasks and questions

This chart shows the relationship between your research goal and the interview questions you will ask your participants in user interviews.

The relationship between your research goal and your interview questions

As you can see, the more objectives you start out with, the more questions you will need to ask and the longer your research session will be. It's a good rule of thumb to not have the user session last longer than 1 hour. Our typical research sessions at GitLab last 30-45 minutes.

How to write a strong hypothesis

Video transcript

When you hear a customer problem, it can be tempting to just dive right in and devise a solution. However, it’s important to remember there is never just one good solution to a problem. A problem can be solved in many different ways, depending on what we need to focus on.

Users can also be unpredictable, what we think might solve their pain points, may not actually even begin to address the problems they are facing. Therefore, it’s advisable to test your ideas before you start building a solution. A way in which you can do this is to write and test hypotheses.

A hypothesis is basically an assumption. It’s a statement about what you believe to be true today which can be proven or disproven using research.

A strong hypothesis is usually driven by existing evidence. Ask yourself: Why you believe your assumption to be true? Perhaps your hunch was sparked by a passing conversation with a customer, something you read in a support ticket or issue, or even something you spotted in GitLab’s usage data.

There are lots of different structure for hypotheses, but I recommend using this simple statement:

We believe [doing this] for [these people] will achieve [this outcome].

The statement is comprised of three elements.

The first part: We believe [doing this] should detail your proposed solution to users’ problems.

The second part: For [these people] should identify who you are targeting.

The third and final part: will achieve [this outcome] is where you should document your measure of success. What is your expected result?

For example:

We believe storing information about how an incident was resolved, how long it took to resolve and what the outcome was in a historical record for engineers responsible for incident management will achieve a 20% faster resolution time for incidents. This is because referring to past incident information helps to inform potential solutions for remediation.

When writing your hypothesis, focus on simple solutions first and keep the scope small. If you’re struggling to articulate your assumptions about users, it’s probably better to start with developing a better understanding of users first, rather than forming weak hypotheses and running aimless research studies.

A strong hypothesis is easy to test. It shouldn’t take you much time to design a research study to validate or invalidate your hypothesis.

If your hypothesis is invalidated by users, don’t feel disheartened. You’ve stopped precious Engineering time being spent on building a solution that simply doesn’t solve users’ problems. A good measure of being iterative is throwing something away because user research proved that it wasn’t going to work. You’re not always going to get things right the first time. We learn more about user needs as a result of testing multiple hypotheses and, in turn, we generate new ideas for future rounds of testing.