Why I don't hand off my designs
Every mockup handed to someone else is a summary, and summaries lose things. My workflow is built on a simple bet: if the same person hears the interview, draws the screen, and ships the code, nothing important has to survive being summarized.
What a handoff actually costs
A handoff isn't just a delay. It's a translation step, and translation steps lose things. A researcher writes up what they heard, a designer reads the write-up and designs against it, an engineer reads the design and builds against that — and at each step, whatever didn't make it into the artifact quietly disappears. The engineer never heard the hesitation in someone's voice. The designer never saw exactly how the API actually behaves under load. Everyone downstream is working from a summary of a summary.
Doing the research, the design, and the build myself doesn't make me smarter than a team doing the same work. It just removes the translation. The mockup stays buildable because I know what the code can actually do. The code stays humane because I heard the interview firsthand, not a note about it.
It also changes what a design file is for. A mockup made for someone else to build has to be legible on its own — every state spelled out, every edge case annotated, because the person reading it wasn't in the room. A mockup I'm about to build myself doesn't need that. It can stay rough where the interaction is still uncertain, because the next step is testing it in code, not handing it off for someone else to interpret.
What the loop looks like in practice
In practice the loop is short enough to feel physical. I watch someone fight the interaction model in the morning, and because the person who saw the friction is the person who ships the fix, the distance between the two is a to-do list, not a planning cycle. An interview in the morning can be a shipped change that afternoon — there's no second person's queue to wait in.
It also changes what gets protected. When the person who designs a state is the one who ships the code for it, the idea doesn't get quietly simplified somewhere between the mockup and the API — and the compromises that do happen are at least made by someone who knows exactly what's being compromised.
A handoff isn't just a delay. It's a translation step, and translation steps lose things.
Latency is the real material
For an AI product this matters more than it would elsewhere. Latency, streaming, and half-finished generations are the actual material of the interface — not an edge case to handle later, but the thing most screens spend most of their time showing. I only understood that properly once I had to implement it against the model providers MML ONE routes through. A static mock can show a finished result and a loading spinner. It can't show you what a creator sees for the four seconds in between, or what happens when a video model returns something usable but not quite right. Designing and building the same feature means the design accounts for what a model actually returns, not what a mock wishes it returned.
What this costs
The obvious risk of running research, design, and engineering through the same person is that nobody is positioned to challenge the framing. If I misread what a creator needs, there's no designer in the next seat to say "are you sure that's the problem?" before I've already started building the answer.
The weekly creator sessions are the check against that — an external signal I didn't generate myself, on a fixed cadence, whether or not last week's read turns out to be right. And this isn't the only way I know how to work: the CAD redesign I ran in the same period was pressure-tested with the engineers and PM who had to live with it, and my research years ran through co-authors and an advisor by default. Running the full loop myself is a deliberate choice for this stage of this product, not a limitation.
Why it's worth it here
MML ONE is trying to make a genuinely unstable material — nondeterministic generative output — behave like something a filmmaker can trust. That kind of problem changes shape as you learn more about it, and a design that gets fully specified before anyone writes code tends to fossilize around whatever was true the week it was drawn. Keeping research, design, and code in one loop means the product can keep changing shape as fast as the understanding does. More on how that shows up in the actual interaction model is in the MML ONE case study →, and more about how I got here is on the About page →.
