Teams that skip research almost never do so because they think it is worthless. They skip it because the smallest unit available to them is a three-week project, and nothing that size fits inside a two-week sprint with four other things in it. So research becomes something that happens before a big redesign, once every eighteen months, and the hundred smaller decisions in between get made on instinct.
The fix is not more conviction. It is a smaller unit. Most of the questions a team actually faces can be answered in between one and four hours, using evidence that in several cases is already sitting in systems you pay for. What follows is ten techniques sized that way, with what each one can and cannot tell you.
The short version
- Shrink the unit, not the ambition. Four hours answers more questions than you would expect.
- Four of the ten techniques use evidence you already own and need no participant recruitment at all.
- Five participants find most usability problems in a single flow. The sixth rarely changes the decision.
- Attach research to conversations that are already happening — sales calls, support tickets, onboarding.
- One hour a week beats a quarterly project, because the findings arrive while decisions are still open.
- If writing the report is the expensive part, stop writing reports. Three lines in a shared channel is a finding.
Why it actually does not happen
Worth being precise about the obstacles, because each has a different workaround.
Scheduling, not effort. Four hours of work spread over a fortnight is easy. Four hours that must be booked, defended and sequenced is hard. Most research that gets dropped was dropped at the calendar, not at the budget.
Access to users. In B2B especially, the people who use the product are shielded by an account manager who does not want them bothered. This is real and it is the reason four of the ten techniques below deliberately need no participants.
The report tax. Teams associate research with a deliverable, so a one-hour study acquires three hours of write-up and stops being worth doing. The write-up is a convention, not a requirement.
Fear of inconclusive results. Nobody wants to spend a day and report “it was mixed”. But a small study that comes back ambiguous has still told you the decision is genuinely uncertain, which is useful and is not failure.
Research gets dropped at the calendar, not at the budget. Four hours is cheap. Four hours that must be scheduled and defended is expensive.
The ten techniques
Sorted roughly by how little they cost. The last column is the one to read first — every technique here has a real boundary, and most bad research decisions come from using a cheap method to answer a question it cannot reach.
| Technique | Time | Answers | Cannot answer |
|---|---|---|---|
| 1. The five-minute corridor test | 5 min | Whether a label, icon or screen is comprehensible to someone who has not been staring at it for a week | Whether anyone wants the thing. Your colleague is not your user. |
| 2. Support ticket mining | 1–2 hrs | Where the product confuses people, in their own words, at volume — already collected and already paid for | Anything about people who struggled silently and never wrote in. |
| 3. Search log reading | 1 hr | What people cannot find, and what vocabulary they use for it rather than yours | Why they wanted it, or what they did when the search failed. |
| 4. Session replay triage | 1–2 hrs | Where people hesitate, loop, rage-click or abandon within one specific flow | Intent. You see the behaviour and have to guess at the reason. |
| 5. The sales objection log | 1 hr | Why deals are lost and what buyers compare you against — research someone else has already done | Anything about daily users, who are not the people in that conversation. |
| 6. The assumption audit | 45 min | Which of your team’s beliefs are load-bearing and unevidenced, ranked by what it costs to be wrong | The answers. It tells you what to go and find out. |
| 7. The one-question intercept | 2 hrs to set up | One specific thing, asked in-product at the moment of the behaviour, at reasonable volume | Anything requiring follow-up. You get one question and no second chance. |
| 8. The call rider | 5 min per call | Real user context, by adding two research questions to calls that are already in the diary | Depth, and anything the account manager would rather you did not ask. |
| 9. Unmoderated task test | 3–4 hrs | Whether people can complete a specific task, where they fail, and roughly how often — runs overnight | Why they failed, beyond what they narrate. No probing possible. |
| 10. The demand test | 2–4 hrs | Whether anyone wants a thing, measured as behaviour, before you build it | Whether they would pay, keep using it, or like the version you actually build. |
Four that are consistently underused
Support ticket mining
One to two hours · no participants neededExport the last three months of tickets, filter to the area you are working on, and read a hundred of them with a tally sheet. Group by the thing the person was trying to do, not by the label support assigned. Within an hour you will have a ranked list of confusions in customers’ own language, including the vocabulary they use for your features — which is frequently not the vocabulary on the buttons.
This is the highest-return hour available to most teams, and it is skipped because it does not feel like research. It is also the one to run before any interview study, because it tells you what to ask about.
Boundary: a survivorship bias runs through the whole dataset. Everyone in it cared enough to write in. The larger group who gave up quietly is invisible here, and they are usually the more important group.The assumption audit
Forty-five minutes · the team, a timer, one boardEveryone writes down what the current plan assumes to be true — silently, eight minutes, one assumption per note. Then plot each on two axes: how confident are we, and how expensive is it to be wrong. The top-right quadrant is your research backlog, in priority order, and it was produced in under an hour.
What makes this worth the time is not the list. It is that it converts “we should do some research” into three specific questions with a stated cost of being wrong attached, which is the form that survives a planning meeting.
Boundary: it surfaces only the assumptions people can articulate. The dangerous ones are usually so embedded that nobody writes them down — which is why running it with one outsider in the room is worth the awkwardness.The one-question intercept
Two hours to set up · runs by itselfOne question, asked in the product, at the exact moment of the behaviour you care about. On the empty state: what were you hoping to find here? After the third use of a feature: what nearly stopped you using this? At cancellation: one optional free-text box, which is the single most informative field most SaaS products never read.
The power is in the timing rather than the question. Asked a week later in an email survey, the same question gets a reconstructed memory. Asked in the moment, it gets the actual reason, in the person’s own words, at a volume no interview schedule could reach.
Boundary: one question only, with no ability to probe. And every intercept is an interruption, so running several at once degrades both the data and the experience.The call rider
Five minutes per call · no recruitment at allYour company already holds dozens of calls a week with customers — sales demos, onboarding sessions, quarterly reviews, support escalations. Ask to sit in on two, and request five minutes at the end for two questions. No recruitment, no incentives, no scheduling overhead, because the meeting was happening anyway.
Keep the questions behavioural rather than speculative. “Walk me through the last time you did this” beats “would you use a feature that…” every time, and takes the same five minutes.
Boundary: the sample is whoever agreed to a call, which skews heavily toward engaged customers and away from the people quietly disengaging. Pair it with something that reaches the silent group.What can you learn by Friday?
Set the hours you can realistically protect, what you need to know, and whether you can reach users at all. The last input changes the answer most.
This week’s research
Three inputs, one technique you could start this afternoon.
How much time can you actually protect?
What do you need to know?
Can you reach actual users?
Three inputs, one technique
Pick your available time, the question you have, and whether users are reachable.
How to run it
—
What it will not tell you
—
0 of 3 chosen
Making it a habit rather than an event
One hour, same slot, every week. Not a research day, not a research sprint. A recurring hour that belongs to whatever question is currently most expensive to be wrong about. The compounding effect is the point: fifty hours a year arriving while decisions are still open beats three concentrated weeks arriving after they have closed.
Keep a question queue in the open. One shared list of unanswered questions, each with a line on what it costs to be wrong. When the hour comes round you take the top item rather than spending twenty minutes deciding. It also means anyone on the team can add to it, which is how research stops being one person’s responsibility.
Rotate who runs it. An engineer who has watched five people fail at the flow they built argues differently in planning afterwards. That change in the room is often worth more than the finding itself, and it is the main reason not to let a single researcher absorb all of this work.
Book the next one before you finish this one. Mundane and effective. Research habits die in the gap between sessions, not during them.
Reporting, without the report
If the write-up costs more than the study, the study stops happening. For work at this scale, three lines in the channel where the decision is being made is a complete and sufficient output:
What we did — five people, the checkout flow, unmoderated, Tuesday. What we saw — four of five missed the delivery options step entirely and were surprised by the total. What it means for the decision — the options need to sit before the summary, not after; we think this is most of the abandonment but it does not explain the drop-off at payment.
Include the uncertainty explicitly, as in that last clause. Small studies have real limits, and stating them is what makes the next small study credible. Keep the raw material — clips, tickets, notes — somewhere findable, and let people go to it if they want to argue.
One habit worth adopting whatever else you take from this: when a finding changes a decision, write that down too. A short running log of “we were going to do X, we saw Y, we did Z instead” is the only evidence that research is earning its hour — and it is what you will need the first time someone asks whether the weekly slot is still worth protecting.
Where this goes wrong
| Failure | Looks like | Prevention |
|---|---|---|
| Cheap method, wrong question | A corridor test used to decide whether to build something | Read the “cannot answer” column before choosing. |
| Colleagues as participants | Five internal testers who already know the product | Internal testing checks comprehension of wording, nothing more. |
| Leading the witness | “Would you use a feature that…” answered politely and uselessly | Ask about the last time they did the thing, not about the future. |
| Over-reading five people | A percentage quoted from a sample of five | Small samples find problems; they do not size them. |
| Findings with no decision attached | A channel full of observations nobody acted on | End every study with what it changes, or state that it changed nothing. |
| The report tax returning | A one-hour study with a three-hour deck | Three lines. Keep the raw material findable instead. |
| Only hearing the engaged | Tickets and calls, never the silent majority | Pair owned-data methods with something that reaches non-complainers. |
| The slot quietly disappearing | Research hour cancelled three weeks running for delivery | Keep the decisions-changed log and show it when the slot is questioned. |
Where to start this week
Run the assumption audit on Monday — forty-five minutes, the whole team, and you leave with a ranked list of what is most expensive to be wrong about. Then spend one hour reading support tickets for whichever area came out on top. By Wednesday you will know more about that part of your product than you did after the last three planning meetings, and you will not have booked a single participant or spent anything.
If that works, put the hour in the calendar as a recurring slot and keep the queue. The whole argument of this piece is that the unit is the obstacle, and the only way to prove it is to run one small thing and notice that the sky stayed up.
How we work at Adi Design. We start client engagements by reading what already exists — tickets, search logs, lost-deal notes — before recruiting anyone, and we run research as a weekly hour rather than a phase. If your team keeps meaning to do research and never finds the fortnight for it, get in touch.
