In my previous post, I documented 22 concrete UI prompts I use to audit, refine, and stabilize interfaces with the help of large language models. Each prompt has a full before-and-after runnable example, the exact prompt text, and a clear explanation of what changed, all available in a GitHub repository.

This post answers a different question:

How do these 22 prompts fit into a real workday when UI is not your primary role?

What follows is a repeatable, engineering-first workflow that shows when each of the 22 prompts appears during normal feature development. This is not a design methodology. It is a practical system that keeps UI quality high without slowing down delivery.

The problem this workflow is designed to solve

UI rarely breaks in obvious ways. Instead, it degrades gradually:

• Colors drift
• Spacing becomes inconsistent
• Buttons behave slightly differently
• CSS becomes harder to touch safely

None of these blocks' features, but over time, it erodes confidence and polish.

The workflow below exists to:

• Catch UI problems early
• Limit polish work to high-impact moments
• Keep UI changes reviewable and intentional
• Make UI quality compatible with back-end priorities

Overview: how the 22 prompts map to the workflow

The workflow is split into six phases. Each phase references the exact prompt numbers (1–22) from the first post and the GitHub repository.

You do not run all phases every time. You move between them based on what the feature needs.

Phase 1: Feature start — intent and structure first

Before worrying about spacing or colors, I validate that the UI is solving the right problem.

Prompts used in this phase

• 13 Ask if a layout matches user intent for a given scenario
• 14 Ask how to split a page into reusable components
• 22 Ask what UI elements are actually necessary

What happens here

• Prompt 13 ensures the primary action is obvious and the layout supports the user’s goal.
• Prompt 14 helps identify component boundaries early, before the page grows into a monolith.
• Prompt 22 removes unnecessary UI before the styling effort is wasted.

Why this phase matters

Polishing the wrong layout is expensive. This phase ensures structural correctness before refinement begins.

Phase 2: Build a working baseline quickly

Once intent is clear, I focus on getting a functional UI in place with minimal friction.

Prompts used in this phase

• 1 Asking to change something on the page
• 2 Asking how to change something in the page manually
• 7 Asking to create global box-sizing

What happens here

• Prompt 1 is used repeatedly for fast, safe tweaks while shipping.
• Prompt 2 is used when I want to understand which rule actually controls a behavior instead of guessing.
• Prompt 7 is applied early if the project lacks predictable sizing.

Why this phase matters

This phase keeps UI work from blocking feature development. Speed and clarity matter more than polish.

Phase 3: Consistency pass once patterns appear

After two or three components exist, inconsistency starts to appear naturally.

This is where I switch from building to stabilizing.

Prompts used in this phase

• 3 Asking to check colour consistency
• 4 Asking to check font size consistency
• 12 Asking to detect hidden inconsistencies in spacing, radii, shadows, or icon sizes
• 20 Asking whether shadows, borders, or separators are overused

What happens here

• Prompt 3 consolidates color usage and removes near-duplicates.
• Prompt 4 normalizes typography and improves readability.
• Prompt 12 catches subtle “almost consistent” values that degrade polish.
• Prompt 20 simplifies visual hierarchy by choosing one separation strategy.

Why this phase matters

Consistency is much easier to establish early than to retrofit later.

Phase 4: Reuse and maintainability before it spreads

If patterns repeat without structure, UI debt multiplies quickly.

Prompts used in this phase

• 6 Asking to check if there is a potential reuse possibility and refactor similar styles and HTML
• 15 Asking to standardize naming conventions
• 21 Asking to simplify CSS to reduce cascade complexity

What happens here

• Prompt 6 extracts shared primitives and removes duplication.
• Prompt 15 enforces consistent naming so ownership is clear.
• Prompt 21 flattens selectors and reduces specificity battles.

Why this phase matters

This phase prevents fear. When CSS is predictable, future changes feel safe instead of risky.

Phase 5: Pre-merge polish and UX refinement

Right before merging, I run a focused polish pass.

This is not a redesign. It is a quality filter.

Prompts used in this phase

• 5 Asking to check responsiveness
• 8 Asking to make the look of elements professional
• 16 Ask to improve perceived quality without adding decoration
• 18 Ask to reduce visual noise while keeping functionality
• 19 Ask for micro-adjustments that improve alignment and rhythm

What happens here

• Prompt 5 ensures the UI works across breakpoints and touch sizes.
• Prompt 16 improves quality through spacing, typography, and states only.
• Prompt 19 fixes subtle alignment and rhythm issues.
• Prompt 18 removes clutter while preserving functionality.
• Prompt 8 is used if the UI still feels unfinished.

Why this phase matters

This phase is where the UI transitions from “works” to “feels intentional”.

Phase 6: Evolution phase — tokens and theming

Not every UI reaches this phase. This is for interfaces that live longer than a sprint.

Prompts used in this phase

• 10 Ask to extract design tokens from an existing UI
• 11 Ask to rename tokens and variables for clarity and scalability
• 9 Asking to respond, use colours and replace them to change the theme

What happens here

• Prompt 10 turns repeated values into a system.
• Prompt 11 improves token clarity and long-term usability.
• Prompt 9 enables clean theme changes like dark mode or brand refreshes.

Why this phase matters

This phase ensures growth does not turn into chaos. Future changes become controlled instead of painful.

How this workflow feels in practice

Most days, I operate in:

• Phase 2 (building and small tweaks)
• Phase 5 (pre-merge polish)

Phase 3 appears when things start to feel off.

Phase 6 happens rarely, but when it does, it saves significant time later.

The key outcome is that UI quality becomes something I can reason about and schedule, not something I hope emerges by accident.