Can You Do UX Research Without Access to Real Users?

“We cannot reach users” rarely means there is no evidence at all. It usually means the team lacks a convenient, stable, and compliant recruiting channel. Alternative evidence can reduce risk, but teams must label what comes from real behavior, what was relayed by frontline staff, and what remains an internal assumption.

“We cannot reach users” rarely means there is no evidence at all. It usually means the team lacks a convenient, stable, and compliant recruiting channel. Alternative evidence can reduce risk, but teams must label what comes from real behavior, what was relayed by frontline staff, and what remains an internal assumption.

01 Set a Boundary: Substitute Evidence Is Not User Evidence

Without real-user participation, teams can still analyze documents, map processes, conduct expert reviews, and run low-risk validation. They cannot call coworkers' opinions “user needs” or present generated content as completed interviews.

More honest statements include:

• “Support tickets show that this issue recurred during the past three months”;
• “Sales believes buyers care most about permissions, but we have not validated this with buyers”;
• “Competitor reviews suggest a hypothesis that requires confirmation in the next round of real-user research.”

This distinction does not weaken research. It tells decision-makers exactly what risk they are accepting.

02 Build an Evidence Ladder

The lower the evidence level, the more cautious the conclusion must be. Level E evidence can tell a team what deserves investigation, but should not determine a high-risk feature.

03 Find the User Traces You Already Have

Many companies claim they have no research channel while already holding substantial user traces:

• Search queries and searches that return no results;
• Support chats, ticket categories, and escalation records;
• Questions raised during sales demos, reasons for lost deals, and procurement checklists;
• Product funnels, repeated clicks, undo actions, exports, and failure logs;
• Implementation training records, help-center searches, and common configuration errors;
• Refunds, cancellations, contract changes, and complaints.

These sources cannot explain every cause, but they can narrow “users dislike it” to “new administrators often stop on the permission-settings page after importing members.” With a specific lead, even a small number of later user sessions can focus on the right problem.

04 Ask Frontline Staff for Facts, Not Answers on Behalf of Users

Support, sales, and implementation consultants matter because they repeatedly encounter user problems. The interview style, however, must change.

Ask less often, “What feature do customers want most?”

Ask instead:

• When did a customer most recently get stuck on this;
• What was the customer trying to accomplish;
• What exact words did the customer use;
• What did the frontline employee do;
• Does the issue recur, and among which customers;
• What records, screenshots, or tickets can we review.

Frontline staff provide events and patterns, not final substitutes for users. Sales requests may be influenced by closing pressure, while support primarily sees people after problems occur. Document those source biases in the analysis.

05 Six Practical Alternative Paths

Create a Small Window Through Existing Customer Relationships

You do not need a large research community at the start. Ask customer success or account managers to invite a few different roles each month, clarify that the session is not a sales meeting, and limit it to 30–45 minutes. Stabilize the channel before expanding the sample.

Observe Training, Implementation, and Support

B2B products are especially suitable for observing real configuration, import, permission, and handoff work. With consent, researchers can sit in on training or remote support and note where users pause, repeat questions, or create their own spreadsheets.

Use Adjacent Users to Validate Lower-Level Questions

If actual approvers cannot participate, administrative or finance staff familiar with similar work can validate terminology, information structure, and basic workflows. When organizational politics, compliance responsibility, or real decision pressure matters, adjacent users cannot replace the target role.

Run a Cognitive Walkthrough With Internal Experts

Domain experts can identify missing rules, product and design teams can conduct heuristic reviews, and engineers can check technical boundaries. This removes obvious issues early, but it is expert evidence—not proof of user usability.

Extract Language and Scenarios From Public Material

Industry forums, app-store reviews, help centers, procurement documents, and regulatory material can reveal common terminology and risks. Do not turn them into precise prevalence estimates or assume posters represent all users.

Begin With a Low-Risk Pilot

If complete research is impossible, do not launch to everyone. Select a cooperative customer group, one business unit, or a noncritical workflow. Establish feedback and rollback mechanisms, then use real usage to close evidence gaps.

06 Which Decisions Can Proceed, and Which Need Real Users?

07 A Two-Week Research Recovery Plan

Days 1–3: Organize Existing Evidence

Collect product data plus support and sales records. Ask frontline teams to explain problems through specific events. Produce a problem map, not a feature wish list.

Days 4–6: Create Recruiting Entry Points

Define concise screening criteria and have customer success, sales, or community teams invite different roles. Prepare confidentiality, incentives, and scheduling at the same time to reduce participation cost.

Week 2: Combine a Small Amount of Real Research With Triangulation

Run three to five high-quality sessions first, focusing on the riskiest issues in the evidence map. After every session, cross-check findings against data, tickets, or field records, then decide whether to recruit more of a particular user type.

Even a small amount of real evidence can correct how the team interprets substitute sources.

08 Three Things Not to Do

Treat Employees as Target Users

Employees can test flows and find defects, but they know the product language, business goals, and organizational context. They do not represent a first-time customer.

Use “Synthetic Users” Instead of Interviews

Generative tools can help organize questions and simulate hypotheses, but they cannot provide lived experience, organizational constraints, or unexpected behavior. Use them to prepare research, never as user evidence.

Let Context-Free Competitor Reviews Determine Features

Public reviews often overrepresent extreme experiences and omit version, region, and user type. Use them to find possible problems, not to estimate demand directly.

09 Write Conclusions Honestly and Usefully

Organize findings into three columns:

• Observed facts: from real behavior or verifiable records;
• Strong inferences: supported by multiple sources but not yet confirmed with target users;
• Hypotheses to validate: mainly from experts, competitors, or one channel.

Also record what happens if each assumption is wrong. Test low-cost decisions incrementally; prioritize recruiting for decisions with expensive consequences.

Frequently Asked Questions

What if B2B customers do not want to join research?

Reduce participation cost and risk: keep sessions short, define the topic, avoid trade secrets, allow anonymity, and have the account manager explain the purpose. Keep research separate from training, business reviews, and renewal conversations so users do not mistake it for sales.

Can we interview only sales and support?

They can build an initial problem map, but cannot provide final validation. Sales, support, and implementation see buying, failure, and deployment respectively. Cross-checking all three reduces bias, but still pursue at least a few target users.

When must design pause until recruiting is solved?

Pause critical decisions involving security, privacy, money, permissions, healthcare, compliance, or large development investment when the team has no real behavioral evidence. The more polished an unsupported solution becomes, the more expensive the rework.

10 Put Research and Design Into Product Decisions