Frontend design

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

• Color palette goes beyond primary/secondary/neutral
• Typography creates clear hierarchy (not just size changes)
• Spacing creates intentional rhythm (not uniform gaps)
• Icons have consistent style/weight/meaning
• Micro-interactions add personality

Purposeful Patterns

• Each component solves a specific user problem
• Layout serves content structure (not vice versa)
• Navigation reflects user mental models
• Empty states guide users (not just "No data")
• Loading states reduce perceived wait time

Avoiding Generic Traps

• Not using component library defaults unchanged
• Headers aren't just logo-left, nav-right
• Forms have personality beyond labels + inputs
• Buttons vary by importance (not just color)
• Data displays fit the data (not just tables)

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:

1. Is this recognizable? Would users know it's from us?
2. Is this purposeful? Can we justify every choice?
3. Is this necessary? Does it solve a real problem?
4. Is this accessible? Can all users interact with it?
5. 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

<!-- [CUSTOMIZE] Add project-specific anti-patterns below -->

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