Published on | Prototyping: From UX to Front End — Medium Benjamin Berger Photo by Drew Hays on Unsplash

The nature of design is grounded in constraints.
Because we are working to solve user’s problem in a certain business context, we are bound to make compromises.

It took me some time to accept this concept. I was believing in design as finding the one absolute solution. But, as my process matured, I realized that there never is just one good solution to a problem. Each problem can be seen and solved in many ways, depending on what we need to focus on.

Also, I learned that users can be unpredictable. They might use a design in a totally unexpected way. What is common sense for someone is not for the other. So, no matter how much theory I would use to perfect my design, it would always be difficult to affirm its efficiency without testing it in real-world conditions.

To capture all the aspects of a product design challenge and embrace the uncertainty of our work, my previous team and I used to work with hypotheses.
Borrowed from the scientific method, their purpose is to make sure that we phrase our solutions as an assumption to be proven.
They helped us determine the right goals and ensure that our reasoning is utilizing as many evidences as possible to increase our chances of success.
In doing so, we entered an iterative loop where each solution was being tested and analyzed, leading to new and stronger hypotheses.

Graphic by Stewart McCoy

Formulating an hypothesis

When should they appear?

In the scientific method, writing hypotheses is the third step of the process, right after making observations and expressing problematics.
The parallel we can do between the scientific and design process would place all of the user researches under the “observe” phase. It strongly implies that any solutions should come from identified insights rather than raw intuitions and preconceived opinions. Therefore, we should only start to create ideas after gathering enough data.

Graphic by Stewart McCoy

Hypothesis framework

The framework we used to write our hypothesis is composed of three elements:

The proposed solution solving the problem
The design’s goal, that will help define if the solution is a success
The insights, research, data, etc. all evidences that are justifying the reasoning behind the proposed solution

and is using plain english.

Image by Benjamin Berger

Example

Imagine that an application is using a drawer menu navigation. After a series of user & usability tests and data analysis, we have uncovered confusion in the navigation.
Comes the time to find solutions. Here’s what an hypothesis could look like:

We believe that a tab-bar navigation exposing all navigation items
will result in a reduction of lostness and increase in second pages visits
because analytics shows that few users open up the drawer navigation and the user interviewed were not aware of the secondary pages.

While solutions and evidences can be “easy” to figure out, defining the expected result of our solution is another story. Science dictates that we need to be able to measure our result to test an hypothesis. Is it possible to quantify a design?

The definition of success

One of the question I’ve heard the most during my two years working in Atlassian’s design team has been: “How will you define the success of your design?”.
I used to think: “well I’m going to make it great” but never took the time to define what “great” actually means.

One definition of industrial product design, that I find quite relevant to digital product design, explain the following:

“Industrial design is the professional service of creating and developing concepts and specifications that optimize the function, value and appearance of products and systems for the mutual benefit of both user and manufacturer.”

The manufacturer

First of all, we can understand the word “manufacturer” as the “company”. Indeed, to define success, the first intuitive action is to look in the business direction. Product managers and business analysts have always been looking at quantifying the aspects of a company.
So, we could judge the success of a design by its ability to move a business metric in the right direction such as improving a conversion rate, decreasing churn or increasing the amount of active users.

Secondly, we can understand the word “manufacturer” as “the one who build the product”. In our case, engineers are the person coding the production version of a design. This would imply that “great design” must be considerate of the technology being used and the method of implementation.

The user

Unfortunately, business metrics are rarely a good representative of what the users are experiencing. Design dark patterns, for example, can increase a conversion rate to the detriment of the users’ profit.
As explained in the definition above, designers should not forget the importance to build with empathy. They always need to outline the way their solutions will benefit users.

However, quantifying the way users respond to a design is extremely complicated. Some experts would even argue that it is impossible to measure satisfaction because its value is non-linear and always in flux. But, there’s a few techniques we can use to make sure that we take the users’ interests into account when working with hypothesis.

User’s problems
Expressing the user problem we want to solve is a good start. To get to the bottom of a problem, I like to ask “Why” 5 times. This technique helps identify the underlying causes rather than staying on a superficial layer.
We can also reason in terms of “user’s goal” to focus on the true objective of our design.
Usability
Even though they are not directly measuring the user experience, usability tests ensure that a product is functional. According to Aarron Walter’s pyramid of user needs this is the first step towards a delightful design.
Scales like SUS, UMUX or SUPR-Q provide a nice framework to compare and judge multiple solutions.
Design principles
The specifications of design principles early on in the project help lead the design direction on the right tracks. They act as guidelines that we need to follow to stay true to our original intent.

“Will result in …”

I personally believe that no sustainable solution can be crafted when we only focus on moving a number that will benefit our company. From experience, I’ve mainly seen bad analytics being the symptom of a much deeper problem in the user experience.
The formulation of a design hypothesis shouldn’t just focus on which business metrics we want to improve. Even though not scientific, because not measurable, we need to explain which user problem our solution is trying to solve.

Conclusion

When designing, we need to remember that a solution have no value until we have defined what needs to be optimized both for the company and the user. Working with hypotheses help frame our work around a definition of success while grounding our decisions in facts and data.

I personally enjoy using this mindset because it allows me to stay modest in my design propositions. It reminds me that I do not have an absolute knowledge, that good design happens through iterations.

Thanks for reading!

I always like to reflect on my process and put words on the method I use. Hopefully you enjoyed reading this article, if not, let’s discuss!

About me

I’m looking for a new full-time position — Visit my brand new portfolio
Find me on Twitter or Dribbble

Links & sources

in order of appearance

Photo by Drew Hays on Unsplash
Graphic by Stewart McCoy
Graphic by Stewart McCoy
Graphic by Benjamin Berger
Quote attributed to the IDSA, 2009
https://darkpatterns.org/hall-of-shame
https://jtbd.info/the-illusion-of-measuring-what-customers-want-3672a7892eb by Alan Klement
https://blog.prototypr.io/5-ux-plays-to-start-your-design-on-good-tracks-45d00260909e
https://en.wikipedia.org/wiki/5_Whys
https://www.nngroup.com/articles/theory-user-delight/
https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html
https://measuringu.com/umux-lite/
https://measuringu.com/product/suprq/
https://www.interaction-design.org/literature/topics/design-principles

Thinking your design with hypotheses was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thinking your design with hypotheses

Cool stuff, every week

More Articles