AI-Native Design Workflow

Executive Summary

Becoming an AI-native designer means shifting from hand-crafting every pixel to directing an AI collaborator that can generate, prototype, and even ship working interfaces — and the payoff is premium, less bloated design, not more of it. The four designers in these videos consistently produce work that feels deliberate and high-craft precisely because AI compresses the cost of exploration and iteration, freeing the designer’s taste to do the deciding. Instead of spending three days in Figma assembling a single mock, an AI-native designer generates ten working concepts in an afternoon, kills the weak ones fast, and invests saved time in typography, hierarchy, and interaction polish — the details that make a product feel expensive (GW-roadmap @ 1:17; WP-WS @ 46:59; AM-Mercury @ 33:29). The result is tighter, more intentional design because the designer is now steering implementation, not handing off and hoping. Premium design is not more features or more elements — it is the confidence to remove what muddies clarity, and an AI-native workflow gives you the velocity and evidence to do that.

The Mindset Shift

The single biggest change across all four videos is that the designer stops being the sole creator of every artifact and becomes the director of an AI collaborator. Griffin names this directly: brief AI “like a junior designer that you’re mentoring, not a vending machine” (GW-roadmap @ 2:10). Carol at Mercury treats the system prompt as a design artifact she shapes (AM-Mercury @ 21:51). Danny at Wealthsimple lets the model interview him instead of writing one-shot prompts (WP-WS @ 20:28). Clint at Givebutter says half his job is now “aggressively vibe-checking robots” — the robots produce brilliance and garbage, and both are useful because you learn from both (GD-Givebutter @ 50:54).

The key principles that recur across the videos:

  • Taste is the moat. AI can generate endless options but cannot tell you which one is worth shipping — that is the designer’s job (GW-roadmap @ 7:24). The best AI-native designers are not the ones using the most AI; they are the ones with the best taste (GW-roadmap @ 7:17).
  • Design for clarity and remove what muddies it. Carol killed a file-attachment flourish on invoices because it looked like the payment card and confused the UI text — the info was already interpreted into the UI, so the flourish was redundant (AM-Mercury @ 36:28). This is the anti-bloat principle in action.
  • Lead with intent, not navigation. Mercury’s Command flips the interaction model: the user states what they want and the system navigates to the right page with filters applied (AM-Mercury @ 8:28). Premium feels effortless; bloated feels like sidebar hunting.
  • Speed is learning faster, not just shipping faster. Clint’s switcher-intent experiment went from concept to deployed prototype in 2 days, and the team learned within ~2 weeks their mental model was wrong — the win was pivoting before over-committing (GD-Givebutter @ 35:06, 38:16).
  • Seek inspiration outside your vertical. Danny studies Spotify and Suno curation patterns for a finance discovery feature, because the best ideas come from apps outside your universe (WP-WS @ 13:56).
  • You do not need to become a software engineer — just gain enough technical fluency to collaborate with AI and guide it toward a cleaner implementation (GW-roadmap @ 5:56). This shifts the designer toward a “design engineer” role with far more control over the final product (GW-roadmap @ 5:22).

The AI-Native Workflow

The four videos, taken together, describe a repeatable end-to-end process. Not every designer does every step, but the shape is consistent.

  1. Diagram the mental model before touching pixels. Start by drawing what the system is doing — context in, reasoning, legible output — to ground your own understanding. Carol’s first step was a small diagram combining search + chat, which she calls a “grounding moment” (AM-Mercury @ 0:09, 13:06). Griffin frames the same instinct as understanding what the app needs to do and who uses it before generating anything (GW-roadmap @ 1:46).

  2. Hunt for friction with qualitative + quantitative data, not a PRD. Before designing, actively find the real problem. Clint runs Enterpret (voice-of-customer, emotional texture) and Hex (behavioral analytics, what users actually do) in tandem, merging both into one friction picture (GD-Givebutter @ 4:46, 5:00). He does not wait for a PRD — he jumps into dashboards and feedback himself (GD-Givebutter @ 0:26).

  3. Capture meeting and research context as searchable memory. Use a tool like Granola to sit in the background of calls and build structured notes, then query it (“what did the PM say about friction at sign-up?”) and feed those nuggets into Claude to generate prompts for your feedback tools (GD-Givebutter @ 6:07, 10:45; GW-roadmap @ 4:17). The context should not be siloed — connect it via MCP so agents can pull it directly (GW-roadmap @ 4:17).

  4. Frame your tool stack as an explore-vs-refine spectrum. Before starting a task, ask where you are: exploring (messy, generative, going wide) or refining (precise, deliberate, narrow) (WP-WS @ 11:08). Exploration tools: Cosmos, Mobbin, Figma, Paper, Claude Design. Refinement/shipping tools: Conductor, Claude Code, Codex, connected to the real codebase (WP-WS @ 11:08). Choose your prototyping tool by intent: use a design-system-connected tool (Magic Patterns) to refine real flows; use Claude Code for novel ideas outside design-system constraints (GD-Givebutter @ 29:20).

  5. Write briefs, not one-liners — and let the model interview you. Brief AI like a junior designer: what the product does, who uses it, the ideal experience, the visual direction (GW-roadmap @ 1:46). Scale prompt detail to constraints: short prompts for open-ended exploration, thorough prompts when brand guidelines, accessibility, or design-system rules apply (GW-roadmap @ 2:16). Danny’s biggest prompting upgrade is the “ask user question” tool — have the model interview you to surface details you had in your head but never wrote down (WP-WS @ 20:28, 42:52).

  6. Always start in plan mode. Plan mode forces the model to think through and state what it is going to do before doing it, driving token efficiency, code quality, and the likelihood it builds what you pictured (WP-WS @ 42:52). “I almost never start without using plan mode first” (WP-WS @ 43:00). Read the plan for misinterpretations before auto-accepting (WP-WS @ 1:00:41).

  7. Generate working interfaces, not static mock-ups. The core agentic loop is: prompt describing the screen/flow → agent generates a working interface → review pass (does it match the ask, is hierarchy sensible, anything missing) → iterative adjust/regenerate until a final draft is presentable or testable (GW-roadmap @ 1:17). This replaces static mock-ups with clickable, testable interfaces.

  8. Vibe-code when Figma cannot capture the medium. Conversation interfaces are turn-by-turn typing and clicking — impossible to prototype well in Figma. Carol vibe-coded in Cursor when feedback was “I can’t feel what this interaction is like” (AM-Mercury @ 17:36). Then connect a real working system prompt to the prototype, because the response architecture is what actually needs testing (AM-Mercury @ 19:16).

  9. Connect your tools via MCP to eliminate copy-and-paste. Wire the agent to Figma, Framer, Mobbin, Slack, and GitHub so you have “one connected system instead of five disconnected tools” (GW-roadmap @ 3:07, 4:05). Use Figma MCP read access to let Claude view a frame and build it in real code; use write access to let Claude generate production-quality Figma files with auto-layout and design tokens (GW-roadmap @ 3:27). Danny’s exact recipe: design two states in Figma → copy “link to selection” → paste into Conductor → describe each state → say “use the Figma MCP to read the designs” → run in plan mode (WP-WS @ 39:56, 44:42).

  10. Use skill.md files for consistent output. A skill.md lays out domain-specific rules up front so the agent is not guessing your standards each time. “Good prompts get you good output once. Skills make that output consistent by default” (GW-roadmap @ 2:31, 3:03). Use existing skills (front-end design skill, Vercel’s web design guidelines) or write your own capturing your design preferences.

  11. Pre-review your own code before tagging engineers. Wealthsimple has a “do code review” skill that spins up eight parallel subagents checking dead code, performance, security, and best practices (WP-WS @ 48:26). Run it before tagging engineers because “anyone can write and ship code now” and engineers are reviewing more than ever.

  12. Get into production and real data as fast as possible. Vibe-codes have a low ceiling — Carol was “hitting her head” on it (AM-Mercury @ 25:16). The best thing is to work directly in production code with real data. Danny’s team ships working prototypes so the feedback/discussion cycle is dramatically faster than sharing a Figma prototype with its caveats (WP-WS @ 46:59).

  13. Land everything in Figma as the source of truth. Figma narrows to a documentation layer, source of truth, and final polish (GW-roadmap @ 0:49). When a concept is approved, push every prototype screen into Figma for handoff; use one shared Figma file per quarter to keep the team converged (GD-Givebutter @ 27:03, 28:01).

  14. Communicate findings with a working prototype video, not a static handoff. Share a video clip or voiceover of the working prototype alongside the PR — it communicates “before → what I’m thinking” far better than a static handoff (WP-WS @ 57:22). For leadership reviews, share prototypes live and synchronously with someone screen-sharing and guiding the conversation; too much is lost in async links for agentic flows (AM-Mercury @ 27:28).

  15. Hold a recurring Craft Crit and hold a quality bar. Mercury runs a biweekly Craft Crit where designers bring explorations and chat about visual details — type weights, hierarchy, consistency (AM-Mercury @ 33:29). The company aligns on a 0–5 design leveling rubric and sets a target quality level per project up front (AM-Mercury @ 50:53). Design can push back on shipping subpar work because quality bars are shared across design, engineering, and product (AM-Mercury @ 49:08).

Tools & Skills to Adopt

Agentic coding tools (your new core design tool):

  • Claude Code, Codex, or Cursor as the primary design tool, with Figma narrowed to documentation and final polish (GW-roadmap @ 0:49)
  • Conductor — GUI wrapper around Claude Code CLI with workspaces (isolated work trees) for parallel sessions and per-tab model switching (WP-WS @ 35:12, 37:28)

Design exploration tools:

  • Claude Design — canvas-based, design-system import, wireframe vs. high-fidelity, interactive prototypes, fast concept branching (WP-WS @ 0:16, 15:32)
  • Paper — canvas tool where everything is HTML/CSS, so code output is close to one-to-one with no Figma-to-code translation loss; used for divergent, design-system-free exploration (WP-WS @ 1:05:21, 1:08:01)
  • Magic Patterns — AI prototyping tied directly to a Storybook design system for real production components and tokens (GD-Givebutter @ 29:20)
  • Cosmos — curated, art-directed UI inspiration (a better Pinterest) (WP-WS @ 11:38)
  • Mobbin — UI pattern reference library; search specific patterns, screen-cap references, and paste them into AI tools (GD-Givebutter @ 45:02; WP-WS)

MCP servers (the connection layer):

  • Figma MCP — read/write access for design-to-code and generating production-quality Figma files (GW-roadmap @ 3:27; WP-WS @ 39:56)
  • Paper MCP, Granola MCP — connect agents to references and meeting context (GW-roadmap @ 4:17; WP-WS)
  • Connect to Framer, Mobbin, Slack, GitHub to eliminate copy-and-paste (GW-roadmap @ 3:07)

Reusable skill files:

  • skill.md files capturing domain-specific rules and conventions so output is consistent by default (GW-roadmap @ 2:31)
  • Existing skills: front-end design skill, Vercel’s web design guidelines (GW-roadmap @ 2:31)
  • Wealthsimple skills marketplace, including a “do code review” skill with 8 parallel subagents (WP-WS @ 48:26)

Prompting techniques:

  • “Ask user question” tool — model-driven interviewing of the designer for nuanced requirements (WP-WS @ 20:28)
  • Plan mode — forces the model to state its plan before execution (WP-WS @ 42:52)
  • Attach a fixed “framework” to every feedback prompt: summarize patterns, focus on missed opportunities, draft a brainstorming doc organized by opportunity area / user stories / citations / experiment ideas (GD-Givebutter @ 12:06)

Research and feedback tools:

  • Enterpret — customer feedback AI aggregating Intercom, Gong, G2, and mobile/web feedback (GD-Givebutter @ 4:46)
  • Hex — behavioral/quantitative analytics (“what users actually do”) (GD-Givebutter @ 5:00)
  • Granola — AI meeting notes, searchable memory, custom recipes into PRDs or Linear tickets (GW-roadmap @ 4:17; GD-Givebutter @ 6:07)

Communication and capture:

  • Loom — async video updates, keep under 5 minutes, default playback ~1.5–1.75x (GD-Givebutter @ 39:15)
  • Screen Studio / Clean Shot — screen recording and screenshot annotation for sharing flows (WP-WS)
  • Whisper Flow / Monologue — voice dictation for hands-free input (WP-WS; GD-Givebutter)

Quality rituals:

  • Craft Crit — biweekly design-craft critique session for visual detail (AM-Mercury @ 33:29)
  • 0–5 design leveling rubric — set a target quality level per project up front (AM-Mercury @ 50:53)
  • Weekly client research calls — every designer talks to a real customer (WP-WS @ 24:02)

Actionable Checklist for Our Designer

  1. This week, rebuild your workflow around an agentic tool (Claude Code, Cursor, or Codex) as your primary design tool, reserving Figma for documentation, source of truth, and final polish (GW-roadmap @ 0:49).

  2. Draw your own explore-vs-refine spectrum and place every tool on it before starting your next task, so you pick the right tool for where you are (WP-WS @ 11:08).

  3. Start every non-trivial design prompt with plan mode + the “ask user question” tool so the model interviews you and states its plan before executing (WP-WS @ 20:28, 42:52).

  4. Write a brief, not a one-liner, for your next screen: specify what the product does, who uses it, the ideal experience, and the visual direction. Scale detail to constraints — thorough when brand guidelines or accessibility rules apply (GW-roadmap @ 1:46, 2:16).

  5. Create your first skill.md file capturing our design preferences and conventions so every prompt inherits them and output becomes consistent by default (GW-roadmap @ 2:31).

  6. Connect Figma via MCP to your agentic tool so Claude can read a frame and build it in real code — then prototype one interaction using the “link to selection” → paste → describe states → plan mode recipe (GW-roadmap @ 3:27; WP-WS @ 39:56).

  7. Vibe-code one conversation or interaction interface in Cursor instead of faking it in Figma, because turn-by-turn flow cannot be prototyped well in Figma (AM-Mercury @ 17:36).

  8. Seek inspiration outside our vertical — study curation/merchandising patterns from Spotify, Apple Music, or Suno for our discovery/feed surfaces, not just competitor SaaS dashboards (WP-WS @ 13:56).

  9. Feed Mobbin reference screenshots directly into Claude or Magic Patterns (“I want to try something like this — here’s a screenshot”) to make inspiration a frictionless part of the process (GD-Givebutter @ 45:02).

  10. Adopt “friction hunting” as a weekly ritual — deliberately search the product for where users get stuck using both qualitative and quantitative data, instead of waiting for a PRD (GD-Givebutter @ 4:36).

  11. Kill one visual flourish that muddies clarity this week. Audit a current screen for elements that look like another element or repeat info already in the UI, and remove them — this is the direct anti-bloat move (AM-Mercury @ 36:28).

  12. Share your next prototype as a working video clip or voiceover alongside the PR, not a static Figma handoff, so engineers and stakeholders review actual behavior (WP-WS @ 57:22).

  13. Propose a biweekly Craft Crit focused on visual craft — type weights, hierarchy, consistency — and a 0–5 quality rubric so the team holds a shared bar and design can push back on shipping subpar work (AM-Mercury @ 33:29, 49:08, 50:53).

  14. Run a self code-review (or a “do code review” skill) before tagging engineers on your next PR, to catch dead code, performance, and best-practice issues yourself (WP-WS @ 48:26).

  15. Maintain a continuous-learning loop: educational videos, design books, and AI-design content on social media to keep taste sharp — the best AI-native designers are the ones with the best taste, not the most AI (GW-roadmap @ 6:59, 7:17).

Contradictions / Caveats

  • Figma’s role is contested. Griffin says Figma narrows to documentation and final polish, with the bulk of design work moving into a chat window connected to code (GW-roadmap @ 0:49). Carol at Mercury still spends a lot of time in Figma as a free canvas to draw and move pixels — “do designers still design in Figma? My workflow is showing yes” (AM-Mercury @ 43:22, 14:37). The honest synthesis: Figma remains the thinking canvas and source of truth, but exploration and implementation increasingly happen in agentic tools.

  • Design systems: crutch or foundation? Danny argues design systems are great but can become a crutch, and the best designers break the system in ways that do not feel broken (WP-WS @ 1:08:36). Carol borrows heavily from the design system for canonicals (AM-Mercury @ 35:15). Clint splits tools by intent: design-system-connected tools for refining real flows, unconstrained tools for inventing new ones (GD-Givebutter @ 29:20). The tension is real — rely on the system for consistency, but deliberately break it for premium, non-templated feel.

  • Vibe-coding has a low ceiling. Carol found vibe-codes “hit a quick ceiling” and was “hitting her head” — the best thing is to get into production code and real data as fast as possible (AM-Mercury @ 25:16). Danny’s team still ships prototypes that are not production code but values them for fast feedback (WP-WS @ 46:59). Do not mistake a vibe-coded prototype for a shippable product.

  • Token cost vs. time saved. Danny argues cheaper throwaway exploration (a day of cheap concepts) beats three days in Figma, and Wealthsimple’s stance is “carrot over stick” — encourage usage rather than limit it (WP-WS @ 27:48, 53:48). But token waste is real, and plan mode exists partly to drive token efficiency (WP-WS @ 42:52). The caveat: be generous with exploration tokens, but use plan mode to avoid burning tokens on misinterpretations.

  • AI cannot tell you which option is worth shipping. “AI can generate endless options, but it still can’t tell you which one is actually worth shipping. That’s your job” (GW-roadmap @ 7:24). Clint echoes this — half his job is “aggressively vibe-checking robots” because they produce brilliance and garbage (GD-Givebutter @ 50:54). The workflow does not remove the need for taste; it raises the stakes on it.

  • The system prompt is the product — but it is not a design tool. Carol says “it feels almost impossible to design without interacting with the system prompt because the system prompt in a way is the product” (AM-Mercury @ 21:51). This means for AI-agent features, the designer must work with the actual prompt, not just visuals — a skill most product designers do not yet have.

  • High-stakes actions need deterministic confirmation, not AI eagerness. Mercury requires explicit button confirmation for real money transfers, with labeled states (draft → edit → confirm → done), because “this is real money that is being moved” (AM-Mercury @ 42:33, 48:24). The caveat: an AI-native workflow that prototypes fast can make it easy to accidentally ship an agent that auto-executes high-stakes actions — design the guardrails deliberately.

  • Not every team has the culture to support this. Mercury aligns quality bars across design, engineering, and product so design can veto shipping subpar work (AM-Mercury @ 49:08). Wealthsimple uses carrot-over-stick adoption (WP-WS @ 27:48). If our team does not share a quality bar or does not encourage AI usage, the workflow will not land — the culture is a prerequisite, not an afterthought.