Skip to main content

User Testing with Real Enterprise Users

Enterprise users are not consumer users. They are time-poor, sceptical, and have workflows they will not change easily.
15 May 2019·7 min read
Rainui Teihotua
Rainui Teihotua
Chief Creative Officer
Consumer user testing has a body of established practice. Recruit participants, give them tasks, observe, iterate. But enterprise users are a different population entirely. They're specialists, often using software eight hours a day, with deep muscle memory for their current tools and very little patience for something that slows them down. Testing with them requires a different approach than what most UX resources describe.

What You Need to Know

  • Enterprise users have established workflows and will resist changes that disrupt them, even improvements
  • Recruit through the client organisation, not through testing platforms. You need the actual people, not proxies
  • Test with real tasks and real data. Artificial scenarios produce artificial results
  • Respect their time aggressively. Sessions over 45 minutes get diminishing returns with busy professionals

Enterprise Users Are Different

They're Experts in Their Domain

Consumer testing often involves people encountering a product for the first time. Enterprise testing involves people who've been doing this job for years. They know their domain deeply. They have opinions about how things should work based on extensive experience. They'll tell you immediately when something doesn't fit their workflow, and they'll be right.
This expertise is an asset, not an obstacle. Enterprise users will spot problems faster and with more precision than consumer test participants. They'll also suggest solutions, though those solutions sometimes optimise for their individual workflow rather than the broader user base.

They're Sceptical

Most enterprise users have experienced at least one failed system implementation. They've been told "the new system will be better" before, and it wasn't. That history creates a baseline scepticism that you need to acknowledge rather than try to overcome.
Enterprise users don't resist change because they're afraid of technology. The burden of proof is on us.
Rainui Teihotua
Chief Creative Officer

They're Time-Poor

A consumer test participant has volunteered their time. An enterprise user has been asked to take time away from their actual job. They're thinking about the work piling up while they're in your session. Respect that. Be efficient. Get to the point.

Recruiting Participants

Work Through the Client

Don't try to recruit enterprise users independently. Work with your client to identify and schedule participants. The client knows who the power users are, who the sceptics are, and who represents the range of workflows you need to cover.
Ask for a range: the most experienced user, the least experienced, someone who loves the current system, someone who hates it. This diversity is more valuable than volume. Six well-chosen participants will reveal more than twenty randomly selected ones.

Include Reluctant Users

The people who volunteer for testing are often the most engaged, tech-forward users. They're not representative. The users who will struggle most with the new system are the ones who didn't volunteer. Ask the client to include at least one or two people who are hesitant about the change.

Running the Session

1. Acknowledge Their Expertise

Start by acknowledging that they know their job better than you do. You're not there to teach them how to work. You're there to understand their work well enough to build something that supports it. This framing changes the dynamic from "evaluation" to "collaboration."

2. Use Real Tasks

"Imagine you need to submit a report" is a consumer testing prompt. "Walk me through how you'd process the Henderson claim using this interface" is an enterprise testing prompt. Use real tasks with real data wherever possible. Anonymise sensitive information, but keep the structure and complexity intact.
Artificial tasks produce artificial behaviour. When an enterprise user processes a real claim through the prototype, they engage their actual decision-making process. They notice missing fields, unexpected data flows, and workflow gaps that artificial tasks would never surface.

3. Watch for Workarounds

Enterprise users have built workarounds for every gap in their current system. When testing, watch for moments where they instinctively reach for a workaround. "Normally I'd check the spreadsheet for this" or "I usually have this open in another tab." These moments reveal gaps in your design that the user might not articulate directly.

4. Keep Sessions Under 45 Minutes

Thirty minutes of focused testing is more valuable than 90 minutes where the participant's attention drifts. Have a clear agenda. Three to four key tasks. Time for open-ended feedback at the end. Thank them and let them get back to work.

5. Test the Transition, Not Just the Product

Enterprise users don't evaluate a new system in isolation. They evaluate it relative to their current workflow. The question isn't "can they use the new system?" It's "will they choose the new system over their current process?"
Test the transition explicitly. "Your current process involves these five steps. The new system changes steps two and four. Walk through it and tell me whether this is faster, slower, or about the same."

Interpreting Results

Separate Resistance from Insight

Some negative feedback reflects genuine usability issues. Some reflects resistance to change. Learning to distinguish between them is the hardest part of enterprise user testing.
A useful heuristic: if the user can articulate why something doesn't work for their task, it's insight. If the reaction is "I just prefer how it works now," it's resistance. Both are valid, but they require different responses. Insight drives design changes. Resistance drives change management.

Look for Patterns, Not Outliers

One user who struggles with a feature might reflect individual preference. Three users who struggle with the same feature reflect a design problem. Enterprise testing with small samples means you need to weight patterns heavily and individual reactions lightly.

Report Back to the Client

Enterprise test participants are employees of your client. They've invested time and opinions. Report the findings back to the client organisation, including what you changed as a result. This closes the loop and builds trust for future testing rounds.
The best enterprise user test I ever ran lasted 25 minutes - the user identified workflow shortcuts that saved nearly two hours a day.
Rainui Teihotua
Chief Creative Officer