mirror of
https://github.com/Shubhamsaboo/awesome-llm-apps.git
synced 2026-04-30 15:20:47 -05:00
refactor: Consolidate granular UX design rules into broader categories and update AGENTS.md to reflect the new structure.
This commit is contained in:
Dileep Pandey
@@ -6,255 +6,120 @@ This document compiles all rules, guidelines, and best practices for the UX Desi
|
||||
|
||||
## Priority 1: User Research (CRITICAL)
|
||||
|
||||
### Rule: Conducting User Interviews
|
||||
> Full details: [rules/research.md](rules/research.md)
|
||||
|
||||
**Why:** Design decisions grounded in real user data lead to products that people actually want to use. Assumptions lead to costly redesigns.
|
||||
|
||||
**Guidelines:**
|
||||
### Conducting User Interviews
|
||||
- Always start with research before opening a design tool
|
||||
- Use open-ended questions that don't lead the participant
|
||||
- Use open-ended questions: *"Walk me through the last time you [did the task]"*
|
||||
- Follow the "5 Whys" technique to uncover root motivations
|
||||
- Record sessions (with consent) for team review
|
||||
- Synthesize findings into themes, not individual anecdotes
|
||||
- Synthesize findings into themes using affinity mapping, not individual anecdotes
|
||||
|
||||
**Good Interview Questions:**
|
||||
- "Walk me through the last time you [did the task]."
|
||||
- "What was the hardest part of that experience?"
|
||||
- "What did you try before finding this solution?"
|
||||
|
||||
**Bad Interview Questions:**
|
||||
- "Don't you think this feature would be useful?" (leading)
|
||||
- "Would you use a product that does X?" (hypothetical, unreliable)
|
||||
- "Do you like this design?" (opinion, not behavior-based)
|
||||
|
||||
**Synthesis Process:**
|
||||
1. Review all session notes and recordings
|
||||
2. Extract key observations as individual data points
|
||||
3. Cluster observations into themes using affinity mapping
|
||||
4. Identify patterns that appear across multiple participants
|
||||
5. Prioritize insights by frequency and impact
|
||||
6. Create actionable recommendations tied to specific findings
|
||||
|
||||
### Rule: Creating Effective Personas
|
||||
|
||||
**Why:** Personas keep the team aligned on who they're designing for and prevent "designing for everyone" (which means designing for no one).
|
||||
|
||||
**Guidelines:**
|
||||
- Base personas on real research data, never assumptions
|
||||
### Creating Effective Personas
|
||||
- Base on real research data, never assumptions
|
||||
- Limit to 3-5 primary personas per product
|
||||
- Include goals, pain points, behaviors, and context
|
||||
- Make personas specific enough to guide decisions
|
||||
- Update personas as you learn more about users
|
||||
- Update as you learn more about users
|
||||
|
||||
**Anti-Patterns:**
|
||||
- Demographic-only personas (age, gender, income without behavioral data)
|
||||
- Aspirational personas (who you wish your users were)
|
||||
- Too many personas (dilutes focus)
|
||||
- Stale personas (never updated after initial creation)
|
||||
**Anti-Patterns:** Demographic-only personas · Aspirational personas · Too many personas · Stale personas
|
||||
|
||||
---
|
||||
|
||||
## Priority 2: Accessibility (CRITICAL)
|
||||
|
||||
### Rule: WCAG Compliance
|
||||
> Full details: [rules/accessibility.md](rules/accessibility.md)
|
||||
|
||||
**Why:** Accessible design isn't optional — it's a legal requirement in many jurisdictions and a moral imperative. It also improves usability for everyone.
|
||||
### WCAG AA Requirements
|
||||
- **Perceivable:** Color contrast 4.5:1 for text, 3:1 for large text; alt text for images; captions for video
|
||||
- **Operable:** Full keyboard access; 44×44px touch targets; visible focus states; no seizure triggers
|
||||
- **Understandable:** Visible form labels; descriptive error messages; consistent navigation
|
||||
- **Robust:** Semantic HTML; ARIA only when needed; screen reader compatible
|
||||
|
||||
**WCAG AA Requirements (Minimum Standard):**
|
||||
- **Perceivable:** Content must be presentable in ways all users can perceive
|
||||
- Color contrast: 4.5:1 for normal text, 3:1 for large text (18px+ bold or 24px+)
|
||||
- Text alternatives for non-text content
|
||||
- Captions for audio/video content
|
||||
- Content adaptable to different presentations without losing meaning
|
||||
|
||||
- **Operable:** Interface must be navigable by all users
|
||||
- All functionality available via keyboard
|
||||
- Sufficient time to read and interact with content
|
||||
- No content that causes seizures (no flashing more than 3 times per second)
|
||||
- Clear navigation and wayfinding
|
||||
- Minimum touch target size of 44×44 CSS pixels
|
||||
|
||||
- **Understandable:** Content and interface must be comprehensible
|
||||
- Readable text at appropriate levels
|
||||
- Predictable page behavior and navigation
|
||||
- Input assistance with clear labels and error prevention
|
||||
|
||||
- **Robust:** Content must work with current and future technologies
|
||||
- Valid, semantic HTML
|
||||
- Compatible with assistive technologies
|
||||
- Proper ARIA roles and attributes when semantic HTML is insufficient
|
||||
|
||||
### Rule: Inclusive Design Patterns
|
||||
|
||||
**Why:** Designing for edge cases often improves the experience for all users.
|
||||
|
||||
**Guidelines:**
|
||||
- Design for one-handed use on mobile
|
||||
- Support both light and dark color modes
|
||||
- Provide text alternatives for every visual-only communication
|
||||
- Ensure forms work with autofill and password managers
|
||||
- Support zoom up to 200% without content loss
|
||||
- Never rely solely on color to convey meaning (use icons, text, or patterns as well)
|
||||
- Respect user preferences for reduced motion
|
||||
- Design for variable content lengths (internationalization)
|
||||
### Inclusive Design
|
||||
- Design for one-handed mobile use
|
||||
- Support light/dark modes and 200% zoom
|
||||
- Use plain language (6th-8th grade reading level)
|
||||
- Never use color as the only indicator of meaning
|
||||
- Design for RTL languages and text expansion
|
||||
|
||||
---
|
||||
|
||||
## Priority 3: Usability & Information Architecture (HIGH)
|
||||
## Priority 3: Information Architecture (HIGH)
|
||||
|
||||
### Rule: Navigation Structure Design
|
||||
> Full details: [rules/information-architecture.md](rules/information-architecture.md)
|
||||
|
||||
**Why:** If users can't find it, it doesn't exist. Navigation is the backbone of usability.
|
||||
### Navigation
|
||||
- Limit primary navigation to 5-7 items
|
||||
- Group by user mental models, not org charts
|
||||
- Use breadcrumbs for hierarchies deeper than 2 levels
|
||||
- Mobile: bottom nav for 3-5 primary actions; hamburger for secondary only
|
||||
|
||||
**Guidelines:**
|
||||
- Limit primary navigation to 5-7 items maximum
|
||||
- Use card sorting to validate category names with real users
|
||||
- Follow the "three-click rule" as a heuristic (most tasks achievable in 3 actions)
|
||||
- Provide breadcrumbs for deep hierarchies
|
||||
- Include a search function for content-heavy products
|
||||
- Make the current location always clear
|
||||
|
||||
**Navigation Patterns:**
|
||||
- **Top bar:** Best for 3-7 primary sections on desktop
|
||||
- **Side nav:** Best for deep hierarchies or tools with many sections
|
||||
- **Bottom bar:** Best for mobile apps with 3-5 primary actions
|
||||
- **Hamburger menu:** Use sparingly; hides navigation and reduces discoverability
|
||||
- **Tabs:** Best for switching between related views at the same level
|
||||
|
||||
### Rule: Content Organization
|
||||
|
||||
**Why:** Well-organized information reduces cognitive load and helps users accomplish their goals faster.
|
||||
|
||||
**Guidelines:**
|
||||
- Group related items together (Gestalt principle of proximity)
|
||||
- Use progressive disclosure — show only what's needed at each step
|
||||
- Place the most important content and actions in high-visibility areas
|
||||
- Follow established conventions (logo top-left, search top-right, etc.)
|
||||
- Use consistent labeling and terminology throughout
|
||||
### Content Organization
|
||||
- **Progressive disclosure:** Show only what's needed; reveal details on demand
|
||||
- **Scannability:** Clear headings, short paragraphs, visual breaks
|
||||
- Place the most important content in high-visibility areas
|
||||
- Validate labels with card sorting and tree testing
|
||||
|
||||
---
|
||||
|
||||
## Priority 4: Interaction Design (HIGH)
|
||||
|
||||
### Rule: User Flow Best Practices
|
||||
> Full details: [rules/interaction-design.md](rules/interaction-design.md)
|
||||
|
||||
**Why:** A well-designed flow minimizes friction and guides users to successful task completion.
|
||||
### User Flows
|
||||
- Map the happy path first, then errors and edge cases
|
||||
- Minimize steps; provide progress indicators for 3+ step flows
|
||||
- Allow going back without losing data; auto-save when possible
|
||||
- Confirm destructive actions with specific consequences
|
||||
|
||||
**Guidelines:**
|
||||
- Map the happy path first, then design for errors and edge cases
|
||||
- Minimize the number of steps to complete a task
|
||||
- Provide clear progress indicators for multi-step flows
|
||||
- Allow users to go back without losing data
|
||||
- Auto-save form data when possible
|
||||
- Confirm destructive actions with clear consequences
|
||||
- Provide meaningful feedback for every user action
|
||||
### Microcopy
|
||||
- Use specific verbs for buttons: "Save Draft", "Create Account" (not "Submit", "OK")
|
||||
- Error messages: explain what happened AND how to fix it
|
||||
- Confirmation dialogs: asymmetric labels ("Delete Project" / "Keep Project", not "Yes" / "No")
|
||||
- Empty states: explain why it's empty and what to do
|
||||
|
||||
**Common Flow Problems:**
|
||||
- Dead ends (no next action available)
|
||||
- Loops (user returns to the same screen without progress)
|
||||
- Forced registration before value is demonstrated
|
||||
- Unclear calls to action (what should I do next?)
|
||||
- Missing error recovery paths
|
||||
|
||||
### Rule: Microcopy Guidelines
|
||||
|
||||
**Why:** Interface text is often the difference between a user completing a task and abandoning it.
|
||||
|
||||
**Guidelines:**
|
||||
- Use verbs for buttons ("Create Account" not "Submit")
|
||||
- Keep labels short but descriptive
|
||||
- Write error messages that explain the problem AND the solution
|
||||
- Use the user's language, not internal jargon
|
||||
- Be consistent — one term for one concept everywhere
|
||||
- Front-load important information in sentences
|
||||
- Write for scanning, not reading
|
||||
**Common flow problems:** Dead ends · Loops · Forced registration before value · Missing error recovery
|
||||
|
||||
---
|
||||
|
||||
## Priority 5: Visual Design (MEDIUM)
|
||||
|
||||
### Rule: Visual Hierarchy Principles
|
||||
> Full details: [rules/visual-design.md](rules/visual-design.md)
|
||||
|
||||
**Why:** Visual hierarchy directs attention and communicates importance without requiring the user to think about it.
|
||||
### Visual Hierarchy
|
||||
1. **Size** — larger elements attract attention first
|
||||
2. **Contrast** — high contrast for key actions
|
||||
3. **Color** — saturated for emphasis, muted for secondary
|
||||
4. **Position** — top-left scanned first (LTR); F-pattern / Z-pattern
|
||||
5. **Whitespace** — isolation creates emphasis
|
||||
|
||||
**Guidelines:**
|
||||
- Use size, color, contrast, and spacing to establish hierarchy
|
||||
- Limit to 2-3 font sizes per screen for clarity
|
||||
- Use whitespace generously to reduce visual clutter
|
||||
- Align elements to a consistent grid
|
||||
- Make primary actions visually dominant (larger, higher contrast)
|
||||
- De-emphasize secondary actions to reduce decision fatigue
|
||||
|
||||
**Hierarchy Techniques:**
|
||||
1. **Size:** Larger elements attract attention first
|
||||
2. **Color/Contrast:** High contrast draws the eye
|
||||
3. **Position:** Top-left (in LTR languages) gets scanned first
|
||||
4. **Whitespace:** Isolation creates emphasis
|
||||
5. **Typography:** Weight and style differentiate content levels
|
||||
|
||||
### Rule: Design System Foundations
|
||||
|
||||
**Why:** A design system ensures consistency, speeds up design work, and reduces developer ambiguity.
|
||||
|
||||
**Core Components:**
|
||||
- **Color palette:** Primary, secondary, neutral, semantic (success, error, warning, info)
|
||||
- **Typography scale:** A modular scale with defined sizes, weights, and line heights
|
||||
- **Spacing system:** Consistent spacing units (4px or 8px base grid)
|
||||
- **Component library:** Buttons, inputs, cards, modals, navigation, and other reusable patterns
|
||||
- **Iconography:** Consistent style, size, and stroke weight
|
||||
- **Motion guidelines:** Easing curves, durations, and when to animate
|
||||
|
||||
**Guidelines:**
|
||||
- Document every component with usage guidelines and examples
|
||||
- Include do/don't examples for each component
|
||||
- Specify states for all interactive components (default, hover, active, focus, disabled, error)
|
||||
- Define responsive behavior for each component
|
||||
- Version the design system and communicate changes
|
||||
### Design System Essentials
|
||||
- **Color:** Primary, secondary, neutral, semantic (success/error/warning/info)
|
||||
- **Typography:** 3-4 sizes per screen, consistent scale ratio
|
||||
- **Spacing:** 8px base grid applied consistently
|
||||
- **Components:** Document purpose, states, variants, responsive behavior, accessibility
|
||||
|
||||
---
|
||||
|
||||
## Cross-Functional Collaboration
|
||||
|
||||
### Working with Product Managers
|
||||
- Share research findings early and often
|
||||
- Align on user needs vs. business goals
|
||||
- Co-create prioritization frameworks
|
||||
- Share research findings early; align on user needs vs. business goals
|
||||
- Use data to support design decisions in priority discussions
|
||||
|
||||
### Working with Developers
|
||||
- Provide detailed specs with all states and edge cases documented
|
||||
- Use developer-friendly tools and naming conventions
|
||||
- Be available during implementation for questions
|
||||
- Review implemented designs against specs before release
|
||||
- Discuss technical constraints early in the design process
|
||||
|
||||
### Working with UX Researchers
|
||||
- Collaborate on research plans and interview scripts
|
||||
- Attend research sessions to build empathy
|
||||
- Co-analyze findings and identify patterns together
|
||||
- Use research findings to validate or invalidate design hypotheses
|
||||
- Provide detailed specs with all states and edge cases
|
||||
- Be available during implementation; review against specs before release
|
||||
|
||||
### Working with Stakeholders
|
||||
- Present design rationale, not just deliverables
|
||||
- Frame feedback requests around specific questions
|
||||
- Use prototypes to make abstract ideas concrete
|
||||
- Connect design decisions to business metrics
|
||||
|
||||
---
|
||||
|
||||
## Tools & Workflow
|
||||
|
||||
### Recommended Tools (2025-2026)
|
||||
- **Design:** Figma (primary), Sketch (macOS alternative)
|
||||
- **Prototyping:** Figma prototyping, ProtoPie (advanced interactions)
|
||||
- **Design:** Figma (primary), Sketch (macOS)
|
||||
- **Prototyping:** Figma prototyping, ProtoPie
|
||||
- **Research:** Maze, UserTesting, Lookback
|
||||
- **Handoff:** Figma Dev Mode, Zeplin
|
||||
- **Documentation:** Notion, Confluence
|
||||
- **Analytics:** Hotjar, FullStory, Google Analytics
|
||||
|
||||
### Design File Organization
|
||||
- Use consistent naming conventions for pages and frames
|
||||
- Organize by flow or feature, not by fidelity level
|
||||
- Maintain a "Components" page as the source of truth
|
||||
- Archive old explorations instead of deleting
|
||||
- Include version notes on major iterations
|
||||
|
||||
@@ -9,7 +9,7 @@ description: |
|
||||
license: MIT
|
||||
metadata:
|
||||
author: awesome-llm-apps
|
||||
version: "1.0.0"
|
||||
version: "1.1.0"
|
||||
---
|
||||
|
||||
# UX Designer
|
||||
@@ -26,9 +26,7 @@ Use this skill when:
|
||||
- Writing UX microcopy and interface text
|
||||
- Reviewing designs for usability and accessibility
|
||||
- Structuring information architecture
|
||||
- Preparing usability test plans
|
||||
- Creating design system components
|
||||
- Collaborating with developers on design handoff
|
||||
|
||||
## How to Use This Skill
|
||||
|
||||
@@ -42,66 +40,42 @@ This skill contains **detailed rules** in the `rules/` directory, organized by c
|
||||
|
||||
### Available Rules
|
||||
|
||||
**User Research (CRITICAL)**
|
||||
- [Conducting User Interviews](rules/research-user-interviews.md)
|
||||
- [Creating Effective Personas](rules/research-personas.md)
|
||||
|
||||
**Accessibility (CRITICAL)**
|
||||
- [WCAG Compliance Checklist](rules/accessibility-wcag.md)
|
||||
- [Inclusive Design Patterns](rules/accessibility-inclusive-design.md)
|
||||
|
||||
**Information Architecture (HIGH)**
|
||||
- [Navigation Structure Design](rules/ia-navigation.md)
|
||||
- [Content Organization](rules/ia-content-organization.md)
|
||||
|
||||
**Interaction Design (HIGH)**
|
||||
- [User Flow Best Practices](rules/interaction-user-flows.md)
|
||||
- [Microcopy Guidelines](rules/interaction-microcopy.md)
|
||||
|
||||
**Visual Design (MEDIUM)**
|
||||
- [Visual Hierarchy Principles](rules/visual-hierarchy.md)
|
||||
- [Design System Foundations](rules/visual-design-system.md)
|
||||
| Priority | Rule | Description |
|
||||
|----------|------|-------------|
|
||||
| 🔴 CRITICAL | [User Research](rules/research.md) | Interviews, personas, and synthesis |
|
||||
| 🔴 CRITICAL | [Accessibility](rules/accessibility.md) | WCAG compliance and inclusive design |
|
||||
| 🟡 HIGH | [Information Architecture](rules/information-architecture.md) | Navigation and content organization |
|
||||
| 🟡 HIGH | [Interaction Design](rules/interaction-design.md) | User flows and microcopy |
|
||||
| 🟢 MEDIUM | [Visual Design](rules/visual-design.md) | Hierarchy, color, typography, and design systems |
|
||||
|
||||
## UX Design Process
|
||||
|
||||
### 1. **Discover & Research** (CRITICAL)
|
||||
Understand users before designing anything:
|
||||
- Conduct user interviews and surveys
|
||||
- Analyze existing analytics and heatmaps
|
||||
- Perform competitive analysis
|
||||
- Create empathy maps to capture user attitudes and behaviors
|
||||
- Identify pain points and unmet needs
|
||||
- Create empathy maps and identify pain points
|
||||
|
||||
### 2. **Define** (CRITICAL)
|
||||
Synthesize research into actionable insights:
|
||||
- Build user personas grounded in real data
|
||||
- Map user journeys end-to-end
|
||||
- Define problem statements using "How Might We" framing
|
||||
- Prioritize features by user impact and feasibility
|
||||
- Establish success metrics and KPIs
|
||||
|
||||
### 3. **Ideate & Design** (HIGH)
|
||||
Explore solutions through iterative design:
|
||||
- Sketch multiple concepts before committing
|
||||
- Create low-fidelity wireframes for structure
|
||||
- Progress to mid-fidelity with annotations
|
||||
- Build high-fidelity mockups with visual design
|
||||
- Create low → mid → high-fidelity wireframes
|
||||
- Design responsive layouts for all breakpoints
|
||||
|
||||
### 4. **Prototype & Test** (HIGH)
|
||||
Validate designs with real users:
|
||||
- Build interactive prototypes for key flows
|
||||
- Conduct moderated and unmoderated usability tests
|
||||
- Use think-aloud protocol during testing
|
||||
- Measure task success rate, time on task, and error rate
|
||||
- Iterate based on findings
|
||||
|
||||
### 5. **Handoff & Iterate** (MEDIUM)
|
||||
Ensure accurate implementation:
|
||||
- Prepare detailed design specifications
|
||||
- Prepare detailed design specifications with all states
|
||||
- Document interaction states and edge cases
|
||||
- Annotate responsive behavior
|
||||
- Collaborate with developers during build
|
||||
- Review implemented designs against specs
|
||||
|
||||
## Deliverable Templates
|
||||
@@ -110,32 +84,21 @@ Ensure accurate implementation:
|
||||
|
||||
```markdown
|
||||
## [Persona Name]
|
||||
**Photo:** [Representative image]
|
||||
**Age:** [Age] | **Occupation:** [Job Title] | **Location:** [City]
|
||||
|
||||
### Background
|
||||
[2-3 sentences about who they are and their context]
|
||||
|
||||
### Goals
|
||||
- [Primary goal related to the product]
|
||||
- [Secondary goal]
|
||||
- [Tertiary goal]
|
||||
|
||||
### Pain Points
|
||||
- [Frustration with current solutions]
|
||||
- [Unmet need]
|
||||
- [Barrier to adoption]
|
||||
|
||||
### Behaviors
|
||||
- [How they currently solve the problem]
|
||||
- [Technology comfort level]
|
||||
- [Relevant habits or preferences]
|
||||
|
||||
### Quote
|
||||
> "[A representative quote that captures their mindset]"
|
||||
|
||||
### Scenario
|
||||
[Brief narrative of how they would use the product in context]
|
||||
```
|
||||
|
||||
### User Flow Template
|
||||
@@ -148,123 +111,16 @@ Ensure accurate implementation:
|
||||
|
||||
### Steps
|
||||
1. **[Screen/State]** → User action → [Next screen/state]
|
||||
2. **[Screen/State]** → User action → [Next screen/state]
|
||||
3. **[Screen/State]** → User action → [Success state]
|
||||
2. **[Screen/State]** → User action → [Success state]
|
||||
|
||||
### Error States
|
||||
- **[Error condition]** → [Recovery path]
|
||||
- **[Edge case]** → [Fallback behavior]
|
||||
|
||||
### Decision Points
|
||||
- **[Decision]** → Path A: [outcome] | Path B: [outcome]
|
||||
```
|
||||
|
||||
### Usability Test Plan Template
|
||||
|
||||
```markdown
|
||||
## Test Plan: [Feature/Product Name]
|
||||
**Date:** [Date] | **Facilitator:** [Name]
|
||||
|
||||
### Objectives
|
||||
- [What you want to learn]
|
||||
- [Specific hypothesis to validate]
|
||||
|
||||
### Participants
|
||||
- **Count:** [5-8 recommended]
|
||||
- **Criteria:** [Recruitment screener details]
|
||||
- **Demographics:** [Relevant characteristics]
|
||||
|
||||
### Methodology
|
||||
- **Type:** [Moderated/Unmoderated, Remote/In-person]
|
||||
- **Duration:** [30-60 minutes per session]
|
||||
- **Tools:** [Platform and recording tools]
|
||||
|
||||
### Tasks
|
||||
1. **[Task name]** - [Success criteria] - [Time limit]
|
||||
- Scenario: "[Context given to participant]"
|
||||
2. **[Task name]** - [Success criteria] - [Time limit]
|
||||
- Scenario: "[Context given to participant]"
|
||||
|
||||
### Metrics
|
||||
- Task success rate (target: >80%)
|
||||
- Time on task
|
||||
- Error rate
|
||||
- System Usability Scale (SUS) score
|
||||
- Net Promoter Score (NPS)
|
||||
|
||||
### Post-Test Questions
|
||||
1. [Overall impression question]
|
||||
2. [Specific feature feedback question]
|
||||
3. [Comparison to alternatives question]
|
||||
```
|
||||
|
||||
### Wireframe Annotation Template
|
||||
|
||||
```markdown
|
||||
## Screen: [Screen Name]
|
||||
**Flow:** [Parent flow] | **State:** [Default/Error/Loading/Empty]
|
||||
|
||||
### Layout Notes
|
||||
- [Header behavior: fixed/scrolling]
|
||||
- [Grid structure: columns, gutters, margins]
|
||||
- [Responsive breakpoints and adaptations]
|
||||
|
||||
### Component Annotations
|
||||
1. **[Component name]** (coordinates or region)
|
||||
- Purpose: [Why this exists]
|
||||
- Behavior: [What happens on interaction]
|
||||
- States: [Default, Hover, Active, Disabled, Error]
|
||||
- Content rules: [Character limits, truncation, fallback]
|
||||
|
||||
2. **[Component name]**
|
||||
- Purpose: [Why this exists]
|
||||
- Behavior: [What happens on interaction]
|
||||
- States: [Default, Hover, Active, Disabled, Error]
|
||||
|
||||
### Edge Cases
|
||||
- Empty state: [What shows when no data]
|
||||
- Error state: [What shows on failure]
|
||||
- Loading state: [Skeleton/spinner/progressive]
|
||||
- Overflow: [How excess content is handled]
|
||||
```
|
||||
|
||||
## Accessibility Checklist
|
||||
|
||||
When reviewing any design, verify:
|
||||
|
||||
- [ ] **Color contrast** meets WCAG AA (4.5:1 for text, 3:1 for large text)
|
||||
- [ ] **Interactive elements** have minimum 44×44px touch targets
|
||||
- [ ] **Focus states** are visible for keyboard navigation
|
||||
- [ ] **Alt text** is defined for all meaningful images
|
||||
- [ ] **Heading hierarchy** follows logical order (h1 → h2 → h3)
|
||||
- [ ] **Form labels** are explicitly associated with inputs
|
||||
- [ ] **Error messages** are descriptive and suggest corrections
|
||||
- [ ] **Color is not the only indicator** of state or meaning
|
||||
- [ ] **Motion and animation** respect `prefers-reduced-motion`
|
||||
- [ ] **Screen reader** flow matches visual reading order
|
||||
|
||||
## Microcopy Guidelines
|
||||
|
||||
### Principles
|
||||
- **Clarity over cleverness** — users scan, they don't read
|
||||
- **Action-oriented** — lead with verbs in buttons and CTAs
|
||||
- **Consistent terminology** — one word for one concept throughout
|
||||
- **Human tone** — conversational but not informal
|
||||
- **Helpful errors** — explain what happened and how to fix it
|
||||
|
||||
### Examples
|
||||
|
||||
| Context | Weak | Strong |
|
||||
|---------|------|--------|
|
||||
| Empty state | No results | No results for "blue shoes." Try a broader search term. |
|
||||
| Error | Error occurred | We couldn't save your changes. Check your connection and try again. |
|
||||
| Button | Submit | Create Account |
|
||||
| Confirmation | Are you sure? | Delete this project? This can't be undone. |
|
||||
| Loading | Loading... | Finding the best options for you... |
|
||||
|
||||
## Design Review Output Format
|
||||
|
||||
When reviewing designs, structure feedback as:
|
||||
### Design Review Output Format
|
||||
|
||||
```markdown
|
||||
## Design Review: [Screen/Feature Name]
|
||||
@@ -278,59 +134,80 @@ When reviewing designs, structure feedback as:
|
||||
### Accessibility Concerns 🟠
|
||||
1. **[Issue title]**
|
||||
- **WCAG Criterion:** [Specific guideline reference]
|
||||
- **Current state:** [What's wrong]
|
||||
- **Required fix:** [How to resolve]
|
||||
|
||||
### Improvement Opportunities 🟡
|
||||
1. **[Suggestion title]**
|
||||
- **Current:** [What exists now]
|
||||
- **Proposed:** [What would be better and why]
|
||||
1. **[Suggestion]** — Current: [what exists] → Proposed: [what's better]
|
||||
|
||||
### Strengths ✅
|
||||
- [What's working well and should be preserved]
|
||||
- [Design decisions that align with best practices]
|
||||
```
|
||||
|
||||
## Example
|
||||
---
|
||||
|
||||
**User Request:** "Help me design a user flow for a password reset feature"
|
||||
## Worked Example
|
||||
|
||||
**Response:**
|
||||
Below is a concrete example showing how an agent uses this skill end-to-end.
|
||||
|
||||
```markdown
|
||||
## Flow: Password Reset
|
||||
**Goal:** User regains access to their account after forgetting their password
|
||||
**Entry Point:** Login screen → "Forgot password?" link
|
||||
**Success Criteria:** User sets a new password and is logged in
|
||||
### User Prompt
|
||||
|
||||
### Steps
|
||||
1. **Login Screen** → User clicks "Forgot password?" → Email entry screen
|
||||
2. **Email Entry** → User enters email, clicks "Send reset link" → Confirmation screen
|
||||
3. **Confirmation Screen** → Displays "Check your email" message with resend option
|
||||
4. **Email** → User clicks reset link → New password screen
|
||||
5. **New Password Screen** → User enters and confirms new password → Success screen
|
||||
6. **Success Screen** → Displays confirmation, auto-redirects to dashboard after 3 seconds
|
||||
> "I'm building a SaaS onboarding flow. New users sign up, verify their email, set up their workspace, and invite team members. Can you review this plan and give me UX feedback?"
|
||||
|
||||
### Error States
|
||||
- **Unrecognized email** → "We couldn't find an account with that email. Check the spelling or create a new account." (Do NOT reveal whether email exists for security)
|
||||
- **Expired link** → "This link has expired. Request a new one." with CTA
|
||||
- **Weak password** → Inline validation showing requirements not yet met
|
||||
- **Mismatched passwords** → "Passwords don't match" shown below confirm field
|
||||
### Agent Response (applying UX rules)
|
||||
|
||||
### Decision Points
|
||||
- **Email found** → Send reset email | **Not found** → Show same confirmation (security)
|
||||
- **Link valid** → Show password form | **Expired** → Show expiry message with resend
|
||||
---
|
||||
|
||||
### Security Considerations
|
||||
- Rate limit reset requests (max 3 per hour per email)
|
||||
- Reset links expire after 30 minutes
|
||||
- Invalidate link after single use
|
||||
- Require minimum password strength
|
||||
- Log out all other sessions after password change
|
||||
#### Step 1 — Research Check *(from [research.md](rules/research.md))*
|
||||
|
||||
### Accessibility Notes
|
||||
- Email field must have visible label and aria-describedby for instructions
|
||||
- Password requirements visible before user starts typing
|
||||
- Success/error states announced to screen readers via aria-live region
|
||||
- Reset link in email should have descriptive link text, not "click here"
|
||||
Before designing, validate your assumptions:
|
||||
- **Do users need a workspace?** Interview 5-8 target users to confirm this matches their mental model. Ask: *"Walk me through setting up a new tool at work."*
|
||||
- **Build a persona** to focus the flow. Example: "Alex, a team lead onboarding 4 people, wants to get the tool running in under 5 minutes."
|
||||
|
||||
#### Step 2 — Flow Analysis *(from [interaction-design.md](rules/interaction-design.md))*
|
||||
|
||||
Your proposed flow: **Sign Up → Verify Email → Set Up Workspace → Invite Team**
|
||||
|
||||
**Issues identified:**
|
||||
|
||||
| # | Issue | Severity | Recommendation |
|
||||
|---|-------|----------|----------------|
|
||||
| 1 | Email verification blocks the entire flow | Major | Let users proceed to workspace setup while verification happens in the background. Show a gentle reminder banner instead of a hard gate. |
|
||||
| 2 | Four sequential steps with no progress indicator | Minor | Add a step indicator: "Step 2 of 4 — Set up your workspace" |
|
||||
| 3 | "Invite Team" is mandatory but may not apply to solo users | Major | Make this step skippable: "Invite team members (you can do this later)" |
|
||||
|
||||
**Recommended flow:**
|
||||
```
|
||||
Sign Up → Workspace Setup → [Optional] Invite Team → Dashboard
|
||||
↑ ↑
|
||||
Progress bar "Skip for now"
|
||||
Step 1 of 3 link available
|
||||
|
||||
Email verification runs in background → banner until confirmed
|
||||
```
|
||||
|
||||
#### Step 3 — Accessibility Review *(from [accessibility.md](rules/accessibility.md))*
|
||||
|
||||
Ensure the onboarding flow meets WCAG AA:
|
||||
- [ ] All form inputs have visible labels (not just placeholders)
|
||||
- [ ] "Continue" buttons have minimum 44×44px touch targets
|
||||
- [ ] Error messages are descriptive: *"Workspace name must be 3-50 characters"* not *"Invalid input"*
|
||||
- [ ] Progress indicator is conveyed to screen readers via `aria-live`
|
||||
- [ ] Color is not the only indicator of current step (use number + label)
|
||||
|
||||
#### Step 4 — Visual Hierarchy *(from [visual-design.md](rules/visual-design.md))*
|
||||
|
||||
- **Primary CTA** ("Continue") should be the most visually dominant element — full-width, high contrast
|
||||
- **Skip links** ("Skip for now") should be visually secondary — text-only, muted color
|
||||
- **Form fields** should use consistent 8px spacing with clear section grouping
|
||||
- Limit each screen to **one primary action** to reduce decision fatigue
|
||||
|
||||
#### Summary
|
||||
|
||||
| Area | Status | Key Action |
|
||||
|------|--------|------------|
|
||||
| Research | ⚠️ Validate | Interview 5-8 users on their onboarding expectations |
|
||||
| User Flow | 🔴 Redesign | Remove email verification blocker, make invite optional |
|
||||
| Accessibility | 🟡 Review | Add visible labels, proper ARIA, and descriptive errors |
|
||||
| Visual Design | ✅ Apply | F-pattern layout, single CTA per screen, 8px grid |
|
||||
|
||||
---
|
||||
|
||||
@@ -1,66 +0,0 @@
|
||||
# Rule: Inclusive Design Patterns
|
||||
|
||||
**Priority:** CRITICAL
|
||||
**Category:** Accessibility
|
||||
|
||||
## Description
|
||||
|
||||
Inclusive design goes beyond compliance. It proactively considers the full range of human diversity — ability, language, culture, age, and context — to create experiences that work for everyone.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Motor & Physical
|
||||
- Design for one-handed mobile use (place key actions within thumb reach)
|
||||
- Provide generous tap targets (minimum 44×44px, ideally 48×48px)
|
||||
- Avoid hover-only interactions (no hover on touch devices)
|
||||
- Support both tap and swipe gestures with alternatives
|
||||
- Allow form completion without precise clicking (large inputs, generous spacing)
|
||||
|
||||
### Visual
|
||||
- Never use color as the only means of conveying information
|
||||
- Support both light and dark modes
|
||||
- Allow text resizing up to 200% without layout breakage
|
||||
- Use sufficient contrast for all text and interactive elements
|
||||
- Provide text labels alongside icons
|
||||
|
||||
### Cognitive
|
||||
- Use plain language (aim for a 6th-8th grade reading level for general audiences)
|
||||
- Break complex tasks into smaller, clearly labeled steps
|
||||
- Provide clear progress indicators for multi-step processes
|
||||
- Minimize cognitive load by reducing the number of choices per screen
|
||||
- Use familiar patterns and conventions over novel interactions
|
||||
|
||||
### Situational
|
||||
- Design for poor network conditions (offline states, loading indicators)
|
||||
- Support use in bright sunlight (sufficient contrast)
|
||||
- Account for one-handed use while holding something
|
||||
- Consider noisy environments (don't rely solely on audio feedback)
|
||||
|
||||
### Cultural & Linguistic
|
||||
- Design layouts that support RTL (right-to-left) languages
|
||||
- Allow for text expansion (some languages need 30-40% more space)
|
||||
- Avoid culturally specific metaphors, icons, or color meanings
|
||||
- Use internationally recognized date, time, and number formats
|
||||
|
||||
## Examples
|
||||
|
||||
### Good
|
||||
```
|
||||
A toggle switch that uses both color AND a label to indicate state:
|
||||
[● ON ] — green with "ON" text
|
||||
[ OFF ○] — gray with "OFF" text
|
||||
```
|
||||
|
||||
### Bad
|
||||
```
|
||||
A toggle that only uses color:
|
||||
[● ] — green (on? selected? active?)
|
||||
[ ○] — red (off? error? disabled?)
|
||||
```
|
||||
|
||||
## Common Mistakes
|
||||
- Assuming all users have a mouse and precise cursor control
|
||||
- Testing only with the latest devices and fast internet
|
||||
- Using idioms or humor that don't translate across cultures
|
||||
- Designing empty states that blame the user ("You haven't done anything yet!")
|
||||
- Ignoring right-to-left language support until it's too late to fix
|
||||
@@ -1,53 +0,0 @@
|
||||
# Rule: WCAG Compliance Checklist
|
||||
|
||||
**Priority:** CRITICAL
|
||||
**Category:** Accessibility
|
||||
|
||||
## Description
|
||||
|
||||
Web Content Accessibility Guidelines (WCAG) provide the standard for accessible digital experiences. Meeting WCAG AA is the minimum bar for professional UX work.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Perceivable
|
||||
- **Color contrast:** 4.5:1 for normal text, 3:1 for large text (18px bold or 24px regular)
|
||||
- **Text alternatives:** All images have descriptive alt text; decorative images use `alt=""`
|
||||
- **Captions:** Video content includes synchronized captions
|
||||
- **Adaptable:** Content meaning is preserved when CSS is disabled or layout changes
|
||||
|
||||
### Operable
|
||||
- **Keyboard accessible:** Every interactive element is reachable and usable via keyboard
|
||||
- **Focus visible:** Focus indicators are clearly visible (minimum 2px, high contrast)
|
||||
- **Skip links:** Provide "Skip to main content" for keyboard users
|
||||
- **Touch targets:** Minimum 44×44 CSS pixels for touch interfaces
|
||||
- **No time traps:** Users can extend or disable time limits
|
||||
- **No seizure triggers:** No content flashes more than 3 times per second
|
||||
|
||||
### Understandable
|
||||
- **Labels:** All form inputs have visible, associated labels
|
||||
- **Error identification:** Errors are clearly described in text (not just color)
|
||||
- **Error prevention:** Confirm destructive actions; allow undo
|
||||
- **Consistent navigation:** Navigation order is the same across pages
|
||||
- **Language:** Page language is declared in HTML (`lang` attribute)
|
||||
|
||||
### Robust
|
||||
- **Semantic HTML:** Use proper elements (`<button>`, `<nav>`, `<main>`, `<header>`)
|
||||
- **ARIA:** Use ARIA roles only when semantic HTML is insufficient
|
||||
- **Valid markup:** HTML validates without critical errors
|
||||
- **Compatibility:** Test with at least 2 screen readers (VoiceOver, NVDA)
|
||||
|
||||
## Testing Checklist
|
||||
|
||||
- [ ] Run automated audit (Axe, Lighthouse)
|
||||
- [ ] Keyboard-only navigation test (Tab, Enter, Escape, Arrow keys)
|
||||
- [ ] Screen reader walkthrough (VoiceOver or NVDA)
|
||||
- [ ] Zoom to 200% — no content loss or overlap
|
||||
- [ ] High contrast mode — all content remains visible
|
||||
- [ ] Reduced motion preference — animations disabled or reduced
|
||||
|
||||
## Common Mistakes
|
||||
- Adding `aria-label` to elements that already have visible text labels
|
||||
- Using `<div>` and `<span>` for interactive elements instead of `<button>` and `<a>`
|
||||
- Hiding focus outlines with `outline: none` without providing an alternative
|
||||
- Relying on placeholder text as the only label for form fields
|
||||
- Using color alone to indicate errors, status, or required fields
|
||||
75
awesome_agent_skills/ux-designer/rules/accessibility.md
Normal file
75
awesome_agent_skills/ux-designer/rules/accessibility.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# Rule: Accessibility & Inclusive Design
|
||||
|
||||
**Priority:** CRITICAL
|
||||
**Category:** Accessibility
|
||||
|
||||
## Description
|
||||
|
||||
Accessible design is a legal requirement in many jurisdictions and a moral imperative. Inclusive design goes further — proactively considering the full range of human diversity (ability, language, culture, context) so that experiences work for everyone.
|
||||
|
||||
## WCAG AA Requirements (Minimum Standard)
|
||||
|
||||
### Perceivable
|
||||
- **Color contrast:** 4.5:1 for normal text, 3:1 for large text (18px bold or 24px+)
|
||||
- **Text alternatives:** All images have descriptive alt text; decorative images use `alt=""`
|
||||
- **Captions:** Video content includes synchronized captions
|
||||
- **Adaptable:** Content meaning preserved when CSS is disabled or layout changes
|
||||
|
||||
### Operable
|
||||
- **Keyboard accessible:** Every interactive element reachable and usable via keyboard
|
||||
- **Focus visible:** Focus indicators clearly visible (minimum 2px, high contrast)
|
||||
- **Skip links:** Provide "Skip to main content" for keyboard users
|
||||
- **Touch targets:** Minimum 44×44 CSS pixels for touch interfaces
|
||||
- **No time traps:** Users can extend or disable time limits
|
||||
- **No seizure triggers:** No content flashes more than 3 times/second
|
||||
|
||||
### Understandable
|
||||
- **Labels:** All form inputs have visible, associated labels
|
||||
- **Error identification:** Errors described in text, not just color
|
||||
- **Error prevention:** Confirm destructive actions; allow undo
|
||||
- **Consistent navigation:** Same navigation order across pages
|
||||
- **Language:** Page language declared in HTML (`lang` attribute)
|
||||
|
||||
### Robust
|
||||
- **Semantic HTML:** Use proper elements (`<button>`, `<nav>`, `<main>`, `<header>`)
|
||||
- **ARIA:** Use ARIA roles only when semantic HTML is insufficient
|
||||
- **Compatibility:** Test with at least 2 screen readers (VoiceOver, NVDA)
|
||||
|
||||
## Inclusive Design Patterns
|
||||
|
||||
### Motor & Physical
|
||||
- Design for one-handed mobile use (key actions within thumb reach)
|
||||
- Provide generous tap targets (minimum 44×44px, ideally 48×48px)
|
||||
- Avoid hover-only interactions (no hover on touch devices)
|
||||
|
||||
### Visual
|
||||
- Never use color as the only means of conveying information
|
||||
- Support both light and dark modes
|
||||
- Allow text resizing up to 200% without layout breakage
|
||||
|
||||
### Cognitive
|
||||
- Use plain language (6th-8th grade reading level for general audiences)
|
||||
- Break complex tasks into smaller, clearly labeled steps
|
||||
- Minimize choices per screen to reduce cognitive load
|
||||
|
||||
### Situational & Cultural
|
||||
- Design for poor network conditions (offline states, loading indicators)
|
||||
- Design layouts supporting RTL languages and text expansion (30-40% more space)
|
||||
- Avoid culturally specific metaphors or color meanings
|
||||
|
||||
## Testing Checklist
|
||||
|
||||
- [ ] Automated audit (Axe, Lighthouse)
|
||||
- [ ] Keyboard-only navigation (Tab, Enter, Escape, Arrow keys)
|
||||
- [ ] Screen reader walkthrough (VoiceOver or NVDA)
|
||||
- [ ] Zoom to 200% — no content loss or overlap
|
||||
- [ ] High contrast mode — all content remains visible
|
||||
- [ ] Reduced motion preference — animations disabled or reduced
|
||||
|
||||
## Common Mistakes
|
||||
- Using `<div>` and `<span>` for interactive elements instead of `<button>` and `<a>`
|
||||
- Hiding focus outlines with `outline: none` without providing an alternative
|
||||
- Relying on placeholder text as the only label for form fields
|
||||
- Using color alone to indicate errors, status, or required fields
|
||||
- Assuming all users have a mouse and precise cursor control
|
||||
- Testing only with the latest devices and fast internet
|
||||
@@ -1,42 +0,0 @@
|
||||
# Rule: Content Organization
|
||||
|
||||
**Priority:** HIGH
|
||||
**Category:** Information Architecture
|
||||
|
||||
## Description
|
||||
|
||||
How content is structured and grouped directly affects whether users can find what they need and complete their tasks efficiently.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Organizational Principles
|
||||
- **User-centric grouping:** Organize by user goals, not business departments
|
||||
- **Progressive disclosure:** Show only what's needed at each level; reveal details on demand
|
||||
- **Consistency:** Same type of content should appear in the same location across pages
|
||||
- **Scannability:** Use clear headings, short paragraphs, and visual breaks
|
||||
|
||||
### Content Hierarchy
|
||||
1. **Page title:** What is this page about? (one per page)
|
||||
2. **Section headings:** Major content groups
|
||||
3. **Supporting content:** Details within each section
|
||||
4. **Related content:** Cross-links and supplementary information
|
||||
5. **Metadata:** Dates, authors, categories, tags
|
||||
|
||||
### Information Scent
|
||||
- Labels should clearly indicate what users will find behind them
|
||||
- Preview content where possible (descriptions, thumbnails, counts)
|
||||
- Use "trigger words" that match user vocabulary and search terms
|
||||
- Provide visual cues for content types (icons for video, PDF, external links)
|
||||
|
||||
### Card Sorting for Validation
|
||||
- **Open sort:** Participants group items and name the categories (discovery phase)
|
||||
- **Closed sort:** Participants sort items into predefined categories (validation phase)
|
||||
- Run with 15-20 participants for reliable patterns
|
||||
- Use results to validate or restructure your information architecture
|
||||
|
||||
## Common Mistakes
|
||||
- Mirroring the database structure in the UI
|
||||
- Using the same label for different things in different contexts
|
||||
- Burying important content below the fold on key pages
|
||||
- Creating deep hierarchies when a flat structure would be clearer
|
||||
- Not accounting for content that belongs in multiple categories
|
||||
@@ -1,48 +0,0 @@
|
||||
# Rule: Navigation Structure Design
|
||||
|
||||
**Priority:** HIGH
|
||||
**Category:** Information Architecture
|
||||
|
||||
## Description
|
||||
|
||||
Navigation is the primary wayfinding mechanism in any digital product. Well-designed navigation reduces time-to-task and prevents users from feeling lost.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Structure
|
||||
|
||||
- Limit primary navigation to 5-7 items
|
||||
- Use clear, descriptive labels (nouns for sections, verbs for actions)
|
||||
- Group related items logically based on user mental models, not org charts
|
||||
- Validate navigation labels with card sorting and tree testing
|
||||
- Provide breadcrumbs for hierarchies deeper than 2 levels
|
||||
|
||||
### Patterns
|
||||
|
||||
- **Global navigation:** Persistent across all pages; contains top-level sections
|
||||
- **Local navigation:** Context-specific; shows sub-sections within the current area
|
||||
- **Utility navigation:** Account, settings, help — secondary but always accessible
|
||||
- **Contextual navigation:** Related content links within the page body
|
||||
|
||||
### Mobile Considerations
|
||||
|
||||
- Use bottom navigation for 3-5 primary actions (most reachable on mobile)
|
||||
- Reserve hamburger menus for secondary navigation only
|
||||
- Highlight the current section in the navigation bar
|
||||
- Ensure navigation doesn't consume more than 20% of the viewport
|
||||
|
||||
### Search as Navigation
|
||||
|
||||
- Include search for products with more than 50 content items
|
||||
- Provide autocomplete suggestions based on popular queries
|
||||
- Show recent searches for returning users
|
||||
- Display helpful empty states when search returns no results
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- Organizing navigation by internal team structure instead of user needs
|
||||
- Using jargon or branded terminology that users don't understand
|
||||
- Hiding essential navigation behind a hamburger menu on desktop
|
||||
- Not indicating the current page in the navigation
|
||||
- Deep nesting that requires more than 3 clicks to reach important content
|
||||
|
||||
@@ -0,0 +1,62 @@
|
||||
# Rule: Information Architecture
|
||||
|
||||
**Priority:** HIGH
|
||||
**Category:** Information Architecture
|
||||
|
||||
## Description
|
||||
|
||||
Information architecture determines how content is structured, labeled, and navigated. If users can't find it, it doesn't exist.
|
||||
|
||||
## Navigation Structure
|
||||
|
||||
### Core Principles
|
||||
- Limit primary navigation to 5-7 items
|
||||
- Use clear, descriptive labels (nouns for sections, verbs for actions)
|
||||
- Group by user mental models, not org charts
|
||||
- Validate labels with card sorting and tree testing
|
||||
- Provide breadcrumbs for hierarchies deeper than 2 levels
|
||||
|
||||
### Navigation Patterns
|
||||
- **Top bar:** Best for 3-7 primary sections on desktop
|
||||
- **Side nav:** Best for deep hierarchies or tools with many sections
|
||||
- **Bottom bar:** Best for mobile apps with 3-5 primary actions
|
||||
- **Hamburger menu:** Use sparingly; hides navigation and reduces discoverability
|
||||
- **Tabs:** Best for switching between related views at the same level
|
||||
|
||||
### Mobile Considerations
|
||||
- Use bottom navigation for 3-5 primary actions (most reachable)
|
||||
- Reserve hamburger menus for secondary navigation only
|
||||
- Highlight the current section in the navigation bar
|
||||
- Ensure navigation doesn't consume more than 20% of the viewport
|
||||
|
||||
## Content Organization
|
||||
|
||||
### Organizational Principles
|
||||
- **User-centric grouping:** Organize by user goals, not business departments
|
||||
- **Progressive disclosure:** Show only what's needed; reveal details on demand
|
||||
- **Consistency:** Same type of content in the same location across pages
|
||||
- **Scannability:** Clear headings, short paragraphs, visual breaks
|
||||
|
||||
### Content Hierarchy
|
||||
1. **Page title:** What is this page about? (one per page)
|
||||
2. **Section headings:** Major content groups
|
||||
3. **Supporting content:** Details within each section
|
||||
4. **Related content:** Cross-links and supplementary information
|
||||
|
||||
### Information Scent
|
||||
- Labels should clearly indicate what users will find
|
||||
- Preview content where possible (descriptions, thumbnails, counts)
|
||||
- Use "trigger words" that match user vocabulary
|
||||
- Provide visual cues for content types (icons for video, PDF, external links)
|
||||
|
||||
### Search as Navigation
|
||||
- Include search for products with more than 50 content items
|
||||
- Provide autocomplete suggestions based on popular queries
|
||||
- Show recent searches for returning users
|
||||
|
||||
## Common Mistakes
|
||||
- Organizing navigation by internal team structure instead of user needs
|
||||
- Using jargon or branded terminology users don't understand
|
||||
- Hiding essential navigation behind a hamburger menu on desktop
|
||||
- Deep nesting requiring more than 3 clicks to reach important content
|
||||
- Mirroring the database structure in the UI
|
||||
78
awesome_agent_skills/ux-designer/rules/interaction-design.md
Normal file
78
awesome_agent_skills/ux-designer/rules/interaction-design.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# Rule: Interaction Design
|
||||
|
||||
**Priority:** HIGH
|
||||
**Category:** Interaction Design
|
||||
|
||||
## Description
|
||||
|
||||
Interaction design covers user flows and microcopy — the two elements that most directly determine whether users complete tasks or abandon them.
|
||||
|
||||
## User Flow Best Practices
|
||||
|
||||
### Design Principles
|
||||
- Map the happy path first, then design for errors and edge cases
|
||||
- Minimize steps — every additional step loses a percentage of users
|
||||
- Provide clear progress indicators for flows with 3+ steps
|
||||
- Allow users to go backward without losing entered data
|
||||
- Auto-save form data at each step when possible
|
||||
- Confirm all destructive actions with clear, specific consequences
|
||||
|
||||
### Multi-Step Flows
|
||||
- Show total steps and current position (step 2 of 4)
|
||||
- Allow skipping optional steps
|
||||
- Summarize entered data before final submission
|
||||
- Send confirmation via email/notification for important transactions
|
||||
|
||||
### Error Recovery
|
||||
- Detect errors as early as possible (inline validation)
|
||||
- Explain what went wrong in plain language and how to fix it
|
||||
- Preserve all valid input — never clear the form on error
|
||||
- Offer alternative paths when the primary path fails
|
||||
|
||||
### Good vs. Bad Flow
|
||||
|
||||
```
|
||||
✅ Cart → Shipping → Payment → Review → Confirmation
|
||||
↑ ↑ ↑ ↑
|
||||
[Back] [Back] [Back] [Edit]
|
||||
Progress bar visible · Each step validates · Review before commit
|
||||
|
||||
❌ Cart → Login Required → Shipping → Re-enter email → Payment → Surprise fees → Submit
|
||||
↓
|
||||
[No going back]
|
||||
```
|
||||
|
||||
## Microcopy Guidelines
|
||||
|
||||
### Buttons & CTAs
|
||||
- Use specific verbs: "Save Draft", "Send Message", "Create Account"
|
||||
- Avoid generic labels: "Submit", "OK", "Click Here"
|
||||
- For destructive actions, name the consequence: "Delete Project" not "Confirm"
|
||||
|
||||
### Error Messages
|
||||
- Explain what happened AND how to fix it
|
||||
- Be specific: "Password must be at least 8 characters" not "Invalid input"
|
||||
- Don't blame the user: "We couldn't find that page" not "You entered a wrong URL"
|
||||
|
||||
### Empty States
|
||||
- Explain why it's empty and what to do next
|
||||
- Example: "No projects yet. Create your first project to get started." + [Create Project]
|
||||
|
||||
### Confirmation Dialogs
|
||||
- Use asymmetric button labels: "Delete Project" / "Keep Project" (not "Yes" / "No")
|
||||
- Mention if the action is irreversible
|
||||
- Provide context: "Delete 'Marketing Plan'? All files and comments will be permanently removed."
|
||||
|
||||
| Context | ❌ Weak | ✅ Strong |
|
||||
|---------|---------|----------|
|
||||
| Save button | Submit | Save Changes |
|
||||
| Delete dialog | "Are you sure?" / Yes / No | "Delete 'Q4 Report'? This can't be undone." / Delete / Cancel |
|
||||
| Empty inbox | No messages | You're all caught up! New messages will appear here. |
|
||||
| Form error | Invalid | Enter a valid email address (e.g., name@example.com) |
|
||||
|
||||
## Common Mistakes
|
||||
- Requiring account creation before the user sees any value
|
||||
- Dead ends with no clear next action
|
||||
- Using "Yes" and "No" for destructive action confirmations
|
||||
- Inconsistent terminology (using "remove", "delete", and "trash" for the same action)
|
||||
- Missing feedback after the final action (did it work?)
|
||||
@@ -1,63 +0,0 @@
|
||||
# Rule: Microcopy Guidelines
|
||||
|
||||
**Priority:** HIGH
|
||||
**Category:** Interaction Design
|
||||
|
||||
## Description
|
||||
|
||||
Microcopy is the small text that guides users through an interface — button labels, tooltips, error messages, empty states, and confirmation dialogs. Great microcopy reduces confusion and builds trust.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Buttons & CTAs
|
||||
- Use specific verbs that describe the action: "Save Draft", "Send Message", "Create Account"
|
||||
- Avoid generic labels: "Submit", "OK", "Click Here", "Next"
|
||||
- Match the button label to the user's intent, not the system's action
|
||||
- For destructive actions, name the consequence: "Delete Project" not "Confirm"
|
||||
|
||||
### Error Messages
|
||||
- Explain what happened in plain language
|
||||
- Tell the user how to fix it
|
||||
- Be specific: "Password must be at least 8 characters" not "Invalid input"
|
||||
- Don't blame the user: "We couldn't find that page" not "You entered a wrong URL"
|
||||
- Place error messages near the field that caused them
|
||||
|
||||
### Empty States
|
||||
- Explain why it's empty
|
||||
- Tell the user what to do to fill it
|
||||
- Provide a clear call-to-action
|
||||
- Example: "No projects yet. Create your first project to get started." + [Create Project] button
|
||||
|
||||
### Confirmation Dialogs
|
||||
- State the action and its consequences clearly
|
||||
- Use asymmetric button labels: "Delete Project" / "Keep Project" (not "Yes" / "No")
|
||||
- Mention if the action is irreversible
|
||||
- Provide context: "Delete 'Marketing Plan'? All files and comments will be permanently removed."
|
||||
|
||||
### Loading States
|
||||
- Use specific messages when possible: "Saving your changes..." rather than "Loading..."
|
||||
- For long waits, explain what's happening: "Analyzing 1,247 responses..."
|
||||
- Consider skeleton screens over spinners for content-heavy pages
|
||||
|
||||
### Tooltips & Helper Text
|
||||
- Keep tooltips under 150 characters
|
||||
- Use helper text for persistent guidance, tooltips for supplementary info
|
||||
- Don't hide critical information in tooltips — it should be visible by default
|
||||
- Format: Explain what it is, then why it matters
|
||||
|
||||
## Examples
|
||||
|
||||
| Context | Weak | Strong |
|
||||
|---------|------|--------|
|
||||
| Save button | Submit | Save Changes |
|
||||
| Delete dialog | "Are you sure?" / Yes / No | "Delete 'Q4 Report'? This can't be undone." / Delete / Cancel |
|
||||
| Empty inbox | No messages | You're all caught up! New messages will appear here. |
|
||||
| Form error | Invalid | Enter a valid email address (e.g., name@example.com) |
|
||||
| 404 page | Page not found | We can't find that page. It may have been moved or deleted. |
|
||||
|
||||
## Common Mistakes
|
||||
- Using technical jargon ("Error 422: Unprocessable Entity")
|
||||
- Writing error messages that only say what's wrong, not how to fix it
|
||||
- Using "Yes" and "No" for destructive action confirmations
|
||||
- Inconsistent terminology (using "remove", "delete", and "trash" for the same action)
|
||||
- Placeholder text that disappears on focus, serving as the only label
|
||||
@@ -1,67 +0,0 @@
|
||||
# Rule: User Flow Best Practices
|
||||
|
||||
**Priority:** HIGH
|
||||
**Category:** Interaction Design
|
||||
|
||||
## Description
|
||||
|
||||
User flows map the path a user takes to complete a task. Well-designed flows minimize friction and guide users to success with clear progress and recovery paths.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Design Principles
|
||||
- Map the happy path first, then design for errors and edge cases
|
||||
- Minimize steps — every additional step loses a percentage of users
|
||||
- Provide clear progress indicators for flows with 3+ steps
|
||||
- Allow users to go backward without losing entered data
|
||||
- Auto-save form data at each step when possible
|
||||
- Confirm all destructive actions with clear, specific consequences
|
||||
|
||||
### Flow Mapping
|
||||
- Start with the user's entry point and goal
|
||||
- Document every screen, decision point, and action
|
||||
- Include error states and recovery paths at each step
|
||||
- Note where users might drop off and design for retention
|
||||
- Map alternative paths (e.g., social login vs. email login)
|
||||
|
||||
### Multi-Step Flows
|
||||
- Show total steps and current position (step 2 of 4)
|
||||
- Allow skipping optional steps
|
||||
- Summarize entered data before final submission
|
||||
- Provide a confirmation screen with next steps after completion
|
||||
- Send confirmation via email or notification for important transactions
|
||||
|
||||
### Error Recovery
|
||||
- Detect errors as early as possible (inline validation)
|
||||
- Explain what went wrong in plain language
|
||||
- Tell the user how to fix it
|
||||
- Preserve all valid input — never clear the form on error
|
||||
- Offer alternative paths when the primary path fails
|
||||
|
||||
## Examples
|
||||
|
||||
### Good Flow: Checkout
|
||||
```
|
||||
Cart → Shipping → Payment → Review → Confirmation
|
||||
↑ ↑ ↑ ↑
|
||||
[Back] [Back] [Back] [Edit]
|
||||
|
||||
- Progress bar visible at all times
|
||||
- Each step validates before proceeding
|
||||
- Review screen shows everything before final commit
|
||||
- Confirmation includes order number, email, and estimated delivery
|
||||
```
|
||||
|
||||
### Bad Flow: Checkout
|
||||
```
|
||||
Cart → Login Required → Shipping → Re-enter email → Payment → Surprise fees → Submit
|
||||
↓
|
||||
[No going back]
|
||||
```
|
||||
|
||||
## Common Mistakes
|
||||
- Requiring account creation before the user sees any value
|
||||
- Hiding total cost until the final step
|
||||
- Dead ends with no clear next action
|
||||
- Loops where the user returns to the same screen without progress
|
||||
- Missing feedback after the final action (did it work?)
|
||||
@@ -1,75 +0,0 @@
|
||||
# Rule: Creating Effective Personas
|
||||
|
||||
**Priority:** CRITICAL
|
||||
**Category:** User Research
|
||||
|
||||
## Description
|
||||
|
||||
Personas are archetypal representations of user groups, grounded in research data. They guide design decisions by keeping the team focused on real user needs.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Creation Process
|
||||
1. Conduct user interviews and gather behavioral data
|
||||
2. Identify patterns in goals, behaviors, and pain points
|
||||
3. Cluster users into 3-5 distinct groups
|
||||
4. Draft persona profiles based on data patterns
|
||||
5. Validate personas with additional research or stakeholder input
|
||||
6. Share personas with the full team and refer to them by name in discussions
|
||||
|
||||
### What to Include
|
||||
- **Name and photo:** Makes the persona feel real and memorable
|
||||
- **Goals:** What they're trying to accomplish (both functional and emotional)
|
||||
- **Pain points:** Current frustrations and unmet needs
|
||||
- **Behaviors:** How they currently solve the problem, tools they use
|
||||
- **Context:** When, where, and why they interact with the product
|
||||
- **Quote:** A representative statement that captures their mindset
|
||||
|
||||
### What to Avoid
|
||||
- Demographics without behavioral data (age and income alone don't drive design decisions)
|
||||
- Aspirational personas (who you wish your users were, not who they are)
|
||||
- Too many personas (more than 5 dilutes team focus)
|
||||
- Generic personas that could describe anyone
|
||||
|
||||
## Examples
|
||||
|
||||
### Good
|
||||
```markdown
|
||||
## Sarah, The Busy Parent
|
||||
**Age:** 34 | **Occupation:** Marketing Manager | **Location:** Austin, TX
|
||||
|
||||
### Goals
|
||||
- Order groceries in under 10 minutes during her commute
|
||||
- Never run out of essentials (milk, diapers, snacks)
|
||||
- Stay within her weekly grocery budget of $150
|
||||
|
||||
### Pain Points
|
||||
- Hates scrolling through irrelevant promotions to find basics
|
||||
- Forgets items because she can't easily reorder past purchases
|
||||
- Delivery windows are too broad — needs precision for her schedule
|
||||
|
||||
### Behaviors
|
||||
- Shops on her phone, never desktop
|
||||
- Reorders 70% of the same items weekly
|
||||
- Compares prices across 2 apps before committing
|
||||
|
||||
> "I just need the basics fast. Don't make me think about groceries more than I have to."
|
||||
```
|
||||
|
||||
### Bad
|
||||
```markdown
|
||||
## User Type A
|
||||
**Age:** 25-45 | **Gender:** Any | **Income:** Middle class
|
||||
|
||||
### Goals
|
||||
- Wants a good experience
|
||||
- Likes easy-to-use apps
|
||||
|
||||
[Too vague to inform any design decision]
|
||||
```
|
||||
|
||||
## Common Mistakes
|
||||
- Creating personas in a brainstorming session without research
|
||||
- Updating personas only once and never revisiting them
|
||||
- Making personas but never referencing them in design reviews
|
||||
- Confusing personas with market segments
|
||||
@@ -1,55 +0,0 @@
|
||||
# Rule: Conducting User Interviews
|
||||
|
||||
**Priority:** CRITICAL
|
||||
**Category:** User Research
|
||||
|
||||
## Description
|
||||
|
||||
User interviews are the foundation of evidence-based design. This rule ensures interviews yield actionable insights rather than confirmation of assumptions.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Planning
|
||||
- Define clear research objectives before scheduling interviews
|
||||
- Write a discussion guide with 8-12 open-ended questions
|
||||
- Recruit 5-8 participants per round for qualitative insights
|
||||
- Screen participants to match your target user profile
|
||||
- Schedule 45-60 minutes per session (30 min interview + buffer)
|
||||
|
||||
### During the Interview
|
||||
- Start with easy warm-up questions to build rapport
|
||||
- Ask about past behavior, not hypothetical future behavior
|
||||
- Use "Tell me about a time when..." framing
|
||||
- Follow up with "Why?" and "Can you show me?" prompts
|
||||
- Stay silent after asking — let the participant fill the space
|
||||
- Take notes on observations, not just words
|
||||
|
||||
### After the Interview
|
||||
- Debrief within 24 hours while memory is fresh
|
||||
- Tag and categorize key quotes and observations
|
||||
- Use affinity mapping to cluster findings into themes
|
||||
- Distinguish between what users say vs. what they do
|
||||
- Prioritize findings by frequency and severity
|
||||
|
||||
## Examples
|
||||
|
||||
### Good
|
||||
```
|
||||
Interviewer: "Walk me through the last time you tried to book a flight online."
|
||||
Participant: [describes experience with specific details]
|
||||
Interviewer: "You mentioned you got frustrated at the seat selection. What happened?"
|
||||
```
|
||||
|
||||
### Bad
|
||||
```
|
||||
Interviewer: "Would you like it if we added a feature that shows seat maps?"
|
||||
Participant: "Sure, that sounds nice."
|
||||
[This tells you nothing about actual behavior or real needs]
|
||||
```
|
||||
|
||||
## Common Mistakes
|
||||
- Asking leading questions that suggest the "right" answer
|
||||
- Interviewing only power users and missing beginner perspectives
|
||||
- Not recording sessions (with consent) for team review
|
||||
- Jumping to solutions during the interview instead of exploring the problem
|
||||
- Treating a single participant's feedback as representative of all users
|
||||
94
awesome_agent_skills/ux-designer/rules/research.md
Normal file
94
awesome_agent_skills/ux-designer/rules/research.md
Normal file
@@ -0,0 +1,94 @@
|
||||
# Rule: User Research
|
||||
|
||||
**Priority:** CRITICAL
|
||||
**Category:** User Research
|
||||
|
||||
## Description
|
||||
|
||||
User research is the foundation of evidence-based design. It ensures decisions are grounded in real user data — through interviews that yield actionable insights and personas that keep teams focused on real needs.
|
||||
|
||||
## Conducting User Interviews
|
||||
|
||||
### Planning
|
||||
- Define clear research objectives before scheduling
|
||||
- Write a discussion guide with 8-12 open-ended questions
|
||||
- Recruit 5-8 participants per round for qualitative insights
|
||||
- Schedule 45-60 minutes per session (30 min interview + buffer)
|
||||
|
||||
### During the Interview
|
||||
- Start with easy warm-up questions to build rapport
|
||||
- Ask about past behavior, not hypothetical future behavior
|
||||
- Use "Tell me about a time when..." framing
|
||||
- Follow up with "Why?" and "Can you show me?"
|
||||
- Stay silent after asking — let the participant fill the space
|
||||
|
||||
### Synthesis
|
||||
1. Debrief within 24 hours while memory is fresh
|
||||
2. Extract key observations as individual data points
|
||||
3. Cluster observations into themes using affinity mapping
|
||||
4. Identify patterns across multiple participants
|
||||
5. Prioritize insights by frequency and impact
|
||||
6. Create actionable recommendations tied to specific findings
|
||||
|
||||
### Good vs. Bad Interview Questions
|
||||
|
||||
| ✅ Good | ❌ Bad |
|
||||
|---------|-------|
|
||||
| "Walk me through the last time you [did the task]." | "Don't you think this feature would be useful?" (leading) |
|
||||
| "What was the hardest part of that experience?" | "Would you use a product that does X?" (hypothetical) |
|
||||
| "What did you try before finding this solution?" | "Do you like this design?" (opinion, not behavior) |
|
||||
|
||||
## Creating Effective Personas
|
||||
|
||||
### Creation Process
|
||||
1. Conduct user interviews and gather behavioral data
|
||||
2. Identify patterns in goals, behaviors, and pain points
|
||||
3. Cluster users into 3-5 distinct groups
|
||||
4. Draft persona profiles based on data patterns
|
||||
5. Validate with additional research or stakeholder input
|
||||
6. Share personas with the full team; refer to them by name
|
||||
|
||||
### What to Include
|
||||
- **Name and photo** — makes the persona memorable
|
||||
- **Goals** — functional and emotional objectives
|
||||
- **Pain points** — current frustrations and unmet needs
|
||||
- **Behaviors** — how they currently solve the problem
|
||||
- **Context** — when, where, and why they use the product
|
||||
- **Quote** — a representative statement capturing their mindset
|
||||
|
||||
### Example
|
||||
|
||||
#### Good Persona
|
||||
```markdown
|
||||
## Sarah, The Busy Parent
|
||||
**Age:** 34 | **Occupation:** Marketing Manager | **Location:** Austin, TX
|
||||
|
||||
### Goals
|
||||
- Order groceries in under 10 minutes during her commute
|
||||
- Never run out of essentials (milk, diapers, snacks)
|
||||
|
||||
### Pain Points
|
||||
- Hates scrolling through irrelevant promotions to find basics
|
||||
- Forgets items because she can't easily reorder past purchases
|
||||
|
||||
### Behaviors
|
||||
- Shops on her phone, never desktop
|
||||
- Reorders 70% of the same items weekly
|
||||
|
||||
> "I just need the basics fast. Don't make me think about groceries more than I have to."
|
||||
```
|
||||
|
||||
#### Bad Persona
|
||||
```markdown
|
||||
## User Type A
|
||||
**Age:** 25-45 | **Gender:** Any | **Income:** Middle class
|
||||
Goals: Wants a good experience. Likes easy-to-use apps.
|
||||
[Too vague to inform any design decision]
|
||||
```
|
||||
|
||||
## Common Mistakes
|
||||
- Asking leading questions that suggest the "right" answer
|
||||
- Interviewing only power users and missing beginner perspectives
|
||||
- Creating personas in a brainstorming session without research data
|
||||
- Making personas but never referencing them in design reviews
|
||||
- Treating a single participant's feedback as representative of all users
|
||||
@@ -1,55 +0,0 @@
|
||||
# Rule: Design System Foundations
|
||||
|
||||
**Priority:** MEDIUM
|
||||
**Category:** Visual Design
|
||||
|
||||
## Description
|
||||
|
||||
A design system is a collection of reusable components, guidelines, and standards that ensure consistency across a product. It speeds up design and development while maintaining quality.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Core Elements
|
||||
- **Color palette:** Primary, secondary, neutral, and semantic colors with defined usage rules
|
||||
- **Typography:** Font families, size scale, weight usage, and line heights
|
||||
- **Spacing:** A base unit (typically 4px or 8px) applied consistently throughout
|
||||
- **Grid:** Column structure, gutters, and margins for each breakpoint
|
||||
- **Elevation:** Shadow levels to indicate depth and layering
|
||||
- **Border radius:** Consistent rounding (e.g., 4px for subtle, 8px for cards, full for pills)
|
||||
|
||||
### Component Library
|
||||
Every component should document:
|
||||
- **Purpose:** When and why to use it
|
||||
- **Anatomy:** Labeled parts of the component
|
||||
- **States:** Default, hover, active, focus, disabled, loading, error
|
||||
- **Variants:** Size options, style variations, with/without icons
|
||||
- **Usage guidelines:** Do's and don'ts with visual examples
|
||||
- **Responsive behavior:** How it adapts across breakpoints
|
||||
- **Accessibility:** Keyboard behavior, ARIA attributes, screen reader announcements
|
||||
|
||||
### Essential Components
|
||||
- Buttons (primary, secondary, tertiary, destructive)
|
||||
- Text inputs (single line, textarea, with validation states)
|
||||
- Select / Dropdown
|
||||
- Checkbox and Radio
|
||||
- Toggle / Switch
|
||||
- Cards
|
||||
- Modals and Dialogs
|
||||
- Toast / Snackbar notifications
|
||||
- Navigation components (tabs, breadcrumbs, sidebar)
|
||||
- Tables and Lists
|
||||
- Loading indicators (spinner, skeleton, progress bar)
|
||||
|
||||
### Governance
|
||||
- Assign design system ownership (dedicated team or rotating responsibility)
|
||||
- Version components and document breaking changes
|
||||
- Establish a contribution process for new components
|
||||
- Conduct regular audits to identify inconsistencies
|
||||
- Measure adoption through component usage analytics
|
||||
|
||||
## Common Mistakes
|
||||
- Building a design system before understanding actual product needs
|
||||
- Creating components that are too rigid to accommodate real use cases
|
||||
- Not documenting when to use (and when NOT to use) each component
|
||||
- Maintaining separate design and code component libraries that drift apart
|
||||
- Over-engineering components for hypothetical future needs
|
||||
61
awesome_agent_skills/ux-designer/rules/visual-design.md
Normal file
61
awesome_agent_skills/ux-designer/rules/visual-design.md
Normal file
@@ -0,0 +1,61 @@
|
||||
# Rule: Visual Design
|
||||
|
||||
**Priority:** MEDIUM
|
||||
**Category:** Visual Design
|
||||
|
||||
## Description
|
||||
|
||||
Visual design communicates hierarchy, establishes brand consistency, and guides user attention — without requiring users to think about it. A solid design system ensures these principles are applied consistently.
|
||||
|
||||
## Visual Hierarchy Principles
|
||||
|
||||
### Establishing Hierarchy
|
||||
1. **Size:** Larger elements attract attention first; use for headings and primary CTAs
|
||||
2. **Contrast:** High contrast draws the eye; use for key actions and critical information
|
||||
3. **Color:** Saturated/brand colors for emphasis; muted tones for secondary elements
|
||||
4. **Position:** Top-left scanned first (LTR); place key content in F-pattern or Z-pattern
|
||||
5. **Whitespace:** Generous spacing isolates and elevates important elements
|
||||
6. **Typography:** Weight, size, and style create clear content levels
|
||||
|
||||
### Typography Scale
|
||||
- Limit to 3-4 distinct text sizes per screen
|
||||
- Maintain a consistent ratio between levels (1.25× or 1.333× scale)
|
||||
- Use weight (bold vs. regular) to differentiate within the same size
|
||||
- Reserve ALL CAPS for very short labels only (buttons, tags)
|
||||
|
||||
### Color Usage
|
||||
- Primary color for main CTAs and key interactive elements
|
||||
- Neutral colors (grays) for body text and secondary elements
|
||||
- Semantic colors for feedback: green (success), red (error), yellow (warning), blue (info)
|
||||
- Limit accent colors to 1-2 per screen to maintain focus
|
||||
|
||||
### Layout Principles
|
||||
- Align to a consistent grid (8px base unit is standard)
|
||||
- Use tighter spacing between related elements, looser between unrelated
|
||||
- Group related items visually using proximity and shared containers
|
||||
|
||||
## Design System Foundations
|
||||
|
||||
### Core Elements
|
||||
- **Color palette:** Primary, secondary, neutral, and semantic colors with usage rules
|
||||
- **Typography:** Font families, size scale, weight usage, and line heights
|
||||
- **Spacing:** A base unit (typically 4px or 8px) applied consistently
|
||||
- **Grid:** Column structure, gutters, and margins for each breakpoint
|
||||
- **Elevation:** Shadow levels indicating depth and layering
|
||||
- **Border radius:** Consistent rounding (4px subtle, 8px cards, full for pills)
|
||||
|
||||
### Component Documentation
|
||||
Every component should define:
|
||||
- **Purpose, anatomy, and states** (default, hover, active, focus, disabled, error)
|
||||
- **Variants** (size options, with/without icons)
|
||||
- **Responsive behavior** and **accessibility requirements**
|
||||
|
||||
### Essential Components
|
||||
Buttons · Text inputs · Select/Dropdown · Checkbox/Radio · Toggle · Cards · Modals · Toast notifications · Navigation (tabs, breadcrumbs, sidebar) · Tables/Lists · Loading indicators
|
||||
|
||||
## Common Mistakes
|
||||
- Making everything bold or large (if everything is emphasized, nothing is)
|
||||
- Using too many colors without clear purpose
|
||||
- Competing CTAs of equal visual weight on the same screen
|
||||
- Building a design system before understanding actual product needs
|
||||
- Maintaining separate design and code component libraries that drift apart
|
||||
@@ -1,43 +0,0 @@
|
||||
# Rule: Visual Hierarchy Principles
|
||||
|
||||
**Priority:** MEDIUM
|
||||
**Category:** Visual Design
|
||||
|
||||
## Description
|
||||
|
||||
Visual hierarchy directs user attention and communicates the relative importance of elements on a screen. A strong hierarchy means users instinctively know where to look and what to do.
|
||||
|
||||
## Guidelines
|
||||
|
||||
### Establishing Hierarchy
|
||||
1. **Size:** Larger elements attract attention first; use for headings and primary CTAs
|
||||
2. **Contrast:** High contrast draws the eye; use for key actions and critical information
|
||||
3. **Color:** Saturated or brand colors for emphasis; muted tones for secondary elements
|
||||
4. **Position:** Top-left scanned first (LTR languages); place key content in the F-pattern or Z-pattern
|
||||
5. **Whitespace:** Generous spacing isolates and elevates important elements
|
||||
6. **Typography:** Weight, size, and style create clear content levels
|
||||
|
||||
### Typography Scale
|
||||
- Limit to 3-4 distinct text sizes per screen
|
||||
- Maintain a consistent ratio between levels (1.25x or 1.333x scale)
|
||||
- Use weight (bold vs. regular) to differentiate within the same size
|
||||
- Reserve ALL CAPS for very short labels only (buttons, tags)
|
||||
|
||||
### Color Usage
|
||||
- Primary color for main CTAs and key interactive elements
|
||||
- Neutral colors (grays) for body text and secondary elements
|
||||
- Semantic colors for feedback: green (success), red (error), yellow (warning), blue (info)
|
||||
- Limit accent colors to 1-2 per screen to maintain focus
|
||||
|
||||
### Layout Principles
|
||||
- Align to a consistent grid (8px base unit is standard)
|
||||
- Use consistent spacing between related elements (tighter) vs. unrelated elements (looser)
|
||||
- Group related items visually using proximity and shared containers
|
||||
- Leave breathing room — cramped layouts increase cognitive load
|
||||
|
||||
## Common Mistakes
|
||||
- Making everything bold or large (if everything is emphasized, nothing is)
|
||||
- Using too many colors without clear purpose
|
||||
- Inconsistent spacing that makes the layout feel chaotic
|
||||
- Competing CTAs of equal visual weight on the same screen
|
||||
- Decorative elements that distract from content and actions
|
||||
Reference in New Issue
Block a user