The AI UX Designer for Flows and Wireframes

The most expensive mistake in software development is building the wrong thing with the right execution. A beautifully implemented feature that confuses users on step two, an onboarding flow that loses forty percent of signups at the email confirmation screen, a dashboard layout that requires five clicks to reach the action users need every day, these are not engineering failures. They are design failures that engineering delivered faithfully. The discipline that prevents them is UX design at the wireframe and flow stage: the work that happens before any interface is built, when the cost of changing a decision is measured in minutes of annotation rather than weeks of refactored React components. That early-stage work is what most product teams skip, not because they do not value it, but because they do not have a designer available at the pace a development team moves, and because asking a generalist AI for a wireframe produces something that looks like a design artifact without containing any design reasoning. AI UX designer tools that generate pretty mockups are solving the wrong problem. The problem is not generating pixels, it is working through the logic of how a user moves through a system before the system is built.

Why the generalist approach fails at UX work

Ask a generalist chatbot to produce a user flow and you get a list, numbered steps in a linear sequence, occasionally with a branching note if you specifically ask for it. What you do not get is a flow that models the decision points a user faces, the error states that need handling, the dead-ends that send users backward, or the happy path versus the recovery path for every branch. A real user flow is a model of the system's behavior as experienced by a user, not a list of screens. The difference between a flow and a list of screens is the same as the difference between a program and a collection of statements, structure, branching, and the explicit handling of every case, not just the case where everything goes right.

Figma templates solve a different problem. They give you pre-built UI components and layout structures, useful when you know what you are building and need it fast. They are not a substitute for information architecture work, which is the prior question: what content and functionality belong in this product, how is it organized, and what navigation model makes that organization findable? Dropping a Figma template onto an unresolved IA problem produces a product that looks polished and is structurally disorganized, the UX equivalent of building a well-finished house on a bad floor plan. The template does not know what goes where. Only the IA work does.

AI UI generation tools, v0, Galileo, similar, produce interface screenshots from prompts. They are remarkably good at generating plausible-looking screens and useful for rapid visual prototyping. What they do not produce is the reasoning behind the interface: why this navigation model over that one, what the information hierarchy implies about user priorities, where the user experience breaks down under error conditions, whether the form can be completed without needing to leave and find information, or whether the flow has accounted for the user who arrives with a different mental model than the one the designer assumed. UX design is not screenshot generation. It is decision-making under uncertainty about how humans will interpret and navigate a system, and that decision-making requires a different tool than one optimized for generating attractive pixels.

What a UX designer actually does

A senior UX designer approaching a new feature starts with the user's goal, not the interface. They map who the user is, what they are trying to accomplish, what they know and do not know when they arrive, and what a successful completion looks like from the user's perspective. From that model, they derive the information the interface needs to surface, the sequence of decisions the user needs to make, the points where the user is most likely to get confused or stuck, and the recovery mechanisms the system needs to provide when the happy path breaks. The wireframe is a tool for communicating that reasoning, not an end in itself, a way to make the flow visible to stakeholders and developers who need to build it. A wireframe without a flow rationale is just a drawing. A wireframe with a flow rationale is a specification.

The usability review dimension of UX design is equally undervalued. A heuristic review against Nielsen's ten principles, a cognitive walkthrough from the perspective of a first-time user, a review of every form field for unnecessary friction, these are systematic analyses that find problems before users do. They require knowing what to look for, which is expertise, not content generation. A designer reviewing a flow for heuristic violations is applying a structured framework to identify specific categories of failure: visibility of system status, match between system and the real world, user control and freedom, error prevention, recognition over recall. These are not obvious from looking at a screenshot, they require analytical attention to the interaction model.

Meet Draft

Draft is Tonone's dedicated AI UX designer, a purpose-built agent for the full UX workflow before the visual layer: user flow mapping, information architecture, wireframe production, usability review, and landing page structure. It does not generate pixels or produce Figma files. It produces the reasoning, structure, and annotated specification that tells visual designers and developers exactly what to build and why. Draft brings UX expertise to the work that happens before the design tool opens: the decisions about how a system should work that determine whether the finished product is usable, regardless of how well it is visually executed.

Tonone's Draft is the AI UX designer that maps complete user flows with branches and error paths, produces annotated wireframe specifications, and reviews flows against usability heuristics before any interface is built.

What Draft actually does

Mapping user flows with full branching and error paths

The draft-flow skill takes a feature description and produces a complete user flow: happy path, all decision branches, error states, recovery paths, and dead-end handling. The output is a structured flow diagram in Mermaid or annotated text, every node labeled with the user's state and the system's response, every branch labeled with the triggering condition, every error state connected to a recovery path. The flow explicitly distinguishes between states where the user makes a decision, states where the system processes, states where the system needs input it cannot predict, and states where the user can recover from an error without starting over. This level of completeness is what separates a flow that a developer can build from a flow that leaves implementation decisions to the developer, and implementation decisions made by developers without UX context are the source of most usability problems that emerge in QA. draft-flow also annotates each step with the user's mental model at that point in the flow, making it easy for reviewers to identify steps where the system's behavior will violate the user's expectation. The flow output is typically the first artifact that gets handed to both engineers and visual designers as the definitive spec for a feature.

Producing annotated wireframes with component placement rationale

The draft-wireframe skill produces text-based wireframes for each screen or state in a flow, structured layouts with component placement, content hierarchy, and annotations explaining the design decisions. The wireframe format is deliberately low-fidelity: it communicates structure and content hierarchy without styling, so reviewers focus on the interaction logic rather than visual polish. Each component in the wireframe includes an annotation: why it is placed where it is, what behavior it triggers, what the system displays in the empty state versus the populated state, and what happens when the user interacts with it incorrectly. draft-wireframe also flags components where the design decision is genuinely uncertain, where two approaches have different trade-offs and the right choice depends on data about user behavior that the team should validate before committing. This converts the wireframe from a deliverable into a conversation starter, surfacing the design decisions that need alignment rather than embedding them invisibly in a polished mockup. Teams that work from annotated wireframes before moving to Figma consistently find that they spend less time revising visual designs because the structural decisions were made explicitly, not discovered during design review.

Structuring information architecture for findability

The draft-ia skill takes a product's content and functionality and produces an information architecture: a taxonomy of what exists in the product, a navigation model that makes it findable, and a content hierarchy for each major section. The IA output includes: a top-level navigation map with rationale for the groupings (why these items are grouped together, what mental model the grouping assumes), a page hierarchy for each section, a labeling vocabulary that matches how users think about the content rather than how the organization thinks about it, and the key findability risks, the items that users will look for in the wrong place because the label or grouping assumes knowledge they do not have. draft-ia is the skill that prevents the most common structural UX problem: a product where everything is there but nothing is findable, because the organization was built around internal categories rather than user mental models. It also produces a card sort brief if the team needs to validate the IA with real users before building, a ready-to-run research activity that Echo can execute.

Reviewing flows against usability heuristics

The draft-review skill takes a flow or wireframe and reviews it systematically against a full set of usability heuristics, Nielsen's ten principles, Fitts's Law for touch targets, cognitive load theory for form design, and progressive disclosure principles for information-dense interfaces. The output is a structured findings report: each issue described with the specific heuristic it violates, the user behavior it will likely cause (confusion, error, abandonment, or missed functionality), and a concrete recommendation for the fix. Issues are prioritized by severity: cosmetic (does not affect completion), friction (slows completion), error-prone (causes recoverable errors), and blocker (prevents completion). draft-review is most valuable when applied to an existing product as a cold-eyes audit, finding the usability debt that accumulated as the product was built feature-by-feature without a systematic UX review. It produces a prioritized backlog of UX improvements that a team can address incrementally without a full redesign, and the severity scoring ensures the highest-impact fixes happen first.

Designing landing page structure and conversion flow

The draft-landing skill produces a landing page information architecture and content flow: section order, content purpose for each section, the hierarchy of evidence (what the visitor needs to know first, what addresses the key objection, what triggers the conversion action), and the CTA placement rationale. The output is not a visual design, it is the structural specification that tells the visual designer or front-end developer what each section needs to communicate and in what order. draft-landing is grounded in conversion flow principles: above-the-fold must answer the visitor's first question (what is this?), the middle sections must resolve the key objections before the visitor reaches a decision point, and every CTA must be placed at the moment of maximum commitment, after enough evidence to convert, before the user has scrolled past the point of engagement. The skill also produces an information hierarchy for each section: the primary claim, the supporting evidence, and the trust signal, in a structure that works regardless of the visual execution.

A worked example

A team needs to design a checkout flow for a SaaS product that involves a free trial, a credit card pre-authorization, and a plan selection step. The product manager has a rough description: users pick a plan, enter payment info, get a confirmation. Draft is given the brief and runs draft-flow to produce the full user flow before any wireframes begin.

The flow output includes branches the PM had not considered, returning user who wants to upgrade, user whose card declines, user who wants to compare plans before committing. An excerpt of the Mermaid flow looks like this:

User Flow, SaaS Checkout (draft-flow output)

[Start: Clicks "Start free trial"]
      |
      v
[New user?]
  ├─ Yes → [Plan selection screen]
  │           ├─ Selects plan → [Payment entry screen]
  │           │                   ├─ Card valid → [Confirmation + onboarding]
  │           │                   ├─ Card declined → [Error: retry / try different card]
  │           │                   │                    └─ 3 failures → [Support contact offered]
  │           │                   └─ User exits → [Cart abandonment email queued]
  │           └─ Wants to compare → [Plan comparison drawer]
  │                                   └─ Closes drawer → [Returns to plan selection]
  └─ Returning user → [Upgrade path: current plan shown, upgrade options listed]
                         └─ Selects upgrade → [Confirm change screen (no re-entry of card)]
                                               └─ Confirm → [Success: plan updated]

Notes:
- Card pre-auth happens at payment entry, NOT at confirmation.
- Error states must not clear previously entered card info.
- Plan comparison must be accessible without leaving checkout context.
- Trial end date shown prominently at confirmation (reduce churn surprise).

After the flow is approved, draft-wireframe produces annotated screens for each state. The payment entry screen wireframe includes an annotation flagging that the card field label should use the term the card network uses ("Card number", not "Credit card number") to reduce mental friction for debit card users, a detail that would typically be discovered during usability testing, not design review. The team moves from this specification into Figma with zero ambiguity about what each screen needs to communicate. Design review focuses on visual execution rather than structural debates, and the flow is validated against usability heuristics via draft-review before the first line of frontend code is written.

Draft vs the alternatives

Draft is not a UI generation tool and it is not a Figma plugin. It occupies the structural reasoning layer of UX work, the decisions about how a system should work that determine whether it is usable, independent of how it is visually executed. The comparison below makes the functional differences concrete.

Tonone's Draft draft-review skill audits flows and wireframes against Nielsen's ten heuristics, cognitive load theory, and progressive disclosure principles, producing a severity-scored findings report before any interface is built.

Tonone's Draft draft-ia skill produces an information architecture that labels content using the user's mental model rather than the organization's internal categories, the structural work that determines whether a product is findable.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Draft, are available in your Claude Code session. You pay only for the Claude Code token usage during work. Start with draft-flow on your next feature brief to surface the branches and error states before your visual designer opens Figma.