Arrive and notice the gap
The brief was design. The constraint was the stack. The product would be built in .NET. The team had no way to prototype in .NET. Researchers were testing pictures of journeys, then waiting for engineering to discover that the pictures had skipped a branch.
I have spent years arguing that a prototype is only honest if it can fail the way the product will fail: forms that post, paths that fork, empty fields that break. A clickable file cannot do that. A kit in the real stack can.
There was no kit. That was the job, whether it was in the contract or not.
Learn the stack in public
I learned ASP.NET Core by building the thing we needed. Models, views, controllers. How a form posts. How a null parameter in MVC sends you somewhere you did not intend. How to inject JavaScript through middleware so a prototype can share behaviour without copying a script into every page.
Those are not glamorous skills. They are the difference between a prototype that survives a research session and one that dies on the first empty input.
The kit followed the patterns designers already knew: layouts, components, a form model that could carry data through a journey. The point was not originality. The point was that a designer who did not write C# every day could still put a real journey in front of a user.
Tooling is a ways-of-working problem
A kit that nobody has time to use is a repo. While I built it I also changed the cadence. Cycles mixed Shape-Up’s appetite with a sprint-shaped calendar: eight weeks, four phases, fewer empty stand-ups, a retro that only happened when there was something to say.
The board had two swimlanes. Design and research at the bottom, development on top. Work moved left to right and bottom up. That sounds like process theatre. It was a way to stop design finishing a journey the kit could not yet express.
The kit and the cadence were the same experiment: make the risky work testable before it is expensive.
What I would do again
If the tooling is wrong, do not wait for permission to be a developer. Learn enough of the stack to remove the blockage, then hand the kit to people who will be faster at it than you.
If the cadence is wrong, do not add another meeting. Change the unit of time until people can finish a slice.
The experiment is archived. I still use the same test: can we put the risky journey in front of a user this month, in the stack we will ship? If the answer is no, the missing piece is usually infrastructure, not another workshop.
Related
- The experiment — What was built and what it changed
- Cycles — The working pattern that ran alongside the kit
- Prototype validation — How much fidelity research actually needs