Welcome to chapter eighteen. This chapter is about the skill that matters more than any fabrication method: hearing a request, recognising the solution it already contains, setting that solution gently aside, and finding the problem underneath. It covers who is who in a clinical environment, how to observe and interview, how to write a need without choosing the answer, how to separate evidence from interpretation, and how to decide which needs are worth your time. It is also the chapter that tells you to start looking for a collaborator in week one, not week twenty-one.
Requests to someone known for making things almost always arrive shaped like the requester's guess at what that person can make. Could you make us a holder? Could you write us an app? Could you put a sensor on it so it beeps? Could you sew a cover, or weld a frame like the old one? Each of those sentences contains a solution and conceals a need. Take the holder. Perhaps the educator needs a part to stay visible. Perhaps they need a free hand. Perhaps things keep getting lost, or setup takes too long. Each implies a different design, and three of them are not a holder.
The skill is to hear the proposed solution, set it aside without being tiresome about it, and find the problem underneath, without substituting your own guess for their expertise. And here is the uncomfortable timing fact. Finding a collaborator takes longer than learning the biology. Emails go unanswered, the right person is on leave, onboarding has a process, and the first conversation often redirects you. That is why this chapter belongs in week one of the schedule as much as in week twenty-one.
A clinical environment contains many professions, and addressing the wrong one wastes their time. Nurses deliver most direct care and know how a task really happens, what gets improvised, and what the night shift does differently. Doctors give clinical context and what is negotiable. The occupational therapist is the key partner for most assistive technology. Physiotherapists know movement and safe loading. Prosthetists and orthotists are the closest professional equivalent to a skilled maker. The simulation educator is the key partner for training aids. And clinical engineers know local technical standards and who approves what.
Then there are the gatekeepers. Infection prevention and control must review anything shared or reusable. Pharmacists own anything touching medicines. Procurement knows what already exists, what it costs, and why the current product was chosen. Information governance must approve anything involving real data, photography or records. Quality and regulatory staff decide whether a locally made item can be used at all. The innovation office is often your actual route in. And the intended user, whether patient, carer or staff member, is the only expert on their own experience, priorities and what better means.
You need two inputs, and they are not interchangeable. The clinician brings professional assessment. The user brings lived experience, priorities and context. A therapist can tell you a person has limited pinch strength. Only the person can tell you that what they actually care about is fastening their own coat before their grandchild arrives, and that a device requiring two hands to put on defeats the whole purpose. Neither input is sufficient alone.
Map the whole task: what triggers it, the preparation, the action, what happens when it fails, the cleanup, and the handoff. A newcomer watches the action step and designs for it. The difficulty is almost always somewhere else. Preparation takes four minutes because the thing cannot be found. Nobody reprocesses it, so it is never available. It fails one time in five, and the recovery is what costs the time. For each stage ask what happens, who does it, how long it takes, how often, what can go wrong, what they do when it does, and what they have already improvised.
Look for the tape. The improvised workaround, tape, an elastic band, a cardboard wedge, a bent paperclip, a second person holding something, is a solution someone has already built under the real constraints: the real environment, the real time budget, the materials to hand, the acceptable cost. It encodes the actual requirement more reliably than anyone's description of it, and it is usually the single most informative thing you will see.
The core interviewing move is to ask for a specific recent instance rather than an opinion. Would this help invites politeness; tell me about the last time this happened produces an account you can analyse. Instead of asking whether the current one is bad, ask them to walk you through how they did it this morning. Instead of would an app help, ask what makes this part of the job difficult. People estimate frequency badly but recall instances well, so ask when it last happened, and before that. And instead of would you use it, ask what they do now instead, because the current workaround is the real baseline your idea must beat.
Then comes the step people skip: summarise back and invite correction. So if I have understood, the problem is this, it happens about this often, you currently do that, and what would help is being able to do this. Have I got that wrong? People correct a wrong summary far more readily than they volunteer a right one. And all observation and interviewing happens through the host's authorised process: access, consent, confidentiality, photography and data handling. Record no patient identifiers. Photograph nothing without permission, and ask about the background as well as the subject. If you are unsure whether something is permitted, it is not, until you have asked.
A good need statement names who, what difficulty, and what outcome, and then it stops. It does not name a technology, a material, or a mechanism. The template is: a way for someone to achieve some outcome that overcomes some constraint. Naming a technology commits to a solution and a process before either is justified, and silently rules out every simpler answer, including changing the workflow, buying something, or doing nothing.
Compare these. We need a motorised elbow model with an app commits to actuation, electronics and software before any is justified. Learners do not understand the elbow is too broad to design against or assess. Nurses need an app names a technology and no problem at all. The good versions are specific. Beginning learners need a way to distinguish muscle force generation from tendon force transmission during an elbow demonstration: population, difficulty and desired understanding, with many solutions left open. And a way for a person with limited pinch strength to open their own medication packaging, independently: who, outcome and constraint, and nothing about how.
The need says what. The constraints say what will survive contact with reality, and they are information to verify, not assumptions to bury in your CAD. Where is it used, with what light, noise, space and interruptions? Who uses it, trained or not, gloved, with one hand free or two? How often, for how long, and how much time is there to reset between uses? How is it stored, powered and cleaned? Then life after you: maintenance, consumables, existing products and why they were rejected, cost, procurement and training. And the most commonly skipped question, the one that decides whether a project survives: who owns this after you leave?
This is a discipline, and it is visible in your notes or it does not exist. An observation is what happened: a learner pointed at the cord and called it a muscle. An interpretation is one explanation among several: the label may be unclear, so generate at least one alternative. An assumption is an untested prediction: a coloured sleeve will fix it, so mark it and build a cheap comparison. A requirement needs an agreed observable test. And never turn one observation into all users need this. One learner's confusion shows a confusion is possible. It does not show how common it is, or whether your fix works.
Here is a sample conversation. The educator says we need a better elbow model. The maker asks what is difficult with the current one. Learners watch me pull the cable and think the cable is a muscle. The maker summarises and checks: so the issue is where the force comes from? Yes, they can name the bones fine. When did that last come up? Last Tuesday, two out of six described the cord as contracting. And what do you do when that happens? I explain it again. It usually lands, but it costs me five minutes I do not have, and I am not sure it sticks.
Look at what six questions produced. The opening request, a better model, was a solution with an unstated problem. The actual difficulty is a specific misconception about force generation versus transmission. There is a baseline, roughly a third of learners in one session; a workaround, verbal re-explanation; and its cost, five minutes of scarce teaching time. A constraint emerged that nobody asked about: time is the scarce resource. And crucially, it ruled out a plausible but wrong direction. A more anatomically detailed shell would not touch this misconception. Visually separating the force input, the transmission element and the moving part might, and that is probably simpler and cheaper.
When you have more candidate needs than time, filter them, in the spirit of the Stanford Biodesign process. Is the need real, described by at least two independent people, with a workaround? Does it matter, in time, safety, dignity or cost, and how often? Is the outcome observable, so you could tell it improved? Can a meaningful version fit your time, skills and supervision? Is it in the right risk class, or invasive, life-supporting or decision making? Is there a named sponsor who will review and own it? Does something already exist, and if it was rejected, why? And is there a route to use at all?
The honest answer to the last two filters is often no, and that is useful information, not failure. If a product exists and was rejected, understand why before rebuilding it. The reason is usually cost, availability or policy, and making a copy by any method fixes none of those. A project you decline early is three months you did not spend. Say so plainly; the collaborator will usually agree and respect the reasoning. And intellectual property will come up, so ask at the start who owns what. For most volunteer projects, the honest answer is an open licence and a clear statement that the host owns the deployment decision.
The request: can you make us a holder for these? The conversation found that items set down on a trolley during a procedure sometimes roll off, about twice a week. Nobody is harmed, but re-fetching takes ninety seconds and breaks concentration. The workaround is a folded blue roll wedge, remade every time. A commercial tray exists but does not fit this trolley. Three staff use it, each arranging it differently. It must be wiped with the department's existing wipes, and nobody has time to assemble anything. So the need: a way to keep these items stable and reachable on the existing trolley, cleanable with the current process, requiring no setup time.
Notice the need says nothing about a holder or a method. Stable and reachable might be a change to how the trolley is laid out, with no making at all. It might be a non-slip silicone mat, bought or cast to fit. It might be a welded stainless wire rack or folded sheet-metal tray, the established form for equipment wiped many times a day, or a machined, thermoformed, moulded or printed insert. Choosing between them is chapter fourteen's job. Requirements fall out, each with a check: items stay put over a door threshold, no setup time, cleanable with infection control review, fits without modification, and any user can position it unprompted.
For the exercises: rewrite build an app for nurses as three unanswered questions about the need. Write a need statement for the elbow model that names no material or mechanism. Separate one observation, interpretation and assumption. Map a task end to end; it need not be clinical, and setting up a lathe for a batch or soldering and testing a board teaches the same skill. Answer every constraint for your project and mark each known, assumed or unknown. Get your brief corrected before you build, or record it as pending. And send one real outreach email this week, because the reply may take a month.
The limits. You cannot observe clinical work on your own initiative; access runs through the host's process every time. You cannot handle patient data, not even de-identified data or photographs, without formal approval. One conversation is a start, not requirements gathering; needs get refined, contradicted and sometimes abandoned. A confirmed brief means you agree on the problem, not that the result may be used. And you are not the person who decides what matters; the clinician's and the user's judgements are the ones that count. Next, requirements, hazards, and useful tests.