A structured pipeline for designing user interfaces. Architecture before aesthetics. Every stage produces a gate artifact. No stage can be skipped. Visual design cannot begin until the architecture is locked.
The default failure mode in UI design is showing everything on one screen. This happens because visual design starts before information architecture decisions are made. Styling a cluttered interface does not fix it — it produces a prettier cluttered interface.
GAIT forces architecture before aesthetics. Six stages, six gates. The person reviewing the design has one question at each gate. If the answer is no, fix that stage before proceeding.
Who this is for: Practitioners who ship products — not design theorists. Engineers and architects who own the entire pipeline from research through deployed code. Teams where the same person (or AI agent) who researches the domain also builds the final application.
What this is not: A design system. A component library. A course. GAIT is a decision-making pipeline that tells you what to decide and in what order — your design system, components, and tools plug in at Stage 5, not before.
| Stage | Name | Mode | Gate Question |
|---|---|---|---|
| 1 | Domain Soak | Understand the problem AND the domain | "Do we understand how this work actually gets done in the real world?" |
| 2 | Task Bones | Break jobs into tasks, identify system objects | "Is the task decomposition accurate? Is the importance classification right?" |
| 3 | Content Lock | Define what goes where, write the words before drawing the boxes | "When the user opens this, do they immediately know what to do?" |
| 4 | Structure Pass | Layout with design system patterns — what goes where, using your system's presentation rules | "Can the user complete their primary job without getting lost?" |
| 5 | Surface Polish | Apply color, material, motion, and interactive states | "Does it look and feel like a product that costs money?" |
| 6 | Build Lock | Lock the design, produce build specification | "Is the build spec complete enough that a fresh session can execute it?" |
The rule: Each stage produces a gate artifact. The architect reviews the artifact and either approves it or sends it back. No stage can be skipped. Stages 1-4 must be complete before Stage 5 begins. If architecture feedback surfaces at Stage 5, it means Stage 3 or 4 failed — go back.
Mode: Understand the problem AND the domain
Before designing anything, understand how the work actually gets done in the real world. Not how you think it gets done. Not how a product manager described it. How practitioners actually do it today, with all the weird workarounds and informal processes.
- Problem statement (can be as sparse as "users need a better way to review contracts")
- Target persona (or enough context to identify one)
- Parse the problem statement — who, what, why, constraints
- Research the domain — how does this work in the real world?
- Standard workflows in this domain
- Common tools and their UX patterns
- Known pain points and failure modes
- Industry terminology and mental models
- Regulatory or compliance considerations
- Research the persona — pull from organizational docs, previous projects, persona maps
- Identify Jobs-to-Be-Done — what is the user hiring this tool to do?
- Primary job (the main reason they open the app)
- Secondary jobs (things they do while they're there)
- Emotional jobs (confidence, trust, speed, control)
- Problem statement (expanded from input)
- Persona summary (with relevant organizational context)
- Domain research findings (how this work actually gets done)
- 3-5 JTBD statements: "When [situation], I want to [motivation], so I can [outcome]"
- Known constraints
The architect reviews the Problem Brief. If the domain research surfaced workflows the architect hadn't considered, those get validated or rejected here. No design thinking occurs yet.
This is the critical differentiator of GAIT. The engineer is expected to perform domain research independently. When given "build a contract review tool," the engineer researches how contract review actually works before asking the architect a single question.
When to infer:
- The problem domain has well-established workflows (legal review, help desk, sales CRM, security operations)
- Industry tools exist that define standard UX patterns
- Professional standards or regulations constrain the workflow
When NOT to infer:
- The architect has stated a specific workflow that contradicts industry standard
- The domain is novel (no external reference exists)
- The architect explicitly says "don't assume, ask me"
How to infer:
- Research the domain (web search for workflows, tool reviews, professional standards)
- Research existing tools in the space (what patterns do they use?)
- Cross-reference with persona context from organizational docs
- Present findings as "here's what I found" for validation — not as assumptions silently baked into the design
Mode: Break jobs into tasks, identify the system's objects
-
Hierarchical Task Analysis — decompose each JTBD into subtask trees
- Level 0: The job itself
- Level 1: Major activities (these typically map to screens or views)
- Level 2: Subtasks within each activity
- Level 3: Individual actions (these map to UI interactions)
-
Object Modeling (OOUX ORCA)
- Objects: What are the nouns?
- Relationships: How do objects relate?
- CTAs: What actions exist per object?
- Attributes: What data does each object carry?
-
Frequency x Importance Matrix — classify every element
- Always visible: High frequency + high importance
- One click away: High frequency + low importance OR low frequency + high importance
- Buried: Low frequency + low importance
- Hierarchical task analysis (text-based tree)
- Object map with relationships
- CTA inventory per object
- Frequency x Importance classification for every element
- Recommended screen/view mapping (which Level 1 tasks become screens)
The architect validates the task decomposition matches reality. "Is this actually how users do this work?" Every element must be classified before proceeding.
Mode: Define what goes where, write the words before drawing the boxes
This is the hardest gate. Most interfaces fail here.
-
Screen Inventory — based on Level 1 task mapping from Stage 2
- List every screen/view the application needs
- Define the primary job of each screen (one sentence)
- Define what the user sees on first load (the "zero state")
-
Content-First Design — write before you draw
- For each screen, write the actual headings, labels, and CTAs
- Write error messages, empty states, loading states
- Write the microcopy (button labels, tooltips, confirmation dialogs)
- This prevents "lorem ipsum" designs that ignore content hierarchy
-
Progressive Disclosure Tiers — for each screen
- Tier 1 (Visible on load): The minimum the user needs to start their primary task
- Tier 2 (One interaction away): Available on hover, click, or expand
- Tier 3 (Deep): Behind a menu, settings, or secondary navigation
-
Navigation Architecture
- How does the user move between screens?
- What is the primary navigation pattern?
- What persists across screens?
-
Apply Simplification Strategies (in order)
- Remove: Can any element be eliminated entirely?
- Displace: Can any element move to a different screen/context?
- Hide: Can any element be revealed on demand instead of always shown?
- Organize: For what remains, what is the best grouping?
- Screen inventory with primary job statements
- Content-first copy for each screen (headings, labels, CTAs, states)
- Progressive disclosure tier assignments per screen
- Navigation map
- Simplification decisions (what was removed, displaced, hidden, organized — and why)
"When the user opens this app, do they immediately know what to do?" If the answer involves scanning a cluttered screen, go back and remove/hide more.
Mode: Layout with design system structural patterns — what goes where, using your system's presentation rules
Your design system is not a paint job applied at Stage 5. It defines HOW information is presented — what surfaces content sits on, how navigation is structured, how status is communicated, how data tables organize information. Wireframes must use these structural patterns even when rendered in gray boxes.
-
Read your design system documents FIRST (mandatory)
- Material/surface system (what types of surfaces exist, which ones hold content vs. navigation)
- Component anatomy (how are tables, cards, badges, navigation elements structured)
- Typography hierarchy (what sizes and weights create information hierarchy)
- Spacing scale (what's the base unit, how does padding/margin work)
- Layout grid (what's the app shell structure)
-
Wireframe each screen using boxes, real text, and design system structural patterns
- Gray boxes, no brand colors — but sized and spaced per the design system grid
- Every box must map to a classified element from Stage 2
- Tier 1 elements are prominent, Tier 2 elements show their trigger point, Tier 3 elements are not shown
- Use real content from Stage 3, not placeholders
- Navigation uses the design system's navigation patterns
- Data presentation uses the design system's table and card anatomy
-
Task Flow Walkthrough — walk through each JTBD against the wireframes
- Can the user complete the job without confusion?
- Is every step reachable? Are there dead ends?
- Does the information available at each step support the decision the user needs to make?
-
Edge Cases — empty state, error state, loading state, dense state (maximum data)
- One wireframe per screen (HTML with design system structural patterns, gray palette, real text)
- Design system pattern mapping (which patterns are used where)
- Task flow walkthrough notes
The architect walks through the wireframes following the primary JTBD. If they get confused, lost, or overwhelmed at any screen, the IA is wrong. Fix the architecture, not the visual design.
Mode: Apply color, material, motion, and interactive states to the locked structure
Stage 4 established the structure. Stage 5 applies the visual treatment — brand colors, material effects, motion, dark mode. The structure does not change here. If architecture feedback surfaces at Stage 5, it means Stage 3 or 4 failed and must be revisited.
- Apply design system visual tokens — colors, material values, shadows
- Apply motion and interaction — page load animation, hover states, focus rings, easing
- Produce high-fidelity mockups (HTML) — full visual treatment, light and dark mode, real data, interactive states via CSS
- Quality Checklist (adapted from Stripe):
- Utility: Does it solve the user's problem?
- Usability: Can the user figure it out without instructions?
- Craft: Are the details polished? Consistent spacing, alignment, typography?
- Beauty: Does it create a positive emotional response?
- HTML mockups (light + dark) for each screen
- Component inventory (what design system components are used)
- Quality checklist results
"Does it look and feel like a product that costs money?"
Mode: Lock the design, produce build specification for handoff
- Lock the design — confirm all gate artifacts are approved, freeze mockups as reference
- Produce build spec — technology stack, screen-by-screen implementation notes, API requirements, all states (loading/empty/error/dense), component mapping
- Verify completeness — every JTBD task flow covered, every screen has all four states, design system tokens specified for both modes
- Locked design reference (pointers to Stage 5 mockups)
- Implementation notes per screen
- Data/API requirements
- State inventory
- Component mapping
"Is the build spec complete enough that a fresh session can execute it?"
All pipeline artifacts are written to a .gait/ directory in the project root:
project/
.gait/
pipeline.md # Pipeline state: current stage, gate decisions
stage-1-problem.md # Domain Soak: problem brief
stage-2-tasks.md # Task Bones: decomposition + object model
stage-3-ia.md # Content Lock: information architecture
stage-4-wireframes/ # Structure Pass: HTML wireframes
stage-5-mockups/ # Surface Polish: HTML high-fidelity mockups
build-spec.md # Build Lock: build specification
This directory survives session boundaries. Any session can resume the pipeline by reading pipeline.md.
For applications that already exist, start at Stage 2 instead of Stage 1. The problem is known. The question is whether the current UI matches the task decomposition.
- Run Stage 2 (Task Bones) against the current UI
- Compare: does the current screen inventory match the Level 1 task mapping?
- Run the Frequency x Importance matrix on every visible element
- Identify elements that are visible but should be Tier 2 or 3
- Identify elements that are missing but should be Tier 1
- Produce a remediation plan (what to remove, displace, hide, reorganize)
- Re-enter the pipeline at Stage 3 with corrected IA
GAIT synthesizes ideas from several established methodologies and adapts them for AI-assisted, single-session product design:
- Jobs-to-Be-Done (Christensen, Moesta) — Stage 1's problem framing and the JTBD statement format
- Shape Up (Ryan Singer / Basecamp) — the concept of appetite-setting and fixed-scope work, adapted into GAIT's gate system
- Object-Oriented UX (Sophia Prater) — Stage 2's ORCA object modeling
- Hierarchical Task Analysis (Annett & Duncan) — Stage 2's task decomposition trees
- Content-First Design (Jeffrey Zeldman, Luke Wroblewski) — Stage 3's "write the words before drawing the boxes"
- Progressive Disclosure (Jakob Nielsen) — Stage 3's tier system
- Apple Human Interface Guidelines — the philosophy that design system structural patterns (how information is presented) belong in wireframes, not just in visual polish
- Stripe's quality framework — Stage 5's four-part quality checklist (Utility, Usability, Craft, Beauty)
While GAIT builds on the work of many practitioners, the synthesis, sequencing, errors, and questionable choices are entirely my own.
Good fit:
- Enterprise products with complex information density
- AI-powered tools where the AI's capabilities must be designed around, not just decorated
- Products where multiple user personas need different views of the same data
- Redesigns of existing applications that have accumulated feature clutter
- Teams where one person or AI agent owns the full pipeline from research through code
Bad fit:
- Marketing landing pages (you don't need six stages for a hero + CTA)
- Consumer mobile apps with simple task flows (one JTBD, one screen)
- Rapid prototyping where the goal is to test a hypothesis, not ship a product
- Design-system-first work where the system already dictates the layout
This work is licensed under CC BY-SA 4.0. You are free to share and adapt this methodology for any purpose, including commercial use, as long as you provide attribution and distribute adaptations under the same license.
Created by Glenn Bezanson — Infrastructure architect building AI-powered enterprise products.