amoye-ui-ux

界面设计与用户体验

基于当前产品／项目证据和经得起时间考验的 UX／设计判断，确定一个连贯的界面方向。不要维护私有的框架／字体／样式目录或编码推荐层。

工作流程

1. 在推荐方向之前，检查实际产品、现有品牌指南、截图／设计稿、平台、组件惯例、设计令牌和相关项目清单。现有获批的品牌标识和产品惯例优先于附带示例。
2. 明确用户／任务、主要界面、平台限制、内容／数据形态、无障碍需求、信息密度和现有设计决策。审查实现时，还要明确获批的方向以及确切的渲染候选方案／证据。根据需要使用 amose。
3. 阅读快速参考，了解适用的交互／布局／设计分支。若要优化原生应用／移动应用，或进行最终应用审查，还要阅读专业应用规则。
4. 如果方向确实存在重大不确定性、仍有多个差异显著的构图方案都可信，或已实现的结果需要设计收敛，请阅读设计收敛。只探索足以呈现真实选择的设计空间；如果现有证据已确定方向，就不要凭空创造变体。
5. 如果内部证据不足以确定视觉处理方式、组件构成、交互细节或精致度，请阅读参考驱动的构图。利用实际范例提升判断力，而不是把判断外包出去或照搬设计。
6. 确定一个方向：产品模式、视觉特征、语义颜色角色、字体表现、信息密度、布局层级、交互／状态行为、动效策略、数据／图表处理方式，以及一份简短的反模式清单。仅当易变的平台／框架要求可能改变建议时，才查阅当前一手资料；不要在此处缓存这些资料。
7. 如果截图、模型图、原型或其他视觉参考对验收有实质影响，请将明显可见和可交互的元素与底层语义能力分别列出。对每项都明确选择采纳、保留、调整或拒绝。不要将支持语义节点／状态／组件视为已证明其可见元素、层级、可发现性或交互方式符合获批方向。
8. 根据需要使用 brand。

决策规则

• 优先采用当前产品／品牌证据，而不是泛泛的行业刻板印象。
• 将请求未要求重新审议的已批准产品／品牌约束视为不变量，而不是为了追求新意而改变的维度。
• 只有在重要决策确实尚未确定时，才探索备选方案；同一构图的不同配色或表面变化不算有意义的备选方案。
• 使用外部参考来回答范围明确的设计问题；方向已有充分依据后，不要为了追求新意而继续浏览。
• 提炼可迁移的层级、构图、交互、动效、信息密度和状态处理原则。不要复刻具有鲜明特色的布局、插图、文案、品牌标识或专有素材。
• 使用语义化颜色角色和符合无障碍要求的前景色／背景色搭配；不要因为模板称蓝色或绿色是惯例就凭空设计配色方案。
• 对于 Web 界面，以当前的 WCAG 指南作为无障碍基线；对于原生／移动界面，采用当前平台的无障碍指南以及适用的跨平台原则。当自定义／组合式 Web 控件所需的交互语义超出原生／库的行为时，将当前的 WAI-ARIA Authoring Practices（APG） 作为推理／参考依据，而不是维护一份捆绑的无障碍手册。
• 优先采用成熟的平台原语和可预测的交互行为，而不是装饰性的标新立异。
• 当界面需要时，明确说明正常、加载、空、错误、禁用、焦点／按下和恢复状态。
• 根据内容和层级设计响应式行为，不要迷信固定的设备尺寸。
• 动效必须说明状态／关系，并尊重减少动态效果的偏好。
• 图表必须让目标比较／关系更易理解，且绝不能仅依赖颜色。
• 将框架／组件库的具体特性视为实现负责人／当前工具的证据，而不是持久有效的 UX 事实。
• 当视觉／交互保真度很重要时，检查实际渲染的行为；不要仅凭源代码意图推断验收结果。

输出

建议

返回以下内容：

• 用户／任务；
• 选定的产品／交互模式；
• 视觉方向；
• 语义化颜色、排版和布局规则；
• 状态、动效和无障碍约束；
• 相关时的图表／数据方向；
• 实现交接约束；以及
• 反模式。

当提供的视觉参考对验收产生实质影响时，还需说明：

• 语义能力预期；
• 明显可见／可交互的功能；
• 对每项功能采取的采用 | 保留 | 调整 | 拒绝处理方式；以及
• 哪些功能仍需通过实际渲染／交互验证才能验收。

当重要的探索过程影响了方向时，还需说明尚未解决的设计问题、考虑过的实质不同方案、选定的方向及其改变决策的依据，以及只有在会约束未来实现时才说明被拒绝的备选方案。

当外部参考对方向产生了实质影响时，还需说明：

• 范围明确的设计问题；
• 选定的范例；
• 采用的可迁移原则；
• 不匹配而被拒绝的内容；以及
• 任何证据缺口。

评审

返回以下内容：

• 已接受的方向或起决定作用的证据；
• 重要情况下的确切渲染候选方案／证据；
• 违反的 UX／设计原则、方向约束或重要功能预期；
• 受影响的行为；
• 证据；
• 最小且有效的修正；以及
• 任何仍存在的重要设计缺陷或证据缺口。

如果不再存在重要缺陷，不要要求再次评审。