How to keep the fidelity of prototypes when moving to prd and issues

[fauns-ai]

Hi Matt, thanks for sharing and developing your skills in public. As a product person trying to learn more about engineering, your work has helped me develop mental models for thinking about these things.

I wanted to share my experience using your skills and ask for guidance about how you've solved this particular problem with prototyping. I've gone through many cycles of grilling with docs, PRDs, issues, and TDD. I've also used the grilling, hand-off, prototype, hand-off cycle a number of times.

The part I'm having trouble with is the transition from a satisfying prototype to an implementation path. There was one feature I remember when I spent a lot of time iterating on the prototype. I had just invested in getting my design system right, and then getting the details of that prototype to where I wanted it, with all the right nuances, and then I handed it off to PRD and issues, and what it built kind of ignored the prototype. It's like it didn't look at it and instead tried to rebuild it from prose. That didn't make sense to me because, in the prototype, you have a very clear specification of the actual visual and interactive fidelity that is required, and then you have two steps that are lossy, where the PRD only captures some part of the original and then issues further dilutes it.

So I modified the approach to stop trying to recreate the prototype from prose and instead "fold" the prototype code into the feature implementation. Of course, that created it's own problems of doing a hijacked version of TDD where it was still writing tests during the prototype, but those tests might have just been for show. And I don't know what else might be wrong with that approach of trying to take code and just throw it in when it needs to be connected to the rest of the codebase and have other kinds of tests applied to it and so on.

At the same time, I'm not sure of the point of designing a prototype where you become very clear on exactly what you're trying to build from a user experience standpoint and then just throw away the code and try to recreate through a lossy process.

Anyway, thanks for reading, and I'd love to hear yours or anyone else's perspective on this problem. Thanks for your time.

Keyur

[myklsc]

Hi Keyur, I read your post right as I was about to transition from a prototype to integration for the first time so I bookmarked it to come back to with my experience which I can say was quite successful. But from your post, I cant quite say where our methodology diverged. My approach fwiw:

I created the prototype (a dashboard view) within the project, not in isolation. I had the agent build the prototype with the existing architecture in mind, created data fixtures that mapped to existing schema, and documented where updates were needed. Essentially I made sure there was a clean seam for the prototype/codebase to merge when it was ready.

As far as design-system and fidelity: Im building an app from scratch so currently Im only using ui library defaults and letting the ai choose the components - pills, buttons, dropdowns, menus etc - unless its custom ui/ux then I'll treat that as its own prototype/component/grill session. I focus on layout, and high level ui/ux. Zero focus on design/styling. I'll create a nice design-system, refine ui/ux at the end when I have a working app.

Once I had a working prototype of the dashboard, I took it into a new grilling session where I worked out where any final gaps might be before integrating. At the end of the session I invoked /to-issues. Now I had a clean set of tickets for new agents to execute the migration. The first issue it created was rebuilding the UI shell from the prototype. Everything else was connecting existing data or creating logic for new data to the new UI.

All of this went very smoothly and without drift from the prototype so I'd be curious to know more about your methodology.