The question
I joined as a designer. The team needed to prototype in the same stack the product would ship in. There was no kit. Handing off Figma files and hoping the first coded version survived contact with users was not a process. It was a delay.
The experiment was personal and organisational at the same time: could a designer learn enough .NET to build the missing infrastructure, and would the team actually use it?
What I built
A prototyping kit in ASP.NET Core. Forms, layouts, components, and the awkward parts that static kits skip: posting data between pages, injecting scripts through middleware, handling nulls in MVC so a prototype does not fall over on an empty field.
The kit was not a demo. It was the environment researchers and designers used to test journeys with real branching. That is the only prototype worth the name.
While the kit took shape I also changed how the team planned work. Cycles was a Shape-Up and Scrum hybrid: longer focus time, fewer empty retros, a board that made design and development visible to each other.
What it revealed
Tooling is a leadership problem. If the team cannot test the risky journeys, the designer is decorating a guess. Learning the stack was not a side quest. It was the shortest path to making the work real.
The experiment is archived. The lesson is not. Arrive, notice the gap, build the thing the team is missing, then change the cadence so the thing gets used.
Related reading
- Building a prototyping kit from scratch — The full write-up
- Cycles: a new way of working — The Shape-Up and Scrum hybrid that ran alongside the kit
- Prototype validation — How much fidelity a prototype needs before research