| name | frontend-design |
| description | Guide for creating distinctive UI designs that avoid generic templates. Use when designing new UI components, screens, or evaluating designs for uniqueness and purpose. DO NOT USE FOR: architecture decisions or SOLID evaluation (use software-architecture), open-ended exploration (use brainstorming), or React test strategies (use ui-testing). |
Frontend Design Skill
Guide for creating distinctive, purposeful UI designs that avoid cookie-cutter patterns.
When to Use
- Designing new UI components or screens
- Evaluating existing designs for uniqueness
- Reviewing designs that feel "generic"
- Creating brand-aligned interfaces
- Building memorable user experiences
Core Principles
1. Purpose Over Pattern
Every design decision should answer: "Why this, not something else?"
- Bad: Using a card grid because it's common
- Good: Using a card grid because content is comparable and scannable
2. Distinctive Identity
Your UI should be recognizable without the logo.
Questions to ask:
- Would users recognize this as our product?
- What makes this different from competitors?
- Does this reflect our brand personality?
3. Intentional Defaults
Don't accept framework defaults blindly.
[CUSTOMIZE] Review these common defaults in your stack:
- Border radius values
- Shadow depths
- Spacing scales
- Color applications
- Typography scales
Design Review Checklist
Visual Distinction
Purposeful Patterns
Avoiding Generic Traps
Breaking Generic Patterns
Instead of Generic Cards
Consider:
- Asymmetric layouts for visual interest
- Inline expansion vs. navigation
- Progressive disclosure of details
- Content-specific shapes (not all rectangles)
Instead of Generic Forms
Consider:
- Conversational flows for complex inputs
- Smart defaults that reduce input
- Inline validation with helpful context
- Progress indication for multi-step
Instead of Generic Tables
Consider:
- Is a table the right pattern at all?
- Grouped/nested rows for hierarchy
- Inline actions vs. row selection
- Responsive transformations (not just scroll)
Instead of Generic Dashboards
Consider:
- User goals, not data availability
- Actionable metrics, not vanity metrics
- Contextual insights, not just numbers
- Personalization based on role/usage
Design Language Documentation
[CUSTOMIZE] Document your design language:
## Our Design Personality
- [Define 3-5 adjectives: e.g., "Professional but approachable"]
## Signature Elements
- [Unique visual elements that define your brand]
## Intentional Constraints
- [Self-imposed rules that create consistency]
Review Questions
Before shipping any design:
- Is this recognizable? Would users know it's from us?
- Is this purposeful? Can we justify every choice?
- Is this necessary? Does it solve a real problem?
- Is this accessible? Can all users interact with it?
- Is this maintainable? Can we scale this pattern?
Resources
[CUSTOMIZE] Add your project's design resources:
- Design system documentation
- Brand guidelines
- Component library
- Design tokens
- Approved patterns and templates
Supplement Skills
A supplement skill is a project-specific skill that layers additional constraints, themes, or identity guidance on top of this hub skill. When a project has one, load both together — the hub skill provides the universal design principles and the supplement narrows them for the project.
Naming convention: {project}-{hub-skill-name} — for example, windgust-frontend-design supplements frontend-design.
When to create one: When your project has a unique visual identity, brand-specific design tokens, or theme customizations that go beyond what the [CUSTOMIZE] markers in this skill cover. If you find yourself adding the same project-specific guidance to every session, extract it into a supplement.
Supplement ≠ replacement: A supplement adds to the hub skill; it does not replace it. Load both together. Do not contradict hub skill defaults — extend or constrain them instead.
Worked Example
windgust-frontend-design in Grimblaz-and-Friends/Windgust-Questbook supplements this skill with the Windgust brand personality, color palette, and component conventions specific to that project.
Supplement SKILL.md Template
Note: This template is pre-filled for frontend-design supplements. When creating a supplement for a different hub skill, replace every occurrence of frontend-design with your hub-skill name.
---
name: {project}-frontend-design
description: Supplements `frontend-design` with {project} brand identity, design tokens, and visual conventions. Use when designing {project} UI components or screens alongside the `frontend-design` hub skill. DO NOT USE FOR: standalone sessions without `frontend-design` loaded (this is a supplement skill; always load `frontend-design` alongside).
---
# {Project} Frontend Design Supplement
Project-specific design constraints that layer on top of the `frontend-design` hub skill.
## Brand Identity
[CUSTOMIZE] Document brand personality, color palette, and typography rules.
## Design Tokens
[CUSTOMIZE] List token overrides that go beyond `frontend-design` defaults.
## Component Conventions
[CUSTOMIZE] List component conventions that extend `frontend-design` hub skill guidance.
## When to Use
- [CUSTOMIZE] List the conditions when this supplement should be loaded (alongside `frontend-design`).
## Gotchas
| Trigger | Gotcha | Fix |
| -------------------------------- | --------------------------- | ------------------------- |
| [CUSTOMIZE] Observable condition | [CUSTOMIZE] What goes wrong | [CUSTOMIZE] How to fix it |
Gotchas
| Trigger | Gotcha | Fix |
|---|
| Keeping every component library default (border-radius, shadow, spacing) unchanged | Design feels generic — indistinguishable from any other app using the same framework | Audit defaults; make ≥3 intentional overrides per component type |
| Header layout is logo-left, nav-right without questioning it | The invisible default — identical to every SaaS app | Evaluate navigation mental models; consider sidebar, bottom nav, or contextual nav |
| "It's common" or "everyone does it" as design justification | Common ≠ purposeful; pattern chosen without intent | Force "why this, not something else?" using §1 Purpose Over Pattern |
| Reaching for a table when asked to "show data" | Tables rarely fit mobile; rarely surface hierarchy | Ask "Is a table the right pattern?" before building; consider cards, timelines, or grouped lists |
| Shipping without answering the 5 review questions | UI may be polished but not recognizable, purposeful, or accessible | Answer all 5 review questions before declaring design done |
