App screens: wireframes first, then hi-fi mockups

The problem this solves

Feature discussions stall at the same wall: everyone agrees on the goal and nobody can see the screens. Written specs hide layout decisions, whiteboard sketches die with the meeting, and the design team's queue means real mockups are weeks away. So the feature conversation loops - the same debate about what goes where, re-argued from memory each time, while engineering waits for something concrete enough to estimate against.

When mockups finally arrive, they compress two decisions into one review. Structure - what lives on each screen and in what hierarchy - gets debated simultaneously with styling, and polish wins the attention. Stakeholders approve a beautiful screen with a structural flaw nobody interrogated, and the flaw surfaces in engineering where it is expensive. Wireframes first is the old discipline for exactly this reason: settle the bones while they are cheap to move, then spend styling effort once, on a structure that has already survived review.

How the mission runs

1. Define the three screens. From the feature described in your thread, the agent identifies the three screens that carry the flow and what each must accomplish: the entry state, the core interaction, and the resolution. Screen intent is agreed in the thread before any drawing, so the wireframes answer the right questions.
2. Design the grayscale wireframes. Design produces the three screens as deliberate grayscale wireframes: real hierarchy, real content placement, real interaction affordances, and zero styling to hide behind. Grayscale is the point - reviewers argue about structure because structure is all there is to react to.
3. Publish the wireframes for structural review. The wireframes go live as a navigable page, and the link is posted to #product in Slack. The team clicks through the flow and argues placement, hierarchy, and sequence in the thread. Structural changes here cost minutes, and the agent revises the live page as decisions land.
4. Build the hi-fi mockups. Once the structure survives review, Design executes the same three screens in your brand style: palette, typography, spacing system, and component styling applied to the agreed bones. Because structure is settled, the hi-fi pass is purely about execution quality rather than relitigating layout.
5. Publish both pages side by side. The hi-fi mockups publish as a second live page, and both links are posted to #product: the wireframes as the structural record, the mockups as the visual target. Engineering gets an unambiguous reference pair, and the approval trail lives in the Slack thread beside the links.

The prompt

This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.

What comes back

Two published live pages posted to #product: a navigable grayscale wireframe set covering the feature's three key screens, and the same screens executed as hi-fi mockups in your brand system after structural review. Together they give engineering a settled structure with an explicit visual target, and the review conversation that approved each stage sits in the Slack thread as the decision record.

Make it yours

• Widen the flow to five screens for features with branching states, keeping the same two-stage discipline of structure first and styling second.
• Publish two competing wireframe structures for the core screen and let #product argue them against each other before any hi-fi work begins.
• Point it at an existing feature that underperforms: wireframe the current structure as-is, then propose the revised structure beside it for direct comparison.

Frequently asked questions

Go deeper

• How AI agents execute marketing work, step by step
• Approval queues that keep autonomy fast