designing-beautiful-websites

Websites fail when they look “nice” but:

• don’t match user goals,
• hide key actions,
• require too much thinking,
• or are visually inconsistent.

This skill turns vague requests like “make it look better” into a repeatable workflow that produces:

• clear structure,
• usable interactions,
• and a cohesive visual system.

Deliverables should be usable by builders (engineers, no-code builders, future agents):

• Design brief: users, goals, constraints, success metrics.
• IA + flows: sitemap (or nav model), and 1–3 key user journeys.
• Layout + wireframes: responsive page structure, component inventory.
• Visual system: tokens (type, spacing, colour, radius, shadow), and usage rules.
• Component specs: states, behaviour, empty/loading/error.
• QA notes: accessibility, responsiveness, edge cases.

If time is limited, prioritise: clarity + hierarchy + consistency + accessibility.

Copy this checklist into the working notes and tick it off:

• [ ] 0. Inputs: goal, audience, content, constraints, brand signals.
• [ ] 1. Strategy: user goals + business goals + success metrics.
• [ ] 2. Scope: pages/features/content; prioritise “key paths”.
• [ ] 3. Structure: IA + navigation model + flows.
• [ ] 4. Skeleton: wireframes + component inventory + responsive layout.
• [ ] 5. Surface: visual system + page comps + states.
• [ ] 6. Validate: usability pass + accessibility pass + consistency pass.
• [ ] 7. Hand-off: tokens + component specs + implementation notes.

Default rule: do not jump to surface polish until structure and skeleton are believable.

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.

When responding, produce:

1. Design brief (bullets)
2. IA + key flows (bullets + simple diagrams if useful)
3. Component inventory (table or list)
4. Design tokens (CSS variables or JSON)
5. Page-level guidance (for each page/section)
6. States & edge cases
7. 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”.

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.

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.

Use these reference files when deeper detail is needed:

• Workflow & deliverables → [references/WORKFLOW.md](references/WORKFLOW.md)
• Page patterns → [references/PAGE-PATTERNS.md](references/PAGE-PATTERNS.md)
• Audit / critique → [references/DESIGN-AUDIT.md](references/DESIGN-AUDIT.md)
• Usability & navigation → [references/USABILITY.md](references/USABILITY.md)
• Visual design systems → [references/VISUAL-DESIGN.md](references/VISUAL-DESIGN.md)
• Interaction & forms → [references/INTERACTION-DESIGN.md](references/INTERACTION-DESIGN.md)
• Information architecture → [references/INFORMATION-ARCHITECTURE.md](references/INFORMATION-ARCHITECTURE.md)
• Content & microcopy → [references/CONTENT-COPY.md](references/CONTENT-COPY.md)
• Responsive rules → [references/RESPONSIVE.md](references/RESPONSIVE.md)
• Accessibility → [references/ACCESSIBILITY.md](references/ACCESSIBILITY.md)
• Checklists & templates → [references/CHECKLISTS.md](references/CHECKLISTS.md)

If running locally:

```bash

grep -i "empty state\|hierarchy\|spacing" -n references/*.md

```

```

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.

```

```

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.

```

```

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.

```

```

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.

```

```

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)

```

```

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.

```