How I AIThe internal AI tool that's transforming how Stripe designs products | Owen Williams
CHAPTERS
- 0:00 – 2:51
Why Stripe needed better AI prototyping than “blurple slop”
Owen explains the immersion-breaking problem with generic AI-generated UI that doesn’t match Stripe’s design system. The team wanted prototypes that feel real in design reviews—convincing enough that people ask whether they’re looking at the actual product.
- •AI design tools often output uncanny “Tailwind indigo/blurple” UI that clashes with Stripe’s look
- •Design reviews suffer when prototypes don’t match the production experience
- •Goal: prototypes that are realistic enough to evaluate interactions, layout, and polish
- •Need to teach AI tools Stripe’s predictable design system building blocks
- 2:51 – 5:38
Protodash v1: an internal, design-system-aware prototyping starter kit
Owen introduces Protodash: a prototype environment built on React and Stripe’s Sail design system that makes dashboards fast to spin up. It combines design-system components, routing, and opinionated conventions so designers and PMs can prompt their way to a near-realistic product shell.
- •Protodash provides a dashboard-like “Chrome” (nav, routing, frame) plus Sail components
- •Works with Cursor/Claude Code to generate pages from prompts
- •Typically gets users ~80–90% of the way, with designers refining the last mile
- •Designed to hit Stripe’s high quality bar so prototypes don’t look “off” in reviews
- 5:38 – 7:09
Engineering background as a design superpower: lowering the technical barrier
Owen shares how his engineering-first background shaped the tool: reduce setup friction so non-engineers can prototype in code without wrestling with web tooling. AI changes the equation by making terminals, Git, and NPM approachable through asking instead of memorizing.
- •Technical fluency is powerful for designers, but the “jump” to NPM/Vite/Git is intimidating
- •AI enables designers to ask for commands and explanations on demand
- •Design goal: the minimum required knowledge (ideally just ‘run dev’)
- •Hiring/empowering “technical designers” becomes more feasible with AI assistance
- 7:09 – 9:04
Teaching the AI Stripe’s design system: Cursor rules + Sail MCP integration
The heart of Protodash v1 is a bundle of rules and an internal MCP server that exposes Sail components. Owen describes how the rules guide the AI’s order of operations, prevent hallucinated components, and handle failure modes when design-system data isn’t available.
- •Cursor rules instruct: check Sail MCP before writing code; follow specific workflows (e.g., Figma links)
- •MCP server provides authoritative design-system components and patterns
- •Rules mitigate hallucinations (LLMs inventing non-existent components/styles)
- •Codifies common pitfalls and guardrails for consistent, Stripe-like output
- 9:04 – 9:57
Running prototypes locally vs. on dev boxes—and why URLs change reviews
Owen contrasts early local workflows with Stripe’s dev box infrastructure that spins up ready-to-use environments from a simple internal URL. Dev boxes remove setup steps and, crucially, create shareable prototype URLs that make reviews interactive and frictionless.
- •Local setup worked but was slower and harder to share
- •Dev boxes spin up a configured environment in minutes via an internal URL
- •Designers connect via Cursor as if local, but without running NPM or configuring repos
- •Shareable URLs enable stakeholders to click through prototypes during reviews
- 9:57 – 10:46
“Demos, not memos”: rewiring Stripe’s design review culture
The conversation shifts from slide decks and static Figma screenshots to live, clickable demos. Owen frames Protodash as a way to reduce presentation churn and get more meaningful feedback on real flows, error states, and multi-step interactions.
- •Interactive prototypes beat slides for understanding and critique
- •Design reviews can focus on behavior, states, and intent—not explaining static frames
- •Prototypes make it easier to validate error states and secondary actions
- •Cultural goal: eliminate “slideshow” reviews and move to live demos
- 10:46 – 16:36
Why dashboards are a perfect fit: data, states, i18n, and realistic scenarios
Claire and Owen dig into why code-based prototyping is transformative for data-heavy products like Stripe. Protodash enables fast switching between realistic states—zero data vs. high volume, startup vs. enterprise, messy data, and internationalization—without duplicating endless Figma frames.
- •Complex dashboard states and interactions are painful to prototype in Figma
- •Code prototypes make it easy to generate realistic data and scenarios
- •Internationalization and long strings become testable early
- •Multi-step flows become feasible with reusable components and routing
- 16:36 – 19:08
Protodash Studio: bringing vibe-coding prototyping into the browser
Owen introduces Protodash Studio, a browser-based layer on top of the Protodash environment. It offers a prototype hub, a feed of examples for inspiration, and the ability to remix others’ prototypes—reducing reliance on local editors and making prototyping more accessible.
- •Studio runs primarily on dev boxes and is accessed entirely via browser
- •Home shows prototypes you’re working on plus a feed of others’ work
- •“Remix” enables copying another prototype’s code to iterate quickly
- •Goal: a v0-like experience tailored to Stripe’s prototyping workflow
- 19:08 – 23:47
Live demo: in-browser variants, line chart swap, and self-testing via screenshots
Owen demonstrates generating a variant that converts a stacked bar chart into a line chart, all from the embedded LLM. The system then self-tests by taking screenshots and checking the result, iterating automatically to improve correctness and presentation.
- •Embedded LLM can create variants without opening Cursor
- •Variant bar allows quick comparison and selection across design options
- •System can self-test by driving the UI, taking screenshots, and validating output
- •Quality focus: iterate until the prototype visually matches expectations
- 23:47 – 26:00
Pushing exploration safely: ‘crazy eights’, Tailwind access, and generative freedom
They discuss balancing strict design-system adherence with space for “happy accidents.” Studio can optionally grant Tailwind access (with strong guardrails) for net-new explorations, and Owen wants a ‘crazy eights’ mode to rapidly generate diverse directions.
- •Strict design system ensures Stripe-like output, but can limit novelty
- •Optional Tailwind access enables more generative, experimental UI ideas
- •Guardrails explicitly prevent Tailwind usage unless enabled
- •Future idea: ‘crazy eights’ mode to generate multiple divergent concepts quickly
- 26:00 – 27:19
In-canvas ‘annotate-for-AI’: targeted feedback without CSS detective work
Owen shows an annotation mode where users can select UI elements directly and leave instructions for the AI to fix. This replaces brittle descriptions like class names and enables batching many precise edits into a single AI task queue.
- •Select elements on the canvas and attach AI-directed comments
- •Batch multiple fixes (padding, tooltip behavior, etc.) for one execution pass
- •Avoids vague debugging prompts like ‘fix the element with class X’
- •Improves iteration speed and precision, especially in complex screens
- 27:19 – 29:38
Design review mode: comments, AI summaries, and automated follow-ups
Studio includes a design-review workflow where stakeholders comment directly on a shared URL. AI can summarize feedback and convert comments into a fix queue, enabling rapid iteration and cleaner post-review follow-through.
- •Start a review session and collect feedback as in-context comments
- •AI generates an at-a-glance review summary
- •Enter review mode to turn comments into actionable AI tasks
- •Reduces post-review busywork and improves closure with stakeholders
- 29:38 – 32:00
Why internal tools beat off-the-shelf: culture fit, rapid evolution, and PR contributions
Claire and Owen argue that internal tools can be precisely tuned to a company’s review cadence and culture, which drives adoption and impact. Owen notes how AI makes it easier to build and evolve tools quickly—and even designers contribute pull requests to shape the workflow.
- •Off-the-shelf tools can’t match company-specific rituals (e.g., ‘vibe checks’)
- •AI lowers the cost of building bespoke tools that change how teams work
- •Internal tools can iterate fast without full production-grade constraints
- •Designers contributing PRs creates empowerment and continuous culture evolution
- 32:00 – 34:59
PMs as surprise power users: faster exploration, better communication, earlier testing
Protodash unexpectedly became popular with PMs, initially raising concerns about PMs “designing.” Over time it improved PM-designer collaboration, let PMs prototype from PRDs, and enabled earlier user testing with realistic interactions instead of static mockups.
- •PMs can paste PRDs (e.g., from Google Docs) and generate Stripe-like prototypes
- •Helps PMs communicate intent visually and advocate with concrete artifacts
- •Enables earlier user testing using clickable flows rather than image hotspots
- •Shifts staffing debates toward discussion of real work and needed elevation
- 34:59 – 42:01
Live speedrun: building a BFCM pet store dashboard—and taming emojis and layout
They prompt Studio to generate a Black Friday/Cyber Monday dashboard for a pet store with real-time sales visuals. The first pass includes an oversized chart and enthusiastic emojis; Owen demonstrates quick iterative correction by pointing at elements rather than over-explaining.
- •Prompt-driven generation produces a usable first draft from a vague request
- •Element-targeted feedback quickly fixes obvious layout issues (chart height)
- •Demonstrates realistic ‘80% then iterate’ workflow in seconds
- •Highlights typical model quirks (emoji overuse) and the value of guardrails
- 42:01 – 45:34
Lo-fi and clarity modes: grayscale, monospace, and ‘Comic Sans for WIP’ signals
They discuss the downside of always showing high-fidelity prototypes and the need to signal ‘work in progress.’ Studio supports fidelity modes (e.g., grayscale/monospace), echoing practices like Shopify’s Comic Sans convention and Balsamiq-like lo-fi intent.
- •High-fidelity prototypes can mislead stakeholders about completeness
- •Modes like grayscale/monospace help communicate ‘not final’ while preserving structure
- •Revisits older UX practices: grayscale checks, Balsamiq wireframe feel, Comic Sans WIP signals
- •Studio also supports quick environment/state emulation (merchant name, banners, nav)
- 45:34 – 49:10
From prototype to handoff: the Radar example and engineer-ready source of truth
Owen highlights a Radar fraud-detection prototype built by two designers that replicates real multi-step product behavior. The most notable shift is handoff: engineers can use the prototype PR as a practical source of truth, inspecting real padding and components instead of relying on redlines.
- •Designers recreated complex Radar functionality and interactions in Protodash
- •Supports realistic journeys: banners, list views, reasons, notes, rule inspection
- •Handoff improves when prototypes live as code/PRs engineers can reference
- •Replaces legacy practices like redlining with inspectable, interactive artifacts
- 49:10 – 54:44
Lightning round: parental-leave vibe-coding, prompting resets, and what’s next
In closing, Owen shares how AI fits into parental leave side projects (receipt/manual/serial tracking) and his prompting habits. His key tactic: when conversations devolve into shouting, clear context and restart—then he invites ‘design engineer’ builders to join Stripe’s prototyping effort.
- •Parental-leave side project: capture receipts + product photos, extract serials, store manuals
- •Feature idea: reminders to sell items later; warranty/maintenance alerts
- •Prompting strategy: be specific; when things go off the rails, reset and start over
- •Stripe is hiring for a design-engineer type to drive internal prototyping tools
