Every project carries a mix of knowns, assumptions and unknowns, and confusing one for another is where research plans go wrong. Knowns are facts the team can point to evidence for, such as data already collected or a policy already confirmed. Assumptions are beliefs the team is treating as true without having tested them, often inherited from past projects or strong opinions in the room. Unknowns are the genuine gaps, the things nobody in the team can currently answer with confidence. Justo (2019) frames this as a knowns-and-unknowns matrix, useful because it forces a team to say out loud which box each belief sits in, rather than letting assumptions quietly pass as facts.
Evidence gaps sit at the boundary between what a team knows and what it still needs to learn. Finding them starts with an honest audit: list every claim being made about users, the service or the problem, then check what evidence actually supports each one. A claim backed by recent, relevant data is a known. A claim resting on a hunch, an old study or a senior stakeholder’s opinion is an assumption, and the gap between that assumption and solid evidence is exactly what research needs to close. GOV.UK’s service manual advises teams to turn unfounded assumptions and opinions into research questions, so the gap becomes something a study can actually answer (GOV.UK, n.d.).
Once gaps are named, they need translating into two related but distinct things: research objectives and research questions. A research objective is a statement of intent, what the study sets out to achieve, for example ‘to understand why users abandon the application partway through’. A research question is the specific enquiry that objective is broken down into, phrased so it can actually be answered, for example, ‘at which step do users abandon the application, and what do they say caused it?’ Purvis, Nicholas and Tai (2024) note that a good research question is neither too broad nor too narrow, and clearly names the thing under investigation; Phair and Shaeffer (2022) describe objectives as the steps that turn a broad aim into something specific enough to design a study around, with questions then following directly from those objectives.
The most common mistake is jumping to solutions before the questions are settled, planning research to validate an idea the team already favours rather than to test it honestly. Reichelt (2015), writing about discovery research at the Government Digital Service, put it plainly: ‘If you set out to validate, you won’t learn what you don’t know. What you don’t know is the thing that will ultimately make your project fail.’ Related mistakes include writing a question so broad it cannot guide a method, such as ‘do users like the service?’, and skipping straight to a method, such as ‘let’s run a survey’, before anyone has agreed what the survey needs to find out.
Holliday (2019) shows how service teams can frame this work as testable hypotheses, using a simple structure: state what you think is true, explain why you think it matters or what opportunity it creates, then say who you can learn more from and how. Written this way, each assumption becomes a question the research can actually settle, and the team can prioritise which hypotheses to test first based on how much the project depends on them being right, an approach Bland and Osterwalder (2019) calls testing the riskiest assumptions before the safer ones. In both cases, the discipline of naming what is known, assumed and unknown before designing a study is what keeps research effort pointed at decisions that matter, rather than confirming what the team believed all along.
Action Point
Take a live or recent service challenge. List every claim being made about users or the problem, and sort each one as known, assumed or unknown. For the three biggest gaps, write one research objective and one research question for each, checking that the question is specific enough to actually be answered before you choose a method.