Frontend Design Direction
Use this skill when the work is not just making UI function, but making it feel
purposeful, polished, and appropriate to the product domain.
Source: salvaged from stale community PR #1659 by linus707.
Note: ECC intentionally does not rebundle the canonical Anthropic
frontend-design skill. Install that from anthropics/skills when you want the
official upstream skill. This skill is the ECC-specific design-direction salvage
of the useful local guidance from #1659.
When to Use
- The user asks to build a web page, app, dashboard, artifact, component, or UI.
- The user asks to make an interface more polished, distinctive, beautiful, or
less generic.
- The implementation needs visual hierarchy, typography, color, motion, layout,
and interaction choices.
- The current UI works but reads as flat, generic, templated, or mismatched to
the audience.
Design Direction
Before coding, choose a specific direction:
- Purpose: what job does the interface do?
- Audience: who repeats this workflow, and what do they need to scan first?
- Tone: utilitarian, editorial, playful, industrial, refined, technical,
maximal, minimal, dense, calm, or another explicit direction.
- Memorable detail: one design idea that makes the result feel intentional.
- Constraints: framework, accessibility, performance, responsiveness, and
existing design system.
Match the direction to the domain. A SaaS operations tool should usually be
dense, quiet, and scannable. A portfolio, launch page, game, or editorial piece
can be more expressive. Do not force a landing-page composition onto a tool that
needs repeated daily use.
Implementation Guidance
- Build the actual usable experience as the first screen unless the user
explicitly asks for marketing copy.
- Use existing project components, tokens, icon libraries, and routing patterns
before introducing a new visual system.
- Use real or generated visual assets when the interface depends on images,
products, places, people, gameplay, charts, or inspectable media.
- Prefer contextual typography and spacing over generic oversized hero text.
- Keep palettes multi-dimensional: avoid a UI dominated by one hue family.
- Use CSS variables or existing design tokens so the direction remains
coherent across states.
- Design responsive constraints explicitly: grids, aspect ratios, min/max
sizes, stable toolbars, and fixed-format controls should not shift when labels
or hover states appear.
- Use motion sparingly but deliberately. Prefer high-signal transitions that
clarify state over decorative animation.
- Verify text fit on mobile and desktop. Long labels must wrap or resize
cleanly rather than overflowing.
Anti-Patterns
- Do not default to common generated patterns: purple gradients, decorative
blobs, oversized cards, vague hero copy, or stock-like atmospheric media.
- Do not add UI cards inside other cards.
- Do not use a single decorative style everywhere when the domain calls for
restraint.
- Do not hide the primary product, tool, object, or workflow behind generic
marketing sections.
- Do not add a new dependency for a design flourish unless it clearly pays for
itself.
- Do not describe the UI's features inside the UI when the controls can speak
for themselves.
Review Checklist
- The first viewport immediately communicates the product, workflow, or object.
- The visual hierarchy supports scanning and repeated use.
- Typography fits the container and does not overlap adjacent content.
- Color choices have contrast and do not collapse into a one-note palette.
- Icons are used for familiar tool actions where available.
- Responsive layout has stable dimensions for boards, grids, toolbars,
controls, tiles, and counters.
- Assets render and carry the subject matter instead of acting as filler.
- Motion improves orientation and does not mask sluggishness.
- The result matches the repo's existing frontend conventions unless there is a
clear reason to depart.
Source: affaan-m/ECC → skills/frontend-design-direction/SKILL.md
Also appears in: affaan-m/ECC/docs/ja-JP/skills/frontend-design-direction/SKILL.md
1---2name: frontend-design-direction3description: Set an ECC-specific frontend design direction for production UI work. Use when building or improving websites, dashboards, applications, components, landing pages, visual tools, or any web UI that needs stronger product-specific design judgment.4---5# Frontend Design Direction67Use this skill when the work is not just making UI function, but making it feel8purposeful, polished, and appropriate to the product domain.910Source: salvaged from stale community PR #1659 by `linus707`.1112Note: ECC intentionally does not rebundle the canonical Anthropic13`frontend-design` skill. Install that from `anthropics/skills` when you want the14official upstream skill. This skill is the ECC-specific design-direction salvage15of the useful local guidance from #1659.1617## When to Use1819- The user asks to build a web page, app, dashboard, artifact, component, or UI.20- The user asks to make an interface more polished, distinctive, beautiful, or21 less generic.22- The implementation needs visual hierarchy, typography, color, motion, layout,23 and interaction choices.24- The current UI works but reads as flat, generic, templated, or mismatched to25 the audience.2627## Design Direction2829Before coding, choose a specific direction:30311. Purpose: what job does the interface do?322. Audience: who repeats this workflow, and what do they need to scan first?333. Tone: utilitarian, editorial, playful, industrial, refined, technical,34 maximal, minimal, dense, calm, or another explicit direction.354. Memorable detail: one design idea that makes the result feel intentional.365. Constraints: framework, accessibility, performance, responsiveness, and37 existing design system.3839Match the direction to the domain. A SaaS operations tool should usually be40dense, quiet, and scannable. A portfolio, launch page, game, or editorial piece41can be more expressive. Do not force a landing-page composition onto a tool that42needs repeated daily use.4344## Implementation Guidance4546- Build the actual usable experience as the first screen unless the user47 explicitly asks for marketing copy.48- Use existing project components, tokens, icon libraries, and routing patterns49 before introducing a new visual system.50- Use real or generated visual assets when the interface depends on images,51 products, places, people, gameplay, charts, or inspectable media.52- Prefer contextual typography and spacing over generic oversized hero text.53- Keep palettes multi-dimensional: avoid a UI dominated by one hue family.54- Use CSS variables or existing design tokens so the direction remains55 coherent across states.56- Design responsive constraints explicitly: grids, aspect ratios, min/max57 sizes, stable toolbars, and fixed-format controls should not shift when labels58 or hover states appear.59- Use motion sparingly but deliberately. Prefer high-signal transitions that60 clarify state over decorative animation.61- Verify text fit on mobile and desktop. Long labels must wrap or resize62 cleanly rather than overflowing.6364## Anti-Patterns6566- Do not default to common generated patterns: purple gradients, decorative67 blobs, oversized cards, vague hero copy, or stock-like atmospheric media.68- Do not add UI cards inside other cards.69- Do not use a single decorative style everywhere when the domain calls for70 restraint.71- Do not hide the primary product, tool, object, or workflow behind generic72 marketing sections.73- Do not add a new dependency for a design flourish unless it clearly pays for74 itself.75- Do not describe the UI's features inside the UI when the controls can speak76 for themselves.7778## Review Checklist7980- The first viewport immediately communicates the product, workflow, or object.81- The visual hierarchy supports scanning and repeated use.82- Typography fits the container and does not overlap adjacent content.83- Color choices have contrast and do not collapse into a one-note palette.84- Icons are used for familiar tool actions where available.85- Responsive layout has stable dimensions for boards, grids, toolbars,86 controls, tiles, and counters.87- Assets render and carry the subject matter instead of acting as filler.88- Motion improves orientation and does not mask sluggishness.89- The result matches the repo's existing frontend conventions unless there is a90 clear reason to depart.9192---9394**Source:** [`affaan-m/ECC`](https://github.com/affaan-m/ECC) → `skills/frontend-design-direction/SKILL.md`9596**Also appears in:** `affaan-m/ECC/docs/ja-JP/skills/frontend-design-direction/SKILL.md`