Simile

A traditional handoff asks a single 2D artifact to carry an enormous amount: visual design, hierarchy, content, interaction intent, system behavior, edge cases, and future states. Annotations cover what the canvas can't, and developers infer the rest. For a simple product that holds up. It starts to fail once the product has real state.

Take a screen where a homeowner approves an agent's access to a property. The mockup can show exactly what approval looks like; the harder question is what approval means. Does the action open a timed access window, and does it notify the agent? What happens when the request expires, or when the seller denies it? What did the agent see beforehand, and what does the brokerage need to know after? Some of that is content and some of it is behavior, and the mockup treats both the same way — which is how the behavior ends up traveling as a guess.

Those are product design decisions, and they rarely survive the trip to implementation in any structured form. They turn into interpretation. The developer builds what seems right, the team reviews it later, and often the result is fine. Sometimes, though, the app becomes a pile of reasonable local decisions that don't add up to the experience anyone intended. I built Simile to make those decisions explicit earlier — without asking designers to write more documentation to do it.

I didn't want Simile to be one more place to draw a picture of an app. The test I held it to was whether it could move a team from loose intent to a working product model.

That meant it couldn't depend on one perfect starting point. The work might begin with a polished Figma frame, a screenshot of an old app, a rough idea typed into chat, a design system that needs applying to screens that already exist, or a single piece of stakeholder feedback. The tool had to meet the work wherever it was, so I built several paths into the same underlying model.

You can import from Figma, drop in screenshots that get scanned and rebuilt as working surfaces, or describe a screen in chat and have Simile assemble it from the project's primitives, including iOS-oriented ones. You can load a design.md file into a project and apply that design system to individual screens from a dropdown. A working Figma plugin syncs back to the design file when a handoff needs to land there. However the work starts, it becomes something the team can inspect, revise, and build from.

One of my earliest decisions was that Simile should render working surfaces, not static previews — and that choice carried more weight than it first appears. When a screen is live in the browser, stakeholders can interact with it, select individual elements, and leave comments on the exact part of the experience they mean, where the rest of the team can see and answer them. Feedback stays attached to the product. In a normal workflow it scatters: a note in Figma, a clarification in Slack, a decision on a call, a ticket the developer reads without the context that produced it. Keeping the review surface and the product surface the same thing closes that distance.

It also makes phone review immediate. Because Simile loads as a PWA, a reviewer can open the flow on a phone without waiting for a simulator or a TestFlight build — and some judgments only arrive that way. A layout that reads clearly on a desktop canvas can feel heavy in the hand. A primary action that looks obvious in a mockup can sit buried in the actual flow. Catching that before a build hardens around it is most of the value.

The workspace is the visible part of Simile — screens, flows, comments, imports, design-system application, phone review. The part I care about most sits underneath it. When someone says "this button should request access," that instruction can't stay as button copy: it may need to become an action, create or change a state, open a transition, and join a flow — and every one of those consequences is something a developer has to build later. In a normal workflow they live in someone's head until they don't. So I built Simile to record them. Each decision drops into a structured contract layer in the background, and no one authors that layer by hand — you work by importing, prompting, correcting, dragging screens into flows, and answering feedback, while Simile translates what you do into the product model.

That model compiles into a graph — a way to see how screens, states, actions, transitions, components, and flows actually relate, instead of leaving those relationships implied by the mockup and reassembled from memory later. The surface is what lets people see and argue about the product. The graph is what keeps the behavior from quietly disappearing between conversations.

Figma stays in the loop because teams already work there, and removing friction from a workflow shouldn't mean tearing out the tools that already work. We don't need to abandon what's working — we need to remove the friction around it. So Simile imports from Figma, and the plugin syncs back when a handoff calls for it. What Simile doesn't do is treat Figma as the source of behavioral truth. A frame carries layout, hierarchy, content, and visual intent; it can't, on its own, say what state the product is in, which actions are legal, what should happen next, or what the app owes the user under a given condition. Figma can be an input or an output. The behavior belongs in the product model.

The design.md workflow came out of a practical problem: imported evidence isn't all target truth. A screenshot might be a loose reference, a Figma frame might be out of date, a competitor screen might be useful for structure but wrong for style, and a generated screen needs to follow the project's real design language before anyone can judge it fairly. So you can load a design.md file into a project and apply it to a screen, and the surface updates on the spot. That turns the design system from a reference document into an active input — one that reinterprets messy sources through the language the product actually uses, instead of copying them pixel for pixel.

AI earns its place in Simile because the input arrives messy. One person asks for a screen where a homeowner can approve access for fifteen minutes; another drops in a screenshot to rebuild; a third types "this button should request access and move the user into the pending state." Translating instructions like those into the structured layer underneath is work AI is genuinely good at, and I lean on it there without hesitation.

What I wouldn't let it do is become the authority. Generated output isn't correct because it was generated, and a tool that behaves as if it were trains a team to stop checking — the opposite of what I wanted Simile to do. So I fixed the roles: I guide the product, Simile records the guidance, the model preserves the relationships, and the surface gives everyone something concrete to correct and sign off on. AI moves the work from rough intent to structured behavior. The people still own the result.

Developers are usually handed artifacts that look finished and still leave the important behavior open. Simile closes that gap with more than a clearer picture. What a developer gets is structure.

A surface built in Simile isn't a flat mockup. It's a component tree, responsive by design across phone sizes, that renders in React today and generates SwiftUI scaffolds from the same product model. The structure already reflects how the app is meant to be assembled: components, slots, actions, bindings, states, transitions, and the design tokens that carry the visual language.

The behavior comes with it. The contracts beneath the workspace codify the system behavior instead of leaving it implied — what actions exist, which states the product has, how screens transition, and what holds true under each condition. That model exports as developer-facing artifacts, and it's the part a static handoff almost never carries: the part teams most often rebuild from memory.

The point isn't to take judgment out of development. It's to stop making developers reconstruct intent from static evidence. When the model is explicit, the whole exchange changes. Designers keep the reasoning behind their decisions, developers get structured components, tokens, and codified behavior to build from, and stakeholders get a live surface to react to. The handoff stops feeling like translation and starts feeling like continuation.

None of this is hypothetical. I built Simile because I needed it, and the proof is a client engagement where I rebuilt their app inside it from scratch, starting from only thin Figma files.

In Simile I designed everything those files couldn't carry: motion, haptics, every empty state, and the corner cases that decide whether a product feels finished rather than merely drawn. What I didn't expect was how much the real, connected surfaces caught before any build code existed. Flows that read cleanly on the canvas turned out to have gaps the moment the screens were live and linked — the kind of problem you normally find in QA, or worse, in production. We resolved them in Simile, while they were still cheap to change.

The phone review is where the value compounded. Because the surfaces ran as a PWA, the client opened the work on their own phones — no simulator, no TestFlight build — and left feedback directly on the screens it referred to. Judgments that only arrive in the hand surfaced early: a layout that felt heavier than it looked on a desktop canvas, a primary action that seemed obvious in a mockup but sat buried in the actual flow. The whole review stayed attached to the product instead of scattering across threads and meetings, and that's the part the team and I valued most.

That engagement is the version of handoff this piece argues for, and it's how I now run product work in my consultancy. Simile isn't publicly available. It's the tool behind the work.

The hard part of this work was never generating another screen. It's keeping the original thinking intact as the work moves from idea to design to review to implementation — which is exactly where teams lose time and products lose coherence. That gap isn't specific to any one product or tool. Every team that ships software loses some intent between the design and the build, because apps aren't static and the documents we design them with are. Closing that distance, so the thinking survives the trip, is the part of product work I most want to get right. Simile is one way I've tried to do it.