Research → Product → Code
The case for collapsing research, design, and engineering into one continuous loop, and what you gain when the person who frames the question also ships the code.
Collapse the relay when the definition of done will change the first time you watch someone use the thing. Keep the relay when it won't.
That is the whole call, and most teams never make it deliberately. They inherit a relay: a researcher frames the question and hands findings to a designer, the designer interprets them and hands mockups to an engineer, the engineer builds what they understood. Every pass compresses. The caveat somebody fought for, the edge case, the reason behind a piece of advice, a little of each is flattened at every step, until what ships is a confident artifact only loosely tied to what was learned. Nobody is at fault. The structure leaks.
01Start with where the fix fails
The obvious answer, one person or a tight pair carrying an idea from research through design into production code and back again, is not a rule for everything, and pretending otherwise sets people up to fail.
A specialist will out-design and out-engineer a generalist on any single axis, most of the time. The range is rare, slow to build and hard to hire for, and it does not scale linearly: you cannot staff a hundred-person org with people who do all three well. On a mature, well-specified surface, relays are fine. Specialise, hand off, and your throughput will be better for it.
So the useful thing to ask is narrower than "should designers write code". Which surface are you on right now?
02The test
Ask whether your team can write down what done looks like before anyone builds, and whether it survives the first hour a real user spends with it. When it does, the spec is doing the work and your handoffs are cheap. The reasoning behind each choice already sits in the criteria everyone agreed, so nothing important has to travel by memory.
When it gets rewritten, what mattered was never written down. Somebody saw it happen. What one person saw degrades a little every time it is re-explained, and a relay re-explains it twice before anyone writes a line of code.
Two tells that you are in the second case. Findings that arrive as advice rather than as what somebody watched are one, because advice is what is left after the watching has been squeezed down for somebody else's benefit. Fights during the build about what the user actually meant are the other, especially when whoever could settle them has already moved on to the next study.
A relay is cheap when writing the spec is the hard part. It is expensive when watching is.
0318 steps to 12
At AutoLeap I researched a digital vehicle inspection workflow, prototyped it to high fidelity, and shipped it. The upload went from 18 steps to 12. What made that cut possible was watching technicians give up part-way through, in the bay, mid-job, with a car on the lift.
Write that finding down for somebody else and it becomes "reduce friction in the upload". True, actionable, and pointing at nothing in particular. A good engineer will act on it in good faith and remove six steps that are genuinely awkward. The six that needed to go were chosen from where people actually stopped, and that is a different set. A write-up can carry the advice. It cannot carry the reason, and the reason was the entire decision.
Nothing there required unusual skill. It required whoever chose the steps to have been standing in the bay.
04What one loop buys
A research finding becomes a working, testable prototype in hours rather than a ticket in a queue, so the result feeds the next study that afternoon instead of next quarter. Whoever decides what to build is holding the evidence and the constraints of the build at once, in the same head. And the shipped thing carries its own reasoning, because the reasoning never had to leave the room. At Articos the rubric that defines a good report is the same rubric that gates the pipeline, so research and code are two views of one call rather than two write-ups that have to agree.
05What it costs you
Depth, first. You trade depth in one craft for range across three, and you will feel that trade on any surface where craft depth is the binding constraint.
Second, and less discussed: a loop stakes a surface on one person's calendar, so their week becomes your roadmap. Pull them onto something urgent and the loop stops dead, where a relay would have kept moving, slower and rougher. Price that risk in rather than treating it as a reason to avoid the model. It is why most teams that get value from this do not reorganise around it. They put the loop where the ambiguity is, on the 0 to 1 surface or the one nobody understands yet, and leave the settled surfaces on handoffs where they belong.
06Where to look first
Take one thing your team shipped last quarter that was correct against the spec and wrong in use. Trace it backwards a hop at a time until you find the step where the reason stopped travelling with the choice it belonged to. That is your leak. It is usually one hop rather than three, and it is usually not the hop people complain about in retros.
If you cannot find a case like that, your surface is mature and your relay is earning its keep. Leave it alone and go and staff the ambiguous thing properly instead.
The goal was never more range. Keep the gap between a question and a shipped answer short where the answer is still moving, and let it stay long where the answer has settled. For what this loop produces when the output has to survive a challenge rather than a read, Auditable AI Research walks through one. For the material it works on, AI as a Design Material.
07References
- The New New Product Development Game
- Managing the Development of Large Software Systems
- Dilemmas in a General Theory of Planning
- A Leader's Framework for Decision Making
- Fast Path to a Great UX - Increased Exposure Hours
- Contextual Design (Encyclopedia of Human-Computer Interaction, 2nd ed., ch. 8)
- The Tacit Dimension
- Exploration and Exploitation in Organizational Learning
- How Do Committees Invent?
- A Novel Approach for Estimating Truck Factors
- Why Documents Fail And What You Can Do About It
- The Product Triad: Design's Role
08Further study
Branching by what you are actually trying to do next.
If you are deciding which surface gets your one loop.
- A Leader's Framework for Decision Making — run the complicated-vs-complex diagnosis before staffing; only complex surfaces pay back a loop.
- Exploration and Exploitation in Organizational Learning — the same call in organizational-learning terms, plus why mixing the two modes starves both.
- Dilemmas in a General Theory of Planning — the ten properties of wicked problems double as a checklist for "done will not survive contact".
If you are trying to stop the leak without reorganising.
- Fast Path to a Great UX - Increased Exposure Hours — the cheapest patch on record: two hours of direct user exposure every six weeks, for everyone who builds.
- Why Documents Fail And What You Can Do About It — what a write-up structurally cannot carry, and the collaboration moves that carry it instead.
- The Product Triad: Design's Role — a half-collapse that works inside a normal org chart: put the engineering lead in the room while the design is made.
If you want the history of the relay you inherited.
- Managing the Development of Large Software Systems — the 1970 paper blamed for waterfall argued against the single pass; the relay was a misreading from page one.
- The New New Product Development Game — the 1986 case for overlapping phases and self-organising teams, drawn from Honda and Canon rather than software.
- How Do Committees Invent? — why the relay's hop boundaries reappear as seams in whatever it ships.