Most research advice quietly assumes a researcher, a panel and a month.

If you are four people shipping every week, you need something smaller: enough signal to stop an argument, cheap enough to run again next sprint.

This stack is that. Roughly one week, start to finish.

1. Mobbin — find out what is already normal

Before testing your idea, learn what your users have been trained to expect everywhere else.

Half of what looks like a usability problem is just an unfamiliar pattern. Checking the convention first stops you testing something you should simply have matched.

2. Typeform — recruit and screen

You need the right handful of people, not a crowd.

A short screener sorts the people who have the problem from the people being polite. Five of the right people will tell you more than fifty of the wrong ones, and this is the step that decides which you get.

3. Maze — test the prototype before you build it

Maze runs unmoderated tasks against a prototype, so you find out whether people can complete the job while it is still cheap to change.

Watch completion and hesitation, not opinions. What people say about a design and what they manage to do with it are different data, and only one of them predicts anything.

4. Lyssna — settle the small arguments fast

First-click tests, preference tests and five-second tests take an hour and end the debates that otherwise eat a standup every day.

Which of these two headlines is understood? Where do people click first to find billing? These are answerable questions, and answering them is cheaper than continuing to have opinions about them.

5. Sprig — ask inside the product

The most useful answers come from people in the middle of the task, not from people remembering it later.

A one-question in-product survey at the right moment beats a long survey emailed on Thursday. Ask right after the behaviour you care about.

6. Hotjar — watch what actually happened

Session replays and heatmaps are where you find the problems nobody reported.

People rarely file a complaint about a form field they gave up on. They just leave. Replays show you the leaving.

7. Figma — synthesis, where the value actually appears

Research that stays in seven tools is not research, it is tabs.

Pull the clips, quotes and numbers onto one board, cluster them, and write the three findings you would defend. A page someone can disagree with is the output. Everything before this was collection.

The one-week shape

  • Monday: convention check and screener out
  • Tuesday–Wednesday: unmoderated tasks and quick preference tests
  • Thursday: replays, plus an in-product question if it is live
  • Friday: synthesis and three findings

Run it again next month. A small study you repeat beats a large one you do once.

How many users do I need for a usability test?
Five to eight is enough to find most severe usability problems in a single flow. Larger numbers are for measuring, not finding — if you want a comparable score over time, plan for more, but do not let sample size stop you starting.
What is the difference between Maze and Lyssna?
Maze runs task-based tests against a prototype to see whether people can complete a job. Lyssna is faster and narrower — first-click, preference and five-second tests that settle a specific question in about an hour.
Do I still need session replay if I run tests?
Yes. Tests tell you what happens when someone is asked to do a task. Replays tell you what happens when nobody asked them to, which is where the problems nobody reports show up.
Can a team without researchers do this?
Yes, if you keep the scope to one flow and one question per round. The failure mode for small teams is not bad method, it is collecting more than they will ever have time to synthesise.