do not jump to surface polish until structure and skeleton are believable.
Non‑negotiables
1) Reduce thinking
Design so users rarely wonder:
“Where am I?”
“What do I do next?”
“Is that clickable?”
“Why did they call it that?”
Prefer
obvious
over clever.
2) Use conventions aggressively
Use familiar patterns unless there is a measured reason to deviate.
Unusual UI is a tax on every user interaction.
3) Clear visual hierarchy
Every screen must answer (at a glance):
what this page is,
what the primary action is,
where the navigation is,
what is secondary.
4) Grouping must be unambiguous
If spacing is doing grouping work:
there must be
more space around groups than within groups
.
5) Feedback and forgiveness
Users should:
see results of actions quickly,
understand system status,
and recover via undo/back/cancel where possible.
Prefer preventing errors over scolding users.
6) Accessibility is part of “beautiful”
Good aesthetics survive:
keyboard-only use,
low vision,
colour‑blindness,
small screens,
slow networks.
Default outputs format
When responding, produce:
Design brief
(bullets)
IA + key flows
(bullets + simple diagrams if useful)
Component inventory
(table or list)
Design tokens
(CSS variables or JSON)
Page-level guidance
(for each page/section)
States & edge cases
Implementation notes
(HTML structure, CSS approach, ARIA, etc.)
If the user asked for a critique/audit, output:
issues (grouped by severity),
fixes,
and a “next iteration plan”.
The workflow in practice
Step 0 — Gather inputs (fast)
Ask only what’s needed; otherwise assume and state assumptions.
Minimum questions:
Primary user
who is this for?
Primary goal
what must they do?
Business goal
what does success look like?
Content
what is real copy/data?
Brand signals
existing colours/logo/type/voice?
Constraints
tech stack, deadline, accessibility level.
If inputs are missing, create a
working brief
with explicit assumptions.
Step 1 — Strategy (align intent)
Produce:
primary + secondary user goals,
business objectives,
success metrics,
constraints/risk.
Step 2 — Scope (decide what exists)
Define:
pages/screens,
features,
content requirements,
and what is out of scope.
Pick 1–3
key paths
(the journeys that matter most). Optimise these first.
Step 3 — Structure (make it findable)
Create:
sitemap / nav model (global + local nav),
page purpose statements,
user flows for key paths.
Rule: navigation labels should be self‑evident; avoid internal jargon.
Step 4 — Skeleton (arrange the UI)
Create:
wireframes per page,
component inventory,
layout constraints (container widths, grids, spacing rhythm),
and priority order per breakpoint.
Rule: start with the
feature/content
, not the “app shell”.
Step 5 — Surface (make it beautiful)
Build a consistent system:
spacing + sizing scale,
typography scale,
colour palette + shades,
radius + border rules,
elevation/shadow scale,
icon + illustration style,
motion rules (optional).
Apply to page comps.
Step 6 — Validate (fast loops)
Run these checks:
Glance test (5–10 seconds):
can someone tell what this is and what to do?
Key‑path walkthrough:
can a first‑time user complete the main task?
Consistency pass:
are tokens respected? is hierarchy consistent?
Accessibility pass:
contrast, focus states, semantics, error messaging.
Step 7 — Hand-off (make it buildable)
Provide:
tokens,
component specs (states + spacing + behaviour),
responsive rules,
and edge cases.
Default starter system
Use this system unless the project already has one.
Spacing & sizing scale (px)
Use a
non-linear
scale so choices are easy:
0, 4, 8, 12, 16, 24, 32, 48, 64, 96, 128
Rules:
pick from the scale; avoid “one-off” numbers.
for grouping:
inside-group spacing < between-group spacing
.
Typography scale (px)
Keep it tight: 6–8 sizes is enough.
Suggested:
12
caption
14
small/body-secondary
16
body
20
subheading
24
h3
30
h2
40
h1/hero
Rules:
default body line-height ~
1.5–1.7
.
limit line length for reading (~45–80 characters).
use weight/colour/spacing before adding new sizes.
Colour system
define neutrals (backgrounds + text), one primary, and semantic accents.
define
shades up front
(e.g., 100–900), don’t generate ad-hoc lightens/darkens.
“Grey” can be warm or cool; keep a consistent temperature.
Contrast rules:
normal text target:
≥ 4.5:1
large text target:
≥ 3:1
Elevation / shadow system
Use 3–5 shadow levels that map to meaning:
1: buttons/cards (subtle)
2: popovers/menus
3: sticky headers
4: modals
5: high priority overlays
Borders
Prefer:
spacing,
subtle shadows,
or small background changes
over heavy borders.
Empty states
Empty states are a first impression.
They must:
explain what’s empty,
why it matters,
and what to do next.
Progressive disclosure
Use these reference files when deeper detail is needed:
Workflow & deliverables
→
references/WORKFLOW.md
Page patterns
→
references/PAGE-PATTERNS.md
Audit / critique
→
references/DESIGN-AUDIT.md
Usability & navigation
→
references/USABILITY.md
Visual design systems
→
references/VISUAL-DESIGN.md
Interaction & forms
→
references/INTERACTION-DESIGN.md
Information architecture
→
references/INFORMATION-ARCHITECTURE.md
Content & microcopy
→
references/CONTENT-COPY.md
Responsive rules
→
references/RESPONSIVE.md
Accessibility
→
references/ACCESSIBILITY.md
Checklists & templates
→
references/CHECKLISTS.md
Quick search
If running locally:
grep
-i
"empty state|hierarchy|spacing"
-n
references/*.md
THE EXACT PROMPT — UX/UI plan
You are designing a website UI/UX.
1) Write a crisp design brief (users, goals, constraints, success metrics).
2) Define information architecture + navigation model.
3) Identify 1–3 key user paths; write step-by-step flows.
4) Produce a component inventory for the key pages.
5) Propose a design token system (spacing, type, colour, radius, shadow) with rules.
6) Describe page layouts (mobile-first) and key interactions.
7) List empty/loading/error states and edge cases.
8) Run a usability + accessibility + consistency pass; revise.
Output must be specific and implementable.
Avoid vague advice.
THE EXACT PROMPT — Visual polish pass
Review this UI for visual quality.
- Fix hierarchy (what is primary vs secondary vs tertiary?)
- Fix spacing (grouping clarity; rhythm; alignment)
- Fix typography (scale, weights, line height, line length)
- Fix colour (contrast, palette consistency, accent usage)
- Fix depth (shadows/borders; focus on meaning)
- Improve empty states and microcopy
Return:
1) a list of concrete changes
2) updated tokens (if needed)
3) before/after descriptions of the most important screens.
THE EXACT PROMPT — Usability “glance test”
Pretend you have 10 seconds to look at this page.
Answer:
- What is this page?
- Who is it for?
- What are the top 3 things I can do here?
- What is the primary action?
- Where is the navigation?
Then list everything that created a question mark, and propose fixes.
THE EXACT PROMPT — Component spec (single component)
Write a build-ready spec for this component.
Include:
- Purpose + when to use
- Anatomy (parts)
- Variants
- States: default/hover/focus/active/disabled/loading/error/success/empty
- Behaviour rules (keyboard + mouse + touch)
- Spacing + typography + colour tokens used
- Accessibility notes (ARIA if needed)
- Edge cases (long text, missing data, localisation)
Keep it concise but unambiguous.
THE EXACT PROMPT — Accessibility pass
Review this design for accessibility.
Check:
- text contrast (normal and large text)
- keyboard navigation and focus visibility
- semantic element choices (button vs link vs div)
- form labelling and error announcement
- motion and reduced-motion behaviour
Return:
1) issues grouped by severity
2) concrete fixes (design + implementation)
3) any token changes needed (colours, focus styles)
THE EXACT PROMPT — Responsive pass
Define responsive behaviour for this page/component.
For each breakpoint (small phone, large phone, tablet, desktop):
- layout (stack/columns)
- what becomes primary vs secondary
- how text wraps/truncates
- how tables, toolbars, and secondary actions adapt
Then list edge cases (long text, empty, error) and how they render.