Closing the gap between prototype and product
Rebuilding a design system for better decisions, not just faster builds.
At Agreena, we used to spend a lot of time in user research sessions asking farmers to join from a desktop browser to view Figma prototypes. They rarely did! But this gave us the impetus to rethink our product development process.
Farmers are busy. They're often in fields with poor wifi, in the car, on the combine. More often than not, they didn't show up on desktop. The feedback we needed; specific and grounded in real use wasn't getting through.
The prototype and the product had drifted too far apart. Users were reacting to something that didn't quite exist. Feedback was partial – so decisions were getting made on the wrong signal.
The decision
We rebuilt the design system around shadcn — recomposable components that worked properly with LLMs, shareable via URL and fully responsive. The goal wasn't aesthetic consistency from the outset, it was to close the gap between what we were testing and what we were actually building.
The key design challenge wasn't the components themselves, tokens and components came together well. The harder problem was consistency across flows. Rules and guidelines were developed to govern how layouts were compiled, so the system held together as prototypes got more complex and more people built with them.
What changed
The first session using the new setup, a farmer joined on mobile, and for the first time, that wasn't a problem. A responsive URL replaced the Figma link. The session ran normally. The feedback was specific.
The bigger shift was in what the change unlocked more broadly. With prototypes built on real components with real data, behaving like the actual product, feedback got more specific. Users reacted to something real rather than something representative.
That meant hypotheses got tested and disproved faster. The gap between "we think this works" and "we know whether it works" shrank considerably.
With the design system more accessible, PMs and developers could build and adapt prototypes without waiting for design. Features got shipped that simply wouldn't have had time in the queue.
The outcomes
In this work, the design system itself wasn't the goal - better decisions about what to build were.
When prototypes are indistinguishable from the real product, something changes in how people respond. The responses are more informed. You find out earlier what's actually wrong, before it costs to change.
The right tools don't just make building faster, they mean better questions get asked earlier, which means better decisions get made about what's worth building at all.