designing-beautiful-websites

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: designing-beautiful-websites
description: >-
  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, style guide, or UI kit.
allowed-tools: Read,Write,Bash(python:*)
---

# 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?
- **Pr