How Great Teams Approach Usability Studies

Most teams approach usability studies like a box-ticking exercise. Schedule some sessions, watch users struggle, write a report, file it away. Rinse and repeat.

That’s not how great teams do it.

The misconception is that usability studies are this formal, heavyweight process you do before launch to make sure nothing’s catastrophically broken. Sure, that’s one use case. But the teams shipping the best products treat usability studies as continuous intelligence gathering, not pre-launch insurance.

I learnt this watching a designer at a previous company run what he called “Tuesday tests.” Every Tuesday, without fail, he’d put whatever we were working on in front of three users. Didn’t matter if it was half-finished. Didn’t matter if it looked rough. He wanted to see people use it.

At first, I thought it was excessive. By month three, I realised it was genius. We caught issues when they were easy to fix and validated solutions before we’d invested weeks building them.

The Development Context

Technical Considerations

Usability studies need to fit into your development process, not disrupt it. If they require weeks of prep and perfect prototypes, you won’t do them consistently.

The technical setup matters. You need the right tools, sure. Screen recording software. Video conferencing. Prototype tools. But more importantly, you need infrastructure that makes testing cheap and fast.

This means your prototyping tools should let designers test interactions without writing code. Your test environment should let users interact with real-ish data without seeing production data. Your recording setup should be one-click, not thirty minutes of technical faff.

I’ve seen teams abandon usability testing entirely because their technical setup was too painful. The friction between “let’s test this” and actually testing was so high that it never happened.

Reduce that friction. Make it trivial to spin up a test. Make it easy to record and share results. The lower the activation energy, the more tests you’ll run.

Team Dynamics

Usability studies work best when the whole team participates. Not just watches. Participates.

I’m talking engineers in the room. PMs in the room. Designers obviously in the room. Everyone watching real users struggle with what they’ve built.

There’s something powerful about watching someone completely misunderstand your carefully crafted interface. Reading about it in a report doesn’t have the same impact as seeing the confusion on their face.

The best teams I’ve worked with rotate who facilitates sessions. Not because the designer can’t do it. Because when an engineer facilitates, they ask different questions. When a PM facilitates, they probe different areas. This diversity of perspective makes the insights richer.

But here’s the key: make it safe to fail. If someone runs a session badly, that’s fine. You’ll get better. The worst thing you can do is make usability testing this high-stakes performance where only “qualified” people can facilitate. That kills participation.

Implementation Approach

Best Practices

Let me share what actually works, based on years of running (and screwing up) usability studies.

Test early and often. Not “let’s do a big study before launch.” Test the moment you have anything testable. Sketches. Wireframes. Prototypes. Real features. Test it all.

Keep sessions short. Thirty minutes, max. People’s attention spans are limited. Yours and theirs. You’ll get better insights from three focused thirty-minute sessions than one sprawling ninety-minute session.

Focus on tasks, not opinions. Don’t ask “do you like this?” Ask “can you add a new project?” Then shut up and watch. What people do matters infinitely more than what they say.

Test with the wrong users sometimes. I know, heresy. But watching someone completely outside your target demographic use your product reveals assumptions you didn’t know you were making. Do this occasionally, not always.

Record everything. You’ll think you’ll remember the key moments. You won’t. Record the screen. Record their face if they consent. Take notes during. Review after. You’ll catch things you missed live.

Share insights immediately. Saw something interesting in a session? Post it in Slack right after. Don’t wait for the full analysis. Speed matters more than polish.

Tooling and Process

Your tooling should get out of the way. The process should be repeatable without being bureaucratic.

For remote testing, you need reliable video conferencing (obvs) and screen sharing that doesn’t lag. I’ve had sessions ruined by choppy screen sharing where I couldn’t actually see what users were doing. Test your setup before you test with users.

For prototyping, use whatever lets you move fast. Figma. Framer. HTML prototypes. I don’t care. The tool doesn’t matter. The speed does. If it takes you two days to make a testable prototype, you won’t test.

For recruitment, build a pool of willing participants. Offer them Amazon vouchers or donations to charity. Make it easy to say yes. The hardest part of consistent usability testing isn’t running sessions - it’s finding participants. Solve this once, properly.

Process-wise, I use a simple template:

What are we testing? (Specific tasks or flows)
What do we want to learn? (Specific questions)
Who are we testing with? (Target users)
What’s our script? (Task prompts, not leading questions)
How will we capture insights? (Notes doc everyone can access)

That’s it. Anything more complex creates friction. Anything less creates chaos.

Scaling What Works

Growth Considerations

As your team grows, you can’t have everyone in every session. That’s fine. You need to scale insights, not attendance.

Create a highlight reel. After each round of testing, put together a five-minute video of the key moments. Engineers won’t watch a full hour of sessions. They will watch five minutes of users struggling with their feature.

Build a research repository. Somewhere searchable where insights live. Not fancy. A Notion database works. Tag insights by feature, user type, date. Future you will thank present you.

Rotate attendance. Different people in different sessions. Everyone should watch users at least once a quarter. This keeps the insights fresh and prevents a single person becoming the “voice of the user” bottleneck.

Train facilitators. Don’t make it complicated. Pair new facilitators with experienced ones for a session or two. Let them practice. Give feedback. This scales your capacity without sacrificing quality.

Maintaining Quality

As you do more studies, the temptation is to get sloppy. Don’t.

Keep your recruiting quality high. If you’re testing with anyone willing to take a gift card, your insights will be garbage. Better to do fewer tests with the right people than more tests with random people.

Stay rigorous about what you’re testing. Every session should have clear goals. “Let’s just show them the new thing and see what they think” isn’t a goal. That’s how you get diffuse, useless feedback.

Maintain the feedback loop. If you’re running studies but nothing’s changing based on what you learn, you’re wasting everyone’s time. Track recommendations. Follow up on implementation. Show how testing influenced decisions.

I’ve seen teams run dozens of usability studies to zero effect because nobody actually acted on the insights. That’s worse than not testing at all. It creates the illusion of user-centricity without the reality.

Key Takeaways

Here’s what matters for usability studies that actually drive better products:

Test continuously, not just before launch. Small, frequent studies beat big, infrequent ones.
Lower the friction to testing. Make it easy to run a session. The easier it is, the more you’ll do it.
Get the whole team involved. Different perspectives lead to better insights.
Focus on what users do, not what they say. Task-based testing reveals truth.
Share insights immediately. Speed matters more than perfect documentation.
Build infrastructure for scale. Participant pools, highlight reels, research repositories.
Maintain quality as you scale. Better to do fewer good tests than many bad ones.

Final Thoughts

Usability studies aren’t about proving you’re right. They’re about learning where you’re wrong while it’s still cheap to fix.

Great teams embrace this. They want to see their assumptions challenged. They actively look for evidence that they’ve misunderstood something. Because finding out in testing is infinitely better than finding out in production.

The difference between adequate products and excellent products often comes down to this: did someone watch real users struggle with it and then fix the struggle points? It’s not complicated. It’s just work.

Start small. Pick one feature you’re working on this week. Put it in front of three users. Watch what happens. You’ll learn something. I guarantee it.

And once you’ve experienced the difference between building with user feedback and building without it, you won’t want to go back. Because shipping something you know works feels completely different from shipping something you hope works.

Hope is not a strategy. Testing is.