I am primarily a back-end developer. I design APIs, data models, background jobs, and systems that need to scale and behave predictably. UI work is part of my job, but it is not where I naturally spend most of my time or energy. That does not mean I accept weak UI.

What changed for me is not suddenly becoming a UI designer. What changed is that LLMs gave me a reliable, fast feedback loop for UI decisions. They act like a senior UI reviewer who never gets tired of audits, refactors, or second opinions. I still own the decisions, but I no longer work in isolation or guesswork.

This post documents 22 concrete UI prompts I now use regularly. Each one solves a specific UI problem I encounter in real projects.

For every single point below, you can find in the linked GitHub repository:

• A full standalone “Before” HTML page
• A full standalone “After” HTML page
• The exact prompt used
• A clear explanation of what changed

This article focuses on why each prompt exists, when to use it, and what kind of UI problems it solves. The concrete artifacts live in GitHub so you can run them locally and see the impact immediately.

How the 22 prompts are grouped

I group these prompts by intent, not by CSS properties.

1. Direct UI changes and learning-oriented edits (1–2)
2. Visual consistency audits (3, 4, 12, 20)
3. Responsiveness and layout safety (5)
4. Reuse, structure, and maintainability (6, 14, 21)
5. Global foundations (7)
6. Professional polish and perceived quality (8, 16–19)
7. Theme systems and design tokens (9–11)
8. Intent clarity and necessity (13, 22)
9. Naming and conventions (15)

1) Asking to change something on the page

This is the most tactical prompt. You already know what you want to change. Alignment, spacing, button style, visual emphasis.

The value here is speed and safety. Instead of poking at CSS until it looks right, you ask for a minimal diff that preserves intent and avoids accidental regressions.

You use this when:

• The UI works but needs a targeted adjustment
• You do not want refactors or philosophy, just a clean change
• You want something you can review like a code diff

The GitHub example shows how a simple alignment and button-style change can immediately improve clarity without rewriting anything.

2) Asking how to change something manually

This prompt exists to teach you your own UI.

Sometimes you do not want the change done for you. You want to understand which rule controls what, how to inspect it in DevTools, and how to avoid fighting specificity.

This is especially useful when:

• You are debugging unexpected layout behavior
• You inherit CSS you did not write
• You want to build intuition instead of blindly applying patches

The Before and After example demonstrates how restructuring CSS and adding clarity makes future edits dramatically easier.

3) Asking to check color consistency

Color drift happens slowly. One gray becomes three. One blue becomes two almost-identical blues.

This prompt treats color like technical debt.

You use it when:

• You notice the UI feels slightly incoherent
• You suspect duplicate or near-duplicate colors
• You want to introduce variables without a full redesign

The GitHub example shows how consolidating colors into semantic roles instantly improves visual coherence and future maintainability.

4) Asking to check font size consistency

Typography inconsistency is one of the fastest ways to make a UI feel unpolished.

This prompt surfaces accidental one-offs and replaces them with a deliberate scale.

You use it when:

• Text feels noisy or uneven
• Headings feel too loud or body text feels cramped
• You want to improve readability without changing content

The example demonstrates how small changes to font size, spacing, and line height dramatically improve scanability.

5) Asking to check responsiveness

Most UI bugs do not appear on your screen. They appear on smaller screens.

This prompt audits layout behavior across common breakpoints and fixes issues with minimal intervention.

You use it when:

• Buttons overflow or get squished
• Fixed widths cause horizontal scrolling
• Touch targets feel unsafe on mobile

The example shows how wrapping, flexible sizing, and small breakpoint rules prevent real-world usability issues.

6) Asking to detect reuse and refactor similar styles

This is about preventing future inconsistency.

When multiple components look the same but are styled separately, every future change becomes risky.

You use this when:

• You see copy-pasted styles across components
• You anticipate more features coming
• You want to reduce duplication without over-engineering

The example shows how extracting a shared primitive cleans up the codebase immediately.

7) Asking to create global box-sizing

This is a foundation-level fix.

Without global box-sizing, layouts behave in surprising ways when padding and borders change.

You use this when:

• You notice widths behaving unpredictably
• You want fewer mental calculations when adjusting spacing
• You are starting or stabilizing a project

The example demonstrates why this single rule eliminates an entire class of layout bugs.

8) Asking to make the look of elements professional

This prompt focuses on polish, not decoration.

It improves spacing, hierarchy, interaction states, and accessibility without adding visual noise.

You use this when:

• The UI works but feels slightly unfinished
• You want production quality without redesign
• You care about focus states and interaction clarity

The example shows how subtle adjustments dramatically raise perceived quality.

9) Asking to replace used colors to change the theme

This prompt proves whether your UI is structurally sound.

If changing a theme is painful, the UI was brittle.

You use this when:

• Introducing dark mode
• Supporting brand refreshes
• Testing design system readiness

The example demonstrates a full theme swap without changing structure.

10) Asking to extract design tokens

This is where ad hoc styling becomes a system.

You use this when:

• Styles start repeating across screens
• You want consistency without manual policing
• You expect the UI to grow

The example shows how tokens clarify intent and simplify future changes.

11) Asking to rename tokens and variables

Bad token names slow teams down.

This prompt improves communication, not visuals.

You use this when:

• Tokens exist but feel confusing
• New contributors struggle to understand usage
• You want long-term scalability

The example demonstrates how semantic naming reduces cognitive load.

12) Asking to detect hidden inconsistencies

These are the “almost right” problems.

7px instead of 8px. 11px instead of 12px.

You use this when:

• The UI feels subtly off
• You want to normalize without redesign
• You suspect organic drift

The example shows how normalization improves rhythm immediately.

13) Asking if a layout matches user intent

This is a UX sanity check.

You describe a scenario, not a design rule.

You use this when:

• A page has a clear primary action
• You want to reduce hesitation or confusion
• You care about task completion speed

The example shows how small changes in order and alignment improve clarity.

14) Asking how to split a page into reusable components

This prompt introduces structure before chaos.

You use it when:

• Pages grow organically
• Similar sections appear repeatedly
• You want clean boundaries before refactoring becomes expensive

The example demonstrates how visual structure maps naturally to component boundaries.

15) Asking to standardize naming conventions

Naming is architecture.

This prompt removes ambiguity and enforces consistency.

You use it when:

• Class names mix styles
• Ownership is unclear
• CSS becomes harder to reason about

The example shows how BEM-style naming clarifies structure instantly.

16) Asking to improve perceived quality without decoration

This is one of the highest ROI prompts.

No new visuals. No branding changes.

You use it when:

• The UI feels slightly cheap
• You want refinement, not flair
• You care about subtle quality signals

The example shows how rhythm, spacing, and states do the work.

17) Asking to make UI feel calm, confident, or premium

This prompt translates emotional goals into concrete changes.

You use it when:

• Stakeholders describe feelings, not specs
• You want intentional tone
• You need repeatable guidance

The example demonstrates how “calm” maps to contrast, spacing, and hierarchy.

18) Asking to reduce visual noise

This prompt removes clutter without removing capability.

You use it when:

• Screens feel busy
• Too many separators compete for attention
• Users need focus

The example shows how simplifying structure improves clarity immediately.

19) Asking for micro-adjustments

This is a refinement pass.

You use it when:

• Everything is almost right
• You want alignment and rhythm to snap into place
• You are preparing for release

The example shows how small fixes compound into polish.

20) Asking whether shadows, borders, or separators are overused

This prompt enforces hierarchy discipline.

You use it when:

• Multiple separation techniques stack
• The UI feels heavy
• You want clarity without flatness

The example shows how choosing one hierarchy method improves calmness.

21) Asking to simplify CSS to reduce cascade complexity

This is maintainability-focused.

You use it when:

• Specificity battles appear
• Overrides pile up
• Fear of touching CSS grows

The example demonstrates how flattening selectors restores confidence.

22) Asking what UI elements are actually necessary

This is the hardest and most valuable prompt.

It asks whether elements earn their place.

You use it when:

• Screens accumulate features over time
• Cognitive load increases
• You want focus and speed

The example shows how removing noise improves task completion.

Final thought

None of these prompts replace design skill. They amplify engineering judgment.

For me, LLMs did not turn UI into magic. They turned it into something reviewable, auditable, and iterative, just like back-end code.

If you want to see every example in action, with full runnable code, exact prompts, and detailed diffs, check the GitHub repository linked with this post.

That is where the real proof lives.