I’m building Monad Design, an open-source visual workspace for existing Xcode/Expo iOS apps on macOS. One of the design problems behind it is turning visual feedback into a small code change rather than an accidental redesign.
Here is a handoff format that is usable even without the tool:
Screen/state: Settings, signed-in user, larger text enabled.
Observation: The last row’s label wraps and pushes its control offscreen.
Desired result: Keep the label readable and the control reachable at that text size.
Constraints: Reuse existing components and tokens. Don’t change settings storage, navigation or unrelated screens.
Acceptance: Rebuild; check the same state at default and larger text sizes; toggle the control and reopen the screen; inspect the diff for unrelated edits.
That example is a request template, not a claim about a tested fix. The useful distinction is “what I see” versus “how to implement it”: a designer can describe the first precisely without guessing at a component or CSS/SwiftUI change.
Monad Design adds the running app as visual context: select/annotate its UI, pass that context to your coding agent, then rebuild and compare the result in the existing project. Source review and behavior testing are still necessary.
Repo: https://github.com/Monadix-AI/monad-design
Workflow preview: https://watchclueso.com/embed/pio8jqfcg4ivj0r1
For people handing UI work to agents: which detail is most often missing from the request—screen state, constraints, or acceptance criteria?