The prototype is the product
Why we start projects as gray boxes on a real foundation.
Fantasy’s Head of Design Matt Steenburg on what changes for a project when designers and engineers build in the same place from the first week, and what the client’s team inherits when Fantasy leaves.
Last time I wrote about what a prototype becomes once it stops being disposable. On too many projects I’ve watched the old version play out: A team spends weeks building a clickable facsimile of a product. It does its job in the room. The client leans forward, the direction gets approved, and everyone feels good. Then it goes in the bin, because it was never real. Everything under the screens was placeholder code and placeholder data.
Throw the prototype away and you throw away everything the team learned building it. At handoff, every decision the team argued through, every dead end that taught us something, and every reason behind every screen is gone with it. The build team starts over with a PDF and their best guesses.
Teams lose all of this because the prototype and the product are built from different materials, and the two can share one.
From gray boxes to a finished product
On an engagement run the way I described in the last piece, the prototype starts as gray boxes on a real foundation. They’re deliberately plain, because the team needs to settle whether the product works before anyone debates how it looks.
From there we build every flow in rough form across the whole experience, so you can see the whole product early. Then we cut deep through one slice and make it real, with real interactions and real edge cases. Detail goes in where decisions have landed and stays rough where they haven’t, so at any moment the prototype reflects what the team knows.
Placeholder content gets replaced the same way. The made-up profile that filled a card in week two becomes a real record from a real source later, with exactly the same styling, because the design system that grew during the build treats both the same way.
Internally I’ve been calling this progressive release, which is a horrible name, but it describes what happens. You build a small part, you keep adding, engineering keeps adding, and at some point the build becomes the finished product, with nothing left to hand over. The v0.1 a client clicks in week two and the v1.0 they launch are the same build, only further along.
Throw the prototype away and you throw away everything the team learned building it.
Where we’ve run it
We’ve tested parts of this in three places.
The clearest was the demo we built for MIT’s EmTech AI conference this spring. Design iterated inside the same environment engineering was building in, at the same time, right up to the deadline. A stage date can’t move, and that project convinced me that designing and building at the same time holds up under real pressure.
On client work, we’ve run sections of it. For Eliza, the enterprise AI platform at BNY, we delivered the design system in a form the bank’s own AI-assisted engineering organization builds from directly. That is this idea applied to the handoff, because the system we grew during design became what their teams build the product with.
By the bank’s own numbers, the platform spans 14 micro-frontends, more than 600 production deployments, and more than 25 active contributors, which is the scale that handoff had to support. On a prototype for a large advisory business, stakeholders spent their first review clicking a working product instead of paging through a deck.
Each of those tested one part of the approach. Running all of it as one continuous engagement, from gray boxes all the way to a client team iterating on their own, is what we’re working on now.
What the client gets at handoff
The system grew while the product grew, so by the time a product built this way ships, the design system is already finished. Nobody had to start a separate project to build one, and nothing drifts between what was designed and what got made, because one build holds both.
The client receives a live system plus the way of working that produced it, where a frozen set of files used to be. Their team should be able to pick it up and keep going in the same environment, without us. Their first release after we leave should look like our last release before it.
I care most about getting handoff right, because a product built this way keeps improving, and freezing it on delivery day would bring back the waste I described at the start.
What we're still watching
The caveats I mentioned in my first piece still stand. Taking a solid foundation up to the level of craft we’d put the Fantasy name on is hard, and it’s most of the current work. This approach also fits a single platform best, and an ecosystem of hundreds of products would need a rethink.
That raises a question about the jobs themselves: When designers work inside the build and engineers shape the experience from the first week, what exactly are those two jobs now? The prototype is no longer disposable, and the line between the disciplines is starting to fade, too.
This is what we’ll cover in our third installment.
Common questions
A single build carries the work from the first gray boxes to launch. The team starts on a real foundation, adds detail where decisions have landed, and engineering keeps building on the same base until the product ships.
A typical prototype runs on placeholder code and data, so after the client signs off there is nothing to build on. The build team begins again from a PDF and their own guesses, and the reasoning behind each screen goes with the prototype.
Fantasy’s internal terminology for building a product through small additions, with design and engineering working in the same environment. Placeholder content gets swapped for real records from real sources, in the same styling.
A live design system and the way of working that produced it. Their team can carry on in the same environment, and the first release after Fantasy leaves should look like Fantasy’s last one.
Parts of it. Fantasy’s MIT EmTech demo ran design and engineering in the same environment up to the stage deadline. For Eliza, BNY’s enterprise AI platform, Fantasy delivered the design system in a form the bank’s AI-assisted engineering organization builds from directly. On a prototype for a large advisory business, stakeholders spent their first review clicking a working product instead of paging through a deck. Running all of it as one continuous engagement is the next step, and the approach fits a single platform best.
