Most prompts for interface work fail the same way: they describe the thing and not the constraints, so the model picks the constraints itself and picks the average ones. "A pricing section" has a million valid answers and the model returns the median. "A pricing section with three tiers, a monthly and annual toggle, no animation library, working as a server component" has perhaps four.
Here is what to put in, and what to stop putting in.
The four things worth naming
The constraint before the aesthetics. What it must not do is more informative than what it should look like. No animation runtime, works without JavaScript, must render on the server, must fit 320px: each of those eliminates most of the possibility space in one clause.
The content, roughly. A pricing section with two tiers looks nothing like one with five. A nav with four items is not the same component as one with twelve. Giving the actual shape of the data stops the model designing for content you do not have.
Your tokens. Naming your CSS variables means the output is adapted in the same step rather than in a second pass. This is the highest-value line in most prompts and almost nobody includes it.
The environment. Framework, React version, Tailwind version, whether server components are in play. A component written for the wrong Tailwind version installs and silently does nothing, which the v4 guide covers.
Ask for options, not for code
The single change that improves interface work most. "Show me four hero sections that use CSS rather than video" returns things to choose between; "build me a hero" returns a file to review.
With a catalogue connected through MCP, those options are real components with previews, which is the difference between reviewing a decision and reviewing a diff.
Iterating without losing what worked
Three habits.
Change one thing per turn. A prompt asking for a new layout, a different palette and tighter spacing at once produces a component with none of the three quite right and no way to tell which instruction caused what.
Point at the part. "The card padding" beats "make it cleaner". Vague adjectives get vague edits, and "modern" is the vaguest of them.
Say what to keep. Models regenerate freely. "Keep the current layout and only change the type scale" is what stops the third iteration losing the thing that was working in the first.
What not to bother with
Adjective stacking. "Beautiful, modern, sleek, professional" adds nothing and costs the model attention that a constraint would have used. The not-generated guide covers why those words produce exactly the look people complain about.
Asking for the whole page in one turn. A landing page is nine blocks with different requirements. Generated as one artefact it is average everywhere; the landing page guide has the sequence to work through instead.
Describing what a catalogue could show. If a component exists, finding it beats specifying it, and the model is far better at choosing than at inventing.
After the output
Whatever the prompt, the same checks apply, and they are the review checklist: is the text in the HTML, does Tab reach everything with a visible focus state, are the states beyond the happy path there, and did it hardcode a colour instead of reading a token.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| 21st MCP | Options as previews rather than as generated files | Installs need a membership |
| A project rules file | Conventions the agent applies without being asked each time | Instructions, not components |
| A design brief | Deciding what the screen should be before any prompt | Not a prompt at all, which is the point |
| 21st | Real components to choose between | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- What makes a good prompt for a component?
- The constraint, the content shape, your tokens and the environment. What it must not do eliminates most of the possibility space in one clause, the real number of tiers or nav items stops the model designing for content you do not have, and naming your CSS variables gets the adaptation done in the same step.
- Should you ask for code or for options?
- Options. Show me four hero sections that use CSS rather than video returns things to choose between; build me a hero returns a file to review. With a catalogue connected through MCP, those options are real components with previews rather than generated guesses.
- How do you iterate without losing the good parts?
- Change one thing per turn, point at the specific part rather than using adjectives, and say explicitly what to keep. Models regenerate freely, so keep the current layout and only change the type scale is what stops the third iteration losing what worked in the first.
- What is not worth putting in a prompt?
- Stacked adjectives such as beautiful, modern and sleek, which add nothing and produce exactly the generic look people complain about. Also whole-page requests, since a landing page is nine blocks with different requirements and comes out average everywhere when generated as one artefact.