Design Is No Longer Screens: A 7-Phase Design Workflow for Building AI-Native Products 设计不再是画界面：构建 AI 原生产品的 7 步设计流

In the whirlwind of AI-native building, where tools like Claude Code or Replit turn prompts into prototypes in minutes, the old design playbook crumbles. We no longer design for developers. We design with AI. That shift changes everything: exploration happens faster, implementation is instant, and drift scales just as quickly if unchecked.

The misconception? “Vibe coding means just describe what you want, and AI builds it.” It sounds magical in demos, but in real products, unconstrained AI defaults to its training average: generic buttons, inconsistent padding, mismatched colors, typography without intent. The result: UIs that look fine in isolation but fall apart side-by-side, functional yet soulless.

The new reality demands a recalibrated role for designers. Not making every decision, but deciding which decisions AI can make. Set the boundaries wrong (too loose, and the output is chaotic slop; too tight, and the process becomes micromanaging with fancier tools) and the whole thing collapses. The art is in the calibration: defining systems that amplify a product’s unique character while ensuring stability, consistency, and scalability.

This workflow addresses that at the root. It’s not rigid steps. It’s adaptive logic, refined across diverse products with varying audiences, aesthetics, and stacks. Products that feel intentional and alive, shipped at velocity without the hangover.

---

Three Situations, One Logic

Before getting into the framework, one thing needs to be clear: the starting point changes how to use it.

Situation A: An existing product with a mature design system. Someone already did the hard work. Design tokens exist. Components are defined. The job is ensuring new AI-generated features respect the system. The work is execution and extension, not invention. Focus intensively on Phases P3 through P6; the earlier phases are already done.

Situation B: An existing product, but no design system. This is the sneakiest situation because it looks like Situation A from the outside. There are screens. There’s a product. But no one ever extracted the rules from those screens into explicit tokens. The first move is extraction: reverse-engineering the design language already implied in the existing product before building anything new. Otherwise, AI will invent a parallel visual language that fights with the existing one.

Situation C: Building from zero. The most complete version of the workflow. Every phase matters. This is what the full walkthrough covers.

The internal logic connecting all three: A is pure execution. B is extraction, then execution. C is ideation, then extraction, then execution. The emphasis shifts; the underlying structure doesn’t.

---

The 7-Phase Framework

1. P0: Intent & Positioning

What kind of product is this, and what must it never feel like?

This is the phase most designers skip because it doesn’t feel like design work. It feels like strategy. Skipping it is expensive: premature mechanics kill differentiation.

Building before answering “what emotional territory are we claiming?” produces screens that are technically correct and emotionally indistinct. A container with no soul.

The work in P0 is defining the product’s emotional north star in writing. Not a mood board (yet). Words first. Why? Because words force commitment in a way that images don’t. Anyone can collect beautiful images. Fewer people can write a paragraph that says: “This product should feel like the first hour of a Sunday morning: quiet focus, no urgency, a cup of tea. It should never feel like a pop quiz, a leaderboard, or a birthday party.”

That paragraph is worth more to the AI build process than a 20-image mood board, because it can be pasted into every prompt.

Use AI for divergent brainstorming. Ask for five radically different positioning angles. Ask what the anti-version of each looks like. The goal is to pressure-test instincts, not replace them.

Outputs: A single paragraph capturing emotional intent. A short list of keywords the product should embody. An equally short list of things it must never feel like (this negative constraint list is often more useful than the positive one). One sentence defining success qualitatively: “It feels like ___.“

---

2. P1: System Blueprint

What exists, what flows where, and what cannot break?

Build the skeleton before any visuals touch it.

Here’s the mistake that appears constantly: jumping from “here’s what the product is” to “here’s what it looks like,” skipping the step of figuring out what it does. The complete state model. The edge cases. The invariants.

The result is beautiful screens that don’t compose into a coherent product. A gorgeous onboarding flow that never accounted for returning users. A perfect empty state with no defined trigger.

P1 is where AI serves as a stress-tester, not a generator. Don’t ask AI to design flows. Ask it to break them. “What states does this screen need to handle?” “Where would this logic fail if 10,000 people used it?” “What hasn’t been accounted for?”

This produces something invaluable: a complete list of screens, states, and data requirements before any time is spent on how they look. The blueprint gives expression a reliable canvas instead of a blank page.

Outputs: Flow diagrams. A complete screen inventory with every state named. Interaction contracts (“tapping X always does Y, regardless of state”). And critically: a “what cannot change” list, the invariants all visual decisions must respect.

---

3. P2: Expression & Visual Exploration

What does this product look like, sound like, feel like?

This is the phase everyone wants to start with. And now, with P0 and P1 done, it’s finally time.

The reason sequencing matters: exploration without constraints produces beautiful things that don’t work. Exploration with constraints produces beautiful things that compose. The starting point isn’t a blank page. It’s filling in a specific shape.

The practical goal is generating 3 to 5 genuinely different visual directions, then choosing one. Not 20 directions. Not 1. The range forces the recognition that a first instinct isn’t the only option; the limit forces commitment.

AI is exceptional at this phase when briefed well. The brief is the P0 intent statement plus the P1 constraints. Give it both. Then ask for contrast: “Show me a direction that’s warm and analog alongside one that’s cool and precise. Show me what happens if you push the typography further. Make one feel more minimal.”

The selection criteria, which most frameworks skip: test each direction against three questions. Does it serve the primary user’s emotional state, not just look good in a portfolio? Does it stay coherent when imagined across 20 screens, not just 3? Does it feel distinct from the closest competitor, not just from bad design?

Pick one. Commit to it publicly in the project documentation, so there’s no quietly drifting back to the others.

Outputs: 3 to 5 visual directions, each shown across 2 to 3 representative screens. One selected hero direction. Initial hero screens that will become the reference artifacts for everything downstream.

---

4. P3: Token Extraction & Spec Definition

Convert vibe into logic.

This is where the magic becomes math.

There’s a chosen visual direction. It looks right. But “looks right” is not a specification. Handing AI “looks right” and expecting consistent results across 30 screens will fail.

Token extraction is the bridge between expression and maintainability. The process translates every decision in the hero screens into an explicit, named rule. Not “the cards are kind of rounded” but border-radius: 12px. Not “the text feels light and airy” but line-height: 1.7, font-weight: 400, letter-spacing: 0.02em.

The practical format: a constraints file. Plain text or markdown. Named tokens only; no raw hex values or arbitrary pixel numbers in component code. Every color gets a semantic name (color-primary, color-surface, color-feedback-correct). Every spacing value gets a token name (space-md: 16px). Every component gets a written spec covering appearance, sizing, states, and, critically, what it must never do.

That last part is disproportionately important. Negative constraints work better than positive ones with AI. “Primary button: 52px height, solid fill, color-primary background” is good. Adding “Never use a gradient. Never appear more than once per screen. Never float without a resting surface below it” is what makes the rule binding.

AI can do much of this extraction work. The most reliable method is MCP, which gives the model direct access to a Figma design repository. Without MCP, Figma’s “copy as code” feature provides the next best source of truth. If neither is available, screenshots work as a fallback: show AI the screens, then verify that the extracted tokens accurately reflect the actual design decisions.

Outputs: A constraints file. A small set of Figma components for the 6 to 8 most-used UI elements, built as real Figma components (not static frames). These become the reference artifacts for all future AI build prompts.

---

5. P4: Vertical Slice

Does it actually hold together?

Before building everything, build one complete thing.

Pick the most critical user flow, from entry to completion: the daily learning loop, the checkout flow, the onboarding sequence. Build the entire thing, end to end, using the blueprint and the tokens.

This phase exists to find the blind spots that look invisible on paper but become obvious in practice. Does the visual language that felt right on hero screens hold up under the repetition of a real session? Does the card component that looked clean in isolation feel cluttered when it contains real content? Does the spacing system that felt generous on an empty screen feel cramped when the UI is fully populated?

The key discipline here is the Hybrid Rule: if something feels visually wrong, don’t just fix the screen. Pause. Re-enter expressive mode fully, exploring the fix as if it were a new design decision. Validate the solution. Then immediately update the tokens and spec. Never patch visually without a system update. A patched screen and an unchanged spec creates invisible inconsistency that multiplies across every screen built afterward.

This is where most drift starts. The vertical slice is specifically designed to surface it early, while the cost of fixing it is still low.

Outputs: One fully functional, coherent end-to-end flow. Updated tokens and spec reflecting any adjustments made during the slice. Confidence that the system is real, not theoretical.

---

6. P5: Expansion

Scale without drift.

Now build everything else.

With a validated vertical slice, a constraints file, and a set of Figma components, AI can generate screens with real consistency. The work becomes methodical: apply the system to each remaining screen and flow.

The prompt style changes fundamentally here. In P2, prompts were loose and comparative (“show me 5 directions”). In P5, they’re locked and specific: “Build the settings screen using only the defined tokens. The layout follows the pattern established in [reference screen]. Here is the wireframe [attach]. Here is the constraints file [attach]. Do not introduce any new visual patterns.”

The golden rule for P5: if there’s an urge to make a one-off aesthetic tweak, that’s a signal the system is incomplete, not that the screen needs a special exception. Stop. Go back to P3. Strengthen the token. Then build the screen. A system that requires exceptions is a system that’s about to drift.

Outputs: Complete, consistent product flows. A deviations log documenting any gap between what was intended and what AI produced that was accepted. This log will be essential in P6.

---

7. P6: Audit, Refine & Polished

Ruthless quality control and the final 10% that makes the difference.

This phase separates products that feel finished from products that feel almost done.

The work is diagnostic first: where is the visual rhythm inconsistent? Where does the density feel wrong (too sparse in some places, too crowded in others)? Where are the accessibility gaps that weren’t visible until everything was assembled? Where did content drift from the tone established in P0?

Use AI as an auditor here, not just a builder. “Compare these six screens. Where is spacing inconsistent? Where does the typography hierarchy break down? What three things feel most off?” Then fix surgically. Every expressive refinement must end with a system lock-in: if it’s not in the updated spec, it doesn’t ship.

Throughout this phase, one discipline matters: know whether each revision is local (a one-time visual adjustment) or systemic (a rule that should apply everywhere). For systemic revisions, tell AI explicitly: “This is a system-level change. Update the design token.”

The last 10% is also where soul-lifting touches arrive: micro-interactions that make the product feel alive, copy that sounds like a human wrote it for a specific person, transitions that give weight and physicality to state changes. These are small, but they’re felt. They’re the difference between “this works” and “I want to use this.”

Outputs: A polished, shippable product. An updated, battle-tested constraints file reflecting the real implemented system. A clean deviations log for the next iteration.

---

The 20/80 Rule: Why Not Everything Needs to Be Built from Scratch

This framework looks like a lot of work. And for P0 through P3 especially, the question will arise: does every token, every component, every constraint really need to be defined from scratch?

No. And working as if they do means working too hard.

The 20/80 principle of vibe coding design: 80% of what makes a product solid is infrastructure that should be adopted wholesale. 20% is expression that makes it distinctive.

Think of it like renovating a house. The plumbing doesn’t get redesigned. The electrical system doesn’t get re-engineered. Work happens on the walls, the furniture, the light: the things people actually experience. A good UI kit is the plumbing. Accessibility, touch targets, interaction patterns, responsive behavior, animation timing, component architecture. These represent decades of refinement and user research. Adopting them wholesale is not a shortcut. It’s good judgment.

What to adopt unchanged:

• Touch target sizing (minimum 44×44pt on iOS, 48×48dp on Android)
• Safe area insets and margin conventions
• Standard gesture patterns (swipe, long press, pull-to-refresh)
• Accessibility standards (color contrast ratios, screen reader behavior)
• Established interaction timing (transitions, feedback delays)
• Responsive layout logic within platform conventions

What to customize:

• Color system (full ownership: this is where brand lives)
• Typography choice and scale (typeface selection, weight distribution, spacing)
• Shape language (border radius values, card elevation, shadow depth)
• Iconography style (filled vs. outlined, weight, corner rounding)
• Motion personality (spring physics, duration preferences, easing character)
• Information density (how much shows on each surface)

What to add on top for genuine distinction:

• Brand moments: places where the visual identity speaks directly (onboarding, celebration states, empty states)
• Voice and copy: the most underrated design element in any digital product
• Character-specific details: custom illustrations, unique empty states, personality in microcopy
• Signature interactions: one or two animations or transitions that feel unmistakably the product’s own

Material 3 and Apple’s HIG are excellent starting points precisely because they already encode the infrastructure layer. Choosing either as a foundation isn’t a limitation. It’s freedom to spend design energy on the 20% that actually makes a product distinctive.

---

The Real Shift: From Screens to Systems

In the AI era, the work has fundamentally reframed.

The designer’s job is no longer screens. It’s constraints.

AI can generate 50 screens in minutes. It can generate versions of any design artifact. What it cannot do is know when it’s gotten them wrong.

That’s the work.

Design is no longer pixel work. Design is decision architecture.

---

In the AI era, creativity without structure becomes noise. Structure without creativity becomes generic.

Design has always been about constraint. Every medium has its material limits: wood grain, screen resolution, human attention spans. Great designers don’t fight their constraints. They use them.

AI changes what the constraints are, not whether they exist. The new constraint is this: AI will fill every vacuum left to it with its best guess, and its best guess is the visual average of everything it has seen before. The job is to leave fewer vacuums.

The framework above is a system for leaving fewer vacuums. For making more decisions before the build starts rather than after. For converting taste into rules that travel across tools, across sessions, and across the entire surface area of a product.

Because in the end, design is about anchoring to one specific possibility among thousands. It’s about knowing which decisions are worth making, which to delegate, and how to make delegation precise enough that the outcome is still recognizably the designer’s own.

That’s the skill. It’s always been the skill. AI just made it visible.