Back to Details

visual-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
You decide how a screen looks: colour, type, spacing, surfaces, actions, icons, and imagery. A good-looking product is mostly a consistent one. It picks one visual direction, writes it down as tokens, and applies it everywhere. These rules are strong defaults, not laws. A product with a reason to differ keeps that reason.
你负责决定一个屏幕看起来是什么样：颜色、字体、间距、表面层、操作、图标和图像。好看的产品在很大程度上依赖一致性。它会选择一种视觉方向，将其记录为 token，并在各处统一应用。这些规则是强有力的默认值，而不是不可违背的法则。如果产品有充分理由存在差异，就应保留这种差异。

1. Choose the Mode

1. 选择模式

Infer the mode from the request without asking.
  • Build: the task creates or restyles UI. Apply the rules while writing the code. Do not narrate them: name a rule only when it changed a choice, in one line (e.g. "accent kept to the primary button and the selected day — colour"). Produce no report.
  • Audit: the user asks for a visual review or critique, asks why a UI looks off, cheap, generic, or inconsistent, or shares screenshots or mockups for feedback. Produce the report in Step 6.
Requests to make an app "look premium", "look modern", or "pop" are usually hierarchy, consistency, or type problems, not palette problems. Check 
rules/hierarchy.md
, 
rules/surfaces.md
, and 
rules/typography.md
before proposing new colours.
根据请求推断模式，不要询问。
  • 构建（Build）：任务要求创建 UI 或重新设计 UI 的视觉样式。编写代码时应用这些规则。不要逐条讲解：只有当某条规则改变了某个选择时，才用一行提一下该规则（例如：“强调色仅保留给主按钮和选中的日期——颜色”）。不要生成报告。
  • 审查（Audit）：用户要求进行视觉审查或点评，询问某个 UI 看起来不对劲、廉价、千篇一律或不一致，或分享截图或模型图以获取反馈。按照步骤 6 生成报告。
要求应用“看起来高端”“看起来现代”或“更醒目”时，问题通常是层级、一致性或字体排版问题，而不是调色板问题。提出新颜色之前，先检查 
rules/hierarchy.md
、
rules/surfaces.md
和 
rules/typography.md
。

2. Find the Platform and the Existing System

2. 确定平台和现有系统

Read the manifest as prose, then load only the matching guide:
PlatformSignalGuide
Web / SaaSA web framework in 
package.json
(Next.js, Vite, Remix, Astro, Nuxt, SvelteKit, …), or plain HTML/CSS
references/web.md
React Native / Expo
expo
or 
react-native
in 
package.json
references/cross-platform.md
Apple platforms
*.xcodeproj
, or 
Package.swift
with an app target
references/apple.md
Android (Compose)Compose in 
build.gradle(.kts)
references/android.md
React Native/Expo also loads 
references/apple.md
or 
references/android.md
when the work touches system chrome on that OS (tab bars, sheets, materials). Expo web output also loads 
references/web.md
. Flutter and other cross-platform stacks use 
references/cross-platform.md
.
Then look for a design system already in place:
  • Token or theme files, CSS custom properties, or a Tailwind theme
  • A component library (shadcn/ui, HeroUI, MUI, Chakra, Tamagui, NativeWind)
  • Colour sets in an asset catalog, or a 
    MaterialTheme
  • A design document (
    DESIGN.md
    , a style guide, or brand guidelines)
An existing system wins. Use its tokens and components, and apply the rules only where it says nothing. When the user asks for a redesign, propose updating the design document first, so later work does not follow the old rules.
先阅读 manifest 并理解其上下文，然后仅加载匹配的指南：
平台判断信号指南
Web / SaaS
package.json
中有 Web 框架（Next.js、Vite、Remix、Astro、Nuxt、SvelteKit 等），或使用纯 HTML/CSS
references/web.md
React Native / Expo
package.json
中有 
expo
或 
react-native
references/cross-platform.md
Apple 平台存在 
*.xcodeproj
，或 
Package.swift
中包含 app target
references/apple.md
Android（Compose）
build.gradle(.kts)
中使用 Compose
references/android.md
当 React Native/Expo 的工作涉及相应操作系统中的系统界面框架（system chrome，如标签栏、面板、材质）时，还需加载 
references/apple.md
或 
references/android.md
。Expo Web 输出还需加载 
references/web.md
。Flutter 和其他跨平台技术栈使用 
references/cross-platform.md
。
然后查找项目中已有的设计系统：
  • Token 或主题文件、CSS 自定义属性，或 Tailwind 主题
  • 组件库（shadcn/ui、HeroUI、MUI、Chakra、Tamagui、NativeWind）
  • 资源目录（asset catalog）中的颜色集，或 
    MaterialTheme
  • 设计文档（
    DESIGN.md
    、样式指南或品牌规范）
现有系统优先。 使用它已有的 token 和组件，仅在这些内容未作规定的地方应用规则。当用户要求重新设计时，应先建议更新设计文档，避免后续工作继续遵循旧规则。

3. Settle a Direction (New Products or Redesigns)

3. 确定方向（新产品或重新设计）

Choose one direction before the first screen. Mixing directions is the most common reason a UI looks unconsidered.
DirectionNeutralsAccentTypeImageryDepth
RestrainedNear-white or near-black, barely tintedOne, on two or three elements per screenOne sans; large tabular numbersNone; the data is the heroLayering and blur, few cards
Product showcaseTinted toward the accentOne, plus a dark ink buttonHeavy sans headline, one accented wordReal interface pieces, rotated and overlappingLarge radii, soft shadows
Character-ledWarm paperTwo to four soft tints, each with a meaningFriendly or rounded sans, handwritten notesOne mascot with a pose per stateFlat, almost no shadow
EditorialPaper or creamOne or two, mutedDisplay serif, italic for emphasisSparse line drawings or photographyAlmost none; type carries it
Pick from what the product does and who uses it: a finance or data tool leans Restrained, a consumer app competing for attention leans Product showcase, a habit or wellbeing app leans Character-led, and a content- or craft-led brand leans Editorial. Then draw the direction from the product's own subject matter (its content, its domain, what it produces) so it does not look like every other app in that direction.
Write the direction down as tokens in the project's own format (
references/
shows how per platform):
  • 4–6 colours: a tinted neutral scale, ink, one accent, and status colours
  • 2–3 type roles: display, body, and numeric or mono if needed
  • Radius, spacing, and shadow scales
  • One imagery mode
Compare options on the real product (
rules/real-screenshots.md
), not on invented mockups.
Showcase screens and daily screens differ in volume. Onboarding, empty states, paywalls, and store assets carry the full direction: oversized headlines, rotated tiles, doodles. Home, lists, and settings use the same tokens more quietly.
设计第一个屏幕之前，先选择一种方向。混用方向是 UI 看起来未经深思熟虑的最常见原因。
方向中性色强调色字体图像深度
克制型接近白色或黑色，几乎不带色调一个强调色，每屏仅用于两三个元素一种无衬线字体，配大号等宽数字不使用图像；让数据成为视觉主角使用层次和模糊效果，卡片很少
产品展示型偏向强调色的色调一个强调色，另加一个深色墨感按钮粗重无衬线标题，其中一个词使用强调色使用真实界面组件，经过旋转并相互叠放大圆角、柔和阴影
角色主导型暖纸色两到四种柔和色调，每种都有明确含义友好或圆润的无衬线字体，搭配手写注释使用一个吉祥物，并为每种状态设置不同姿势扁平，几乎不使用阴影
编辑型纸色或奶油色一到两个低饱和色调展示型衬线字体，以斜体强调稀疏的线稿或摄影图像几乎不使用深度，以字体表现力为主
根据产品的用途和用户群体进行选择：金融或数据工具通常采用克制型；消费级应用需要在竞争中吸引注意力，通常采用产品展示型；习惯养成或健康应用偏向角色主导型；以内容或工艺为核心的品牌则偏向编辑型。然后从产品自身的主题中汲取方向（其内容、领域和产出），这样它就不会看起来像该方向下的每一个其他应用。
使用项目自身的格式记录这一方向（
references/
展示了各平台的写法）：
  • 4–6 种颜色：带轻微色调的中性色阶、墨色、一个强调色和状态色
  • 2–3 个字体角色：展示、正文，以及需要时的数字或等宽字体
  • 圆角、间距和阴影标度
  • 一种图像风格模式
应在真实产品上比较方案（
rules/real-screenshots.md
），而不是在虚构的模型图上比较。
展示型页面和日常页面的视觉分量不同。 引导页、空状态、付费墙和商店素材承载完整的视觉方向：超大标题、旋转图块、涂鸦。首页、列表和设置则更克制地使用同一套 token。

4. Rules

4. 规则

Each rule file has a When building constraint and a When auditing check. Read a rule when the screen involves what its "Applies to" column names.
RuleImpactApplies toFile
HierarchyHIGHevery screen
rules/hierarchy.md
ColourHIGHpalettes, themes, dark mode, any colour choice
rules/color.md
TypographyHIGHheadlines, body text, numbers, font choice
rules/typography.md
Spacing & layoutHIGHlayout, alignment, multi-screen flows
rules/spacing-layout.md
Real screenshotsHIGHcomparing palettes, type, or token changes
rules/real-screenshots.md
SurfacesMEDIUMcards, sheets, tab bars, modals, shadows, radii
rules/surfaces.md
ActionsMEDIUMbuttons, CTAs, selection states
rules/actions.md
ImageryMEDIUMheroes, onboarding, empty states, widgets, store assets
rules/imagery.md
Reference designsMEDIUMwork from shared inspiration, Dribbble or Mobbin shots
rules/reference-designs.md
Generic defaultsMEDIUMfirst impressions, "looks like a template"
rules/generic-defaults.md
IconographyLOWicons, tab bars, toolbars
rules/iconography.md
DecorationLOWdoodles, annotations, emoji, stickers
rules/decoration.md
每条规则文件都有一个构建时约束和一项审查时检查。如果某个屏幕涉及其“适用范围”列所列的内容，就读取该规则。
规则影响程度适用范围文件
层级高每个屏幕
rules/hierarchy.md
颜色高调色板、主题、深色模式及任何颜色选择
rules/color.md
字体排版高标题、正文、数字和字体选择
rules/typography.md
间距与布局高布局、对齐和多屏幕流程
rules/spacing-layout.md
真实截图高比较调色板、字体或 token 变更
rules/real-screenshots.md
表面层中卡片、面板、标签栏、模态框、阴影和圆角
rules/surfaces.md
操作中按钮、CTA 和选择状态
rules/actions.md
图像中主视觉、引导页、空状态、组件和商店素材
rules/imagery.md
参考设计中使用共享灵感、Dribbble 或 Mobbin 截图作为参考
rules/reference-designs.md
模板化默认值中第一印象以及“看起来像模板”的问题
rules/generic-defaults.md
图标设计低图标、标签栏和工具栏
rules/iconography.md
装饰低涂鸦、注释、emoji 和贴纸
rules/decoration.md

5. Build

5. 构建

  • New product or redesign: settle the direction (Step 3), then build each screen with the rules as constraints.
  • Existing UI: match what is there. Use the existing tokens and components, apply the rules to the part being changed, and leave screens nobody asked about alone.
  • 新产品或重新设计：先确定方向（步骤 3），再将规则作为约束构建每个屏幕。
  • 现有 UI：与其保持一致。使用现有 token 和组件，将规则应用于正在修改的部分，不要改动用户未要求修改的屏幕。

6. Audit

6. 审查

  1. Scope: the files, screens, or images named; otherwise every user-facing screen. Screenshots and mockups are valid input: open them with Read.
  2. Identify the direction: name the one the product is aiming for, or the ones it is mixing. Judge every screen against that direction, not against personal taste. Content that depicts other directions on purpose (style guides, theme pickers, mockups or screenshots of other products) is illustration, not mixing: judge the page's own chrome against its direction, and leave the depicted content alone.
  3. Check: compare each screen with the rules whose "Applies to" matches it, plus the platform guide.
  4. Report grouped by impact, HIGH first. Cite a file and line, or the image and the area of the screen:
undefined
  1. 范围：指定的文件、屏幕或图片；如果没有指定，则审查所有面向用户的屏幕。截图和模型图都是有效输入：使用 Read 打开它们。
  2. 确定方向：指出产品正在采用的一个方向，或正在混用的多个方向。根据该方向而非个人审美来判断每个屏幕。刻意展示其他方向的内容（风格指南、主题选择器、模型图或其他产品的截图）属于插图，不是方向混用：应根据页面自身的界面框架对照其方向进行判断，并忽略其中所描绘的内容。
  3. 检查：将该屏幕与适用范围相符的规则及平台指南进行比较。
  4. 报告：按影响程度分组，先列 HIGH。引用文件和行号，或者引用图片及屏幕中的具体区域：
undefined

HIGH — Colour

HIGH — Colour

  • src/screens/Welcome.tsx:24 — blue button, pink badge and green chip compete → keep blue as the accent; move the badge and chip to tinted neutrals

End with the counts per impact. Change nothing in audit mode unless asked; when asked, fix in impact order.
  • src/screens/Welcome.tsx:24 — blue button, pink badge and green chip compete → keep blue as the accent; move the badge and chip to tinted neutrals

最后汇总各影响等级的计数。审查模式下不要做任何更改，除非用户提出要求；收到要求后，按影响程度顺序修复。

Boundaries

边界

  • UX behaviour (what a screen needs, flow order, persuasion, permission timing) belongs to 
    ux-psychology
    . This skill decides how a primary action looks; that one decides whether it should exist.
  • Contrast ratios, text scaling, and colour-only signals belong to the 
    accessibility
    skill when it is installed; apply it alongside this one. This skill never trades legibility for style.
  • Motion (easing, springs, durations) belongs to an animation skill when one is installed.
  • Copy and proofreading are out of scope, apart from casing and length where they affect layout.
  • UX 行为（屏幕需要包含什么、流程顺序、说服机制、权限请求时机）属于 
    ux-psychology
    。此 skill 决定主要操作的外观；另一个 skill 决定它是否应该存在。
  • 对比度数值、文字缩放和仅依赖颜色的信号在安装了 
    accessibility
    skill 时由其负责；应与本 skill 一同应用。本 skill 绝不会为了样式而牺牲可读性。
  • 动效（缓动、弹簧动画、持续时间）属于安装了 animation skill 时由其负责。
  • 文案和校对不在范围内，但影响布局的大小写和长度除外。