How to design for users you’ve never met.
When you can’t access users directly, good design starts with the evidence you have. Learn how to separate facts from assumptions, use proxy insights carefully, design around real scenarios, and keep moving closer to the people affected by your decisions.
·
Product Decisions
Sometimes the people using your product are difficult to reach.
They may work in another country, operate in a highly specialized industry, or sit several layers away from the team building the product. In some cases, you may be designing for people who aren’t customers yet.
This doesn’t mean you have to design unthinkingly. But it does mean being honest about what you know, what you’re assuming, and how close your evidence is to the people you’re designing for.
The goal is to reduce the distance between the product team and the user, even if you can’t remove it completely.
Start with what you know
Before organizing new research, gather the evidence that already exists.
Useful sources might include:
Product analytics
Search behavior
Support tickets
Sales calls
Customer success notes
Previous research
Session recordings
Product reviews and cancellation feedback
Existing industry or academic research
Each source shows you something different, and each sits at a different distance from the user. Analytics can reveal what people are doing without explaining why. Support conversations may help explain where people are struggling. Sales teams may understand what motivates someone to buy but know less about what happens once the product becomes part of their everyday work. Industry research can supply useful context, but it does not prove that the same conditions apply to your product.
This evidence is imperfect, but it gives you a starting point. It also helps you identify real gaps rather than commissioning new research simply because it feels like the right next step.
Separate evidence from assumptions
When teams don’t regularly contact users, assumptions can quickly start to sound like facts.
Someone says, “Our users won’t understand that,” or “They need to complete this task quickly.” The statement gets repeated enough times that nobody remembers where it came from.
Make those assumptions visible and label them.
Write down what you believe about the user, alongside the evidence supporting it. For example:
We believe users complete this task under time pressure.
We believe they primarily use desktop computers.
We believe this information is already familiar to them.
We believe managers and operators need different levels of detail.
Then ask: How do we know?
Some assumptions will be supported by existing evidence. Others will turn out to be inherited opinions. The riskiest unsupported assumptions become your research questions.
When you’re designing for users you haven’t met, you don’t need to pretend you know them. Instead, stay rigorous about acknowledging what you don’t know.
Talk to the people closest to them
If direct access isn’t immediately possible, speak to the people who interact with users regularly.
Customer support, sales, success, implementation, and subject-matter experts each see different parts of the customer experience, from the language people use to describe their problems to the workflows and constraints that shape how the product is actually used.
These people can provide valuable context, but they are not substitutes for users.
Those perspectives are also partial. Sales is closest to buying concerns, support sees problems, and internal experts may understand the domain without sharing the intended user’s conditions.
Treat these conversations as useful evidence, not definitive truth.
Where direct recruitment is difficult, professional bodies, community organizations, specialist groups, and recruitment agencies can help teams reach actual or likely users. Remote moderated and unmoderated methods can also reduce geographic and scheduling barriers, making it easier to conduct research across locations and time zones.
Design around scenarios
Without direct contact, personas can easily become fictional biographies built from stereotypes.
Scenarios are often more useful. Rather than imagining a generic user, describe the situation in which someone is trying to accomplish something:
What are they trying to do?
What happened immediately before?
What information do they have?
What pressures or interruptions are present?
What happens if they make a mistake?
What device, environment, or connection are they using?
A nurse checking information during a busy shift is not simply “a healthcare user.” An operations manager reviewing an exception while speaking to a customer is not just “an enterprise user.” The context changes what the product needs to do.
Scenario-based design helps the team reason about behavior and constraints without claiming personal knowledge it doesn’t have.
Your scenarios should also account for people who use assistive technologies, have limited digital confidence, or work with poor connectivity or older devices. Research recruitment should represent the range of people likely to use the service, not only the easiest participants to reach.
Make something you can test
You don’t need a complete understanding before you start designing.
Create a rough flow, sketch a concept, or build a lightweight prototype based on your current evidence. Label the assumptions embedded in it and identify what needs validation.
A prototype gives people something concrete to respond to. It can also expose disagreement within the team before external research begins.
When you eventually reach users, don’t ask whether they like the design. Give them a realistic task and observe what happens. Good research focuses on whether people can reach the right outcome, not simply which option they prefer.
The design doesn’t prove your assumptions were correct. It is a tool for making those assumptions testable.
Keep moving closer
No research technique fully replaces contact with the people who will use the product.
Proxy conversations, analytics, and secondary research can help you begin. They can narrow the problem, reveal constraints, and prevent the team from relying entirely on instinct. But they cannot replace direct user evidence when the team is making consequential decisions.
Designing for users you’ve never met is sometimes unavoidable. Continuing never to meet them is usually a choice.
Start with the evidence available. Make your assumptions explicit. Design something small enough to test. Then keep looking for ways to bring the team closer to the people affected by its decisions.