One File for UI Design: How a Single Open File Replaces Handoff
A one-file UI design workflow keeps layout, states, motion, logic and data bindings in a single open file. What it changes, what it does not solve, and how ExodeUI uses it.
Core Takeaway
A one-file UI design workflow keeps the layout, interaction states, motion, logic and data bindings of a component in one open file instead of spreading them across a design file, a prototype and a codebase. The file becomes the thing designers edit, developers review and AI agents can read. ExodeUI uses this model: an .exode file describes a component, and runtime packages play it in the app.
What does "one file" mean in UI design?
It means the component has one authoritative source. The artboards, the hover and pressed states, the spring values, the conditions that decide which state comes next, and the inputs your app can set all live in the same document. Nothing important is left in a separate handoff note. When the file changes, the component changes.
The handoff problem one file removes
In a typical handoff, the designer delivers a static file plus a prototype and a written description of the motion. A developer rebuilds that motion in code, and the two versions drift immediately. A one-file workflow removes the rebuild step for the parts the file covers. It does not remove the need for review, but it gives reviewers the same artifact instead of two descriptions of it.
What goes into an open UI design file
The exact structure depends on the tool, but a useful file covers the same jobs:
- Layout, including breakpoints and how the component reflows
- Interaction states such as idle, hover, pressed, loading, success and error
- Motion, including timelines, spring physics and transitions between states
- Logic and conditions that decide which state is active
- Inputs and events so application code can drive the component and react to it
- Data bindings for values that come from the app at runtime
What stays outside the file
A component file is not the whole application. Routing, authentication, data fetching, permissions, analytics and the accessibility wrapper around an interactive control stay in your codebase. Platform navigation and system gestures usually stay platform-specific too. Being clear about that boundary matters: a one-file workflow is easier to adopt when it handles the interactive component and leaves application concerns to the application.
Can a team review one file?
Yes, if the format is open and readable. ExodeUI stores a component in an open .exode JSON file, so changes can be diffed, reviewed and kept in version control. That is a practical advantage over binary design files: a reviewer can see what changed in the file, and an AI coding tool can read it without a proprietary decoder. Openness does not answer every governance question, but it makes review possible.
How ExodeUI uses one file
In ExodeUI, an .exode file can hold layout, breakpoints, timelines, state machines, spring physics, logic, inputs and data bindings. Runtime packages play the file in React, Vue, Svelte, Angular, Solid, React Native, SwiftUI and Flutter. Your code passes inputs in and receives events back instead of restating the motion. The same file can be opened in the browser or desktop editor, and AI coding tools can edit it through the MCP server.
When one file is the wrong choice
One file is a poor fit for work that is not an interactive component: long-form video, heavy 3D scenes, or a freeform whiteboard for early ideation. It is also a poor fit when a team has no review process and needs one file to enforce standards by itself. The format can make good practice easier. It cannot replace the practice.
Production Implementation Snippet
import { ExodeUICanvas } from 'exodeui';
// One component, one file. Layout, states, motion and logic stay in the
// .exode file; the app only supplies inputs and handles events.
export function CheckoutButton({ loading, disabled, onComplete }) {
return (
<ExodeUICanvas
src="/checkout_button.exode"
inputs={{ loading, disabled }}
onTrigger={(name) => name === 'complete' && onComplete()}
/>
);
}Key Principles to Remember
- A one-file workflow keeps layout, states, motion, logic and inputs in one authoritative document
- It removes the rebuild step for the interactive component, not the need for review
- Application concerns such as routing, auth and data fetching stay in your codebase
- An open JSON source file can be diffed, versioned and read by AI tools
- ExodeUI plays the same .exode file through runtimes on web, mobile and desktop frameworks