s1366560/designing-beautiful-websites

Designing Beautiful Websites

Core philosophy: Make the next action obvious. Build from user goals upward. Systemise visuals. Validate early.

Why this exists

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.

What “done” looks like

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.

Quick start workflow

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.

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:

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”.

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.