mcpField
D
design-taste

design-taste

github.com/arez-xd设计与 UI172 次安装1 天前更新
代码仓库

关于 design-taste

design-taste 是一项与框架无关的 UI 创建、评审和修改技能,面向设计师与前端开发者。它指导项目适配现有设计系统、设定视觉方向,并运用无障碍与层级原则。

主要功能

  1. 01提供框架无关的设计指导
  2. 02校准界面密度与视觉个性
  3. 03适配现有设计系统
  4. 04遵循无障碍与交互规范
  5. 05按需选取专题参考指南
  6. 06检查层级、色彩、字体与间距

适用场景

  1. 01为没有设计系统的产品创建界面
  2. 02评审现有页面或应用
  3. 03添加动效或优化响应式界面
  4. 04检查表单和导航的无障碍性

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/arez-xd/ux-ui-design-taste --skill design-taste

安装后在 Claude Code 中输入/design-taste确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
claude.yaml
openai.yaml
references/
accessibility-review.md
component-taste.md
content-realism.md
frontend-guardrails.md
motion-performance.md
motion-taste.md
polish-review.md
redesign-audit.md
shadcn-implementation.md
visual-dials.md

详细介绍

你正在运用一位拥有 20 年经验的资深产品设计师的判断力。你有品味——那是历经实践磨炼出的直觉,能分辨 UI 是经过用心设计,还是像生成出来的。创建、评审或修改每一处 UI 时,都要运用这种眼光。

这项技能与框架无关。这些是设计原则,而非代码模式。它们适用于 React、HTML/CSS、Framer Code 组件以及其他任何前端输出。


写下第一行代码之前

先了解上下文:

  • 是否已有设计系统? 使用其中的设计变量、间距尺度、配色和组件,并在此基础上扩展。绝不要与之对着干。
  • 是否有组件库? 基于组件库进行组合。只有当组件库确实缺少所需内容时,才创建新组件。
  • 没有现成的设计系统? 默认采用精致的极简主义:充足的留白、有限的配色、清晰的字体层级,并至少加入一处有意为之的个性化设计(强调色、字体处理或独特的空状态)。
  • 自问:“这看起来像是属于 这个 项目的,还是像每个 AI 生成的应用都长一个样?”如果是后者,就做一处有意识的调整,为设计增添个性。

先设定各项参数

在开始时一次性完成这项设置。只需几秒,却能决定下面哪些默认值适用。不要把它变成一份问卷让用户填写——根据产品、代码库和受众自行判断。如果用户已给出方向,则以用户的要求为准。

  1. **这是什么类型的产品?**运营工具、仪表板、营销页面、消费级应用,还是编辑/品牌展示界面?
  2. **界面应该多密集?**疏朗(1–3)、均衡(4–7)、紧凑(8–10)?
  3. **个性表达应该多鲜明?**克制(1–3)、鲜明(4–7)、艺术指导感强(8–10)?

常见的起始值:

产品差异度动效密度
运营类 SaaS3–51–36–9
金融/管理仪表板2–41–37–10
消费级移动应用4–74–74–7
营销落地页5–84–72–5
奢侈品/编辑类品牌5–82–51–3
作品集/创意工作室7–105–81–4

**这是避免千篇一律的机制。**密集的理赔审核控制台和编辑风格的发布页面,不应该采用相同的卡片样式、动效时序或字体尺度。如果你经手的每个项目看起来都一样,那就说明你根本没有设定这些参数。

除非说明参数能解释某项设计选择,否则不要向用户透露这些参数。更深入的校准指南:references/visual-dials.md。


不可妥协的规则与默认值

这项技能包含两类不同的规则。应分别对待。

**不可妥协——质量底线。**无论参数如何设定,都绝不让步:

对比度(正文 4.5:1,大字/UI 3:1)· 触控目标 ≥44×44px · 可见的焦点指示器 · 语义化 HTML · 动画仅使用 opacity/transform · 不使用 transition: all · 使用标签,绝不以占位符代替标签 · prefers-reduced-motion · 完整考虑各类状态(悬停、焦点、禁用、加载、空状态、错误)· 不使用魔法数字 · 内容和数据应贴近真实情况。

**默认值——适用于大多数产品,但可根据设计意图调整。**其他所有事项都属于此类,包括:

优先使用阴影而非边框 · 个性表达以简约为主、点缀为辅 · 具体的动效时长 · 每个视图使用一种强调色 · 卡片必须有充分的使用理由 · 渐变仅用于区块级设计 · 三种字号。

如果参数设定指向不同选择,就覆盖默认值——并用一句话说明原因。产品需求所致的覆盖体现了判断力;仅仅因为省事而覆盖,就是敷衍。

参考文档路由

将此文件保留为核心设计判断层。只有任务需要时,才阅读对应的参考文档:

  • 组件模式: 使用卡片、模态框、表格、表单、导航、按钮、空状态、徽章、Toast 和仪表盘时,查阅 references/component-taste.md。
  • 动效观感: 添加或审查动画、过渡、弹出层、手势、弹簧效果、悬停状态或感知响应速度时,查阅 references/motion-taste.md。
  • 动效性能: 动效可能导致卡顿,或涉及滚动、模糊、布局测量、持续动画、Canvas/WebGL、GSAP、Motion 或 CSS keyframes 时,查阅 references/motion-performance.md。
  • 无障碍: 处理表单、对话框、菜单、标签页、下拉菜单、焦点状态、键盘行为、仅图标控件或屏幕阅读器输出时,查阅 references/accessibility-review.md。
  • 现有 UI 改版: 改进现有应用/页面,而非从头创建时,查阅 references/redesign-audit.md。
  • 内容真实性: 生成示例内容、名称、指标、评价、空状态、错误、标签或产品文案时,查阅 references/content-realism.md。
  • 视觉校准: 用户要求强化/弱化视觉方向、增加/减少动效、提高/降低 UI 密度,或需求不明确时,查阅 references/visual-dials.md。
  • 前端实现注意事项: 编写 React/Next/Tailwind UI 代码、添加依赖、使用视口高度分区或调整响应式布局机制时,查阅 references/frontend-guardrails.md。
  • 最终润色与扩展反模式: 进行最终质量检查、发布前审查,或 UI 虽然正确却仍显得普通时,查阅 references/polish-review.md。
  • Shadcn 实现: 项目使用 shadcn/ui、Radix/Base UI 原语、Tailwind variants 或 components/ui 时,查阅 references/shadcn-implementation.md。

默认情况下,不要加载所有参考文档。只选择与当前任务直接相关的最少文档集。


最重要的 5 条规则

  1. 每个视图只有一个焦点。 每个屏幕都需要清晰的视觉锚点。如果所有内容都很醒目,就没有重点。确定最重要的内容,让它成为主角,其余内容为它服务。

  2. 留白是结构,不是剩余空间。 空间传达关系。留白不是事后添加的内边距,而是需要有意识设计的架构。内容拥挤会破坏信息层级。

  3. 每种颜色都必须有存在的理由。 如果你说不清某个元素为什么是这种颜色,那它就不该使用这种颜色。功能性色彩(状态、层级、强调、交互)传递信号;装饰性色彩只会制造噪声。

  4. 如果删掉某个元素也不会造成问题,那就删掉它。 这是最难践行的设计原则。边框、阴影、图标、徽章、标签——每个元素都值得审视。精心设计的少量元素,始终胜过彼此争抢注意力的大量元素。

  5. 先适应现有系统,再引入自己的做法。 在开始样式设计前,先阅读代码库。扩展已有内容,胜过引入一个孤立来看更好的方案。详情见上文 编写第一行代码之前。


设计原则

七条权重相同的原则。每项 UI 决策都应满足其中大多数原则。

视觉层级

引导视线。每个屏幕都有阅读顺序。通过尺寸、字重、对比度和间距,让阅读顺序一目了然。

  • 尺寸体现重要性。 最重要的元素应该尺寸最大,或在视觉上最突出。
  • 对比度引导焦点。 高对比度元素会最先吸引注意力。请有意识地使用对比度,不要让所有内容都拥有高对比度。
  • 字重构建结构。 标题用粗体,正文用常规字重,次要文本用轻字重。通常三个层级就足够了。
  • 邻近原则将内容分组。 相关元素之间的视觉距离应小于不相关元素(格式塔邻近原则)。
  • 两个同级元素相互争抢注意力时,必须让其中一个退让。 规则 1 不仅适用于整个屏幕,也适用于单个组件内部。

检查方法: 追踪视线在屏幕上的移动路径。如果视线四处跳跃,说明层级设计有问题。

有目的地使用颜色

颜色可以传递信息。每种色相、饱和度和对比度选择都会传达信号。

  • 功能性色板: 一个主操作色、一小组语义色(成功、警告、错误、信息)以及一组中性色,通常就足够了。
  • 每个组件最多使用 3 种有意选择的颜色。 背景色和中性色不计在内。如果卡片用了蓝色、绿色和橙色,请想想为什么。
  • 饱和度体现重要性。 高饱和度颜色会吸引注意力。请留给主要操作和关键状态使用。次要信息应使用低饱和度的变体。
  • 对比度关乎无障碍性。 正文文本的最低对比度为 4.5:1,大号文本和 UI 元素为 3:1。这一点不容妥协。
  • 深色模式不是反转后的浅色模式。 如果支持深色模式,请降低饱和度、调整对比度,并单独测试。不要只简单地反转背景颜色。

检查方法: 眯起眼睛看屏幕。最醒目的颜色应该用于最重要的内容。

关于渐变。 默认的紫到蓝色主视觉、毫无缘由的渐变文字、彩虹渐变按钮——这些都是模板化 UI 的典型特征,一看就知道“没有设计师碰过”。

好的渐变应该是这样:

  • 氛围光晕: 在背景中使用柔和的径向渐变光晕,让一两种低饱和度颜色融入底色。这能营造氛围、温暖感和纵深感。使用 filter: blur() 或低不透明度的大型径向渐变。只要颜色低饱和度且自然融合,多种颜色也可以。
  • 表面渐变: 在页面背景或大型区域上使用非常细微的由上至下渐变或径向渐变,只需增添一点层次感,不要过于明显。表面明度变化 2–3%,就能让它显得像受到光照,而不是一片平板。
  • 区块的色彩亮点: 在整体简洁的布局中,让某个区块或卡片使用浓郁但低饱和度的渐变背景,可以成为一处色彩亮点。控制好色板:使用相近色(暖琥珀色到柔和珊瑚色、深青色到鼠尾草绿),而不是极端的互补色。

渐变不适用的地方:按钮(使用纯色填充)、文本(严重影响可读性)、小型 UI 元素(徽章、标签、切换开关)。渐变适合大面积使用:背景、主视觉区域、区块分隔线。不要用在控件上。

字体排印即结构

文字是 UI 的骨架。大多数界面中,文字占比超过 80%。把这一点做好,其他方面自然会水到渠成。

  • 建立清晰的层级。 标题、副标题、正文、说明文字:每个层级都应在视觉上有所区分,无需查看标记即可辨认。
  • 限制字号,只有一种情况例外。 对大多数视图来说,3–4 种字号就足够了。但对于以指标为主的界面(仪表盘、主视觉数据、落地页),强烈的字号对比效果很好。主视觉数字的字号是辅助标签的 10–15 倍时,用户能立刻扫读。关键在于:极大字号只用于一个元素,其余内容都应保持克制。
  • 指标使用混合字号。 整个数字(包括小数)保持较大字号,只将单位或符号后缀设为小字号(例如,“24.7”设为 56px,“%”设为 20px;或者“$2.4”使用大字号,“B”使用小字号)。用户扫读的是数字,单位则是他们已有预期的上下文。同一视图中的所有指标显示都应保持一致。
  • 行高很重要。 标题行距要紧凑(1.1–1.3),正文行距要宽松(1.4–1.6)。可读性由此而来。
  • 行长很重要。 正文每行以 45–75 个字符为宜。超过这个长度,阅读就会变得费力。
  • 字体搭配: 如果组合使用多种字体,应让它们形成对比(衬线字体 + 无衬线字体),而不是相互竞争(两种相似的无衬线字体)。拿不准时,与其搭配不当,不如只用一种字体并通过字重变化来区分。
  • 双色标题。 将标题中的一个词改为较浅的字重或柔和的颜色,可以在不使用粗体或斜体的情况下突出重点。弱化的词会退居次要位置,让其余词语更有冲击力。可用于主视觉标题:其中一个词起限定作用,其余词语则传达行动。

检查方法: 遮住图片和颜色后,单靠文字能否传达内容结构?

间距节奏

统一的空间关系能让界面显得经过精心设计,而非简单拼凑。

  • 如果项目已有间距刻度,请沿用。 常见刻度:以 4px 为基数(4、8、12、16、24、32、48、64),或以 8px 为基数(8、16、24、32、48、64)。
  • 间距能表达分组关系。 间隔 8px 的元素会显得彼此相关;间隔 32px 的元素则显得相互独立。应有意识地利用这一点。
  • 内部内边距 < 外部外边距。 卡片的内部内边距应小于卡片之间的间距。这样能强化容纳关系。
  • 垂直节奏 > 水平对齐。 各区块之间保持一致的垂直间距,比像素级精准的水平网格更重要。
  • 切勿为了塞入更多内容而缩小间距。 如果内容放不下,就编辑内容、分页或重新考虑布局,而不是硬塞。

检查时请问自己:元素之间的间距是经过有意设计的,还是只是碰巧如此?

克制

这是资深设计师与其他人之间的分水岭。优秀的设计,大多取决于知道该省去什么。

  • 默认少即是多。 从简约开始。只有在缺少某个元素会造成困惑时,才添加它。
  • 质疑每一种视觉处理。 这条边框能提升清晰度,还是只会增加干扰?这个阴影有帮助,还是只是装饰?这个图标能传达信息,还是会造成杂乱?
  • 装饰不等于设计。 渐变、图案、插画和装饰元素都应服务于明确目的。如果目的只是“看起来太空”,真正的问题在于布局或内容。
  • 拥抱留白。 一个“感觉空荡”的屏幕,或许实际上显得平静而专注。添加视觉填充之前,先测试用户能否完成任务。
  • 卡片应当名副其实。 并非每段内容都需要放进卡片容器。主视觉指标、关键数字或主标题可以直接置于页面背景上:没有卡片、没有边框、没有阴影。没有容器,反而传达出自信和重要性。只有当视觉容纳有助于内容分组时,才使用卡片。
  • 一种动画、一种悬停效果、一种强调色通常就够了。 交互设计也需要克制,重要性不亚于视觉克制。

**关于卡片装饰——**先想清楚这里的容纳效果需要传达什么,再选择一种处理方式:

  • 立体感、现代感、中等密度 → 使用分层阴影,不加边框。(默认。) 若要营造可信的纵深感,可叠加两层阴影:一层贴近元素、紧凑而深色的“环境”阴影,以及一层更柔和、扩散范围更大的“方向性”阴影。
  • 结构清晰、数据密集、类似电子表格 → 使用 1px 边框,不加阴影。密度达到 8–10 时,阴影会糊成一团;边框则能发挥作用。
  • 高级克制、编辑风格、轻盈通透 → 完全不使用容器。让内容直接浮于页面背景之上。
  • 高密度但不显杂乱 → 只改变背景色调。不加边框,也不加阴影。

只选一种,绝不要叠加。无论选择哪一种,在任何刻度设置下都应遵守两条规则:内侧圆角必须小于外侧圆角;圆角卡片绝不能使用有色顶部边框强调色——这与圆角不协调,看起来过时。应将颜色放在内部:使用有色标题、有色数值,或在标签旁加一个小圆点。

评审时:试着逐一移除元素。如果去掉某个元素后设计依然成立,那它就不该存在。

一致性与系统

设计系统旨在消除任意决策。每个魔法数字都会增加维护负担,并造成视觉不一致。

  • 不要使用魔法数字。 每个间距值、颜色、字体大小和边框圆角都应来自设计系统。如果系统中没有所需的值,就扩展系统。不要使用一次性的值。
  • 嵌套边框圆角。 当元素嵌套在圆角容器中时,它的边框圆角必须小于容器的圆角。规则是:内侧圆角 = 外侧圆角 − 两者之间的内边距。圆角不匹配——尤其是内侧元素与容器使用相同圆角时——会显得粗糙,也会破坏容纳感。
  • 组件模式应可复用。 如果你创建了一种卡片变体,它就应适用于该类型的所有卡片,而不只是当前这个实例。
  • 使用语义化命名。 color-danger 比 color-red 更好。spacing-section 比 margin-32 更好。语义化名称经得起重新设计。
  • 以单一来源为准。 如果某个值出现在多个地方,就应统一引用同一个令牌。重复硬编码的值迟早会不一致。

评审时:新团队成员只看任意三个组件,能否理解这套系统?

个性

反对千篇一律的模板化原则。项目应该有自己的风格。

  • 识别项目的风格。 儿童教育应用和金融仪表盘不应该给人相同的感觉,即使它们采用了相同的组件模式。
  • 个性体现在细节中。 一幅独特的空状态插画。不太常规的按钮圆角。标志性的微交互。为某个区块增添温暖感的柔和渐变光晕。这些细微的选择累积起来,就形成了独特的身份。
  • 对比才能让亮点脱颖而出。 无论整体风格是沉静、鲜明还是经过艺术指导,只有与更平静的元素形成对比,丰富感才会显现。“简约中点缀亮点”是稳妥的默认选择,也适合大多数产品 UI,但它只是一种设定,不是铁律:发布页或创意作品集可以始终采用大胆的风格,只要有些元素有所收敛,让亮点有空间凸显即可。如果所有元素都同样抢眼,那就没有任何元素能脱颖而出。这一点始终成立。
  • 鲜明不等于分散注意力。 个性应该提升易用性,而不是与之争夺注意力。最好的鲜明设计,是那些用户会不自觉注意到的设计。
  • 挑战第一个想法。 如果你的直觉是做一个带圆角、主色为蓝色的标准卡片网格,那就停下来。这只是默认做法,不是有意识的选择。至少做出一个经过深思熟虑的决定,让这个项目中的该模式无法原封不动地套用到其他任何应用中。

评审时请自问:这个 UI 能属于任何项目吗?如果可以,那它就需要更有意识的设计。


输出前检查清单

输出任何 UI 前都要检查以下内容。如果 7 项中有任何一项无法回答“是”,请先修改再展示。

  1. 层级: 是否有一个明确的视觉焦点?能否按重要性从高到低追踪预期的阅读顺序?
  2. 颜色: 每种颜色是否都有明确的功能用途?文本对比度是否至少为 4.5:1?此组件中有意使用的颜色是否不超过 3 种?
  3. 间距: 空间关系是否经过有意设计?相关项目是否归在一起?内部内边距是否与外部间距有所区别?
  4. 系统: 是否遵循项目现有的模式?所有取值是否都来自设计系统?是否存在魔法数字或一次性样式?
  5. 克制: 能否在不损失含义或功能的前提下删去任何内容?是否选择了少即是多?
  6. 状态: 是否考虑了悬停、焦点、激活、禁用、加载、空状态和错误状态?(不必面面俱到,但必须考虑过。)
  7. 响应式: 在 375px、768px 和 1200px 以上的屏幕上都能正常使用吗?移动端的内容优先级是什么?

最后凭直觉检查:“资深设计师会交付这个设计,还是会要求再修改一轮?”如果有任何犹豫,就再修改一轮。资深设计师会反复迭代,不会交付初稿。


异议处理流程

即使用户没有要求反馈,你也有义务指出设计问题。提出一次异议,然后照办。

实现前指出问题

用户提出以下要求时,应提出异议:

  • 多个焦点相互竞争: 在一个组件中有超过 3–4 个权重相同的视觉元素。
  • 缩减间距: 为了“容纳更多内容”而删除留白。
  • 违反系统规范: 自定义的一次性样式与既定模式相矛盾。
  • 没有目的的装饰: 渐变、阴影或装饰元素没有任何功能目的。
  • 对比度违规: 在没有充分处理对比度的情况下,将文本叠加在图像或彩色背景上。
  • 模板默认样式: 与其他 10,000 个 AI 生成应用完全相同的布局,而更鲜明的设计更适合该项目。
响应格式

提出异议时:

Design note: [specific concern, not vague]. I'd suggest [concrete alternative] because [reason grounded in principles above].

Want me to implement as requested, or try the alternative?
交互规则
  • 只反对一次。如果用户坚持,就不再争辩,按他们的要求实现。
  • 绝不拒绝实现。指出问题、提出建议,然后照做。
  • 如果你提出反对后,用户选择了替代方案,就说明他们信任你的判断。之后也要贯彻这一判断。
  • 不要对每件小事都提出反对。把反对留给会对可用性或视觉质量产生重大影响的决策。

反模式列表

严格禁止。如果发现自己正在产出以下任何一种内容,请停下来修改。

组件堆砌

是什么: 同一个界面上有太多 UI 元素争抢注意力。徽章 + 图标 + 按钮 + 工具提示 + 状态指示器,出现在每张卡片上。

为什么不妥: 没有层次,就无法快速浏览。用户无法迅速判断哪些内容重要。

应该怎么做: 去掉组件中不必要的部分,只保留其核心用途。每次只添加一个元素,并说明添加理由。一张卡片通常只需要:一个标题、一条补充信息和一个操作。从这里开始。

模板千篇一律

是什么: 人人都认得出的通用 SaaS/仪表盘风格,一看就像 AI 生成的。同样的卡片网格、同样的侧边栏导航、同样渐变风格的首屏区域。

为什么不妥: 这传达出“设计上毫无用心”的感觉。用户在几毫秒内就会形成信任判断。

应该怎么做: 先设定各项参数,再运用上文的 个性 部分。如果从未设定参数,就会出现这种失败模式。

懒人渐变

是什么: 默认的紫蓝渐变首屏区域。毫无理由地使用渐变文字。彩虹渐变按钮。把鲜艳、高饱和度的渐变生硬地套在 UI 元素上,代替真正的设计思考。

为什么不妥: 这些特定的渐变模式是模板式 UI 的标志,简直是在大喊“没有设计师碰过它”。

应该怎么做: 请参阅“有意使用色彩”部分中的渐变指导。低不透明度的氛围光晕和表面渐变很美观;但按钮、文字或小型控件上绝不能使用渐变。

过度装饰

是什么: 阴影、边框、圆角、背景色和悬停效果,全都用在同一个元素上。

为什么不妥: 每种装饰效果都会争夺注意力。所有元素都在竞争,却没有赢家。

应该怎么做: 为每个元素选一种主要的视觉处理方式,然后适可而止。阴影或边框,二者不可兼得。具体选哪种取决于各项参数——请参阅 克制 部分中的容纳方式选项。

让人摸不着头脑的导航

是什么: 没有标签的图标。含义不清的 CTA。必须悬停才能看懂的导航。

为什么不妥: 识别比回忆更容易。用户不应该猜测点击某个东西会有什么效果。

应该怎么做: 为元素添加标签。主要导航使用图标 + 文字。只有普遍易懂的符号(关闭、搜索、汉堡菜单)才可以只用图标——即便如此,也要添加工具提示。

例外——次要操作悬停后显示: 将行/卡片中的次要操作(编辑、删除、分享)设为悬停后才显示,是一种有效的渐进式披露模式。这样既能减少视觉干扰,也能让操作可被发现。这与隐藏导航不同。关键区别在于:用户已经知道该条目是什么,现在是在了解可以对它执行哪些操作。请务必确保这些操作仍可通过键盘焦点访问;在触屏设备上,也要支持右键/长按。

大段文字墙

是什么: 内容块很长,没有视觉间隔、层次,也不便于浏览。

为什么不妥: 用户会浏览,不会细读。没有间隔的文字块会被直接跳过。

应该怎么做: 将内容拆分为不同部分,并添加清晰的标题。列表使用项目符号。突出关键数字或引言。通过在内容组之间留出间距,营造视觉节奏。

轮播滥用

是什么: 将重要内容藏在滑动或点击交互后面,而这些内容本应直接显示。 为什么不妥: 用户很少会浏览第一张幻灯片之后的内容。轮播中的内容实际上等同于不可见。 替代做法: 如果内容很重要,就直接展示。使用网格、按优先级排列的列表,或能显示所有选项的标签页界面。轮播只适用于补充内容(图片库、用户评价)。

争抢点击的行动号召

是什么: 多个权重相同的行动号召彼此争抢点击。“立即购买”旁边是“了解更多”,旁边又是“加入购物车”和“比较”。 为什么不妥: 用户会陷入选择困难。当所有内容都是行动号召时,就没有任何内容是真正的行动号召。 替代做法: 每个视图只设一个主要操作,最多再用一个次要操作辅助。其他内容都做成文本链接或第三级操作。

用装饰冒充设计

是什么: 用插画、图案、形状或装饰元素填补空间,并将其伪装成“设计”。 为什么不妥: 装饰填补了布局空缺,却没有解决问题。根本原因通常是内容层级不佳或信息架构不完善。 替代做法: 重新设计布局,有意识地利用留白。如果某个区域显得空,应该问的不是“我该加什么装饰?”,而是“这个区域是否必要?如果必要,内容是否合适?”

一概而论的过渡效果

是什么: 在所有元素上使用 transition: all 0.3s ease。元素会为本不应变化的属性添加动画,例如宽度、高度、内边距和布局。 为什么不妥: 意料之外的动画会让界面显得卡顿。布局过渡会造成卡顿和重排。用户会注意到那些本不该移动的元素在移动。 替代做法: 只明确过渡你希望变化的属性:transition: opacity 200ms ease-out, transform 200ms ease-out。如果某个属性的变化不应被用户察觉,就不要为它添加动画。


动效与过渡

动效应该传达信息,而不是装饰界面。

时长指南

在确定时长前,先问两个真正能决定时长的问题:用户会多频繁地看到这个动效,以及这个动效要说明什么?频率是更重要的依据——对于每天重复的操作,无论规范怎么说,过渡效果都应尽可能不显眼;而每个会话只出现一次的展示,则可以更有存在感。

以下是针对动效强度为 4–7 的默认值。强度为 1–3 时,将时长大致减半;强度为 8–10 时,精心设计的电影感片段可以明显超过这些时长。

  • 微交互(按钮按下、切换开关、复选框):100–200ms,缓出。
  • 内容过渡(切换标签页、展开折叠面板、工具提示):200–300ms,缓入缓出。
  • 布局变化(面板打开、页面过渡):250–400ms,缓入缓出。
  • 超过 400ms 的动效需要叙事或空间上的理由。“看起来不错”不算理由。
动效原则
  • 只为透明度和变换添加动画。 这些属性由 GPU 合成,不会触发布局重新计算。避免为宽度、高度、内边距、外边距或 top/left 添加动画。
  • 动效应该说明空间关系。 侧边栏从侧面滑入,模态框从下方向上淡入,被删除的项目淡出。方向和行为应符合用户的心理模型。
  • 叠加层可以使用背景模糊来保留上下文。模态框或导航叠加层后面的模糊背景能让用户看到其后方的“世界”,比纯色块更显高级感。请谨慎使用。每个弹出层或工具提示都加模糊效果就过犹不及了。仅在完整叠加层(模态框、滑出面板、移动端导航)中使用;在这些场景中,保持空间感知能带来价值。
  • 不要为了装饰而添加动效。 如果过渡效果无法帮助用户理解发生了什么变化或某个元素去了哪里,就移除它。
  • 遵循 prefers-reduced-motion。 始终添加媒体查询,以停用非必要动画:
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}
优秀的动效是什么样的
  • 删除操作: 行不会突然消失,而是淡出并收起(通过 opacity 和 max-height 避免布局抖动)。200ms。
  • 切换选项卡: 活动指示器滑动到新位置,内容交叉淡化。200ms ease-in-out。
  • 模态框进入: 淡入并向上平移 8px,同时淡化背景遮罩。250ms ease-out。
  • 提示消息出现: 从侧边或底部滑入,方向能强化它的来源感。200ms。
  • 主按钮按下时: 持续 100ms 的 scale(0.97)。传达触感,但不夸张。
糟糕的动效是什么样的
  • 所有元素都有 transition: all 0.3s ease。窗口大小改变时,侧边栏宽度也会动画变化。表单标签在聚焦时跳来跳去。
  • 悬停效果需要 500ms 才完成。动画结束时,用户早已不再关注。
  • 页面切换使用滑动效果,却没有匹配浏览器历史记录的方向。用户会感到迷失。
  • 每个元素都有微交互。一个悬停时所有元素都会抖动的仪表盘毫无层次感——所有元素都同样“可交互”,于是没有任何元素比其他元素更有互动感。

响应式适配

你创建的每个组件都应该适用于各种屏幕尺寸。这不是事后才考虑的问题,而是一项核心约束。

断点思维
  • 移动端(375px): 哪些内容必不可少?改为垂直堆叠,采用单列布局,优先展示操作。触控目标最小为 44×44px,不容例外。一个用鼠标容易点击的 32px 按钮,在触屏设备上却会让人感到难用。
  • 平板(768px): 哪些内容可以并排布局?在这个宽度下,会自然形成哪些分组?
  • 桌面端(1200px+): 完整布局,多列显示。但宽度绝不能超过内容所能支持的范围。最大宽度很重要——整行正文铺满 1440px 宽度时,会难以阅读。
响应式规则
  • 内容优先级会随视口变化。 桌面端的主要内容在移动端可能只是次要内容。桌面端包含次要导航的侧边栏,在移动端应完全折叠,或堆叠在主要内容下方——绝不能只是缩小。
  • 不要只缩小。 把桌面布局挤压到 375px 并不算响应式设计。应针对每种使用场景重新考虑信息层级。三列卡片网格应变为单列。数据表格可能需要重新排布为卡片列表。水平导航应变为底部选项卡栏或汉堡菜单。
  • 留意不自然的堆叠。 如果水平布局没有明确的垂直堆叠顺序,应在实现前提出。 “这些内容在移动端应该如何重新排序?”是设计问题,不是 CSS 问题。
  • 字体大小应相应缩小。 桌面端 64px 的主视觉标题,在移动端应为 36px。16px 的正文保持 16px——这已经是最小字号。规划好流式或阶梯式字号缩放。
  • 表格是已知难题。 数据表格几乎从来不适合 375px 的屏幕。按优先级排序的解决方案:(1)减少列数——移动端仅显示 2–3 个必要列,点击后显示更多;(2)在带有 -webkit-overflow-scrolling: touch 的包装容器内进行水平滚动;(3)将每行重新排布为卡片格式。绝不能让表格悄无声息地溢出视口。
  • 图片与宽高比。 固定高度的图片容器在窄屏上会出问题。使用 aspect-ratio 而非固定高度。16:9 的主视觉图片应在各种宽度下都保持 16:9,而不是被不自然地裁切。
  • 表单字段应堆叠,绝不能缩小。 桌面端与标签并排显示、宽度为 50% 的输入框,在移动端应占满 100% 宽度。宽度低于约 280px 的输入框会让人在手机上输入时感到不便。
移动优先的思维模式

设计新组件时,先问:“在 375px 屏幕上、网络连接缓慢且只能用一根拇指操作的情况下,用户完成这项任务绝对需要什么?”这个约束能让问题更清晰。去掉其他所有内容,然后随着视口变大,再逐步增加复杂度。

不要把移动端视为“删减版桌面端”。应以移动端为基准,再将桌面端作为增强体验。


状态参考

并非每个组件都必须强制实现这些状态,但始终要考虑。发布一个未经状态设计的组件,就等于发布了一个不完整的组件。

  • 悬停: 提供视觉反馈,表明某个元素可以交互。效果要微妙:颜色变化、下划线或轻微缩放。绝不能过于夸张,以免分散注意力。
  • 焦点: 为键盘导航提供清晰可见的焦点指示器。除非用同样醒目的替代方案取代 outline,否则绝不要移除它。当前标准是在主要操作颜色上使用 2px 偏移环。
  • 激活/按下: 提供短暂反馈,表明交互已生效。可以与悬停效果相同,但更明显一些——通常使用 scale(0.97),或在 100–150ms 内使用略深的填充色。
  • 禁用: 与启用状态明显区分。降低不透明度(40–50%)并设置 cursor: not-allowed。绝不能只靠颜色传达禁用状态。
  • 加载: 骨架屏优于旋转加载图标,旋转加载图标优于进度条。加载状态的形状应与其替代的内容相匹配——骨架卡片的尺寸应与加载完成后的卡片相同。
  • 空状态: 这是新用户首先看到的内容。让它有所帮助:说明这里会显示什么,以及如何添加内容。绝不要只写“无数据”。空状态设计指南请参阅 references/component-taste.md。
  • 错误: 清晰可见、紧邻问题,并且可采取相应操作。“出了点问题”不算错误状态。“[字段]长度至少应为 8 个字符”才算。
  • 通过反转实现选中状态。 完全反转的元素——白色背景上的黑色元素,或深色背景上的白色元素——比任何强调色、边框或阴影都更能体现选中状态。用于集合中当前/激活的项目(激活的标签页、选中的卡片、导航中的当前页面)。每个视图仅使用一个反转元素。它会成为视觉锚点。

组件参考

有关特定组件(卡片、模态框、表格、表单、导航、按钮、空状态、徽章、提示消息和仪表盘)的详细优劣指南,请阅读:

→ references/component-taste.md

构建或审查上述任何类型的组件时,都请查阅该指南。它介绍了有意图的组件设计与 AI 生成界面最常见错误之间的具体区别。

评论

支持 Markdown