The era of effectively free AI tokens was never going to last. As VC money gets tighter and five-hour windows, weekly caps, and usage credits become normal, we need to get more deliberate about where those tokens go.
UI iteration is one of the easiest places to waste them. You ask for a dashboard, get the usual purple gradient and floating cards, then spend four prompts saying “less purple”, “more rounded”, “the buttons feel off”, and “please remove the emoji.” The model keeps generating; your context keeps growing; your actual product has barely moved.
Last week, three different people sent me their vibe-coded prototypes for feedback. Different products, different problem spaces. All three looked exactly the same: system-ui font, a purple-to-pink gradient somewhere, decorative emoji in the headings, an unrequested dark mode, and not a single focus ring in sight.
That isn’t Claude’s fault (or v0’s, Lovable’s, or Cursor’s). Nobody told the model what “good” looked like, so it reached for the most probable version of a modern app. The output worked. It just looked like every other first attempt.
I vibe-code almost every day — internal tools at work, weekend prototypes, this site you’re reading on. After enough builds, I found that a minute of upfront UI direction saves several rounds of visual correction later. This post is the small decision I now make before writing the first prompt.
A note: I’m a PM, not a designer. What follows isn’t a design system manifesto. It’s the cheat sheet I keep going back to so that what I ship doesn’t look like everyone else’s first prompt.
TL;DR
-
Spend one minute before you spend tokens. Choosing the UI direction upfront saves repeated “less purple, more rounded” prompting later.
-
Answer two questions: What should the product feel like, and what kind of screen are you building?
-
Give the model a small design spec, not adjectives. Fonts, colours, spacing, radius, motion, and interaction states produce a direction. “Modern and friendly” does not.
-
Reuse your defaults. I keep eight UI directions and a short list of non-negotiables ready to paste into every build.
-
The payoff is practical: fewer generations, less wasted context, and a first version that does not look like every other vibe-coded app.
Why Every Vibe-Coded UI Looks the Same
If you’ve prompted any of these tools recently, you already know the pattern: system font, familiar card shadows, indigo buttons, a gradient header, decorative emoji, and usually a dark mode nobody asked for.
It’s not a bug. The model is doing exactly what you asked: produce the most likely UI given the prompt “build me an X.” The most likely UI is the average of every X it saw during training. The average of a million SaaS landing pages is, predictably, a SaaS landing page that looks like every other SaaS landing page.
The fix is not to become a designer before opening Claude Code. It is to make a few choices that the model would otherwise make for you.
I have found that two choices do most of the work: the vibe and the kind of screen.
The Two Questions I Answer Before Prompting
Before I describe the features, data, or stack, I answer:
- What should this feel like? Calm and editorial? Dense and utilitarian? Warm and consumer-friendly? Sharp and premium?
- What kind of screen is it? A dashboard, a single-purpose tool, a reading page, an onboarding flow, or a landing page?
That is usually enough direction. I am not trying to design the entire interface before the model sees it. I am trying to remove the two biggest sources of ambiguity.
1. What Should It Feel Like?
What’s the vibe? How should this thing feel to use? Calm and editorial? Dense and utilitarian? Playful? Premium B2B?
This is the larger of the two calls because it influences almost everything the model generates: typography, colour, density, spacing, corner radius, shadows, and motion.
The Eight UI Vibes I Keep Reusing
These are not the eight official categories of interface design. They are simply the eight directions that cover most things I build:
- Editorial — Magazine-like. Calm, text-first, generous spacing. Serif headings on warm white. For: blogs, portfolios, essay-style products. This site sits here.
- Utility — Dense, fast, professional. Linear or Notion. Information-first. For: dashboards, internal tools, dev tools. Most of what I build at work lives here.
- Warm Consumer — Soft, friendly, rounded. Headspace or Apple Health. Terracotta or sage on cream. For: personal apps, finance, health, wellness.
- Sharp Product — Premium B2B. Stripe or Vercel. Tight typography, precise spacing, one deliberate brand accent. Flat — no atmospheric effects. For: SaaS landing pages, B2B tools.
- Soft SaaS — The “Lovable” aesthetic. White background with oversized blurred colour blobs in the corners, indigo/violet accents. Atmospheric — floats in space. For: AI products, dev tools, agent UIs.
- Playful — Bold, colourful, expressive. Duolingo. Huge display type, paired bold colours, bouncy motion. For: consumer fun apps, learning tools, side projects with personality.
- Brutalist — Hard edges, mono font for labels, no shadow, no radius, one off-colour accent. Vercel-blog, GitHub Primer, Are.na. For: dev portfolios, indie tools, raw blogs.
- Glass / Spatial — Frosted-blur surfaces with depth via translucency. Vision OS, iOS Settings. Sage or icy accents, ambient. For: spatial / ambient interfaces, meditative tools.
When in doubt, I start with Editorial, Utility, Warm Consumer, or Soft SaaS. Sharp Product, Playful, Brutalist, and Glass need more commitment. Half-executing them tends to look worse than choosing a safer direction and doing it properly.
Play with each vibe
Same component, eight skins. Tap a name to swap. Each redraws the card with the right colours, type, radius, and motion for that vibe. When you find one you like, copy its full prompt block straight to your clipboard.
Read 30 minutes
Streak 12 days · Last completed yesterday
Want to see the complete screen? Open the Editorial reference →
2. What Kind of Screen Is It?
After the vibe, I add one plain layout sentence: “make this a dashboard”, “single-screen tool”, “reading page”, “onboarding flow”, or “landing page.”
The goal is not to create another framework. It is to stop the model from giving you a marketing page when you wanted a working tool, or a dense dashboard when you wanted a calm reading experience.
A few examples from things I’ve actually shipped: the SLAP debug dashboard was Utility with a dashboard layout. Whispr Flow was Sharp Product around one focused screen. This site is Editorial with a reading-first layout.
See What One Minute of Direction Changes
Most “build me an X” prompts look like this:
Build me a habit tracker. I want to track 5 habits a day,
see a calendar view, and get a streak count.You’ll get a working habit tracker. It will also be generic.
Here is the same product after answering the two questions:
Build me a habit tracker. Track 5 habits a day, calendar view,
streak count.
Design system: Warm Consumer
- Background: #FFFAF3 (cream)
- Text: #2D2620 (warm dark brown), secondary #6B5D54
- Accent: #D97757 (terracotta) for primary actions only
- Font: DM Sans throughout; body 16px, headings 24/32
- Corner radius 12px on cards, 9999px pill on primary CTAs
- 8pt spacing scale; card padding 24px; section spacing 48px
- Motion: 250-350ms ease-out; subtle scale-down (0.97) on tap
Layout hint: one focused screen
- Centred canvas, max-width 720px
- 5 habit rows stacked vertically, each with a circular check
- Calendar strip sticky at top, streak counter top-right
- Mobile: full width with 16px horizontal padding
Non-negotiables:
- Light mode. No dark variant.
- Real habit names like "Read 30 min", "Walk 8k steps". No lorem.
- Hover, active, focus, and disabled states on every interactive element.
- Touch targets ≥ 44px on mobile. No horizontal scroll at 375px.
- Icons from lucide-react only. No emoji in the UI.The second prompt is longer, but it usually saves prompts overall. It gives the model fewer visual decisions to improvise, and gives me a much better first version to react to.
I do not write this block from scratch every time. I keep all eight directions in the UI prompt builder. I choose the vibe and screen, add the product context if it matters, and copy the generated prompt.
The Defaults That Save Me More Rework
The vibe changes from project to project. These rules mostly do not:
- Light mode by default. Dark only if I explicitly ask for it.
- Real content. No lorem, no fake placeholder names, no generic marketing fog.
- Designed states. Hover, active, focus, disabled, loading, empty, and error states.
- Mobile-first. Build for 375px, then enhance to tablet and desktop.
- One icon library. I usually ask for lucide-react, 16px or 20px.
- No decorative emoji. It is still the fastest tell of an AI-default UI.
Two things still trip me up. First, the UI drifts as the session gets longer: screen one is Sharp Product, while screen four has somehow acquired a purple glow. I now repeat the visual direction when prompting a new screen instead of assuming the model remembers it.
Second, mixed products confuse the model. A landing page that opens into a dashboard is really two different screens with different jobs. I build them separately, then stitch them together.
The Actual Point
This is not really about making prettier prototypes. It is about reducing avoidable iteration.
As usage limits get tighter and the era of endlessly subsidised tokens fades, vague prompting becomes expensive in a very boring way. Not because one bad prompt costs a fortune, but because every unnecessary correction adds more context, more generations, and more chances for the build to drift.
One minute of “Warm Consumer + single-screen tool” is cheaper than thirty minutes of “no, more rounded, less purple, can the buttons be softer.”
And the choice itself is not purely a design skill. Knowing which direction fits a product is a judgment call about the user, the task, and what the experience should communicate. That is a product decision. The prompt is just where it gets expressed.
This is the first post in a short series on getting more out of Claude Code and vibe-coding tools. Next up: writing prompts the model actually follows — XML structure, anti-patterns, and why specificity beats verbosity. After that: choosing a stack, iterating without burning context, and shipping a vibe-coded prototype past the demo.
If you’re vibe-coding and want to compare notes on any of this, find me on Twitter or LinkedIn. Always up for it. Or subscribe to the RSS feed for the rest of the series.