How to Write a Usability Testing Persona for B2B SaaS
The first finding in most B2B usability tests is that the persona was wrong. The participant clicked through the flow, said something polite, and produced feedback that read like a website critique. What the team has at the end is video, transcripts, and nothing to ship against. The test ran fine. The persona did not match the user.
A usability testing persona is the part of the setup that decides whether the session returns signal or noise, and on B2B products it is the part most teams underspecify. The Maze Future of User Research 2026 report puts 39% of PMs running their own research without a dedicated researcher, which means the persona is now usually written by the same person writing the task, often in five minutes. Five minutes of persona work on a B2B flow is what produces sessions that say nothing useful.
This post is about the fields that change that, and what a complete persona looks like once they are filled in.
What a B2B persona has to do that a consumer persona does not
A consumer testing persona can be thin and still work. “Marketing professional, late 30s, comfortable with software” is enough context for a checkout flow because the flow assumes only general literacy. A B2B flow assumes vocabulary. A procurement workflow assumes the user knows what an approval hierarchy is. A data tool assumes the user has seen a dimension table. A developer integration assumes the user can read a webhook payload without flinching.
When a generic panel participant runs a B2B task without that vocabulary, they reach the right outcome by accident or fail for reasons that have nothing to do with how the actual user would think about the screen. UXtweak’s analysis of UserTesting reviews picks up on this directly: reviewers describe panel participants giving feedback that “feels hurried” and reads like website critique rather than user behavior. The fix is not a new platform. It is a persona that carries the domain context the flow assumes.
The six fields a usability testing persona needs
Most consumer persona templates use two or three fields. A B2B testing persona needs six.
| Field | What to write |
|---|---|
| Role and scope | Specific title, team size, what they actually own. Not “IT manager.” |
| Technical fluency | Comfort with configuration, APIs, permission systems, advanced settings. |
| Product familiarity | First-time evaluator, 14-day trial user, or 90-day power user. Different sessions. |
| Task motivation | What triggered this task. A QBR on Monday is different from idle exploration. |
| Known frustrations | One or two things this user type usually finds clunky in similar tools. |
| Patience level | Will they push through ambiguity, or back out at the first unclear label. |
Each field changes where the persona looks, what they skip, and what they accept as good enough. A technically fluent user skips setup docs a less fluent user reads carefully. A user with a Monday deadline behaves differently from a user who is browsing. Without the patience field, every test defaults to an infinitely patient user who eventually figures things out, which is not how anyone uses software at work.
How to fill the fields without inventing them
The fields are useful only if the values come from somewhere real. The four steps below work whether you have a research repo or just a Slack channel of customer notes.
- Start with one real user. Pull from a sales call transcript, a support ticket thread, a recent onboarding session. Generic archetypes produce generic findings.
- Write the motivation first. Finish the sentence “this user is doing this task because ___.” If you cannot, you do not yet have a persona. You have a job title.
- Add the friction layer. Pick one or two things this user type complains about in similar products, taken from real interactions, not invented. A persona without friction tests the best-case path.
- Read the persona and the task together. Would this specific person plausibly do this specific task at this specific time? A head of finance does not navigate billing settings at 9 a.m. without a trigger. If the pairing does not pass that test, fix one or both.
A worked example
A complete persona for a workflow automation product looks like this.
Persona: mid-market RevOps lead.
- Role: head of RevOps, three-person team, 280-person SaaS company.
- Technical fluency: high. Salesforce admin level, comfortable with webhook concepts, has not written production code in two years.
- Product familiarity: 14-day trial, has opened the product three times.
- Task motivation: setting up an automated report for a Monday QBR. Needs it working by end of day Friday.
- Known frustrations: CRM field mapping in previous tools “was always wrong the first time.”
- Patience level: low for ambiguous field labels. Backs out of flows that do not confirm success.
A session run from this profile surfaces specific things: which field labels confuse a fluent user, where confirmation patterns break down, whether a Friday deadline changes how the user reads error states. Compare that to “RevOps user, mid-market,” which surfaces a session full of clicking and a transcript that says “this seems fine.”
The mistakes that show up most often
Three failure patterns produce most of the noise.
Role without scope. “Enterprise customer” is not a persona. Neither is “designer.” The title needs team size, what the user owns, and how they relate to the product in their week.
Familiarity mismatch. Testing a complex admin flow with a brand-new user persona and expecting nuanced findings produces noise. Match the familiarity to the feature’s actual audience.
No motivation. A persona without a trigger produces sessions where the tester evaluates the interface like a critic, not like a user with something to finish. Triggered usage is the entire point of B2B software.
Where this fits in a sprint
Once the persona is written, the rest of the test is short. One task, one URL or prototype, one persona, one run. The User Interviews 2025 Research Budget Report puts 29% of research teams on under $25,000 a year for everything, which is not a budget that supports custom panel recruiting per sprint. A persona-driven run against a Figma prototype or staging URL fits inside the sprint and reuses the same persona across iterations, so the second test on the same flow compares cleanly to the first.
For how this connects to recruiting reality on B2B products specifically, see B2B SaaS usability testing: what the recruiting data says.
Tessary runs AI personas against a Figma prototype or live URL in a real browser, using exactly the six fields above as configuration. The session returns structured findings with screenshots and reasoning traces, and the persona stays consistent if you rerun the test on the next iteration. Free to start, no credit card.
Written by
Tessary · AI Usability Testing
Tessary runs AI personas on prototypes and live URLs to surface usability friction in minutes, not weeks. Editorial posts on AI usability testing, persona design, and B2B SaaS research economics.