Detalle del Skill
designing-beautiful-websites
Comprehensive website and web-app UX/UI design workflow.
Revisar antes de usar
La revisión automática comprueba relevancia, no seguridad ni respaldo. Lee las instrucciones de la fuente antes de usar este Skill.
SKILL.md
Este extracto es una copia guardada durante la revisión. La fuente externa contiene la versión completa y actual.
--- 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? - **PrLeer la fuente completa en GitHub (abre una página externa)