designing-beautiful-websites
Designs UX/UI for websites and web apps: UX strategy, information architecture, user flows, wireframes, UI systems, component specs, and polished visual design. Use when the user asks to design, redesign, modernise, critique, or improve a website, landing page, web app interface, design system, styl
By tristanmanchester · 2,583 installs
npx skills add tristanmanchester/agent-skills --skill designing-beautiful-websites
Source repository · Upstream listing
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](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)
Quick search
If running locally:
THE EXACT PROMPT — UX/UI plan
THE EXACT PROMPT — Visual polish pass
THE EXACT PROMPT — Usability “glance test”
THE EXACT PROMPT — Component spec (single component)
THE EXACT PROMPT — Accessibility pass
THE EXACT PROMPT — Responsive pass