Stop Prompting for Pretty: 108 UI Prompts That Give Vibe-Coded Products Structure
A screenshot shows your AI what something looks like. It cannot explain the screen’s job, missing-data behavior, responsive transformation, or what must keep working after the redesign. This library turns interface patterns into useful implementation and verification contracts.
- Prompts
- 108
- Categories
- 18
- Groups
- Build · Use · Durable
- Format
- Job · Structure · States · Verify
- Use
- New builds · redesigns · cleanup · QA
Find the job. Compare the patterns. Open the field note.
Search by the interface problem you need to solve, or use the category sidebar to narrow 108 patterns into a useful shortlist.
Every field note explains fit, anatomy, states, responsive behavior, accessibility, verification, and the complete prompt. Copied prompts carry a visible source link, never a hidden instruction.
Choose a category, then compare six focused patterns.
Search when you know the problem. Browse by category when you are still choosing the right structure.
How to choose, adapt, and verify a UI patternThe quick audit, prompt anatomy, repair prompt, field tests, and FAQs.
A layout name is not a strategy.
“Build a dashboard.” “Make a pricing page.” “Use a bento grid.” Those instructions describe shape, not purpose. Name the person, the task or decision, and the next useful action before choosing a pattern.
This screen helps [specific user] understand or do [specific thing] so they can [specific next action].
Twelve questions before another “make it modern” prompt.
- Can a new user explain the screen’s job after five seconds?
- Is one idea or task clearly more important than the rest?
- Do spacing and grouping show what belongs together?
- Are interactive elements recognizable before hover?
- Is the primary action reachable by mouse, keyboard, and thumb?
- Are choices grouped and comparable instead of multiplied?
- Does every asynchronous action show acknowledgment and result?
- Can an error happen without erasing valid work?
- Does mobile preserve the task instead of shrinking the desktop composition?
- Can the interface survive keyboard use, zoom, reduced motion, and assistive technology?
- Is evidence placed beside the doubt or decision it answers?
- Can the team verify the change without using “looks better” as the test?
If several answers are no, choose a structural prompt before adding more visual treatment.
Context. Pattern. Verification.
Copy full prompt combines three layers automatically while storing the shared contract only once.
Inspect before editing.
Define the screen job, preserve working behavior, follow the real design system, and reject generic AI defaults.
Read the universal prefix
You are designing or repairing a real interface inside an existing product. Do not start by decorating it. FIRST, establish the screen job in one sentence: “This screen helps [specific user] understand/do [specific thing] so they can [specific next action].” Inspect the current repository, `design.md`, existing components, tokens, routes, data flow, accessibility behavior, tests, and any supplied reference screenshot before editing. Preserve working product behavior and the project’s existing brand language unless the task explicitly replaces it. Use the Morten A. Giraffe UI/UX field-guide principles as constraints: purpose before polish, visible hierarchy, relationship-driven spacing, meaningful contrast, clear proximity, behavioral consistency, familiar interaction patterns, reachable targets, structured choice, chunking, progressive disclosure, immediate feedback, recoverable errors, accessibility, responsive purpose, deliberate sequence, trust near doubt, and outcome-based measurement. ANTI-AI-SLOPE RULES: do not default to generic SaaS composition, random gradients, glow effects, glassmorphism, oversized rounded cards, cards-inside-cards, decorative icon circles, fake stats, fake testimonials, meaningless bento grids, excessive pills, filler copy, giant empty spacing, or animation that does not explain state. Do not invent proof, customer names, metrics, security claims, reviews, or product capabilities.
Give the screen structure.
The selected entry explains its purpose, fit, limits, behavior, UI/UX rules, and public-page considerations.
Prove the result.
Require complete states, accessibility, responsive behavior, performance restraint, tests, and a completion report.
Read the universal suffix
IMPLEMENTATION CONTRACT - Use semantic HTML and the project’s existing accessible primitives before creating new ones. - Keep one clear primary action; visually subordinate secondary and tertiary actions. - Design the complete state model where relevant: idle, hover/focus, loading, success, empty, partial data, disabled, validation error, server error, offline/retry, and permission/locked. - Preserve user input after recoverable errors. Explain what happened and the next useful action. - Make keyboard operation, visible focus, logical tab order, screen-reader naming, contrast, reduced motion, zoom/reflow, and touch targets part of the implementation—not a later patch. - Treat mobile as the same purpose under different constraints, not a squeezed desktop. Verify narrow phones, tablet, desktop, long content, and 200% zoom. - Avoid new dependencies unless the existing stack cannot reasonably support the requirement. - Keep copy specific, human, and useful. Button labels should describe the outcome. - For public/indexable pages, keep important meaning, links, headings, and metadata available without requiring client JavaScript; preserve truthful canonicals, titles, structured data, and internal links. - Protect performance: avoid layout shift, oversized media, unnecessary client JavaScript, and effects that hurt responsiveness. - Do not silently remove routes, integrations, analytics, auth behavior, deep links, metadata, or existing functionality. - Run the project’s relevant build, typecheck, lint, tests, and targeted browser checks after implementation. Fix issues caused by your changes. BEFORE CALLING IT COMPLETE, report: (1) page/screen job, (2) files changed, (3) what was preserved, (4) UX rules applied, (5) responsive/accessibility states verified, (6) tests/checks run with results, (7) remaining unknowns or production-only checks. Never claim “bug free,” “fully accessible,” or “regression free” without evidence.
When the whole product already feels generated.
Audit the product before redesigning it. Repair the highest-impact journeys while preserving behavior and recording proof.
Follow the complete Morten A. Giraffe UI/UX and Technical SEO field-guide principles as reference material. Begin read-only. Inspect the repository, project instructions, routes, layouts, design tokens, components, forms, authentication, data flow, content, metadata, tests, deployment configuration and current working behavior before redesigning anything.
Define the product audiences, major user journeys and a one-sentence Page Job for every important route. Create or extend `design.md` so the product has an explicit visual and interaction system rather than a collection of generated component decisions. Audit for AI slope: generic SaaS patterns, excessive cards/pills/radii, glow/gradient defaults, decorative icon blocks, empty buzzword copy, fake proof, meaningless bento layouts, animations without state meaning and desktop layouts merely squeezed onto mobile.
Prioritize the highest-impact journeys and repair them systematically. Preserve working business logic and useful brand character. Design complete states: loading, empty, partial, success, validation failure, server error, offline/retry, disabled and permission/locked where relevant. Target WCAG 2.2 AA behavior, intentional responsive transformations, truthful content, performance restraint and public-page technical SEO where applicable.
Do not claim success after a visual pass. Run the project's relevant build, typecheck, lint, tests, browser checks, accessibility checks and route/metadata verification. Maintain a regression ledger recording previous behavior, intended behavior, files changed, verification performed and result. Stop before destructive or speculative changes when product intent, production target, privacy requirements or migration risk cannot be verified.
Return a completion report separating observed facts, changes made, verification evidence, remaining unknowns and production-only checks.
Optional references when web access is available:
- https://www.mortenagiraffe.com/journal/ui-ux-rules-that-make-websites-work
- https://www.mortenagiraffe.com/journal/technical-seo-audit-guideDo not judge the result from the hero screenshot.
A useful prompt reduces ambiguity. Verification proves the result.
- Five-second test
- Can someone name the purpose and next action?
- Grayscale test
- Does hierarchy survive without accent color?
- Blur / zoom-out test
- Do meaningful groups remain visible?
- Keyboard test
- Can the important journey be completed without a pointer?
- Reduced-motion test
- Does removing animation preserve meaning?
- Slow-network test
- Do loading and retry states remain understandable?
- Content stress test
- Try long names, zero results, many results, missing images, and large values.
- Narrow-screen test
- Does mobile preserve the task?
- Error test
- Can the user recover without losing valid work?
- Regression test
- Did the change break a route, form, analytics event, auth flow, or metadata?
Use the prompt as a contract, not a shortcut around judgment.
Is this a component library?
No. The prompts describe interface structure and behavior. The existing project’s components and design system should determine the implementation.
Do I need a screenshot?
No. A screenshot can communicate visual language, but it cannot replace the screen job or behavioral requirements. Use one to extract principles, not to clone another product.
Can I use these prompts with any AI coding tool?
Yes. The prompts are tool-agnostic. Your AI coding agent should still read repository instructions and inspect the existing product before editing.
Why does every prompt include verification?
An interface can look correct while breaking keyboard access, loading behavior, mobile layout, route logic, analytics, metadata, or working product behavior. Verification makes those constraints part of the assignment.
Why include “avoid when”?
Patterns become AI slope when they are chosen because they are familiar rather than because they fit the task. “Avoid when” gives the human and the model a reason not to force the pattern.
Will these prompts automatically remove every AI-looking design?
No prompt guarantees taste. They reduce ambiguity and require the agent to respect the product’s real job, design system, states, and verification evidence.
Should every public page use every SEO check?
No. Use the technical checks relevant to the route. The Technical SEO Field Guide provides the complete investigation method.
Should each prompt create a new design.md?
No. Inspect and preserve the project’s existing design system, tokens, components, and visual language. Extend it only where a real rule is missing.