A Designer’s Scientific Method

Ask questions. Hypothesize. Test. Analyze. Iterate.

Science is people. People use the process of science to make an observation, come up with a hypothesis of why it happens, then try it, and compare it to what you thought was going to happen. That process has changed the world.
— Bill Nye

In technology, a product designer is responsible for how users experience a given product. We spend most of our days in the mindset of a user, thinking through their problems, and designing solutions.

The scientific method starts with a question — “why is the sky blue?” From that question a hypothesis is developed — “because… molecules” — then predictions are made and tested. From those tests, an analysis is given as to whether or not their hypothesis holds true. In a designer’s process we ask many questions, define a problem, propose a variety of solutions, test them, and assess how well they’ve solved the problem.

I recently thought about this comparison and asked myself what it might look like to insert a product designer’s process into the stages of the scientific method.

The Scientific Method

1. Formulate a Question

At the beginning of a project, a designer’s job is to get through the clutter of issues and boil things down to: “what problem are we solving?” This is an important step for a designer because it helps guide them through the rest of the project. An example might be, “why aren’t our users growing?” Which is a great question to ask for a company focused on growth. This is a difficult question to answer, however, because there are so many reasons this particular issue could be happening. The key is to define a question that can have a tangible solution. A more direct question to approach might be something like, “Why are user’s dropping off in our signup flow?”

2. Develop a Hypothesis

Once an addressable question is in front of us, we need to get an understanding of why this problem might be occurring. This can involve discussions with other members of the team or be more data-driven sources like analytics, surveys, or user interviews. The ultimate goal is to define a problem that can be proven true or false.

Under modern interpretations, a scientific hypothesis must be falsifiable… otherwise, the hypothesis cannot be meaningfully tested. – WP

In many cases this might mean getting some numbers to help support the problem at hand. Using the question we created above, we might create a statement like, “30% of users drop off at ___ step in the funnel and we believe this is happening because they’re confused about ___.” In this example an indicator of success would be seeing the 30% drop off go down after testing the proposed solution.

3. Make a Prediction

It is in this stage that a designer gets all the ideas out of their head — depending on their personal preference, this can be in the form of white boarding, sketches on paper, user flow diagrams, or wireframes.

Our process at Shyp is to start with an ideation/sketching session which gets all our ideas down as quickly as possible. We then discuss our various ideas, throw away the bad ones, and narrow them down to one or two solutions.

It is the designer’s responsibility to get the designs to a point where they are ready to be tested. This can mean designing wireframes, visual designs, or interactive prototypes and in some cases it means building out the full feature with the engineering team so it can be tested in the wild.

4. Test

Using the designs we created, it’s time to validate our assumptions. In many cases this involves doing usability tests and looking at responses to a prototype. However, when a larger sample size of data is necessary it is usually better to build out the feature and see how it affects your numbers in the wild.

5. Analyze

Now that testing is complete, what are the results? If the product was shipped, have the numbers changed? In our problem statement above, the designer would be looking to see if that 30% number has increased or decreased. Seeing a decrease in that number would be an indication of success.

6. Iterate

After looking at the analysis, did the hypothesis hold true? If not, it’s time to iterate on your hypothesis.

Many design teams are in a constant state of iteration — “in pursuit of perfection” as we might put it — there are always new features to be added, new objectives to achieve, or new user personas to address. There is almost never a single correct solution to a problem but there can be infinite incorrect solutions. A designer’s process is about looking at many solutions, throwing out the bad, and boiling them down to the good.


Thanks to Kurt Varner for helping me edit.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.