Design Engineer Tools: Why Visual Runtime Matters More Than Another Prototype

The design engineer's problem

A design engineer works between the design file and the production component. They need to see the motion, change it quickly, understand the states and ship something that runs. A tool that only produces a prototype leaves the hardest part, the production behaviour, for later. A tool that only produces code makes it hard to explore. The useful tools sit on the boundary.

What to look for

The feature list matters less than the workflow.

• A runnable output, not only a video or a static spec
• States and transitions that can be inspected and edited
• A code integration path for the framework you ship
• Motion values that can be shared with the design system
• A way to test interruption, failure and reduced motion
• A source a designer can open without reading the codebase

How the common tools differ

Figma is strongest for design and prototyping, with Dev Mode and MCP exposing context to code. Rive is strong for interactive graphics and character state machines. Lottie and dotLottie are strong for After Effects playback, with state machines in dotLottie packages. ExodeUI targets interactive UI with an open .exode file and runtimes across frameworks and mobile. Each has a different centre; none is best at everything.

The shared-source test

Can the designer and the engineer point at the same thing? If the designer edits a prototype and the engineer edits a separate component, they will drift. A shared source can be a design system component, an interactive file or a code component with tokens. The format matters less than the fact that both roles can see and change the same behaviour.

What still needs code

Accessibility semantics, focus management, data fetching, permissions and error handling belong in the app. A visual runtime can own the presentation and interaction states, but it should not become a second application. Design engineers are most effective when the boundary is clear and the runtime has a small, typed contract.

A practical evaluation

Take one real component with loading, error and interruption. Build it in two candidate tools. Measure how long it takes to change the timing, how easy it is to inspect the states, and how much code is needed to ship it. Then test it on a mid-range phone. The tool that survives that test is the one to adopt, not the one with the best demo.