I have shipped mobile apps for nine years, and UI is still my weakest skill. I can architect a backend-for-frontend or wire up NFC health cards without sweating it. Ask me to make an onboarding screen feel premium and I stall out. For a long time I treated that as a fixed fact about myself and shipped slightly-off-looking apps because of it.
I know app UX. I have shipped enough flows to feel where they break. The part I lack is the eye for detail: color matching, branding, fonts, spacing. That has never come naturally to me.
If your AI-generated screens look generic, the fix is not a better model and it is not hiring a designer. Claude already knows what good design looks like. It does not know what your app looks like. Give it two things before it generates anything: a design tokens file (your colors, spacing, and type as named values) and a short rules block describing how your app uses them. With those in the prompt, the output lands on-brand and ships. Without them, you get a template you have to rebuild by hand.
Tokens and rules are not a magic button. You still have to describe the app: who uses it, how it should feel, an app or two you want to borrow the direction from. The model needs that steer. What the tokens and rules do is stop it from guessing on the part you cannot put into words anyway.
Then I stopped pretending the gap would close on its own. I treat it now the way I treat every skills gap: I use AI as a multiplier. The part that took me a while to learn was not prompting. It was what to hand the model so it covers the exact thing I am bad at, instead of guessing and handing me homework. Here is that setup, with the real before and after from my own React Native boilerplate.
Why does Claude's design skill produce generic screens?
Claude Code ships with a design skill. Out of the box it writes components that look fine alone and wrong next to each other. Generic spacing. A violet-and-white card look it falls back on. Hardcoded colors that ignore the palette you already picked.
Nobody told the model your colors, your spacing, your fonts, or your rules, so it reaches for a 2021 template. The whole job is closing that gap. Same content, same app above. The right side is what happens when the model stops guessing.
What are design tokens, and why do they fix most of it?
A design token is a named value. Instead of #7C3AED scattered across forty files, you have accent.primary. Instead of random padding, a spacing scale: 4, 8, 12, 16, 24. Instead of five fonts, one type ramp. You define them once, then paste them into every prompt so the model builds with your system instead of inventing a new one each time.
I skipped this for too long because it felt like overhead. The token file is the asset that keeps the next fifty screens consistent without me thinking about it. Everything downstream reads from it, mobile or web.
What goes wrong when you run the default skill on a real app?
You install the skill, run it on your home screen, it looks decent, you ship it. Two weeks later you have nineteen one-off components that share no styles, and your design system has quietly forked into a mess. I have done this. It is how I learned the rest.
The fix is not a better tool. It is giving the model four things before it generates anything:
- Your tokens, inlined into the prompt.
- A real component from your app, so it matches your conventions.
- The mistakes to avoid: no inline styles, no hardcoded colors, no generic look.
- Where the file goes, so you are not pasting output around by hand.
Give it those four and the output ships. Skip them and you get orphan components.
What does a non-designer actually get from this?
The one design skill you do not have, applied on every screen for free. Every new screen matches the last because the model builds from the same tokens. The first screen takes setup, the fiftieth takes a sentence. And the product reads as funded instead of hacked together by someone who is good at code and shaky at design.
That last part is not vanity. Researchers at Carleton University found people form a visual judgment of an interface in roughly 50 milliseconds, and that snap judgment colors how much they trust everything after it (Lindgaard et al., 2006, Behaviour & Information Technology). A first-time user decides whether your app looks legit before they read a word. A coherent system buys that trust, even when a designer never touched the file.
How do you start this week?
You do not need to redesign everything. Do this:
- Pull your colors, spacing, and fonts into one short list. That is your token set.
- Pick your worst screen.
- Paste the tokens plus "here is the screen, refactor it to use only these, no inline styles" into Claude.
- Compare. Then do the next screen.
That is Claude Design 101. The system is the asset. The model is the labor. I have been running this exact setup for months. The onboarding in Morrow Self, my wellness app, came out of the agent already looking like the product instead of looking like AI. My two boilerplates ship with the same wiring: AI Mobile Launcher for React Native, and AI Web Launcher for Next.js. Different tokens, same workflow, whether it is a mobile app or a web app, same engineer who still cannot design a screen from scratch.
Want the exact prompts? I packaged the two I ship with, the design-system refactor prompt and the token-block template, plus the open-source skill that runs the whole flow:
chohra-med
/
claude_design_skill
A Claude Code skill that front-loads design tokens and rules so AI can only produce on-brand UI, then verifies the output.
claude-design-idea-to-ready
From a one-line idea to on-brand, shippable design, in the right order.
A Claude Code skill that front-loads the constraints (design tokens + a CLAUDE.md design-rules block) so the model can only produce on-brand UI, then runs generation last and verifies it against the rules.
Created by Malik Chohra · Code Meet AI newsletter
Sponsored by AI Web Launcher and AI Mobile Launcher and CasaInnov
Most AI-generated UI looks the same because it is handed zero constraints. This skill front-loads the constraints (design tokens + a CLAUDE.md design-rules block) so the model can only produce on-brand output, then runs the generation last and verifies it against the rules.
Before / after
Same screen, same prompt. The difference is the foundation the model was given before it generated.
| Generic (no constraints) | On-brand (this pipeline) |
|---|---|
 |
 |
It works because the brand lives in two files the model reads first:
The pipeline
- Idea…
If you would rather start from a boilerplate that already has the tokens, components, and design system wired in, that is AI Mobile Launcher Standard for React Native, or AI Web Launcher for the web.
I write Code Meet AI weekly on this kind of AI-first building. I broke down the tool side of this in Stitch vs Claude Design, and the wider idea, own the structure and swap the model, in the harness engineering piece.
FAQ
Do I need to be a designer to use this?
No, and the whole point is that you are not. The tokens and the rules hold the design decisions, so you make a few calls once (colors, spacing, type) and the model applies them after that. I am the proof. I still cannot design a screen on a blank canvas.
What exactly is a design token?
A named value that stands in for a raw one. accent.primary instead of a hex code, space.4 instead of a number. It gives the model and your codebase one source of truth instead of forty scattered copies that drift apart.
Why does Claude produce generic-looking UI by default?
Because it has no information about your app. It knows good design in general, not your palette or conventions, so with no context it reaches for a safe template. Feed it your tokens and a short rules block and that stops.
Does this work outside React Native?
Yes. The tokens-plus-rules approach does not care about the framework. I run the same setup on the web with AI Web Launcher, my Next.js boilerplate, and the before and after looks the same. The examples here are React Native because that is most of what I ship.
Is the design skill enough on its own?
Not on a real app. Run it blind and you get one-off components. The four inputs above are what turn it from a demo into something you can actually ship.
Open your worst screen. Pull its colors into one file. Paste it in with "use only these." That is the entire on-ramp, and it is the same one I used to stop shipping apps that looked like I built them alone.
Top comments (0)