What a full day of building taught us, the loop that turns a prototype into a plan, and the small things (test accounts, open sessions) that decide whether designers build.
Most prototypes are little more than static pictures. They show what a thing could look like, they win the room, and then engineering opens them and starts a conversation the prototype never had: is that data available, is it cached, does that number even exist in our system? I’ve spent enough weeks in that gap to have a rule for it now. Point the prototype at real data, and do it before the planning conversation, because a prototype on real data is a plan.
This rule got sharper in the last few weeks for 3 reasons. One was a full day one of our product groups spent building with AI tools, product, design, and engineering together, with a couple dozen demos at the end and a few small prizes. The design leader for that group worked on 2 small changes and had both running by the afternoon. The demos were the fun part. The useful part was watching how many of them stalled at exactly the same seam, where the prototype needed to read something real and couldn’t.
The proof of concept is there. The data is the next step, and the data is the whole difference between a picture and a plan.
The second reason was a prototype someone outside a squad was building for a strategy conversation, a fairly common setup: a fresh set of eyes, a brief, a deadline, and a deliverable that will influence a roadmap the squad has to live with. In my 1:1 with one of the designers on that squad, we sketched the loop I’d want instead. The person with the brief still sets the intent: here’s the information we need to show, here’s why it’s valuable, here’s the evidence the market wants it. Then a designer in our codebase access pilot prompts the builder tools to create that UX against our actual data. What comes back is the gaps, “this data isn’t cached,” “that field lives in a different service,” and a short round of fine-tuning before the prototype goes into planning. My rough estimate is that a prototype built that way cuts the time to ship in half once it’s approved, because the feasibility argument already happened inside the prototype.
The third reason was an internal dashboard proof of concept one of our senior designers built to see whether campaigns and nudges across the product are colliding, and whether customers are seeing too many of them. She built it with the sources she could reach and stubbed the rest with fake data, and when she showed it to her group’s PMs and designers, the reaction was the good kind: eyes opening at the potential, and an immediate question about when the fake sources become real. That’s the right order. The proof of concept is there. The data is the next step, and the data is the whole difference between a picture and a plan.
None of this works without a few unglamorous things, so here are 3. One of our designers has been hosting open sessions where anyone can show up and set up their agent access together, on the theory that there’s no need to do it alone, and he’s recording short Git intros so the onboarding repeats without him. The same designer found that setting up a test account with dummy data and feature flags was tribal knowledge passed around in threads, and got it written down where new people can find it. I’ll admit that I don’t have a test account of my own; I’ve been borrowing a senior designer’s for months. That’s the kind of gap that decides whether a designer builds or stays a picture-maker, and a document fixes it.
One tension worth calling out. Our engineering partner worries that a hosted home for prototypes turns into a graveyard of half-finished ideas, and would rather push people to build into the product itself. I understand the worry, and I think real data is the answer to it. A prototype that already reads production data is a lot closer to the product than to a graveyard.