B2B SaaS Usability Testing: What the Recruiting Data Says

A researcher on Dscout’s People Nerds blog, Nikki Anderson-Stanier, wrote up a B2B recruiting effort she ran with cold outreach. Two weeks of work, seven participants needed for a single usability test, three booked. “In those two weeks, we managed to recruit three people. THREE.” That number sets the ceiling for what most teams call B2B SaaS usability testing today.

The problem is not that the participants do not exist. It is that finding them, scheduling them, and getting useful sessions out of them takes longer than the sprint that produced the design.

Why generic panels return noise for B2B products

A developer tool needs developers. A procurement workflow needs procurement professionals. A data platform needs analysts who already know what a dimension table looks like. When a generic panel participant runs through a B2B flow without that vocabulary, they reach the right outcome by chance or fail for reasons that have nothing to do with how a real user would think about the screen.

One Capterra reviewer described general-panel sessions as feeling “hurried or low-effort.” That is the polite version. The harder version is that two weeks of recruiting and a quarterly chunk of the research budget can return data that points the next sprint in a misleading direction.

The recruiting gap is widening

Demand for research is climbing while qualified B2B participants stay scarce.

The Maze Future of User Research 2026 report shows that organizations embedding research in all business decisions tripled from 8% to 22% in a single year. Teams are expected to validate more decisions, more often. The supply of senior B2B operators willing to do unmoderated panel sessions has not moved the same way.

The User Interviews 2025 Research Budget Report puts numbers on what that means in practice: 29% of research teams operate on under $25,000 a year, before incentives, recruiter fees, or rerun costs when a study returns weak signal. A two-week cycle that yields three sessions in the wrong domain is not a small loss. It is most of the quarter.

What teams actually do when recruiting stalls

When the panel runs cold, two things happen. Some teams skip B2B SaaS usability testing for the iteration and ship on assumptions. Other teams keep the study on the calendar but lower the bar on participants, which gives the meeting a research shape without the research signal.

Both routes show up later as support tickets, as redesigns after dev work is already spent, and as the kind of CS escalation that starts with “users keep getting stuck on the new flow.” The cost is not one usability test. It is the next three sprints.

Where AI personas fit

Tessary runs AI personas against a Figma prototype or a live URL in a real browser. You configure a persona by role, expertise, and the context the user would actually bring (a procurement lead reviewing a renewal, a data analyst connecting a new warehouse, an IT admin auditing an integration), and the persona navigates the flow and returns structured findings with screenshots and step traces.

The point is not that an AI persona replaces every human session. For lived experience, sensitive workflows, or compliance-grade research, schedule the human study. For the iteration-loop question (does this flow make sense to someone who looks like our user), the persona answers in minutes instead of two weeks. That changes which sprints get a validation step and which do not.

For prototype-stage validation specifically, see the Figma prototype usability testing guide.

What B2B SaaS usability testing looks like at sprint cadence

A small team running this with a persona usually does it in one afternoon:

1. Paste the prototype or staging URL.
2. Configure the persona with role, seniority, and the context they would bring (industry, prior tools, motivation).
3. Write one task in user language: “Submit a budget approval request and confirm it routed correctly.” Not “evaluate the approval flow.”
4. Read the findings: where the persona hesitated, what label or empty state caused a pause, where it tried the wrong path first.

The findings will not be every truth about your product. They will be enough to decide what to fix before the design merges, which is the decision the recruiting cycle was blocking.

We do not yet know how often persona findings disagree with what a moderated session would have found. We have seen they catch the kind of structural friction that shows up in support tickets a month later. That is the directional answer most sprint reviews need.

Try Tessary

Paste a Figma prototype or live URL, configure a persona that matches your actual user, and read the findings the same afternoon. Free to start, no credit card.

Try Tessary