The plan always sounds reasonable: first make the technology work. Turn it into a stable prototype, decide who it is for and then, when it is ready, test it with users. But that's not the best moment to include those who will finally have to live with the technology.
Teams often explain the delay in practical terms. Recruiting participants requires time and coordination, especially in health-related settings, where a session may also depend on clinical partners, accessible materials, risk review, and an appropriate research protocol. The team therefore waits until the cap connects reliably, the model runs consistently, and the interface stops changing every afternoon. In the meantime, it keeps building without the people who could challenge the application itself.
By the time people are invited in, the prototype is more reliable and the slide deck more convincing. Yet over the same period, the intended use, success measures, pilot setting, support model, and funding story have hardened around the project. User testing can still move a button, shorten an instruction, expose an error, or improve a training session, although it can no longer easily ask whether this is the right application, whether its burden is acceptable, or whether the problem should have been framed differently.
This is the paradox of user testing in emerging technology. Teams postpone it until they have an application to test. Yet contact with the people who may use, support, refuse, or live beside the technology is part of discovering what the application actually is.
The work founders know they should do
Technical founders do not need another lecture on the abstract importance of users. Y Combinator’s essential startup advice reduces early-stage work to building and talking to users, followed by repeated iteration. The US National Science Foundation built its I-Corps programme around experiential learning and customer discovery so that researchers can test the assumptions connecting an invention to a market. The advice is hardly obscure, yet it is still easy to postpone.
Building is a comparatively controlled form of progress: a technical problem can be divided, assigned, measured, and demonstrated, and each improvement makes the prototype look more like a product. By contrast, user contact introduces a less manageable uncertainty. The value proposition may not fit the person’s actual priorities, or they may want something the current architecture cannot provide. They may even reveal that the supposedly minor inconvenience is the central obstacle, that the buyer is not the person carrying the burden, or that the proposed solution is less useful than an unglamorous change to an existing service.
For a founder who has spent years making a difficult capability possible, that conversation can feel like a verdict on the work, which makes it tempting to wait until the demonstration is strong enough to survive it.
Startup incentives reinforce the temptation. A coherent product story helps a team recruit, raise money, secure a pilot, and keep moving, whereas early user contact can make that story less coherent just when the institution around the project wants it to become more definite. Recruitment also takes time, accessibility costs money, and the people the project needs to hear from do not arrive on the same schedule as a funding round or conference demonstration. Although the avoidance is understandable, its effect is still serious: the technology keeps improving while the team’s understanding of the application stands still.
The application does not end at the device
A previous article I wrote used a fictional project called Relay to show how responsibility changes as an emerging technology moves from a concept note to a research plan, a clinical investigation, and eventually routine use. Relay was a non-invasive brain-computer interface for stroke rehabilitation. At each transition, the evidence and decision changed, while responsibilities persisted, transferred, or expanded. Even the first transition — from detecting a neural signal to defining an application — was difficult: the team had to specify who the system was for, where it would be used, and what outcome would count as a benefit.
An early review by a stroke survivor and a therapist changed Relay’s proposed endpoint. Uninterrupted task time had looked like a clean measure of progress. The review made calibration burden and tolerable session length visible, so the project’s research question changed before the pilot began. Although that was an important correction, it did not finish the application.
An application is a technical capability arranged inside a life. It includes the person expected to act, the place in which they act, the interface through which the system explains itself, the work required to keep it operating, and the consequences of a result. The US Food and Drug Administration describes this relationship in human-factors terms as a device-user system comprising users, use environments, and user interfaces. For an emerging neurotechnology, that system may also include cap fit, hair and skin preparation, repeated calibration, fatigue, therapist attention, software support, interpretation of uncertain output, and a person’s ability to stop without losing access to care. While the laboratory can test whether the signal is stable, the people entering the arrangement reveal which kinds of stability matter.
A test can preserve the wrong application
Consider what might happen next to the fictional BCI Relay. The sequence below is an illustration of how a test plan can change; it is not participant testimony or evidence about a real device.
After the early review, the team spends several months improving the system. Its planned user session asks whether a participant can complete calibration, use the computer-based rehabilitation exercise, and continue after the system adjusts difficulty within a therapist-set range. The measures are failed calibrations, task completion, adjustment latency, and the number of prompts required from a therapist.
These are legitimate questions, but they also contain a theory of the application: success means completing the task. Consequently, the session begins when the system is ready and therapist assistance is treated as a prompt count, while the participant’s work before and after the measured exercise sits outside the record.
Now imagine that the first sessions expose a different boundary. Preparation takes long enough to consume much of the appointment, while recalibration interrupts the exercise after fatigue has already increased. Although a participant can complete the task, they may not want to repeat the full process several times a week. Meanwhile, a therapist can make the system perform well by quietly absorbing setup, troubleshooting, reassurance, and interpretation into the session. These findings would not necessarily mean that Relay had failed; they would show that the first test was aimed at too small an object.
Instead of containing only a list of interface bugs, the revised test plan would expand the unit of observation to include preparation and recovery time, recalibration, stopping and resuming, the ability to contest an output, support labour, tolerable frequency, and the effect on the rest of the therapy session. That wider boundary might narrow the intended setting, change the assumed service model, or reveal that a less ambitious technical mode produces a more usable application. But if a user test is allowed to change only the interface, most of the product has already been declared out of bounds.
“Talking to users” names several different kinds of work
The phrase is useful because it is simple, but it is too broad to guide a high-stakes project.
Customer discovery asks whether a problem is important, who experiences it, how it is handled now, and who might support or pay for a different approach; this work can begin before a functional prototype exists.
Affected-community participation asks a different question: whether people whose rights, opportunities, work, care, or daily lives may be changed have real influence over the purpose, boundaries, outcomes, safeguards, and access model. Some of these people may never be customers or direct users. A family member supporting a device, a worker subject to an inference system, or a person excluded by the eligibility criteria can still know something the application needs to confront.
Usability and human-factors work observes how intended users interact with a system in expected environments. It can expose use errors, confusing interfaces, environmental constraints, and mismatches between the design and the physical, sensory, cognitive, or experiential characteristics of the people expected to use it.
A clinical investigation addresses still other questions: safety, performance, benefit, risk, and the reliability of evidence under an appropriate protocol. Although patients can help design such a study, that form of engagement differs from enrolling them as its subjects. The FDA’s guidance on patient engagement in medical-device clinical studies notes that patient input can help study designs address challenges across the product lifecycle.
Four kinds of user work
Customer discovery
Which problem matters?
Affected-community participation
Which goals and safeguards should change?
Usability + human factors
Can intended users use it in context?
Clinical investigation
What does evidence show about safety and benefit?
They inform one another, but they do not substitute for one another.
Although these activities can inform one another, they cannot stand in for one another. A founder may conduct many customer interviews without ever giving an affected community influence over safeguards, just as a participatory workshop may change the outcome that matters without showing whether the interface can be used safely. Meanwhile, a successful usability study may leave the business model and access pathway untouched, and a clinical endpoint may demonstrate an effect while missing the burden that makes the application unacceptable outside the study.
The useful question therefore concerns the kind of encounter that took place, the decisions that remained open, and what the people involved were able to change.
A person can arrive early and still arrive late
Project timelines often measure participation by date: whether the workshop happened before the pilot, a patient organization was consulted during development, or the team gathered feedback before launch. Yet decision time is more revealing than calendar time.
A participant can enter a project months before deployment and still arrive after the problem, outcome, use setting, data flow, support model, and viable business story have been fixed. The meeting may be early in the schedule, but it is late in the decision. People can therefore improve the journey while the destination remains someone else’s choice.
This is why one agreeable representative cannot make a process participatory: a direct user, a caregiver, and a professional may depend on the same technology while carrying different work and risk. Even people who share a diagnosis or disability may disagree about acceptable trade-offs, just as workers with secure contracts may understand refusal differently from contractors. Likewise, people with access to a specialist clinic may see a pathway differently from those excluded by geography, language, cost, race, gender, or eligibility. Disagreement is not noise to be averaged away; it shows where a project has distributed benefits, burdens, and authority unevenly.
There is a legal and political history behind this point. Article 4(3) of the Convention on the Rights of Persons with Disabilities requires States Parties to consult closely with and actively involve persons with disabilities, including children with disabilities, through their representative organizations when developing and implementing relevant legislation and policies and in other decision-making processes. Although this duty applies to States Parties rather than serving as a general corporate user-testing rule, its rights-based logic gives technology institutions an important benchmark: decisions about affected people should not be completed first and explained to them afterwards.
The UNESCO Recommendation on the Ethics of Neurotechnology extends the participation principle across neurotechnology’s lifecycle and emphasizes diverse perspectives, especially those of persons and groups in vulnerable situations. Although neither source tells a founder exactly how to run a session, both make a deeper claim about authority: participation belongs where the question is formed, not only where a nearly finished answer is reviewed.
Testing with people is not permissionless
Although earlier contact is essential, teams should not place unfinished, high-risk systems in front of people as quickly as possible. Emerging technologies can involve medical risk, sensitive data, uncertain inference, dependency, accessibility barriers, and unequal power, so human-subject research and clinical investigation require safeguards appropriate to the setting and jurisdiction. Even a non-clinical session needs a clear purpose, meaningful consent, accessible participation, careful handling of data, and an honest account of what the prototype can and cannot do.
The work can still begin before exposure to a functioning system because people can help define goals, compare present alternatives, identify likely burdens, review recruitment materials, shape outcome measures, challenge assumptions about acceptable use, and decide what a future test must be able to learn. Later, appropriately governed usability or clinical work can test interaction, safety, performance, and benefit. This sequence calls for deliberate contact rather than deferral until every consequential choice has closed. The language matters as well: a team tests with people to discover whether the larger arrangement deserves to be called an application, rather than testing people to find out whether they behave correctly around the invention.
Influence should leave evidence
Teams often produce a summary of consultation themes, whereas far fewer can point to the version of an artefact before and after participation. For Relay, the useful trace might show that the original protocol began at successful connection while the revised protocol included preparation and recovery; that a completion endpoint became a measure of tolerable repeat use; that therapist prompts became visible support labour; or that the intended setting narrowed after contributors challenged an assumption about specialist availability.
The trace need not imply that every suggestion was adopted because scientific quality, safety, law, resources, and conflicting interests still matter, and institutions remain responsible for their decisions. But a serious record can show what was open, who was missing, where contributors disagreed, what changed, and why a recommendation was declined, while also allowing contributors to review how their input is represented.
This is where the material conditions of participation become part of the method. People need enough time and information to contribute, as well as payment, care support, interpreters, accessible formats, asynchronous routes, anonymity, or control over quotation and attribution. These conditions determine who can enter the work and whose expertise the project can hear; without them, a founder may believe that users were consulted while hearing mainly from the people easiest for the institution to reach.
The application is still being designed
The emerging-technology team begins with a capability and works to make it reliable before transforming it into an application. This transformation is already hard because the team must choose an intended use, a setting, an outcome, a user, a support model, and a boundary around what the system will claim to do. Yet user contact belongs within that work because it changes the object being designed.
The encounter may confirm that the interface needs improvement, but it may also show that the measured outcome is too narrow, the service model hides unpaid labour, the use setting is unrealistic, the wrong person has been treated as the user, or the application is not worth its burden. A responsible team must be able to learn any of these things.
That is why founders’ reluctance matters. Waiting protects a coherent product story, but it also protects the assumptions inside that story from the people most able to disturb them. By the time the prototype feels ready for users, the institution around it may no longer be ready to change.
The person in front of the prototype is not the last variable to be tested. Their encounter is where the project learns whether it has built the application it keeps naming, or only the technology that made that application sound plausible.
