372 lines
14 KiB
Markdown
372 lines
14 KiB
Markdown
# EasyFlow 产品设计规范 v1
|
||
|
||
## 1. 文档目的
|
||
|
||
本规范用于统一 EasyFlow 的产品主题、视觉语言、交互哲学与前端实现方向，作为管理端、用户端、Web SDK 以及后续设计资产沉淀的共同依据。
|
||
|
||
目标不是追求“更花哨”的界面，而是建立一套长期稳定、可复用、可演进的产品设计系统，让 EasyFlow 在不同模块、不同端上都保持一致的气质、手感与可信度。
|
||
|
||
## 2. 设计主题
|
||
|
||
### 2.1 主题名称
|
||
|
||
`冷静智能`
|
||
|
||
### 2.2 一句话定义
|
||
|
||
EasyFlow 是一个克制、可信、现代、富有表达力且交互友好的智能工作台。
|
||
|
||
### 2.3 品牌气质关键词
|
||
|
||
- 清晰
|
||
- 秩序
|
||
- 安静
|
||
- 智能
|
||
- 可信
|
||
- 精致
|
||
- 顺手
|
||
- 现代
|
||
- 鲜明
|
||
- 灵动
|
||
|
||
### 2.4 明确避免的方向
|
||
|
||
- 赛博霓虹、强对比、高饱和炫技风格
|
||
- 过度玻璃拟态、厚重阴影、复杂渐变堆叠
|
||
- 为了“科技感”牺牲信息层级和可读性
|
||
- 为了“高级感”弱化交互反馈或降低操作效率
|
||
|
||
说明：
|
||
|
||
- 顶栏、侧栏、浮层等导航骨架允许使用轻度液态玻璃质感，包括低对比半透明表面、柔和背景染色与克制的模糊。
|
||
- 这种玻璃质感必须服务于空间分层和手感提升，不能依赖重描边、强高光、厚阴影或大面积彩色铺底制造存在感。
|
||
- `冷静智能` 不等于保守、僵硬、缺乏表现力，不应默认落成传统 ERP 式的重线条后台。
|
||
|
||
## 3. 产品体验目标
|
||
|
||
EasyFlow 需要同时承载企业级管理平台与 AI 应用开发平台的双重身份，因此整体体验必须同时传达以下四类感受：
|
||
|
||
- `专业可信`：让用户敢于在系统中管理流程、配置智能体和处理业务数据。
|
||
- `结构清晰`：让复杂能力在页面中仍然容易理解、容易导航、容易操作。
|
||
- `智能高效`：让 AI、工作流、知识库等能力体现为效率提升，而不是额外复杂度。
|
||
- `交互温和`：让反馈及时、稳定、低打扰，减少紧张感和误操作成本。
|
||
|
||
## 4. 核心设计原则
|
||
|
||
### 4.1 清晰优先
|
||
|
||
先让用户看懂页面层级、当前状态、下一步动作，再追求视觉表现。
|
||
|
||
### 4.2 安静高效
|
||
|
||
界面不喧宾夺主，主任务、主操作与主信息始终占据视觉优先级。
|
||
|
||
### 4.2A 现代但不保守
|
||
|
||
EasyFlow 应主动吸收 Apple HIG 与 Google Material Design 3 中成熟的现代界面语言，包括：
|
||
|
||
- 用表面层、材质、色调和留白建立层级，而不是依赖大量分割线
|
||
- 用语义色和色彩角色建立品牌表达，而不是把色彩收缩到只剩按钮
|
||
- 用流动、适配和组件一致性提升高级感，而不是靠硬框和堆叠结构显得“专业”
|
||
|
||
克制不是收缩表达，而是让表达有秩序、有重点。
|
||
|
||
### 4.2B Apple-first 的 toB 应用策略
|
||
|
||
EasyFlow 在视觉与交互方向上，默认以 Apple HIG 作为第一参照系，再用 Material Design 3 补足系统化的色彩角色、自适应布局与组件一致性。
|
||
|
||
这不意味着机械模仿平台样式，而是意味着：
|
||
|
||
- toB 系统不必天然长成传统 ERP 的厚边框、重分区、强表单压迫感界面
|
||
- 导航骨架可以更通透、更轻盈、更有悬浮感，让内容真正成为主角
|
||
- 工具栏、搜索、筛选、切换控件应更像现代工作台的控制层，而不是一排表单框堆叠
|
||
- 组件要像高质量产品控件，而不是“能用就行”的业务控件
|
||
- 大屏界面要保留留白、呼吸感和动态层次，不因空间变大而自动增加线框和容器
|
||
|
||
若 `传统后台习惯` 与 `现代工作台体验` 冲突，默认优先后者，但必须保证可读性、可学习性和操作效率。
|
||
|
||
### 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% 品牌强调色`。
|
||
- 成功、警告、错误色属于语义系统，不参与品牌表达，不作为页面主装饰色。
|
||
- 深色模式延续同一品牌策略，但背景使用石墨深灰体系，避免纯黑带来的生硬与失真。
|
||
- 品牌色不应只停留在按钮，可合理参与导航当前态、重点操作、选中反馈、局部染色表面和关键数据强调。
|
||
- 参考 Material 3 的 `color roles` 思路，未来 EasyFlow 应逐步建立主色、表面色、容器色、文本色、状态色的语义映射。
|
||
|
||
### 5.4 语义色原则
|
||
|
||
- 成功：偏冷静绿色，强调完成与正常状态，不使用荧光绿。
|
||
- 警告：中低饱和暖黄，用于风险提醒，不制造焦虑。
|
||
- 错误：克制红色，用于错误、删除、失败、危险动作。
|
||
- 信息：浅蓝或冷灰蓝，用于说明、提示、引导，不抢主操作注意力。
|
||
|
||
## 6. UI 视觉语言
|
||
|
||
### 6.1 总体风格
|
||
|
||
EasyFlow 的界面风格定义为：
|
||
|
||
- 扁平
|
||
- 轻层级
|
||
- 弱描边
|
||
- 轻阴影
|
||
- 大留白
|
||
- 强对齐
|
||
- 少装饰
|
||
- 轻材质
|
||
- 鲜明重点
|
||
|
||
### 6.2 层级建立方式
|
||
|
||
- 优先依赖留白、分组、对齐、字号、字重和弱分隔线建立层次。
|
||
- 少用“卡片套卡片”“面板套面板”建立结构。
|
||
- 避免粗边框、重阴影、过多色块同时出现。
|
||
- 对于全局导航骨架，可适度使用轻度液态玻璃表面替代硬分割线，但仍应以低对比、低装饰为前提。
|
||
- 参考 Material 3 的 `tonal elevation` 思路，优先通过表面明度、色调差和轻阴影区分层级，而不是靠边框切出一个个盒子。
|
||
|
||
### 6.2A 导航骨架材质
|
||
|
||
导航骨架默认可以更现代一些：
|
||
|
||
- 侧栏、顶栏、tab 区、搜索框、轻浮层允许使用轻度液态玻璃
|
||
- 导航项的当前态允许更鲜明的品牌强调、柔和胶囊和轻染色背景
|
||
- 工具按钮、搜索入口、切换控件可以比正文组件更具材质感，但不能厚重
|
||
- 内容区仍应保持清晰和稳定，避免整页都被玻璃化
|
||
|
||
补充：
|
||
|
||
- 导航骨架的现代感优先来自透明度、模糊、染色、圆角、轻阴影和动态响应，而不是边框和分隔条
|
||
- 面包屑、标签导航、全局搜索、工具按钮应作为同一套“控制层语言”统一设计
|
||
- 这种表达要让页面看起来更像现代软件工作台，而不是更像传统管理表单容器
|
||
|
||
### 6.3 字体与信息层级
|
||
|
||
- 中文优先系统中文字体链，默认以 `PingFang SC` 体验为参考。
|
||
- 西文、数字、代码信息优先复用系统字体链，保持现代、稳定与跨端一致性。
|
||
- 页面至少保证标题、区块标题、正文、辅助说明四级文字层级。
|
||
- 弱信息不靠缩得过小来退让，而靠颜色、字重和间距让位。
|
||
|
||
### 6.4 圆角策略
|
||
|
||
EasyFlow 的圆角应柔和但理性，不追求玩具感或夸张圆润。
|
||
|
||
建议档位：
|
||
|
||
- 按钮 / 输入框：`10px`
|
||
- 下拉面板 / 工具条 / 小型容器：`12px`
|
||
- 卡片 / 页面面板：`16px`
|
||
- 弹窗 / 抽屉 / 高阶浮层：`20px`
|
||
- 徽标 / 标签胶囊：`999px` 或 `8px`
|
||
|
||
补充：
|
||
|
||
- 导航工具按钮、搜索入口、轻浮层中的控制点，可以适度更圆润，以获得更现代的触感。
|
||
- 这种更圆润的表达应集中在骨架和交互热点，不扩散到整页所有容器。
|
||
|
||
### 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 主次关系
|
||
|
||
- 主操作在用户预期位置稳定出现，减少跨页面学习成本。
|
||
- 次级动作、帮助说明、附属信息应主动退后。
|
||
- 响应式下优先保持层级和操作顺序，再压缩尺寸与布局。
|
||
|
||
### 8.3 自适应与现代布局
|
||
|
||
- 参考 Material Design 的 `adaptive layout` 思路，页面骨架应优先考虑不同窗口尺寸下的重排，而不是仅靠缩小组件。
|
||
- 大屏页面应保留呼吸感和内容聚焦，不因空间变大而增加无意义边框和容器。
|
||
- 导航和内容的关系应尽量“浮于内容之上”或“包裹内容而不压迫内容”，避免传统后台式的刚性框架感。
|
||
- toB 页面不应因为信息复杂就默认采用“满屏表单 + 满屏线框”的保守构图；复杂度应通过层级与编排解决，而不是通过框线堆砌解决。
|
||
|
||
## 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-kit` 或 `effects/*`。
|
||
- 页面层只负责编排业务内容，不重复发明基础组件风格。
|
||
- 若本次任务无法完成视觉、交互或响应式验证，交付说明中必须明确缺失项。
|
||
|
||
## 14. 后续演进建议
|
||
|
||
建议在本规范基础上继续沉淀以下资产：
|
||
|
||
- Design Tokens 详细清单
|
||
- 基础组件视觉与交互规范
|
||
- 页面骨架模板库
|
||
- 空状态 / 错误状态 / 引导状态模板
|
||
- AI 模块专属状态与流程表达规范
|