Academic research and design research are not the same thing
A while ago, someone asked whether we had ethics approval for some research as part of a project I was design lead on. It's a good question to ask inside a university. It's also the moment I realised we were using one word for two different types of activities, and that most of the friction I was feeling came from that.
Both activities are called research. Both involve talking to people, gathering evidence and drawing conclusions. Both can be done well or badly. But they are built to answer different questions, they treat error differently, and they run on different clocks. Confusing them causes problems in both directions.
They answer different questions
Academic research asks: is this true, and how confident can we be?
Design research asks: what should we do next, and what would make us wrong?
That's how I’d like to frame things and everything else can follow on from there.
The unit of value in academic research is the finding. It has to survive scrutiny from people who weren't in the room, be independent of who collected it, and hold up when someone tries to reproduce it. Its worth increases with generalisability.
The unit of value in design research is the decision. It's consumed at the point of use. A beautifully evidenced insight that changes nothing is a failed piece of design research, no matter how well conducted. Conversely, six conversations that stop a team building the wrong thing have done their job completely, and there is no journal that will ever care.
They sample for different reasons
This is where design research gets accused of being sloppy, and where it most often deserves it.
Design research samples for range, not for representativeness. You are trying to find the shape of a problem: the edges, the failure modes, the situations nobody accounted for. Eight interviews will reliably tell you what breaks. They will not tell you how often it breaks, or for whom, or whether the pattern holds up across a population. If you want that, you need a different method and a bigger study.
The discipline isn't in the sample size. It's in being honest about what the sample can carry. "We spoke to eight people and three of them couldn't get past the first screen" is a legitimate finding. "75% of users struggle with onboarding" is not, and putting it in a funding bid is how design research loses its credibility.
They treat being wrong differently
Academic research is organised around minimising the chance of asserting something false. That's what significance testing, peer review and pre-registration are for. Being wrong in public is the failure state.
Design research is organised around minimising the cost of being wrong. A prototype is a cheap way to be wrong. A pilot is a moderately expensive way to be wrong. A national rollout is a very expensive way to be wrong. The craft is in sequencing your mistakes so the cheap ones happen first.
They run on different clocks
In the research we did setting up the design studio, we found roughly a factor-of-forty difference between the two: six to twelve months for ethics approval on an academic study, against about nine days for a full round of design iteration. Neither number is wrong. They are both about right for what they're doing. A study that will be cited for a decade should take a year to set up. A screen flow that will be replaced next fortnight should not.
The problem is when one timescale is applied to the other's work. Ethics processes were not built to govern a Tuesday afternoon workshop, and design sprints were not built to establish clinical safety.
A rough comparison
| Academic research | Design research | |
|---|---|---|
| Core question | Is this true? | What should we do? |
| Output | A finding | A decision |
| Sampling logic | Representativeness | Range and variation |
| Validity test | Reproducibility | Does it survive contact with the build? |
| Failure state | Asserting something false | Changing nothing |
| Typical cycle | Months to years | Days to weeks |
| Audience | Peers, commissioners, regulators | The team, this week |
How it goes wrong
Design research borrowing academic authority. Small-sample qualitative work gets converted into percentages, or a workshop gets described as a study. In health this matters more than elsewhere, because a claim that shapes clinical behaviour needs an evidential base that design research structurally cannot provide. You can design your way to something worth testing. You cannot design your way to proof.
Academic method applied to a decision that needed making the same week. This is the one people in innovation programmes complain about, sometimes fairly. If every piece of user contact has to go through a full approval cycle, nothing gets built, and the ideas that would have been improved by contact with reality never get it. Founders describe this as the missing middle: plenty of research capability, plenty of investment, and very little in between that moves at the speed of a product or service.
Treating ethics as the obstacle rather than the question. This is the failure I'd most want to avoid, and it's the one design people fall into most easily. Research ethics processes exist for extremely good reasons, and the fact that they're slow doesn't make them optional. The honest position is that there are different governance routes for different activities. If you intend to generate generalisable knowledge about people, you go through research ethics. If you're improving a service with the people who use it, service evaluation and information governance are usually the right route. The mistake isn't picking one, it's pretending the question doesn't apply to you because you called yourself a designer.
Where they meet
What I’ve learnt is that health tech is a place where you can't only pick one, which is what makes it interesting to work in.
Design research gets you to something worth testing: a problem that's actually a problem, a proposition that people recognise, a service that fits into how the day already works. Academic research tells you whether it does what you claim. Regulators, commissioners and the NICE evidence standards will want the second, and they will not accept the first as a substitute.
The useful thing to do is to stop treating these as sequential stages owned by different people. Build the evidence question into the design work from the start: what would count as proof here, who needs to be convinced, what would we have to collect, and when. That's not academic rigour bolted onto a design process. It's a design decision about what you're going to be able to say later. Get it wrong at the start and you have a product that works and no way to demonstrate it, which is a fairly reliable way to end up among the large majority of health apps that fall short of evidence or regulatory expectations.
A rule of thumb
When someone says they need research, I've started asking two questions: who has to believe this, and what will they do once they do?
If the answer is "the team, this week, so we can decide what to prototype", that's design research. Do it quickly, sample for range, be clear about the limits.
If the answer is "a commissioner, a regulator or a reviewer, so they can approve something", that's academic research, and it needs the time, the method and the approvals that come with it.
If it's both, and in health it usually is, then you need a plan for both. Design research first is almost always the cheaper order.
Design research is not academic research with the rigour taken out. It's a different craft with its own discipline: sampling deliberately, being explicit about what would change your mind, showing your working, and knowing exactly what your evidence can and can't carry. Working in a university civic innovation programme, the job isn't to pick a side. It's to be clear about which one you're doing, and to stop borrowing the other's authority when it happens to suit.
