How I AIHow Notion designers ship live prototypes in minutes | Brian Lovin (Product designer)
CHAPTERS
- 0:00 – 4:42
Why B2B SaaS design needs “reality” early: prototyping toward production
Brian lays out his core philosophy for designing B2B SaaS: push ideas toward real usage conditions as quickly as possible. He explains why browser-based prototypes reveal critical issues (loading states, responsiveness, interaction feel) that static mocks often hide, and how AI coding tools accelerate that gradient toward production-like truth.
- •Design quality improves when concepts “encounter reality” early
- •Figma-to-browser gaps reveal interaction and state problems quickly
- •AI-assisted coding enables much faster iteration and higher-fidelity prototypes
- •Prototyping can happen in a production-like environment without full shipping
- 4:42 – 7:59
Notion’s Prototype Playground: a shared Next.js repo for team prototypes
Brian explains Prototype Playground as a simple, centralized Next.js app where each person has a namespaced directory of prototypes. The homepage surfaces recently updated prototypes, creating visibility across the team and making it easy to copy/borrow working patterns from others.
- •Prototype Playground is “just a Next.js project” in one repo
- •Each designer/PM/engineer gets a namespace; each subfolder is a prototype
- •Centralized listing boosts discoverability and cross-pollination of ideas
- •Shared repo makes it easy to reuse code patterns across prototypes
- 7:59 – 10:57
Operational setup, adoption, and linking to external prototyping tools
They cover how the playground was created and deployed (basic approvals, Vercel, collaborators), and who actually uses it. Brian notes uneven adoption—some prefer Figma or different stacks—so the system supports external prototype links while he works to reduce onboarding friction.
- •Set up by Brian with an engineer; deployed on Vercel with light process
- •Regular usage is concentrated among a small group with technical background
- •Not everyone wants Next.js/React—supporting heterogeneous workflows matters
- •External prototype links let the playground act as an index for any tool
- 10:57 – 13:00
Creating a new prototype fast: UI button, file-based structure, and workflow layout
Brian shows how a new prototype can be created from the running app (no backend—just files on disk) and pushed to GitHub. He also demonstrates his preferred “three-pane” setup: Claude Code in terminal, code review in editor, and live output in the browser.
- •“New prototype” creates folders/files locally—no database, just disk files
- •Metadata is collated to render the homepage list
- •Built-in affordances like “open in Cursor” streamline editing
- •Three-pane workflow helps catch issues early by continuously reviewing code and output
- 13:00 – 13:22
Demo: podcast episode page with video + audio player (and confetti) using plan mode
They build a contrived but realistic prototype: a podcast detail page with video, audio player, and a confetti effect on play. Brian emphasizes planning before coding and shows how voice-to-prompt (Monologue) speeds up specification input.
- •Use plan mode to get better structured implementations
- •Voice dictation (Monologue) reduces prompting friction and increases detail
- •Plan outputs can include useful wireframes and step-by-step structure
- •Resulting prototype is visually robust and interactive (including confetti)
- 13:22 – 18:02
Getting better Claude Code results: plan review, tight feedback loops, and context files
Claire and Brian discuss why reading plans and code outputs matters—especially for catching nonsense early. Brian shows how global and per-machine instructions (claude.md + claude.local.md) provide consistent context while keeping user-specific details uncommitted.
- •Better outcomes come from reviewing the plan before execution
- •A disciplined code/output review loop prevents costly debugging later
- •claude.md defines project-wide tools and conventions (Bun, Tailwind, structure)
- •claude.local.md adds personal context (username, directory rules) without committing to Git
- 18:02 – 20:26
Teach the AI to do the work it asks you to do: linting and browser verification
Brian shares a rule of thumb: whenever the AI asks you to check something, teach it to check for itself. He describes having Claude lint/validate and use tools (e.g., browser automation) to verify behavior rather than relying on manual inspection every iteration.
- •Meta-technique: turn AI questions into automation instructions
- •Have the agent run lint/TypeScript checks to catch errors proactively
- •Use MCP tooling to open the browser, click through flows, and verify UI behavior
- •Longer autonomous runs reduce interruptions and improve throughput
- 20:26 – 22:42
Slash commands as onboarding accelerators: creating prototypes without clicking
Brian introduces Claude slash commands—prompt templates that can also run scripts—to make common workflows trivial. He demos a “Create Prototype” command and explains how commands are defined with examples so the agent knows what “success” looks like.
- •Slash commands encapsulate repeatable workflows into one consistent entrypoint
- •Create Prototype automates folder/file scaffolding in the right namespace
- •Commands include examples/snippets to anchor the agent’s output format
- •Goal: keep users in terminal flow and reduce intimidating setup steps
- 22:42 – 26:14
Figma → code via MCP: forced tool invocation + a verification loop to reach ~80%
They demonstrate converting a Figma frame into an implementation using a custom /figma command. The command checks MCP setup, extracts design data, implements it, then iteratively verifies against the Figma reference in a loop until changes stabilize.
- •Custom /figma command avoids “magic keywords” and inconsistent MCP invocation
- •Preflight checks help non-experts install/run MCP servers correctly
- •Two-MCP approach (Figma + browser/devtools) supports implementation + validation
- •Verification loop improves quality and reliability versus one-shot generation
- 26:14 – 30:58
MCP limitations and practical framing: context inefficiency, fragility, but best available
Brian and Claire reflect on how quickly the tooling is evolving and why MCP feels imperfect today. Despite inefficiencies and occasional conflicts, MCP-driven iteration still delivers major time savings for scaffolding and pixel-ish translation from designs.
- •MCP can be slow, context-hungry, and sometimes fails unpredictably
- •Even imperfect automation can produce strong first passes with minimal prompting
- •Rapid scaffolding changes the economics of design-to-frontend translation
- •Expect tooling to evolve quickly; today’s workflows may look naïve soon
- 30:58 – 35:08
Custom Claude Skills with scripts: solving icon-name hallucinations via “Find Icon”
Brian explains a recurring pain: AI guesses icon names incorrectly, causing import errors and churn. He built a “Find Icon” skill backed by a TypeScript script to search thousands of icon files efficiently and resolve synonyms (e.g., “search” vs “magnifying glass”).
- •AI often hallucinates internal asset names (icons) leading to repeated fixes
- •Skills differ from commands: they should trigger automatically when relevant
- •Bundling skills with scripts enables efficient, programmatic searching at scale
- •Practical synonym search improves first-pass correctness and reduces friction
- 35:08 – 41:59
Demo: a /deploy command to hide Git/GitHub complexity while teaching it implicitly
To lower the intimidation barrier of Git, branches, and CI, Brian demos a deploy command that checks prerequisites (GitHub CLI, auth), creates a branch/commit/PR, opens the PR in a browser, and monitors CI—fixing failures and pushing updates automatically.
- •Deploy command guides users through prerequisites and correct Git hygiene
- •Automates branch creation, staging, commits, PR creation, and navigation
- •CI monitoring loop reduces “help me fix this red X” support burden
- •Design goal: make workflows approachable without dumbing them down
- 41:59 – 46:49
How code-based prototyping changes design at Notion—especially for AI UX
Brian explains he still spends most time in Figma, but AI product design demands reality-based testing. For chat and agent experiences, static golden paths break quickly; code prototypes connected to real models reveal failure modes, latency issues, and necessary error/progress states.
- •Figma remains valuable for many UI decisions; not everything needs code
- •AI interactions can’t be validated well with static conversational mockups
- •Real-model prototyping exposes errors, follow-ups, delays, and non-ideal paths
- •Designers must track shifting model capabilities to design “at the edge” of what works
- 46:49 – 51:45
Tool and prompting preferences: why Claude Code + Opus, and what to do when AI isn’t listening
Brian discusses his tool stack preferences—using Cursor for quick inline fixes but relying on Claude Code for deeper work and planning quality. For prompting failures, he emphasizes a surprisingly human factor: tired prompts create bad outputs; rest and clarity often outperform clever tricks.
- •Cursor remains useful for fast local fixes (e.g., “Fix in chat” on errors)
- •Claude Code + Opus feels better for planning/execution and communication style
- •Different models have different “mouth feel” and fit different workflows
- •When outputs degrade, the root cause is often unclear/tired prompting—sleep helps
