My team builds internal tools for operations teams. The people using them know their workflows deeply. Getting useful feedback from them should be straightforward.
But we were asking them to do a lot of imagining.
We’d describe a proposed feature in a long Notion document or share wireframes in Figma. Users would have to translate those into a picture of how the finished tool would work.
Some issues only surfaced when we had a testable version on staging. By then, we’d already built enough that changing it meant rework.
I wanted to bring that moment of recognition earlier.
Familiar enough to use
I built a Claude skill that could read our existing application code and create clickable prototypes.
The first challenge was teaching it enough about our product. Access to code didn’t tell it which files backed a particular screen, how our forms were organized, or which interface patterns made something feel familiar to our users.
I put together reference material connecting the screens to their code, describing our design patterns, and documenting the existing forms.
That context helped it produce prototypes that looked and behaved more like the tools people already used. Reviewers could spend less effort interpreting an unfamiliar interface and more attention on whether the proposed workflow made sense.
For upcoming changes, we linked prototypes from the requirements documents and included test scenarios. Reviewers could choose a scenario, click through it, and leave feedback against that specific flow.
A more concrete conversation
One example was a tool that helped our operations team process incoming wire transfers that couldn’t be routed automatically.
We prototyped it before building the production version and showed it to the operations team. Their feedback was richer than what we’d received on a written description. We also had less rework after testing on staging.
The prototype gave people something specific to try. They could react to the sequence of steps, the information on screen, and the choices available to them.
Our engineers later used the prototype as a starting point for the production implementation.
The skill itself is specific to our application. Another team would need to supply its own context. That took work, and it was a large part of why the prototypes became useful.
I’d already been asking users for feedback. What changed was how much interpretation I asked them to do before they could give it. Putting a familiar, clickable workflow in front of them helped us find problems while we still had room to change the design.