Phase 4 of 6

Run /visionaire:start

Most bugs aren't code bugs. They're interactions nobody designed.

Translate your approved Product Brief into user flows, interaction patterns, and interface decisions — before architecture commits to any implementation approach. Experience first. Structure second.

Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after
See how it works  →
One payment. Keep it forever. Runs locally. No telemetry.
04
UI/UX Design
UIUX.md
Experience defined. Architecture informed.
UIUX.md
ARCHITECTURE.md
F-001...F-N
1# UIUX.md — ScopeGuard
2# Product: Scope change tracking · Design agency workflow
3
4## User Flows
5Primary Flow — Sarah logs a change request
6 1. Receives client email requesting revision
7 2. Opens ScopeGuard · navigates to active project
8 3. Taps "+ Request" · pastes or types change description
9 4. System links change to approved spec item or flags as new
10 5. Sends approval link · client approves or declines in-app
11 6. Audit trail updated · Sarah sees approval timestamp
12
13## Screen Inventory
14 Dashboard — active projects, pending approvals
15 Project Detail — spec items, change log, timeline
16 Change Request — create, link to spec, add context
17 Client Approval — read-only, approve/decline, comment
18 Audit Trail — timestamped, exportable as PDF
19
20## Interaction Patterns
21Modal for change creation · no full-page nav interruption
22Inline spec linking via search · not manual ID entry
23Client view: no login required · token-based link access
24
25## Design Constraints
26Platform: web · primary users on desktop · clients on mobile
27Accessibility: WCAG 2.1 AA · full keyboard nav · ARIA labels
28Performance: <1.5s TTI · no spinner for interactions <300ms
29
30✓ User journey coverage — PASS
31✓ Screen and surface clarity — PASS
32✓ Interaction and state definition — PASS
33✓ Constraint declaration — PASS
34✓ Architectural derivability — PASS
35→ UIUX.md APPROVED · Architecture ready
If you skip this phase
  • You will assume flows are obvious because they are obvious to you.
  • Your developer will make interaction decisions in the moment, without context, under deadline.
  • You will fix the same "small issues" repeatedly without realizing they come from the same undesigned gap.

None of this is theoretical. These are the patterns that show up every time.

"Delete task" ships without a confirmation dialog. Users lose work. You schedule a sprint to fix it.

That's the under-specified interaction category. The one nobody designed, nobody caught in review, and nobody noticed until a user lost something real. A product design consultant reviews every user journey and catches exactly this — before a developer sees the spec.

Engineers design the interface
Without explicit UI/UX guidance, interface decisions get made while solving technical problems. A senior engineer implements Settings as a single page with 47 fields because "it's one CRUD form." Users open it, see a wall of options, and close without changing anything. The interface is technically correct. It's also unusable.
Inconsistent patterns across screens
Engineer A adds a save button top-right. Engineer B puts it bottom-left. Engineer C auto-saves on blur. Users learn the pattern in one place, apply it elsewhere, and it fails. Every inconsistency forces users to stop and think. Without UI/UX specs, your interface doesn't even work the same way as itself.
Accessibility as afterthought
Three months before launch, someone runs an audit: 127 contrast failures, no keyboard navigation, touch targets too small, focus indicators invisible. Options: delay launch to fix it, or ship inaccessible — excluding 15–20% of users. When accessibility is designed in from the start, the decisions take minutes. Retrofitting takes weeks.
Critical states nobody designed
Your dashboard looks great with sample data. Launch day: real users log in and see a blank screen. No welcome. No guidance. Just a "Create Project" button. 40% of new users abandon without creating anything — because nobody designed the empty state. Engineers built the happy path. Real users live in the edge cases.
Product Brief requirements lost in translation
Your Product Brief mentioned admin users who curate content. Architecture begins. Someone asks: "Where's the admin interface?" Nobody designed it. Everyone assumed someone else would. The Architecture phase can't design systems for a workflow that wasn't specified. Discovery of this gap mid-architecture means returning, revising, re-reviewing — and restarting.
Responsive design ignored until launch
Your app works perfectly on a 27-inch monitor. A user tries it on their phone. Navigation is cut off. Buttons are too small to tap. The user opens your competitor's app. It works on mobile. You just lost a customer to a responsive design failure that would have taken 30 minutes to spec upfront and took 3 weeks to retrofit.

UX decisions made during implementation are made under time pressure, inside technical constraints, by people solving engineering problems. That gap gets filled — the question is when and by whom.

From architecture guessing at experience to architects designing systems that serve it.

The UI/UX Phase extracts every experience decision before a single architectural choice constrains it. What you get is a specification concrete enough that no architect has to guess.

Before UI/UX Phase
it should be intuitive clean dashboard works on mobile too admin can manage things some kind of approval flow errors handled gracefully accessible I guess
UIUX.md
Flows — 3 primary journeys, step-by-step, with failure paths
Screens — 5 named surfaces, purpose and actions documented
Patterns — modal creation, inline spec linking, token auth
States — loading, error, empty, success — all defined
Access — WCAG 2.1 AA, full keyboard nav, ARIA
Gate — 10 criteria PASS · Architecture can proceed

What the stage gate checks — and why "looks complete" is not enough to pass it.

The standard isn't aesthetic judgment. It's whether an architect can design the system without guessing at a single UX decision. Ten criteria. All must pass.

01
Product Brief comprehension before the first question
Before any interview question is asked, the agent reads BRIEF.md and presents a comprehension summary: the problem, target users, use cases, success criteria, scope boundaries. You confirm or correct. Misalignment caught in 30 seconds, not after hours of misaligned design.
02
One question at a time
No 8-question essay prompts. No overwhelming intake forms. Each question is asked individually. When you go deep on one topic, the interview follows. When an area is clear, it moves on. Adaptive depth over surface-level breadth.
03
Pre-outline gap check before any writing
After the interview, before committing to structure, the agent reviews the Product Brief again with your answers in mind. Use cases without user journeys? Target users without designed workflows? Gaps are surfaced and resolved before the outline is drafted — not discovered after full expansion.
04
Outline approval before expansion
Structure is presented before detail. A one-page outline confirms direction before a five-page specification is written. Structural misalignment caught at outline stage costs 30 seconds. Discovered after full expansion costs hours. You approve explicitly before expansion begins.
05
Skip detection for non-UI projects
Pure APIs, CLIs, libraries, background services — if the Product Brief describes a project with no user-facing interface, the phase detects this automatically and routes to Architecture. No forced UX interview for projects that don't need one. Efficient workflow, inapplicable phases avoided.
06
Implementation-agnostic specification
The specification defines what users experience, not how it's built. No frameworks prescribed. No libraries specified. No technical implementation patterns locked in. Architects retain full flexibility to choose the right technical approach for the experience defined.
07
Silence about constraints is not allowed
Silence about accessibility is not permitted. Silence about responsiveness is not permitted. If there's no WCAG requirement, the spec must say so explicitly — and why. If mobile isn't a priority, that's documented. Ambiguity creates architectural guesswork. Every constraint is declared, even when the constraint is "none."
08
Architectural derivability is the standard
The UI/UX Review passes only if an architect can design the system without guessing at any UX decision. Too abstract? Fails. Missing states? Fails. Accessibility undeclared? Fails. The standard is functional clarity, not aesthetic judgment. A REJECTED review means something needs clarifying — not that the design is wrong.
Every architectural decision that follows executes on this

Missing UI/UX specs force 3–8 hours of rework per gap discovered in architecture.

Architects who don't have a UX spec make UX decisions. Those decisions get built into data models, API contracts, and component boundaries. Changing them later means rewriting the architecture, not just the UI.

Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after

Experience to document in 6 steps.

The outline-first pattern catches structural misalignment before prose is written. The pre-outline gap check catches Product Brief misalignment before structure is committed.

01

Product Brief Comprehension Review

The agent reads BRIEF.md and presents a structured comprehension summary anchored on Design Intent: the core problem, target users, primary use cases, success criteria, scope boundaries. The workflow halts. You confirm the agent understood correctly — or correct it before a single design question is asked.

02

Adaptive Interview

One question at a time across six categories: user journeys, screens and surfaces, interactions and states, accessibility, responsiveness, and performance. The agent adapts based on what needs depth and what's already clear. When you go deep, it follows. When an area is settled, it moves on.

03

Pre-Outline Gap Check

After the interview completes, the agent reviews the Product Brief again with your responses in mind. It checks for gaps: use cases without user journeys, target users without designed workflows, success criteria without UI support, scope items not reflected in navigation. Follow-up questions resolve gaps before outline commitment.

04

Outline Generation and Approval

Produces UIUX-outline.md: user journeys, screens, interactions, states, accessibility, responsiveness, performance — plus explicit assumptions and identified gaps. You review before expansion. Corrections cost minutes at this stage. Corrections after full expansion cost hours.

05

Full Specification Expansion

Approved outline expands into UIUX.md: detailed user journeys with failure scenarios, screen specifications with all states documented, interaction patterns with triggers and constraints, accessibility requirements, responsive strategy, and performance constraints. Nothing is left for architects to infer.

06

Stage Gate Review

An autonomous review agent evaluates UIUX.md against ten criteria: design intent completeness, end-to-end system journey, onboarding and first-use definition, user journey coverage including failure scenarios and recovery paths, screen and surface clarity including all four states, interaction and state definition including error recovery, destructive actions documentation, constraint declaration, success criteria alignment with the Product Brief, and architectural derivability. APPROVED only if all ten pass. REJECTED triggers revision with a specific report on what's missing and why it matters.

Stage Gate

UI/UX Design has a formal stage gate. An autonomous review agent evaluates UIUX.md against ten criteria before Architecture can proceed. APPROVED means an architect can design the system without making a single UX assumption. REJECTED means gaps exist — the review report names each one specifically.

Three ways the gap check finds what the interview missed.

The stage gate rejects. The gap check surfaces a workflow you forgot. The phase detects a project that has no interface. Here's how each plays out.

Scenario 01

The stage gate rejects a document you thought was complete

You ran the full interview. You approved the outline. UIUX.md looks thorough. The review agent comes back: REJECTED. "Client approval flow: success state undefined. Audit trail screen: mobile behavior undocumented. Keyboard navigation: declared as required but no detail on tab order for modals." You thought you were done.

The rejection report is a map to exactly what's missing. Three specific gaps, each with a one-line explanation of why an architect needs that answer. You address the three points. The agent revises. Second review: APPROVED. Architecture proceeds without anyone guessing at a single UX decision.

What you walk away with

UIUX.md-v2 that passes all ten criteria — a document where every state is named, every constraint declared, every screen's mobile behavior documented before architecture builds anything.

Scenario 02

The gap check surfaces a workflow your Product Brief implied but nobody designed

Your Product Brief described admin users who manage the spec library and approve change requests. The interview covered Sarah's workflow in detail. The gap check runs: "BRIEF.md identifies admin users as a distinct role with spec management permissions. No admin workflow appears in the interview responses." You realize you never thought through the admin experience at all.

Four follow-up questions cover the admin interface. The agent confirms the outline now includes both user types. The spec it produces covers Sarah's daily workflow and the admin controls she needs to set up projects and manage permissions. Architecture gets the full picture — not just the primary user's half of it.

What you walk away with

A UIUX.md that reflects every user type your Product Brief defined — not just the one you were thinking about during the interview. The gap check exists precisely for this.

Scenario 03

Your product has no user interface — and the phase detects it

You're building a background webhook processor. Your Product Brief describes an API that receives events, validates payloads, and routes them to downstream services. No user-facing interface. No screens. No interaction patterns to specify. You run /visionaire:start and wonder if this is the right move.

The agent reads BRIEF.md. It detects the project has no user-facing interface: no dashboard, no screens, no end-user interaction patterns. It confirms its interpretation with you and routes directly to Architecture Phase. No interview. No wasted time on questions that don't apply. The pipeline adapts to what you're actually building.

What you walk away with

Immediate routing to Architecture with a clear note in the pipeline log explaining why UI/UX was bypassed — so the decision is documented, not silently skipped.

Phase 4 of six. The shape before the structure.

Market evidence has been gathered. You know what you're building and that people want it. UI/UX is where "what" becomes "how it feels" — before Architecture makes "how it works" decisions that lock in the experience.

Phase 01
Idea
IDEA.md
Phase 02
Product Brief
BRIEF.md
Phase 03
Market Validation
MARKET-analysis.md
Phase 04
UI/UX Design
You are here
Phase 05
Architecture
ARCHITECTURE.md
Phase 06
Features
F-001...F-N

Architecture reads UIUX.md to understand what it's designing a system to support. Every architectural decision — data model design, API contract structure, component boundaries — is made in service of the experience defined here. Without it, those decisions default to engineering convenience.

You can skip this and move straight to Architecture.

Teams do it. The tradeoffs are the same every time.

Without UI/UX Phase

Faster start, unpredictable cost

  • Architects make UX decisions while solving technical problems — the decisions still get made
  • Error, empty, and loading states designed during implementation, under deadline pressure
  • Inconsistent patterns across screens built by different engineers at different times
  • Accessibility issues discovered in a pre-launch audit when changing them means rewriting frontend code
  • Product Brief requirements missed mid-architecture — the most expensive place to discover them
  • Mobile experience is a degraded desktop, not designed mobile — because nobody specified breakpoint behavior
With UI/UX Phase

Experience-first, architecture informed

  • Experience defined before architecture — architects design systems that serve users, not the other way
  • All states specified: loading, error, empty, success — before a line of code is written
  • Consistent patterns from a single specification all engineers work from
  • WCAG compliance level set before architecture locks accessibility options
  • Every Product Brief requirement verified to have a corresponding user journey
  • Mobile behavior explicitly designed for each breakpoint, not retrofitted after launch complaints
The Reframe

The experience gap between the Product Brief and Architecture gets filled either way. The question is who fills it and when. UX decisions made during implementation are made inside constraint boxes that already exist. UX decisions made in the UI/UX Phase are made before any constraint exists. The quality difference between those two contexts is not marginal.

Two principles that shaped every decision in this phase.

"Design is not just what it looks like and feels like. Design is how it works."

— Steve Jobs · The New York Times, 2003
The UI/UX Phase applies this literally. Not aesthetic polish applied after the system is built — but functional experience design before a single architectural decision is made. How users search, how errors surface, how states transition, how screens connect to each other: these are design decisions that determine how the product works, not just how it looks. They belong here, not inside a pull request.

"Good design is actually a lot harder to notice than poor design, in part because good designs fit our needs so well that the design is invisible, serving us without drawing attention to itself."

— Don Norman · The Design of Everyday Things
The goal of UIUX.md is not a beautiful document — it's a specification so thorough that the experience it describes feels inevitable when built. That invisibility doesn't happen by accident. It happens when the questions that expose UX requirements are asked deliberately — before the code starts — and answered explicitly enough that no one has to guess later. When experience design is complete before architecture begins, the result is software that gets out of the user's way.

I built the Product Brief comprehension step into UI/UX after watching architects spend three days reverse-engineering what the product was supposed to feel like — because no one had ever written it down. The stage gate isn't a hurdle. It's the only way to know whether what you wrote is specific enough to build from.

— Robert Evans

Most bugs aren't code bugs. They're interactions nobody designed.

A UX spec reviewed by a product design consultant — before architecture sees it — catches the missing confirmation dialog, the undefined empty state, the workflow nobody thought to draw. A redesign mid-architecture costs 4–6 weeks. This phase costs an afternoon.

$297 < 1 design revision cycle · prevents 4–6 weeks of architecture rework
Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after
One payment. Yours forever. Runs locally in Claude Code. 30-day guarantee.