Insights
When real users can't join research, study their work: records, workarounds, helpers and support queries. Name each source's blind spot. If the people who use your product can't or won't take part in research, study their work rather than settling for whoever is available.
If the people who use your product can't or won't take part in research, study their work rather than settling for whoever is available. Their records and workarounds, the place where the work happens, the people who support them and the questions they ask are all evidence. Each of those sources has a known blind spot, so name it, and before any release where a mistake would be costly, find a way to put the product in front of real users anyway.
Two weak defaults, and a better one
When the intended users are out of reach, there are two easy fallbacks. Teams interview whoever they can recruit and treat those people as the user, or they skip research and design from what stakeholders believe. The first gives confident answers from the wrong people. The second gives the team's assumptions with nothing to test them against.
The better path treats the inaccessible user's work as the evidence, rather than their opinions. The idea is older than most product teams. In 1995 Hugh Beyer and Karen Holtzblatt wrote in Communications of the ACM that traditional interviewing and surveying techniques were not adequate for designing the applications of the day, and that a design team comes to understand the whole work problem by understanding each person in the context of that person's work. Clayton Christensen and his co-authors made a related point in Harvard Business Review in 2016: you can learn as much from people who use no product for a job as from those who do, and people who cobble together workarounds are probably unhappy with the solutions available to them.
A paper timesheet, a shared spreadsheet or a note stuck to a monitor is a record of what the work needs, made by the people you can't interview.
Which kind of "can't take part" are you facing?
The right substitute depends on why the users are out of reach. In business and operational software, five situations are worth telling apart.
| Why users can't take part | Evidence to use instead | What it can't tell you |
|---|---|---|
| They don't use the product yet: the work still happens on paper, in spreadsheets or in another tool | Their current records and workarounds; observation where the work happens | Whether they will adopt the new product, or how they will cope with its interface |
| They are unfamiliar with technology, or a research session feels like a test | Short sessions in their own workplace; the people who onboard, train or support them | How the users themselves experience the product, as distinct from what their helpers see |
| They sit behind your customer, who controls access | The customer's forms, exports, procedures and support history; the supervisors who check the work | The users' own priorities wherever they differ from the buyer's |
| They are too busy or too senior to give an hour | Their output: approvals, comments, edits and how long each takes; brief questions at the point of work | The reasoning behind their decisions |
| Regulation or confidentiality limits contact | Records the customer approves for review; policies and procedures; scenarios tested with people from the same occupation | How the actual users perform; in safety-critical work, nothing here replaces testing with them |
A product can face several of these at once. Name the ones that apply before choosing methods, because each points to different evidence.
What each substitute can and can't tell you
Records and workarounds. Timesheets, forms, exports, spreadsheets and handover notes show what information the work needs, in what order, and where the official system is bypassed. They don't show why a step exists or what the person was thinking when they took it.
Observation where the work happens. The UK government's service manual, in its guidance on users who do not use digital services, tells teams to hold research in places where users use the service, and to have an expert researcher judge people's digital skills rather than ask them, because people often misjudge their own. Seeing the work where it happens shows the conditions people work under. It can't tell you how often what you saw occurs.
The people who onboard, train or support users. The same guidance asks teams to research with the third parties who help users, from contact centres to friends, family and colleagues. These people have watched users struggle, and they are easier to reach than the users. They are also proxies, and proxies distort. Health research has measured how much: a 2022 systematic review and meta-analysis by Khanna and colleagues, covering 30 studies that compared children's own reports of their health-related quality of life with reports from parents and health professionals, found poor overall agreement (a pooled intraclass correlation of 0.49). Agreement was low on domains such as emotion, cognition, worry and pain, in contrast to more observable physical health and functioning. That is a neighbouring field, not software, but it suggests a working rule: trust a proxy on what they could see, and doubt them on what the user felt or understood. Bear in mind, too, that support and training staff see the cases that reach them, which may not be typical ones.
Support queries and feedback. What users ask for help with shows where the product stops making sense to them. It covers only the people confident enough to ask, and only the problems they could put into words.
Public reviews. For consumer-facing products, reviews are plentiful. Dennis Pagano and Walid Maalej analysed more than a million App Store reviews in a 2013 study and found praise in over 75% of a coded sample, while negative feedback typically lacked context and detail about the user's experience. Reviews are good for the language people use and the complaints that recur. They are poor at explaining why.
A competitor study. Other products show what users of the category have learned to expect. They show nothing about whether those expectations fit your users' work.
An expert review of the product. A heuristic evaluation finds where an interface breaks well-established usability principles. That is a different question from what the work requires: it is a useful stand-in for the first and no help with the second.
How we researched Scissors without its ideal participants
At Tcules, we met this problem in our work for Scissors, Auckland-based software for temporary staffing agencies. Its users include recruiters (division administrators), group administrators (client contacts for multiple clients), contacts at the agencies' clients who hire the candidates, and the candidates themselves. In temporary recruiting, self-onboarding was not usual practice and users were not very familiar with technology, so the Scissors team onboarded and trained every user by hand, a process that took a couple of weeks.
While interviewing users during discovery, we found three things:
- the users we had recruited were not the ideal users: they were not tech-savvy and hardly used the product;
- recruiters, the administrators in the system, kept timesheets and other records on paper;
- candidates' shifts were recorded on paper first, at the job location.
The ideal users could not be recruited for the research. So the work drew on several sources at once: a heuristic evaluation and design audit of the product, conversations with stakeholders, a competitor analysis, user research and thematic analysis, followed by wireframes and prototypes. We built an object diagram of the system from three perspectives: the business view of the system's problems, the market view from the competitor study, and users' experience from interviews, feedback and queries. Mapping the system's objects and the relationships between them, the core of our information architecture and workflow design work, let us highlight and deconstruct the problem areas in the object diagram using all three kinds of evidence together.
Our reading of the paper records is that they were findings in their own right: they showed where the product had not yet earned a place in the work. We drew a conclusion that went beyond onboarding. The core functions had to become easier to operate and understand if people were to keep using the system once they had been onboarded. The redesign covered onboarding, candidate shortlisting, talent pools and job creation.
A smaller example comes from our UX research for a kirana store payments app. It was not possible to reach every user of competing payment apps, so we analysed reviews and interactions on social media and app stores. That did not replace speaking to people: we also interviewed 20 people who matched the personas.
When substitute evidence is not enough
Substitute evidence helps you decide what to design. It is much weaker at telling you whether the design works for the people who will use it. Stop and insist on reaching real users when:
- the release carries real consequence. If an error could cost someone money, their job, their legal standing or their safety, test with representative users first. Medical devices make the principle explicit: the US Food and Drug Administration's human factors guidance, revised in August 2026, says in section 8.1.1 that the most important consideration for participants in human factors validation testing is that they represent the population of intended users, and names literacy level and occupational specialty among the user characteristics that could particularly influence how people interact with a device's user interface.
- the question is about understanding, trust or motivation. These are inner states, and in the proxy research above agreement was lowest on inner states such as emotion and worry.
- your sources disagree. When the support team, the records and the customer's managers tell different stories, only the users can settle it.
- everything you have came from the people who were easiest to reach. Ease of access is itself a bias.
When you do reach them, watch for a second distortion. In a 2012 study of 450 interviews in Bangalore, Nicola Dell of the University of Washington and colleagues from San Jose State University and Microsoft Research India found that respondents were about 2.5 times more likely to prefer a technology they believed the interviewer had made, even when the alternative was identical; when the interviewer was a foreign researcher who needed a translator, the bias rose to five times. The study was of participants in Bangalore, and its authors drew the lesson for research with underprivileged populations. It is an inference, not something the study tested, that the same caution applies to anyone who may feel a session is a test or who depends on the person asking: they may not tell you a design is poor. Show alternatives without saying which one is yours, and give more weight to what people do with the product than to what they say about it.
Where this work sits
At Tcules, we plan research around the decision it has to inform, and then look for evidence that can reach it. In our UX Research work on operational products, interviews and usability sessions are only part of the picture: we may examine artefacts, support records, workarounds, handoffs, policies, product data and the environment in which the work occurs. When a direction is clear enough to test, prototyping and usability testing puts it in front of the people who will use it.