06 · Product & medtech · Case study
One language for seven disciplines
Extender brings together seven organisations: robotics labs, an assistive-robotics company, clinicians and social scientists. Everyone agreed on the mission, yet priority meetings stalled, because the same capability meant something different to each person in the room. I designed a way for every discipline to state its needs in its own language and still be understood by the others, working hand in hand with the product side at ORTHOPUS.
- The problem
- What looked like disagreement about priorities was really a failure of translation. A user, a clinician, an engineer and a researcher each gave a correct description of a different thing.
- My role
- Product framing across the consortium: I proposed the model, facilitated the working sessions and co-wrote the shared capability register with ORTHOPUS.
- The result
- A register that the lab and the company both read as research backlog and product backlog, where every capability can be understood by anyone in the room.
Four readings of the same capability
Rather than a lowest common denominator or a translation owned by engineering, each capability is written four times, in parallel, by the people who speak each language.
- Usage
- People with disabilities: lived experience, abilities, frustrations and wishes.
- Clinical
- Occupational therapists and physicians: functions, limitations, risks and clinical criteria.
- Technical
- Software and hardware engineers: system functions, modules, interfaces and constraints.
- Research
- Control, vision and HRI researchers: methods, control laws and scientific metrics.
- Across all four
- Sociology, HRI and ethics check acceptability and dignity at every level, and catch the polite “it’s fine” that really means “I will never use this”.
Capabilities anchored in a user's sentence
Capabilities are grouped into three families, and each family is held to one sentence a user would say about their own day. A feature name can be argued about forever; a first-person sentence can only be agreed with or contradicted with evidence about users.
“The robot helps me make the right movement without taking control away from me.”
“I can try without being afraid.”
“I can really do things in the world.”
How it turns talk into a plan
- Small, meaningful capabilitiesEach one is small enough to own and demonstrate, and large enough to mean something to a user.
- Necessary before interestingEvery capability gets a weight and a type, so the foundations the product stands on come before the exciting research.
- Nothing without a reasonUser intentions lead to user stories, which lead to tasks. No task exists without a story, and no story without an intention.
- Done means validatedEach phase closes with users or clinicians, not on engineering evidence alone: user tests, then clinical validation, then a final protocol.
Social scientists in the room
The socio-anthropological partners took part in the co-design sessions themselves rather than reporting afterwards. On an assistive device, acceptability and dignity fail silently, so they need a discipline watching for them rather than a line in a spec.
The lesson I keep: when someone raises what sounds like a soft concern, it is usually a hard requirement stated in an unfamiliar vocabulary.
What I would do differently
Proposing a whole framework at once asks a lot of busy partners. Next time I would start with the few capabilities people already argue about, write the user sentence for each, and let the structure grow from those conversations.