Proxy Research: How to Run User Research When You Can't Talk to Your Users

Can you do user research without access to users?

Yes — but only under strict discipline, and never as a permanent substitute. Proxy research means learning about users from people who are not those users: support agents, solution engineers, domain experts, account managers. Done well, it is a legitimate bridge that keeps a team evidence-led while access is negotiated. Done badly, it manufactures confident, wrong beliefs that are harder to dislodge than ignorance.

The single rule that separates the two: ask proxies about behavior they have personally observed, never about preferences they imagine users hold. A support lead who has handled 400 tickets about an error state is a genuine source of evidence about that error state. The same person guessing whether users would prefer a redesigned dashboard is not evidence at all.

Why teams end up without access

Blocked access is common enough to be a structural condition of the job rather than an excuse. Recruiting remains the dominant operational constraint in the field: User Interviews' State of User Research 2025 found 54% of researchers struggle with time-to-recruit, 62% report difficulty recruiting for specialized studies, and 57% report participant quality concerns. Those numbers describe teams who are allowed to recruit.

Genuine blockers usually fall into five categories:

1. Enterprise gatekeeping. Sales or account management controls the relationship and will not risk a customer conversation, particularly mid-renewal.
2. Regulated or vulnerable populations. Clinical, financial, or child-facing users where access requires approvals that take months.
3. Security and contractual restrictions. Air-gapped environments, classified deployments, or NDAs that forbid direct contact.
4. Pre-launch products. There are no users yet — only a target market.
5. Low-incidence populations. The role you need represents a fraction of a percent of any panel.

Which category you are in determines the right response. Categories 1 and 5 are usually recruiting problems with real solutions. Only 2, 3, and 4 genuinely justify sustained proxy work.

Check first: is the blocker real, or just the calendar?

Before accepting proxy evidence, exhaust the channels that reach real users without requiring a scheduled meeting. Most access complaints are really scheduling complaints — the objection is to an hour of a customer's time on a specific Tuesday, not to research itself.

• In-product intercepts reach real users at the moment of the behavior, with no calendar involved.
• Support and cancellation flows already contain real users who have volunteered a problem.
• Lapsed and churned users are frequently outside the account team's protection and unusually candid.
• Asynchronous interviews remove the scheduling constraint entirely — the participant answers at 11pm on their own time.

This matters because the asymmetry is enormous: a mediocre thirty-minute conversation with one real user typically outperforms three excellent conversations with proxies.

The proxy ladder: ranked by evidence quality

Not all proxies are equivalent. Rank them by how directly the person has observed real user behavior.

Nielsen Norman Group is direct on the bottom of this ladder: colleagues and stakeholders are not representative of your audience, and employees hold unusually strong views because of their relationship with the organization. Bloomberg's UX team, writing on when proxies are defensible, notes that asking proxies to imagine a scenario produces invalid results — while support and technical sales staff genuinely did help surface pre-launch issues when treated as observers.

The pattern in both: proxies are useful as witnesses, useless as stand-ins.

How to interview a proxy correctly

The interview technique for proxies is different from a user interview, because the failure mode is different. With users you fight memory and social desirability. With proxies you fight generalization — the smooth, confident summary that averages away every specific.

Use the critical incident technique. Never ask "what do users struggle with?" Ask:

• "Walk me through the last three times a customer hit this. What happened first?"
• "What exact words did they use in the ticket?"
• "What did they try before contacting you?"
• "Tell me about one where you were surprised by what they did."

Anchoring to specific, recent, countable incidents converts a proxy's opinion into observational data. Then apply the correction: for every claim, ask yourself which users this person never meets. Support hears from complainers; success managers hear from champions. Neither hears from the silent majority who simply left.

Separate the three claim types. In your notes, tag every statement as observed (they saw it), reported (a user told them), or inferred (they are theorizing). Only the first two are evidence. In most proxy transcripts, the third category is the largest — and it is the category most likely to end up in a slide deck as a user need.

What proxies can never give you

Be explicit in every readout about the ceiling of this evidence:

• Preferences and desirability. No proxy can tell you whether a user would want something.
• Emotional response and trust. Second-hand emotion is anecdote.
• Anything about the silent majority. Proxies systematically over-represent the vocal ends of the distribution.
• Willingness to pay. Account managers guess this constantly and are reliably wrong.

Label proxy-derived findings as such in the repository, with the tier attached and an explicit expiry date. Proxy insight should be treated as a loan against future real-user research, not as a permanent asset.

The modern approach: make real access cheap enough that proxies become rare

Most proxy research is not a methodological choice. It is a cost workaround — the traditional research pipeline (screen, schedule, moderate, transcribe, code) is expensive enough that teams substitute the nearest available human. Change the cost and the substitution stops making sense.

This is where an AI-native platform changes the calculus:

• Asynchronous, always-on interviews. Koji's AI moderator runs interviews 24/7, so the participant chooses the moment. This dissolves the most common real blocker — the calendar — without asking a customer to give up a scheduled hour.
• In-product and CRM-triggered recruiting. Launch interviews directly from product events or an imported CRM cohort, reaching real users in the workflow rather than negotiating through an account team.
• Low-incidence populations become viable. When the marginal cost of an interview approaches zero, you can leave a study open for weeks and accumulate the fifteen rare-role participants that a scheduled study could never justify.
• Multi-language moderation. Access blockers are often linguistic; AI moderation removes the interpreter from the critical path.
• Structured questions keep proxy sessions comparable. When you do interview proxies, Koji's six structured question types (open_ended, scale, single_choice, multiple_choice, ranking, yes_no) let you quantify frequency and severity across many support agents rather than collecting six irreconcilable narratives — turning scattered proxy anecdote into something you can actually count.
• Quality scoring flags thin evidence. Every Koji interview is scored on response quality, which makes it visible when a session produced generalization rather than specifics — exactly the failure mode proxy interviews are prone to.

Legacy platforms optimize for the scheduled, moderated session, which is precisely the format blocked customers cannot accommodate. Removing the scheduling constraint is what converts "we can't reach our users" into "we reached eleven of them last week".

A five-step proxy research plan

When proxy work is genuinely justified, run it as a designed study rather than a series of hallway conversations.

Step 1 — Write down what you would ask a real user. Start from the real research question. This keeps the proxy study anchored to the decision rather than drifting into whatever the proxies find interesting.

Step 2 — Mark each question as proxy-answerable or not. Behavioral and frequency questions survive the translation. Preference, desirability, and emotional-response questions do not. Delete the second group rather than asking them anyway — asking an unanswerable question of a cooperative proxy is how invented findings enter a repository.

Step 3 — Recruit across tiers, not within one. Three support agents will agree with each other and give you false confidence. One support agent, one onboarding specialist, and one solution engineer will disagree productively, and their disagreements map precisely onto the segments each of them sees.

Step 4 — Quantify the qualitative. Ask every proxy the same closed questions about frequency and severity alongside the open discussion. Ten proxies rating the same twelve failure modes on a consistent scale produces something you can rank; ten narrative conversations produce something you can only summarize.

Step 5 — Convert findings into hypotheses with an owner and an expiry. Every proxy finding should leave the study written as a testable claim, tagged with the tier it came from and the date it must be validated against real users. This is what stops proxy evidence from silently becoming permanent.

Getting back to real users

Proxy research should always come with an exit plan, because the access blocker rarely disappears on its own. Two moves work in practice.

The first is to use the proxy findings as the business case. A support-derived estimate that a specific failure mode generates a measurable share of tickets is a far stronger argument for customer access than a generic request for research time, and it converts the account team from gatekeeper to collaborator.

The second is to lower the ask. Most gatekeeping objections are about the cost imposed on the customer — an hour of a named executive's time. An asynchronous interview the customer completes at their convenience is a materially smaller request, and account teams approve it far more often than a scheduled call. The blocker was never research; it was the meeting.

Related Resources

• Structured Questions in AI Interviews — quantify severity and frequency across multiple proxy interviews
• How to Find and Recruit Research Participants — solve the access problem properly
• Recruiting B2B Participants for User Research — getting past enterprise gatekeeping
• Secondary Research: The Complete Guide — evidence from published sources rather than human proxies
• Support Ticket Analysis — mining the record instead of interviewing the agent
• Sales Call to Customer Insight — extracting real user voice from existing conversations
• Synthetic Users in Research — where AI personas are and are not trustworthy

Frequently asked questions

Is proxy research better than no research? Only when it is labelled honestly and restricted to observed behavior. Unlabelled proxy findings presented as user needs are worse than no research, because a confident wrong belief blocks the real study that would have corrected it.

Can I test a prototype with colleagues? For catching broken flows and typos, yes — that is quality assurance. For evaluating whether the design works, no. Colleagues know too much and are socially constrained from being harsh about work their peers did.

How long can a team run on proxy evidence? Treat it as a single cycle. If you are still proxying after one planning period, the access problem has become an organizational one, and the fix is escalation rather than another round of internal interviews.