产品界面设计

为仪表盘、后台、SaaS 应用、工具、设置页、数据界面和交互产品做有明确取舍的设计。目标不是“整齐、现代、组件齐全”，而是让界面从这个人、这个任务、这个产品世界里长出来。

本 skill 以 Dammyjay93/interface-design 当前主分支为骨架，保留其 craft-first、visual hierarchy、anti-default、self-contained 的结构，只增加一层非处方性的产品任务推理。不要把常见后台能力当成默认骨架：搜索、筛选、表格、批量操作、侧栏、分页、保存视图都必须有任务依据。

范围

适用： 仪表盘、后台、SaaS、专业工具、设置页、数据界面、交互产品。

不适用： 营销页、落地页、活动页、纯品牌设计；这些任务使用对应营销或品牌能力。

本文件自包含主要设计纪律。专项评审读取 references/design-review.md；快速去模板化读取 references/design-deslop.md。

问题：模型天然会回到默认模板

模型见过大量仪表盘和 SaaS，模式先验非常强。即使写了“有产品感”“像 Linear”“不要 AI 味”，仍然很容易生成：左侧栏、顶部标题、几张 KPI 卡、搜索、筛选、表格、统一圆角和一个蓝色强调色。

根因不是组件做错，而是没有真正做决定。意图停留在文字里，代码生成却被高频模式牵走。

标准： 如果把相似提示交给另一个模型，会得到大体相同的结构和视觉，说明仍由公共默认值驱动。差异不应为了不同而不同，而应来自具体使用者、任务、信息和产品世界。

默认值藏在哪里

默认方案常伪装成“基础设施”：

• 字体不是内容容器。字重、标签性格和段落纹理在文字被读懂前就建立产品气质。
• 导航不是脚手架。它表达当前位置、可达区域和优先级；但不要因为“后台通常有侧栏”就添加侧栏。
• 数据不是把数字放上屏幕。相同数据可以被表达成数值、趋势、比较、状态、时间序列或直接不突出；表达方式必须服务判断。
• 能力不是后台标配。Search、Filter、Saved View、Table、Batch Action、Pagination 都是解决特定问题的手段，不是页面类型自带槽位。
• Token不是装饰性命名游戏。语义、可维护性和产品气质都重要；不要为了“有个性”牺牲清晰的 token 层级。

没有“只是结构”的决定。只要无法回答“为什么这里需要它”，就可能是默认值。

Intent First：先定意图

动代码前形成一份紧凑工作简报：

• 谁在使用？ 不是抽象的“用户”，而是具体的人、环境和上下文。他们五分钟前在做什么，五分钟后要做什么？
• 必须完成什么？ 用动词表达核心任务，例如批改提交、定位故障部署、批准付款、处理异常、调整权限。
• 应该有什么感觉？ 使用能指导取舍的词，如“像工作台一样紧凑”“像阅读器一样安静”“像终端一样直接”，不要写“简洁现代”。

上下文不足时只问一个真正影响方向的问题；能够负责任地推断时，说明假设后继续。

意图必须贯穿布局、信息密度、文字、颜色、表面、状态和动效。对每个重要决定都能回答“为什么”。“常见”“后台都这样”“组件库里有”都不是理由。

Product Reasoning：在画界面前理解工作

这一层只负责提出问题并约束选择，不预设最终组件。不要把问题的示例答案直接实现成界面。

在复杂产品界面中，至少在内部回答以下问题：

1. Working set — 当前工作集合是什么？ 用户面对一个对象、十几个待办、几千条记录，还是持续变化的数据流？集合大小、变化速度和重复访问频率会改变整个界面。
2. Locate — 用户如何找到正确对象？ 他们已知名称/ID 并需要快速定位，还是在浏览、扫描、排队处理、按状态推进或通过关系发现？
3. Judge — 做决定前必须看到什么？ 哪些证据需要并排比较，哪些信息只在深入检查时出现，哪些状态必须始终可见？
4. Act — 用户如何行动？ 是单对象还是多对象？动作频率如何？风险多高？是否可撤销？高频低风险与低频高风险不应共享同一视觉权重。
5. Continue — 操作前后哪些上下文必须保留？ 返回后是否需要保留位置、选中对象、时间范围、展开状态或当前工作范围？
6. Mode — 任务本质更接近什么？ 扫描、比较、分诊、监控、编辑、配置、创建、阅读或调查？界面应优化真实模式，而不是优化“后台长相”。

Capability Gate：能力准入

任何能力都必须有任务证据。不要因为同类软件常见就添加。

• 只有当用户需要从较大集合中定位一个已大致知道身份的对象，且文本/标识查询确实高效时，才考虑 Search。
• 只有当用户需要反复缩小或切分集合，且条件组合对任务有意义时，才考虑 Filter。
• 只有当同一工作范围会被反复恢复或共享时，才考虑 Saved View。
• 只有当用户需要比较多个同类对象，并且列式对齐能提升判断效率时，才考虑 Table。
• 只有当用户确实会对多个对象执行同一动作时，才考虑 Selection / Batch Action。
• 只有当一级区域足够稳定且跨任务频繁切换时，才考虑 Persistent Sidebar。
• 只有当数据加载方式、定位需求和规模使它合理时，才考虑 Pagination / Infinite Scroll / Virtualization；不要把分页当表格配件。

如果一个能力无法指出它解决的具体摩擦，就删除它。

重要： 这里列出的 Search / Filter / Table 等只是反例和准入说明，不是待实现清单。输出设计时不要为了“覆盖能力”而把它们全部放进页面。

产品领域探索

在提出视觉方向前完成四项探索：

• 领域 Domain：至少 5 个来自产品世界的概念、隐喻或词汇，不是功能清单。
• 色彩世界 Color world：至少 5 种在该领域中自然存在的颜色、材质或光线，而不是“暖色/冷色”。
• 标志 Signature：一个只可能属于这个产品的视觉、结构或交互表达。找不到就继续探索。
• 默认方案 Defaults：列出 3 个这个界面最容易落入的视觉或结构套路，并说明为什么不应该自动采用。

检验方式：去掉产品名称后，别人仍应能大致判断它服务的领域；如果只是“另一个 SaaS”，探索还不够具体。

提出方向时可以使用：

领域：      [至少 5 个产品世界概念]
色彩世界：  [至少 5 种领域色彩/材质/光线]
标志：      [该产品特有的表达]
拒绝：      [默认方案 → 有依据的替代，共 3 组]
方向：      [如何连接任务、领域与视觉]

方向昂贵、重大改版或确实不明确时再确认；不要把每次小改动都变成设计访谈。

有视觉能力时就展示

如果会话具有内联渲染、浏览器、截图或图像生成能力，优先让用户看到方向，而不是只读形容词。

适合展示的三个时刻：

1. 方向阶段：展示真实色板、字体层级、表面层级和标志性组件/结构。
2. 组件阶段：展示实际组件或紧凑 before/after，并包含真正重要的状态。
3. 评审阶段：把当前与改进方向放在一起，让差异可见。

视觉样本只展示结果；任务推理、拒绝默认方案和理由留在文字中。视觉参考不能替代真实实现。

视觉层级与构图

生成式 UI 最常见的问题是平：所有东西一样大、一样重、一样挤，眼睛不知道从哪里开始。

一个 primary task，一套明确的注意力策略

不要机械理解成“每屏必须有一个巨大的 hero”。先明确这一屏的 primary task，再决定用户需要单点聚焦还是并行扫描。

• 对单任务页面，让一个主要动作或信息通过尺寸、字重、对比、位置或留白胜出，并同步降级其他内容。
• 对监控、分诊、交易、运营等高密度专业界面，可以存在多个稳定 scanning anchors；它们服务同一个 primary task，而不是互相抢夺注意力。
• 如果所有东西同等强调，层级失败；如果为了制造“焦点”而把一个 KPI 无理由放大，层级同样失败。

字级是比例，字重与颜色优先于微小字号差

选一个比例并保持一致：高密度/安静界面约 1.2，多数产品界面约 1.25，表现力较强时约 1.333。从正文尺度推导，不使用 15/16/17px 这种难辨认的连续微差来伪造层级。

尺寸、字重、颜色共同建立层级。一个 14px 字号也可以形成三层：值 600 / primary，标签 500 / secondary，元数据 400 / muted。动态数字使用 tabular-nums。

密度是任务决定，不是“后台=紧凑”

先决定用户输入方式、任务频率和扫描需求，再确定密度。高频桌面工具可以紧凑；低频高风险流程可能需要更多空间；触控优先界面需要更宽松的交互目标。

同一产品也可以有不同密度区域：控制区紧、阅读区松、编辑区稳定。不要整页一个 padding 值走到底。

空间节奏要有张有弛

相关内容靠近，组与组之间留出明显空气。卡片尺寸、gap 和密度从头到尾完全一样，是最明显的生成式痕迹之一。

比例表达关系

280px 侧栏和 360px 侧栏传递不同的主次关系；但例子不是要求使用侧栏。任何宽度、分栏和内容最大宽度都应说明它在表达什么关系。

色彩克制

可把约 60/30/10 当作经验性分配，而不是硬指标：大部分屏幕承担结构，少量区域承担身份/状态/动作。一个有意图的强调色通常优于多个无意义强调色。

优先用空间、字重和轻微色调分层，再考虑边框与分割线。

Craft Foundations

轻微分层

表面层级应该“感觉得到但不抢眼”。暗色模式可通过同一色相的轻微亮度变化与低透明边界建立层级；亮色模式可使用非常轻的阴影或色差。

• 侧栏如果存在，不要默认做成另一个强对比世界；是否同底色取决于信息关系和品牌方向，但分隔强度必须克制。
• 下拉、popover、菜单等浮层应与父表面有可感知层级。
• 输入区需要明确“可编辑/可接收内容”，但不要把“输入一定更暗”当硬规则；以整体方向和可辨识性为准。
• 边框应该在需要时找得到，不应成为页面第一视觉信息。

执行眯眼测试：模糊视线后仍能读出结构和注意力分布，同时没有边线或表面突兀跳出。

Infinite Expression：同一问题有无限表达

一个 metric 可以是 hero number、inline stat、sparkline、comparison delta、progress、状态摘要，也可能根本不值得单独成卡。

同样地，“定位对象”可以通过搜索、导航、队列、最近访问、关系图、命令入口或上下文本身完成。不要把概念和某个 UI 组件绑定。

如果每个项目都出现同宽侧栏、相同卡片网格、图标+大数字+小标签、顶部搜索条，那么即使颜色不同，仍然是模板。

Color lives somewhere

产品存在于某个世界。去想那个世界里的材料、光线、对象和环境；色板应该像从那里长出来，而不是后贴上去。温度只是一个轴，还要判断安静/响亮、精密/柔和、几何/有机、稠密/宽松。

写每个非平凡组件前的内部检查

只在内部完成，不向用户倾倒长篇设计独白：

Intent:      [谁、什么任务、什么感觉]
Task:        [当前工作集合、判断依据、动作风险/频率]
Capability:  [为什么需要这些能力；哪些常见能力明确不需要]
Hierarchy:   [primary task；单点焦点或 scanning anchors]
Palette:     [颜色来自哪里，为什么]
Depth:       [深度策略及理由]
Surfaces:    [表面层级及理由]
Typography:  [字体 + 尺寸/字重/颜色杠杆]
Spacing:     [基础单位 + 密度依据]

如果无法解释某个新增控件为什么存在，不要加。

复用项目已有能力

控件：原生 → 成熟 primitive → 自行实现

1. 原生 HTML 能满足时直接使用 <button>、<a>、<input>、<dialog>、<details> 等，不用 <div onClick> 伪装语义控件。
2. select、combobox、dialog、popover、tooltip、dropdown、tabs、date picker 等复杂状态控件，优先使用项目已有组件或成熟 headless primitive，如 Radix UI、React Aria、Ark、Headless UI、Vaul、cmdk。
3. 只有没有合适原语或依赖预算明确禁止时才自行实现，并补齐键盘、焦点、ARIA、关闭和滚动行为。

样式：系统 → 组件 → token → utility

1. 先复用现有设计系统、组件和 variant，遵循项目已有 Tailwind、CSS Modules 或 CSS-in-JS 约定。
2. 样式元素第二次真实复用时再提取组件/variant，不要提前抽象，也不要复制长 className。
3. 使用语义 token，而不是随机 hex 或项目已有 token 能覆盖时仍硬编码颜色。
4. 产品化 token 推荐三层：primitive → semantic → component。例如 slate-900 → --text-primary → --table-cell-value。领域气质不等于把每个 token 都改成诗意名称。
5. inline utility 只用于真正的一次性布局调整。

设计系统基础

• 颜色 token：映射到少量 primitive 与 semantic：前景、背景、边界、品牌、破坏性、警告、成功等。
• 文字层级：至少 primary、secondary、tertiary、muted 四层，对应主要、辅助、元数据、弱化/禁用。
• 间距：选择稳定基数（常见为 4px 或 8px），微间距、组件内、区块间、大区间距都从尺度派生；内容需要时可有经过解释的例外。
• 内边距：默认保持规律；不要为了“规则正确”强行对称，内容结构有理由时可以不对称。
• 深度：优先选一个主要策略并贯彻，避免无理由混用重边框和重阴影。
• 圆角：建立尺度；嵌套元素关注视觉同心，而不是机械套公式。
• 控件 token：输入、选择、复选等可独立调整，不必和普通 surface 共用所有 token。
• 暗色模式：弱化语义色饱和度，更多依靠边界/表面亮度而非深色阴影。

Polish & Motion Essentials

静态细节

• 动态数字使用 font-variant-numeric: tabular-nums。
• 几何居中不等于视觉居中；图标、播放三角等需要光学校正时微调。
• 每个交互元素至少考虑 default、hover、active、focus、disabled；数据界面考虑 loading、empty、error。只实现与当前功能真实相关的状态，不为了清单添加不存在的功能。
• 点击目标按输入环境和可访问性决定。 WCAG 2.2 AA 2.5.8 的最低目标是 24×24 CSS px 或满足其间距等例外；44×44 CSS px 属于更高的增强目标。密集桌面工具可以使用较小的可见控件，但要确保可操作区域、间距和误触风险合理；触控优先界面通常应接近或达到 44px。
• 抬升元素优先用克制的透明阴影/色差；真实边框留给需要明确边界的位置。
• 标题可用 text-wrap: balance，正文/说明可用 text-wrap: pretty；字体平滑按项目/平台需要使用，不把某个平台 hack 当跨平台硬规则。

动效

• 高频重复操作尽量不动画；偶发 modal/drawer/toast 可以有标准动画；稀有时刻才增加表现力。
• 常规 UI 动画通常低于 300ms；大型 modal/drawer 可更长，但不能拖慢任务。
• 进入/反馈偏 ease-out；避免让用户等待的 ease-in。
• 按压缩放是可选手段，不是按钮标配；如果使用，一般不低于 scale(0.95)。
• 出现不要从 scale(0) 开始。
• popover 动效可从触发方向展开；模态保持稳定居中。
• 优先动画 transform 和 opacity，避免无必要的 layout animation；不要 transition: all。
• 遵守 prefers-reduced-motion。

避免

• 强边框成为第一视觉信息
• 戏剧性的表面亮度跳变
• 平坦层级或所有东西都高优先级
• 为了“一个焦点”无理由制造巨大 hero KPI
• 从头到尾完全相同的卡片、gap 和密度
• 混乱的 spacing 和 depth
• 缺失真实需要的状态
• 大阴影、大圆角和装饰性渐变成为默认审美
• 多个没有语义的强调色
• 默认字体 + 只靠字号建立层级
• 负 margin 抵消父 padding、逃生式 calc()、为绕开正常布局流而 absolute positioning
• 后台组件 bingo：因为是后台就自动加入 Search、Filter、Table、Sidebar、Batch、Pagination
• 模式库反客为主：先选 archetype 再找理由，而不是从任务推导结构

Workflow

沟通

不要宣布模式或长篇旁白。把推理压缩成有助于用户决策的结论。

执行纪律

1. 检查现有应用、设计 token、组件模式和 .product-interface-design/system.md。
2. 形成 Intent；对非平凡工作完成 Product Reasoning，尤其明确“哪些常见能力不需要”。
3. 完成领域、色彩世界、标志和默认方案探索，再决定布局、颜色、字体、密度和导航。
4. 绿地界面、重大改版或方向模糊时，如有图像生成能力，可以生成方向板/UI reference/paintover；它们只提供视觉参考，不替代真实实现。
5. 使用项目已有组件/原语完成实现；运行相关 build、typecheck、tests。
6. 对非平凡 UI 做视觉验证；修复重叠、断裂间距、不可读文字、错误状态和泛化构图。
7. 再做一次 capability audit：逐个看 Search、Filter、Sidebar、Table、Batch、Saved View、Pagination 等是否真有任务依据；没有就删。

Build flow

• 存在 .product-interface-design/system.md： 读取并复用已经确定的视觉与组件决策，但新的产品能力仍需任务依据；system.md 不能证明一个新 Search 或 Filter 合理。
• 不存在： Intent → Product Reasoning → Domain Exploration → 方向 → 必要时确认 → Build → Checks → 可选保存。

交付前检查

• Swap test：换成常用字体和标准 SaaS 布局，结果是否几乎不变？不变之处仍是默认设计。
• Squint test：模糊视线后，注意力结构是否仍清楚，同时没有刺眼边界？
• Signature test：至少指出 5 个具体位置体现产品特有表达；“整体感觉”不算。
• Capability test：每个 Search / Filter / Table / Sidebar / Batch 等能力都能回答它解决的具体摩擦吗？不能就删除。
• Task test：用户完成 primary task 的路径是否比“看起来像成熟后台”更优先？
• State test：真实存在的交互和数据状态是否完整？
• Reuse test：是否复用了项目已有组件、token 和 accessible primitive？

任一关键检查失败就继续迭代，再展示结果。

完成任务后

可以询问是否把稳定模式保存到 .product-interface-design/system.md。只有用户同意后才写入。

保存内容只包括已经形成稳定决策的内容：

• 方向与感觉
• 主要深度策略和 spacing 基数
• 字级比例、密度和注意力模式
• 使用两次以上或真正值得复用的组件模式
• 对后续实现有价值的产品任务约束，例如“审核队列按顺序处理，不提供页面级搜索”
• 视觉参考、比例与 signature

不要把一次性页面布局、临时筛选条件或未验证假设固化成设计系统。

专项模式

• 设计评审：读取 references/design-review.md。默认只报告问题，不改代码；用户明确要求修复时再实施。
• 去模板化：读取 references/design-deslop.md。保持业务行为不变，只清理明确的生成式视觉痕迹。
• 状态 / 漂移 / 模式提取：自然语言处理即可。读取 system.md 总结状态；对照它检查漂移；扫描重复值时只提出候选，不因为“出现次数多”就认定为正确设计。