What are we looking at?
“Assumption” and “hypothesis” look alike, so why does analysis go wrong if we mix them up?
A common mistake
One of the common mistakes of analysts is mixing up assumptions and hypotheses. They look similar, but their role and place in analysis are very different.
An assumption is something we take as true without checking it at that stage; that is, “we have to carry the analysis forward on this basis unless the opposite is shown.” Assumptions are the basis of design and decision; they may be right or wrong, but at the start we lean on them. For example, “users have fast internet”, “the government supports this project”, or “all staff have access to a smartphone”. If they later turn out to be wrong, the whole system may run into trouble.
A hypothesis is a testable claim that we want to confirm or reject with data, an experiment or analysis. A hypothesis is a tool for prediction and learning, and it can be both proved and refuted. For example, “if the send button is designed more simply, the error rate falls”, “students aged 18 to 22 are more inclined to use the app”, or “sending messages by bot raises user satisfaction”.
| Feature | Assumption | Hypothesis |
|---|---|---|
| Kind | An accepted claim | A testable claim |
| Checking | Not checked (until later, if ever) | Checked |
| Role in analysis | Basis of decision and design | Basis of learning and correction |
| Risk | If wrong, produces wrong decisions | If rejected, the path of analysis is corrected |
Why does this distinction matter?
When gathering requirements, an analyst constantly hears remarks from users, managers and stakeholders. Some should be put into the analysis as assumptions, and some should be turned into hypotheses and checked. A manager says, “People don’t use the mobile version at all.” The analyst should ask: is this an assumption we must respect in the design? Or a hypothesis that should be checked with data mining?
How to work with each
With assumptions: write them down, list them in the requirements-analysis documents, and check throughout the project whether they are still valid or need correcting.
With hypotheses: turn them into a testable question, reject or prove them with data, interviews, tests or analysis, and use the result to improve the system.
I think separating these two is a mark of professional thinking: with assumptions we build the foundations of analysis, and with hypotheses we discover and correct the course.