SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsdesign-visual-direction

design-visual-direction

Design & creation

View repository

Updated 10-16 10:22

About this skill

Visual Direction — Visual Direction

Entry/Exit

  • Entry: Need to define visual style, hierarchy, component appearance, or external presentation quality
  • Exit: Visual direction, style constraints, and hierarchy rules finalized
  • Points to: Need interaction main path → design-experience-interaction; need typography → design-content-layout
  • Output path: build-content-layout(downstream build skill)
  • Prerequisite loading: CANON.md + design-workflow-design

When not to use

  • Pure text or pure backend tasks
  • User explicitly allows only following a fixed brand template, with no direction judgment

Iron Law

Visual direction must serve understanding and character, and must not replace structure and content itself.

Core principles

  1. Hierarchy Before Decoration
  2. System Before One-off
  3. Brand Before Personal Taste
  4. Mood Must Match Task
  5. Visible Consistency Beats Clever Variation

Best practice inputs

First read references/design-best-practices.md、references/design-inspiration-catalog.md and references/design-pattern-extract.md, and write visual-related evidence into 02-design.md of Design References / Pattern Synthesis / Adopt / Reject。

Scan focus:

  • Enterprise Product Patterns: visual density, sense of trust, brand character, and component language of similar products
  • Official Systems / Platform Rules: brand specifications, design systems, platform visual rules, accessibility contrast
  • Methods / Theory / Style Schools: visual hierarchy, color roles, typography systems, style schools
  • Anti-patterns / Verification: monochrome overuse, decoration overpowering information, card proliferation, brand mixing conflicts
  • Local Project Truth: existing tokens, component libraries, brand assets, media constraints, and user goals; project root DESIGN.md(if it exists, read YAML tokens and visual direction)

Popular styles must go through Adopt / Reject; "premium", "tech feel", or "like a certain brand" cannot be written directly as a conclusion.

Process

Step 1: Read constraints

  • Brand colors
  • Font constraints
  • Component library / existing visual system
  • Media and dimensions
  • ✅ Verification point: Have the token definitions in the project root DESIGN.md(if present) been read?

Step 2: Define visual goals

  • What character to convey
  • What to see at first glance
  • Which information must be de-emphasized
  • ✅ Verification point: Are the visual goals expressed with measurable hierarchy rules rather than only adjectives?

Step 3: Set the visual system

  • Color roles
  • Font hierarchy
  • Spacing and alignment
  • Visual rules for cards/buttons/charts/modules
  • ✅ Verification point: Can each visual rule land on a specific page or component, rather than a general direction?

Step 4: Record the do-not list

  • Styles not to use
  • Visual routines not to adopt
  • Conflicting elements not allowed
  • ✅ Verification point: Does each item in the do-not list have a clear source of conflict or evidence?

Output contract

Write to 02-design.md：

  • Visual direction
  • Style and system
  • Page visual hierarchy
  • Adopt / Reject (visual patterns)
  • Do-not list

Verification failure handling

Failure scenario How to handle
Style words are too abstract Change to executable hierarchy, color, and layout rules
Visual direction conflicts with the brand Defer to brand constraints and record the trade-offs
Visual direction obscures the information hierarchy Roll back decoration and strengthen the primary/secondary hierarchy
Visual pattern has no evidence Add a best-practice scan, and clearly state the source layer and rationale for trade-offs

Common sayings

Saying Reality Consequence
“Do the default styles first, beautify later” Default styles will solidify into de facto design. Default styles solidify → later changes to the visual direction require refactoring 40-60% of the UI code, doubling the rework
“Adding more effects makes it more premium” Effects are not hierarchy; noise eats the focus. Decoration overpowers information → users' attention on the first screen is scattered by 30-50%, and key action conversion rates drop
“Good enough is fine” Good enough usually means there is no visual system. No visual system → each subsequent page makes decisions independently, consistency costs accumulate page by page, and the larger the project, the more out of control it becomes

Good and bad examples

✅ Good: Evidence-driven visual decisions

视觉目标: 传达专业信任感，让数据成为主角

色彩角色:
- 主色: #2563EB（品牌蓝，来源: DESIGN.md → brand.primary）
- 辅色: #64748B（中性灰，数据标签用）
- 强调: #DC2626（仅用于异常指标和 CTA）
- 背景: #F8FAFC → #FFFFFF（层级区分）

字体层级:
- H1: 24px/700（数据标题）
- H2: 18px/600（卡片标题）
- Body: 14px/400（数据值和描述）
- Caption: 12px/400（辅助信息，降权）

Adopt: 单色主色 + 灰层级（参考 Stripe Dashboard，Pattern Synthesis 来源 #2）
Reject: 多色渐变 Hero（与"数据是主角"目标冲突，来源: Anti-patterns）

❌ Bad: Abstract templates with no concrete decisions

视觉目标: 高级、科技感

色彩: 用蓝色系（未定义角色和层级）
字体: 现代无衬线（未定义尺寸层级和对比）
不做清单: (未写)
→ 没有来源证据，没有 Adopt / Reject，无法落地到组件

Output template

Visual direction output should be written into 02-design.md of the following structure:

## Visual Direction — [功能名称]

### 视觉目标
- 传达气质: [具体描述，非形容词堆砌]
- 首屏焦点: [哪个信息/组件是主角]
- 降权项: [哪些信息必须视觉降权]

### 视觉系统
| 角色 | 具体值 | 来源 |
|------|--------|------|
| 主色 | [色值] | DESIGN.md / 品牌规范 |
| 辅色 | [色值] | ... |
| 强调色 | [色值] | ... |
| 背景 | [色值] | ... |

| 层级 | 字号 | 字重 | 用途 |
|------|------|------|------|
| H1 | [px] | [weight] | [用途] |
| H2 | [px] | [weight] | [用途] |
| Body | [px] | [weight] | [用途] |

间距尺度: [4/8/12/16/24/32px 等]
组件视觉规则: [卡片、按钮、图表等的具体规则]

### Adopt / Reject（视觉模式）
| 模式 | 来源 | 决定 | 理由 |
|------|------|------|------|
| [模式 A] | [来源层] | Adopt | [具体理由] |
| [模式 B] | [来源层] | Reject | [冲突点] |

### 不做清单
- [不做项 1]: [冲突来源或证据]
- [不做项 2]: [冲突来源或证据]

Red flags — STOP

  • Starting to choose a style without brand or scenario constraints
  • Missing a visual best-practice scan or Adopt / Reject
  • Writing visual direction as a pile of aesthetic adjectives
  • Pursuing multiple mutually conflicting temperaments at the same time
  • Visual rules cannot be applied to pages or components

Verification checklist

  • Visual constraints are clear
  • Visual goals are clear
  • The visual system is executable
  • The "do not do" list is clear
  • Visual decisions have been traced back to source evidence or Local Project Truth
  • Has been written into 02-design.md