How Notion Designs with AI: Brian Lovin's Prototype Playground and Claude Code Workflows

Notion's design team prototypes directly in code with help from tools such as Claude Code. Brian Lovin, a designer on the Notion AI team, built a shared environment where designers can turn an idea into an interactive prototype and test it in a real browser.

Brian calls the shared environment Prototype Playground and uses Claude Code to build within it. His principle is that designs should encounter reality as early as possible. A working browser prototype exposes constraints, edge cases, and interaction problems that a static mockup can hide.

In this episode of How I AI, Brian demonstrates how the team turns natural language into prototypes, converts Figma frames into working code, and automates repetitive development tasks such as finding valid icon names and handling deployment.

The foundation: Notion's Prototype Playground

The environment Brian built is the key to his team's AI workflows. The Prototype Playground isn't a complex platform; it's a simple Next.js application hosted in a single GitHub repository that the entire design team can access.

The setup has four parts:

• One repository: the design team works in a shared project, making prototypes visible and easy to reuse.
• Namespaced directories: each designer has a separate folder, which organizes the work and avoids collisions. The system is file-based and has no backend database.
• Shared components: styles, colors, typography, and icons from Notion's design system give new prototypes a consistent starting point.
• External links: the playground can also point to prototypes in Figma, v0, and other tools, keeping experiments discoverable in one place.

This setup is the launchpad for all the AI-powered workflows Brian demonstrated. It creates a collaborative space where designers can encounter the "reality" of code and the browser early and often.

Turn an idea into something the team can use

The interactive prototyping workflow captures Brian's voice-first path from a raw idea to a working artifact inside Notion's shared playground.

The most direct application of an AI coding assistant is turning a simple idea into a working prototype in minutes. Brian showed me his process, which combines a few clever tools to make it happen.

Make the prototype environment reusable

Brian works in a three-pane layout: his terminal running Claude Code on one side, his code editor (Cursor) in the middle, and the live browser preview on the other side. This lets him prompt the AI, review the code changes, and see the results in real-time without constantly switching contexts.

Talk through the idea at full speed

To make prompting faster and more natural, Brian uses a tool called Monologue to dictate his instructions. It's much quicker than typing out a detailed spec.

Inspect the plan before the build

Brian starts in Claude's plan mode and reads the proposed components, libraries, and structure before implementation begins. That review catches questionable assumptions before they turn into code.

We decided to build a simple detail page for a podcast episode. Here's the prompt he dictated:

I wanna build a new prototype in this How I AI directory, and we are a podcast, and I want to build a detail page for a podcast episode that has both a video player and an audio player. Underneath the page should have the title of the episode, a description, and how about if you hit play, there's little confetti that shoots up out of the player.

Build, open, and react to the result

After Brian approved the plan, Claude installed a confetti library, structured the page with Tailwind CSS, and generated the React components. A few minutes later, the prototype had working audio, video, and confetti from the player.

Convert Figma designs with a correction loop

The Figma-to-code workflow makes visual verification part of the conversion instead of treating generated code as finished on the first pass.

Brian built a custom /figma command to translate a public Figma frame into front-end code and check the implementation in a browser.

Give the command an exact Figma target

Instead of a vague prompt, Brian created a structured command that streamlines the process. He simply types /figma in his terminal and pastes the public link to a Figma frame.

Compare the render and correct the misses

The command converts the frame, checks the implementation, and repeats when it finds a discrepancy:

1. Extract: it uses Model Context Protocol, or MCP, to connect to Figma and retrieve design tokens, layout information, and assets.
2. Implement: It writes the Next.js and Tailwind code to build the UI.
3. Verify: it uses the Chrome DevTools MCP server to open the generated prototype, inspect it, and compare it with the Figma frame.
4. Iterate: If it finds discrepancies (like a missing image or incorrect layout), it goes back to the code, attempts a fix, and repeats the verification process. Brian instructed it to loop until the implementation is correct or after three iterations with no changes.

Aim for a useful first pass

In the demo, Claude generated a Notion-style sidebar from a Figma link. The first pass had broken images, but the verification loop corrected the paths and checked the page again. Brian estimates that the command can get a prototype roughly 80% complete in one prompt, with polish still required.

Turn repeated fixes into commands and skills

The custom deployment command workflow shows how Brian packages the branch, commit, push, and preview routine he otherwise repeats by hand.

Brian's most powerful insight is his number one rule for working with AI: "Anytime the AI asks you to do something, you should, before responding, try your best to see if you could teach the AI to answer that question for itself."

This philosophy led him to create a suite of custom commands and skills to automate the boring, repetitive, and error-prone parts of development. These tools are what make the Prototype Playground truly accessible to the whole team.

Fix icon-name errors with a custom skill

The problem: the AI sometimes guesses an icon name that does not exist in the codebase, causing a broken import or compilation error.

Brian's find-icon skill combines instructions with a TypeScript script that searches more than 5,000 icons, including synonyms, before choosing a valid name. The linked guide, Claude Skills explained, covers the skill format in more detail.

The skill removes repeated searches for valid icon names and prevents a common class of broken imports.

Simplify deployment with the /deploy command

The problem: designers who do not regularly use Git still need to create a branch, commit code, push it, open a pull request, and monitor CI.

The solution: Brian's /deploy command handles those steps.

The /deploy command does the following:

1. Check prerequisites: verify that GitHub CLI is installed and authenticated, then guide setup if necessary.
2. Create a branch: if the user is on main, create a descriptively named branch for the changes.
3. Open a pull request: stage the files, commit, push the branch to GitHub, and create the pull request.
4. Open the result: launch the new pull request in the user's default browser.
5. Monitor CI: check status every 30 to 60 seconds. When linting or type checks fail, attempt a fix, push it, and continue until the checks pass.

The command handles the mechanics needed to share a prototype. Code review is available but is not required in Prototype Playground. Brian said the team commonly merges after CI passes because the repository is for prototypes rather than production code. GitHub Desktop remains another option for designers who prefer a graphical Git client.

Designing AI products in code

Static mockups cannot reproduce the behavior of a chat interface or expose every failure mode of a language model. Working prototypes let designers experience those states earlier.

Prototype Playground combines shared context, reusable commands, verification loops, and deployment automation. Designers can test realistic loading states, AI failures, awkward interactions, and broken assumptions without first mastering every part of the toolchain.

And if you're ever struggling to get the AI to cooperate, remember Brian's final piece of advice: the quality of your output is directly correlated with the quality of your input. Sometimes the best way to write a better prompt is to just go to bed and try again tomorrow.

The common thread is a shorter distance between thought and artifact. Brian can explore in code without turning every experiment into an engineering request, then hand the useful prototype to the team with its behavior intact.