design-review

设计原则与评审

此技能依据 Bitwarden 设计团队的行为准则和 30-60-90 成熟度框架提供设计反馈。行为准则和 30/60/90 框架源自 bitwarden/clients 的 designer-agent-skills 分支（由设计团队撰写），没有单独的 Confluence 权威版本——在 Claude 工具中，此技能是权威来源。评审产品，而不是设计师。反馈必须可执行、符合阶段，并以产品目标为依据，而非个人偏好。

跨插件依赖。 此技能会组合使用 content-style-guide（在 60% 和 90% 阶段）和 using-figma（设计位于 Figma 文件中时）。两者都随 bitwarden-design-tools 插件一起提供；该插件需要与 bitwarden-designer 一同安装——请同时安装两个插件，以确保完整组合正常工作。

步骤 1：确定阶段

提供反馈前，先确定（或询问）设计处于哪个阶段。什么样的反馈有用，完全取决于此。

• 30%——粗略构想。 设计师正在探索方向。容易调整或放弃。关注点：想法和印象、是否应该做这件事、方向是否正确、如何推进概念，以及是否继续这个想法。
• 60%——确定概念的初稿。 已投入大量时间；除非有充分理由，否则不应大幅改变方向。关注点：是否处理了 30% 阶段的评审意见、视觉/图形反馈、交互组件反馈，以及扩展概念的方式。
• 90%——开发前的最后检查。 应已由真实用户测试。不应再有大幅改动。关注点：是否处理了 60% 阶段的评审意见、细致的语法问题、文案定稿，以及对细节的最后检查。

如果用户没说阶段，就询问。不要对 30% 的草图挑剔 90% 阶段才会关注的细节，也不要建议对 90% 的设计进行全面方向调整。

步骤 2：评审产品，而不是设计师

好的设计能达成目标。差的设计无法达成目标。喜欢或不喜欢都无关紧要。

• 谈优点，不要只谈缺点。好的评审能给予支持——了解哪些地方有效，有助于决定保留什么。
• 区分喜欢/讨厌与好/坏。 将产品目标置于个人看法之上。
• 提问，不要妄下假设。 如果有不清楚的地方，询问做出某项决定的原因。
• 不要当场试图设计更好的方案。 重点指出当前设计有哪些地方未能实现预期目的。设计师可以在有更多时间时解决这些问题。

表述方式

不要这样说	可以这样说
“你为什么这么做？”	“你希望通过 x 实现什么目标？”
“我不喜欢”	“我不确定 x 是否能让用户清楚地知道他们可以 y”
“我们为什么不直接……”	（略过——不要当场设计方案；改为描述差距）

第 3 步：依据行为准则筛选反馈

Bitwarden 设计团队遵循五项原则。让这些原则指导你标记哪些问题，以及如何提出反馈。

1. 我们主动设计，而非被动应对。 以策略为先，通过规划推动创新、塑造产品未来，而不只是应对需求。营造专注投入的空间，让每位设计师都能深思熟虑、关注细节，并为自己的工作感到自豪。标记那些错失了有意识、着眼未来的设计机会的地方——尤其是在 30% 阶段。

2. 我们以同理心设计，并以洞察加以验证。 通过定期交流、研究和数据，让用户的声音指导决策。让客户成为每场讨论的焦点，帮助产品和工程合作伙伴优先考虑客户。每项发布的功能都应以用户为中心，并经过测试和验证。如果某个设计选择缺乏洞察支持，就将其作为待解答的问题提出——这不是缺陷，而是在 60% 阶段之前值得弥补的信息缺口。

3. 我们自信而谦逊地设计。 信任专业能力，同时保持开放心态，承认自己可能有误。共同应对模糊性，明确决策并继续推进，同时保持开放，随着了解加深而调整方向。即使是细微的迭代，也能将过时的体验转变为真正值得自豪的成果。将反馈视为对共同解决方案的贡献，而非裁决。

4. 我们作为一个团结的团队协作。 与产品和工程团队的协作应顺畅、透明。设计文件应清晰、易于浏览、组织有序，并建立共同理解。以清晰、自信和用心的态度开展工作——信任是基础，并鼓励每个人贡献最佳成果。标记那些会让交接变得棘手的模糊之处。

5. 一年后，我们希望拥有一套让我们自豪地署上姓名的 Bitwarden UI——它赢得数百万人的信任，因为我们以彼此信任为基础进行了设计。反馈应达到这一标准。

第 4 步：结合视觉设计评估内容

在 60% 阶段，尤其是 90% 阶段，应依据 content-style-guide 技能评估用户可见文案（按钮标签、标题、错误消息、空状态、辅助文本等），检查语态、语气、句首大写、不使用与号、链接文本是否有意义、代词是否性别中立、不使用空间方位描述等要求。将内容方面的问题视为首要的评审要点，而非事后才考虑的事项。

在 30% 阶段，不要纠结于内容细节——该阶段关注的是方向，而非文案。

与其他技能组合使用

• content-style-guide。 在 60% 和 90% 阶段组合使用，以便在评估视觉设计的同时评估用户可见文案——语态和语气、句首大写、不使用与号以及无障碍规则。在 30% 阶段跳过，因为此时文案还太早，不适合评审。
• using-figma。 如果正在评审的设计位于 Figma 文件中，请组合使用以了解上下文。先使用 get_screenshot + get_metadata 了解整体情况；如果评审涉及设计令牌（偏离系统规范的颜色、间距不一致），则调用 get_variable_defs。

输出格式

按以下结构组织评审：

1. 阶段——确认阶段或询问阶段（30% / 60% / 90%）。
2. 优点——哪些方面有效，应予以保留。
3. 问题——哪些地方不清楚；应请设计师澄清什么。
4. 可执行的反馈——具体且紧扣产品目标的观察，设计师可以据此采取行动。反馈的细致程度应与阶段相符。在 60%/90% 阶段，包含与 content-style-guide 相关的内容观察。

反馈要具体。“CTA 层级不明确，无法判断哪项操作是主要操作”比“按钮感觉不太对”更好。尽可能将每条意见与用户或产品目标联系起来。