Your design file wants to be the product, not a picture of it

For years the deal has been the same. You design a screen. Someone else builds it. The two versions drift apart. Everyone shrugs and calls it handoff.

That deal is starting to break, and in a good way. A handful of people building real tools are asking a sharper question: what if the design file, the dashboard, the customer research all stopped being static artifacts and became live surfaces that the software uses directly? Let me catch you up on where this is heading and what it means for your roadmap.

The file that ships itself

The oldest pain on your team is the fork. The designer edits one artifact. The app ships from another. Someone translates between them, and both stay editable, so they drift. Selman Ay, who spent fifteen years across IBM iX, Vodafone, and Getir, calls it plainly: the handoff problem is a source-of-truth problem, not a communication one.

His fix is a protocol called DESEN. The designer builds an interface, publishes it as a validated bundle, and the app runs that bundle directly. No screenshot-to-code step. No second implementation. The design is the runtime document.

The smart part is where he draws the line. Designers own the composition and the experience behavior: what happens when the button is pressed, what shows while a request is pending, what failure looks like. Developers still own the API calls, tokens, and business rules. The document holds no raw JavaScript. It can only reference capabilities the app already exposes.

The dashboard that reads the question

Same idea, different surface. Kishan has built the same dashboard a dozen times: fifteen filters, tabs, drill-downs. It ships, and the first question is one it can't answer without three dropdowns and a squint. You froze a layout weeks ago and now you're making human intent bend to it.

His answer is an intent-driven UI. The screen assembles itself from a small kit of trusted components based on what the user actually asked. Not a chat box that spits back a wall of prose. An orchestrator reads the question, picks a metric card and a bar chart and an alert banner, and lays them out.

The guardrail matters more than the trick. The model is a router, not an artist. It never touches the numbers. It emits validated JSON that says which components to show; your existing design system does the rendering. "Boring is the feature," he writes, and he means it as a compliment.

The proposal that traces back to a real quote

The third move points the same direction, but starts from research. You finish synthesis. The themes are clear. People nod at your slides. Then very little happens. Josh Thompson names the reason: the translation step is missing, the one where "customers want a more refined grain" becomes something a product team can react to.

His platform turns customer dialogue into structured, evidenced signal, then feeds it into a mask-guided image edit that produces an actual design proposal. "Customers want a more refined grain" is not a design brief. His system makes it one, without losing the trail.

That trail is the whole point. Every concept carries its provenance. A designer can ask "why did you propose this?" and walk the chain back to specific quotes from specific participants in specific sessions. Left unconstrained, he warns, generative image models collapse toward their training prior. Fine for art, disqualifying for product.

Where the accuracy actually lives

Here's the part that should slow you down before you hand a whole workflow to a model. Kolozsi István gave two paid models a full UX review with the brief, the research, the analytics, and the heatmaps. Both produced analyses full of irrelevant and even non-existent problems. Useful bits existed, but mostly at the level of wording. A 2025 study he cites found GPT-4o caught about a fifth of the usability problems experts found, while inventing new false ones.

His takeaway is the one worth pinning up. The accuracy doesn't come from the model. It comes from the expert framework you feed it. Baymard hit 95% accuracy on heuristic evaluations not through better prompting but by grounding the model in their own researched knowledge base.

So the pattern across all three tools holds here too. The model composes and routes. The trusted foundation, your components, your data, your expertise, does the load-bearing work.

The deep cut

The common thread is not "AI makes design faster." It's that these tools only work when a human-owned foundation does the heavy lifting and the model just composes on top. DESEN pins capability versions so the model can't invent a component. The dashboard forbids the model from touching a single number. The research studio composites the real baseline back over the generated pixels so the roof and windows can't drift.

That changes what you build first. Before you chase a generative feature, invest in the fixed kit underneath it: a real component contract, a clean data seam, an encoded set of your team's standards. The magic layer is cheap. The trusted foundation is the work, and it's the thing that decides whether you ship a demo or something you can put in front of a CFO.

Three questions for your team

1. Where does our work still fork into two editable truths, a design file and a separate build, and what would it cost to make one of them the source the other reads from?

2. Do we have a small, validated component kit that a model could safely compose from, or would we be handing it freeform control it will abuse the first time it forgets to close a div?

3. When we lean on AI for research or reviews, can we trace any output back to the specific evidence and expertise behind it, or are we shipping a black box and calling it grounded?