Files
EasyFlow/docs/design/easyflow-product-design-spec.md
陈子默 76c2954a70 docs: 新增产品设计规范知识库
- 新增产品主题、色彩体系与三端一致性规范\n- 补充 Design Tokens 草案与基础组件规范\n- 补充交互与动效规范及设计文档索引
2026-03-06 14:39:14 +08:00

10 KiB
Raw Blame History

EasyFlow 产品设计规范 v1

1. 文档目的

本规范用于统一 EasyFlow 的产品主题、视觉语言、交互哲学与前端实现方向作为管理端、用户端、Web SDK 以及后续设计资产沉淀的共同依据。

目标不是追求“更花哨”的界面,而是建立一套长期稳定、可复用、可演进的产品设计系统,让 EasyFlow 在不同模块、不同端上都保持一致的气质、手感与可信度。

2. 设计主题

2.1 主题名称

冷静智能

2.2 一句话定义

EasyFlow 是一个克制、可信、现代、交互友好的智能工作台。

2.3 品牌气质关键词

  • 清晰
  • 秩序
  • 安静
  • 智能
  • 可信
  • 精致
  • 顺手

2.4 明确避免的方向

  • 赛博霓虹、强对比、高饱和炫技风格
  • 过度玻璃拟态、厚重阴影、复杂渐变堆叠
  • 为了“科技感”牺牲信息层级和可读性
  • 为了“高级感”弱化交互反馈或降低操作效率

3. 产品体验目标

EasyFlow 需要同时承载企业级管理平台与 AI 应用开发平台的双重身份,因此整体体验必须同时传达以下四类感受:

  • 专业可信:让用户敢于在系统中管理流程、配置智能体和处理业务数据。
  • 结构清晰:让复杂能力在页面中仍然容易理解、容易导航、容易操作。
  • 智能高效:让 AI、工作流、知识库等能力体现为效率提升而不是额外复杂度。
  • 交互温和:让反馈及时、稳定、低打扰,减少紧张感和误操作成本。

4. 核心设计原则

4.1 清晰优先

先让用户看懂页面层级、当前状态、下一步动作,再追求视觉表现。

4.2 安静高效

界面不喧宾夺主,主任务、主操作与主信息始终占据视觉优先级。

4.3 统一胜过局部惊艳

单页的“特别设计”如果破坏了全局一致性,不应视为正向设计资产。

4.4 细节有温度

hover、focus、loading、空状态、错误状态、成功反馈等细节必须被完整设计而不是只补主界面。

4.5 动效服务理解

动画用于帮助用户理解状态变化、层级切换和空间关系,不用于炫技或制造噪音。

4.6 AI 也要可信

AI 能力的表达应克制、专业、可预期,重点是流程可理解、状态可感知、结果可恢复。

5. 色彩体系

5.1 主色方案

EasyFlow v1 使用 冷静智能蓝 作为统一品牌色策略。

5.2 核心色值

Token 用途 建议值
Primary 品牌主色 / 主操作 / 当前态 #1677FF
Primary Hover 主操作悬停 #3D8BFF
Primary Active 主操作按下 #0F5FD6
Brand Soft Surface 品牌浅底 #EAF3FF
App Background 页面背景 #F6F8FB
Panel Background 面板/卡片背景 #FFFFFF
Text Strong 强文本 #1C2430
Text Secondary 次文本 #5B6574
Border 常规描边 #DCE3EC

5.3 使用规则

  • 品牌色仅用于主按钮、选中态、焦点态、关键链接、核心数据高亮与重要反馈。
  • 页面大面积区域以中性色为主,不使用大面积纯品牌色铺底。
  • 色彩比例建议控制为:70% 中性背景 + 20% 结构层级色 + 10% 品牌强调色
  • 成功、警告、错误色属于语义系统,不参与品牌表达,不作为页面主装饰色。
  • 深色模式延续同一品牌策略,但背景使用石墨深灰体系,避免纯黑带来的生硬与失真。

5.4 语义色原则

  • 成功:偏冷静绿色,强调完成与正常状态,不使用荧光绿。
  • 警告:中低饱和暖黄,用于风险提醒,不制造焦虑。
  • 错误:克制红色,用于错误、删除、失败、危险动作。
  • 信息:浅蓝或冷灰蓝,用于说明、提示、引导,不抢主操作注意力。

6. UI 视觉语言

6.1 总体风格

EasyFlow 的界面风格定义为:

  • 扁平
  • 轻层级
  • 弱描边
  • 轻阴影
  • 大留白
  • 强对齐
  • 少装饰

6.2 层级建立方式

  • 优先依赖留白、分组、对齐、字号、字重和弱分隔线建立层次。
  • 少用“卡片套卡片”“面板套面板”建立结构。
  • 避免粗边框、重阴影、过多色块同时出现。

6.3 字体与信息层级

  • 中文优先系统中文字体链,默认以 PingFang SC 体验为参考。
  • 西文、数字、代码信息优先复用系统字体链,保持现代、稳定与跨端一致性。
  • 页面至少保证标题、区块标题、正文、辅助说明四级文字层级。
  • 弱信息不靠缩得过小来退让,而靠颜色、字重和间距让位。

6.4 圆角策略

EasyFlow 的圆角应柔和但理性,不追求玩具感或夸张圆润。

建议档位:

  • 按钮 / 输入框:10px
  • 下拉面板 / 工具条 / 小型容器:12px
  • 卡片 / 页面面板:16px
  • 弹窗 / 抽屉 / 高阶浮层:20px
  • 徽标 / 标签胶囊:999px8px

6.5 阴影策略

阴影只承担“层级提示”功能,不承担风格表达主角。

建议仅保留三档:

  • 基础层:弱阴影,仅用于卡片和轻微浮起场景
  • 浮层用于下拉、Popover、菜单、选择面板
  • 模态层:用于弹窗、抽屉、全局悬浮区

6.6 描边策略

  • 描边尽量细、淡、统一,优先作为结构辅助线而不是视觉主角。
  • 相邻容器尽量通过背景层差和留白区分,而不是每层都画边框。
  • 输入类组件可使用更清晰但不刺眼的边框和焦点环。

7. 组件气质与统一手感

7.1 按钮

  • 主按钮明确,但不依赖过饱和颜色或异常尺寸制造存在感。
  • 次级按钮、幽灵按钮、文本按钮的优先级稳定,不随页面作者习惯漂移。
  • 同一区域内按钮高度、圆角、图标尺寸、左右留白必须属于同一档位体系。

7.2 输入类组件

  • 输入框、选择器、日期选择器、搜索框与相邻按钮在高度和节奏上保持一致。
  • 占位文案、前后缀图标、清空按钮的灰度和间距统一。
  • 校验、禁用、只读、加载中的状态风格不能因页面不同而改变。

7.3 卡片与面板

  • 页面应尽量维持一种主容器语言。
  • 卡片与面板优先使用内边距、弱分隔和标题层级建立结构。
  • 同类弹窗、抽屉、操作面板的头部、说明区和底部操作区保持稳定模板。

7.4 表格、筛选区与工具栏

  • 搜索、筛选、批量操作、表格头和分页应被视为同一组效率组件。
  • 搜索与筛选默认低于主操作位,不抢“新建、保存、发布、提交”等核心动作。
  • 表格密度既不能松散拖沓,也不能压缩到难读难点。

7.5 标签、徽标与状态

  • 状态展示优先语义明确、饱和度受控。
  • 避免在同一页面出现大量高彩色标签争夺注意力。
  • 成功、失败、处理中、草稿等状态造型与颜色映射保持统一。

8. 页面骨架与信息层级

8.1 页面推荐结构

大部分业务页面优先遵循以下顺序:

  1. 标题区
  2. 说明区或关键摘要
  3. 工具栏 / 主要操作区
  4. 核心内容区
  5. 辅助说明或次级信息区

8.2 主次关系

  • 主操作在用户预期位置稳定出现,减少跨页面学习成本。
  • 次级动作、帮助说明、附属信息应主动退后。
  • 响应式下优先保持层级和操作顺序,再压缩尺寸与布局。

9. 交互哲学

9.1 总体方向

EasyFlow 的交互应是“顺手”的,而不是“会玩”的。

9.2 必备交互要求

  • 所有交互控件必须具备 hover、active、focus、disabled 状态。
  • 所有异步流程必须具备 loading、防重复提交、成功反馈和失败恢复路径。
  • 表单校验应就近展示并可执行,不让用户自己猜测修复方式。
  • 危险操作必须有确认、反馈和可恢复思路。
  • 空状态、错误状态、无权限状态、无数据状态必须提供解释和下一步动作。

9.3 键盘与可访问性

  • 默认支持 Tab 键导航。
  • 关键操作与对话框保持 Enter / Esc 行为清晰。
  • 焦点样式必须明显,不可依赖颜色轻微变化蒙混通过。

10. 动效规范

10.1 动效关键词

  • 细腻
  • 短促
  • 稳定
  • 不变形

10.2 推荐时长

  • 微交互:120ms - 160ms
  • 面板切换:180ms - 240ms
  • 弹窗 / 抽屉:220ms - 280ms

10.3 推荐形式

  • 透明度变化
  • 轻微位移
  • 轻微缩放

10.4 明确避免

  • 弹跳
  • 果冻式形变
  • 长时间缓动
  • 多段复杂动画
  • 与业务无关的装饰性动画

11. 三端统一策略

11.1 必须统一

  • 色彩体系
  • 圆角体系
  • 阴影与描边规则
  • 字体层级
  • 按钮、输入框、弹窗、标签等基础组件手感
  • 动效节奏和反馈逻辑

11.2 允许差异

  • 页面密度
  • 页面骨架
  • 内容布局方式
  • 业务语气与引导方式

11.3 分端建议

  • Admin更克制、更紧凑、更强调秩序与效率
  • User Center更友好、稍轻松但保持同一设计语言
  • Web SDK更轻、更简、更对话化但控件和反馈必须同源

12. AI 能力的专属表达

  • AI 模块允许比传统管理模块多一点蓝青高亮感,但不能脱离全局视觉语言。
  • 智能体、工作流、知识检索、执行状态等内容,重点体现“过程清晰、状态可感知、失败可恢复”。
  • 不把 AI 能力包装成神秘黑盒,不使用夸张视觉掩盖复杂性。

13. 前端落地要求

  • 颜色、圆角、阴影、间距、字号、动效时长统一沉淀到 Token 与公共层。
  • 同类视觉规则影响多个页面时,优先下沉到 @core/base/design@core/ui-kiteffects/*
  • 页面层只负责编排业务内容,不重复发明基础组件风格。
  • 若本次任务无法完成视觉、交互或响应式验证,交付说明中必须明确缺失项。

14. 后续演进建议

建议在本规范基础上继续沉淀以下资产:

  • Design Tokens 详细清单
  • 基础组件视觉与交互规范
  • 页面骨架模板库
  • 空状态 / 错误状态 / 引导状态模板
  • AI 模块专属状态与流程表达规范