Design System for SaaS Platform

通过对现有页面、公共组件和常见业务流程的整理，我将问题归纳为三个层级：

1. Component：原子组件层

   这一层主要关注基础 UI 组件的使用一致性，包括 Navigation、Table、Filter、Modal、Button、Status、Pagination 等。

   在现有系统中，同一种功能在不同模块中可能使用不同的尺寸、间距、文字、状态样式和操作方式。例如，同样是筛选功能，有的页面采用即时搜索，有的页面需要点击按钮确认；同样是删除操作，不同系统对二次确认、Soft Delete 和 Permanent Delete 的处理方式也存在差异。

   因此，我以 Zoom Global Library、Ant Design 和 Element 等现有组件体系为参考，同时结合 ZCP 的实际业务场景，重新整理组件的基础属性、状态变化和使用条件。

2. Design System：交互模式层

   这一层关注的不是单个组件本身，而是多个组件组合后形成的交互关系。

   例如，页面标题、筛选区域、表格操作和分页之间应该如何排列；不同状态如何通过颜色、文字和标签进行区分；创建、编辑和删除操作使用什么样的弹窗结构；当页面存在多级导航或多个操作入口时，用户如何理解它们之间的层级关系。

   这些问题中，很多页面的单个组件本身并没有明显错误，但组合在一起后，用户会发现不同模块的操作逻辑并不一致。因此，我进一步整理了不同组件之间的关联关系、页面层级、状态反馈和常见 Design Pattern，使相似的任务能够遵循相对一致的交互方式。

3. UX Guideline：任务流程层

   这一层关注用户完成具体任务时需要经历的完整流程，包括创建、部署、编辑、删除和配置等操作。

   我重点梳理了每个任务的开始条件、主要步骤、可选操作、异常情况和完成反馈，并判断哪些步骤是用户完成任务所必需的，哪些功能可以被弱化或放到后续操作中。

   例如，创建和部署流程通常包含多个配置节点，需要通过步骤引导帮助用户理解当前进度；删除操作则需要根据是否可恢复、影响范围和操作风险，决定是否需要二次确认或输入确认信息。

通过这三个层级的问题拆分，我将原本分散在不同页面中的问题转化为可复用的设计规则，最终，这些问题分析成为 ZCP Design Guideline 的基础，支持后续对组件、交互模式和 Task Flow 进行统一设计。由此可以将“让平台看起来更一致”的简单问题转化为一组可以具体讨论的事项：用户当前处于什么角色？他正在完成什么任务？哪些信息需要优先展示？哪些操作可以隐藏？不同状态和风险是否需要明确区分？用户在一个模块中学会的交互规则，能否自然地应用到其他模块中？

从交互架构上，我将系统中的设计分为两类：

• 功能型设计（Feature-oriented）

  功能型设计关注系统具备哪些基础能力，例如业务功能、系统设置、个人信息管理、登录注册等。这一层主要保证产品功能完整，并为不同业务模块提供稳定的基础结构。

• 任务型设计（Task-oriented）

  任务型设计围绕用户需要完成的具体目标展开，例如创建、部署、编辑或删除一个业务对象。设计时重点关注用户完成主要任务所需要的核心路径，而不是将所有系统功能同时展示出来。

实际设计中，这两种方式并不是相互独立的。产品首先需要具备完整的功能型架构，再根据用户角色、当前任务和使用频率，对功能进行取舍：将主要操作直接呈现，将次要功能进行弱化、折叠或延后，将低频且高风险的操作放在更明确的入口中。

例如，Operator 和 Engineer 虽然可能使用同一套系统，但他们关注的内容并不完全相同。Operator 更关注服务状态、任务进度和日常操作；Engineer 可能更关注配置细节、系统依赖和技术信息。因此，同一个页面需要先明确主要服务对象，再决定信息层级和交互重点。

一个页面应尽量围绕一个主要用户角色建立清晰的操作视角。如果因为业务需要必须支持多个角色，则需要通过入口、文案、权限、状态或视觉层级进行明确区分，避免不同角色的任务和信息混杂在同一个操作路径中。

基于这一点，我建立了以 5E 为基础的设计原则：

• Easy to Learn

  用户能够快速找到入口，理解页面结构和基本操作；

• Effective / Efficient / Error Tolerant

  系统能够支持用户完成任务，并对高风险或容易出错的操作提供必要的提示和保护；

• Engaging

  通过清晰的反馈和合理的操作节奏，让用户愿意持续使用；

• Common Sense

  让用户在一个模块中学习到的交互逻辑，可以迁移到其他模块中，减少重复学习成本。

我将“Common Sense”作为跨模块设计的重要判断标准。例如，页面标题、按钮层级、状态颜色、筛选方式和弹窗行为都需要保持相对一致。这样用户不需要重新记忆每个系统的操作方式，而是可以根据已有经验推测新的页面应该如何使用。

针对这个问题，我将导航拆分为几个具体维度：

• 当前系统包含几级信息；
• 用户是否需要同时查看上一级和下一级内容；
• 菜单内容较多时是否需要折叠；
• 折叠后如何保留用户对图标和功能的识别；
• 第三级菜单适合原地展开，还是通过 Hover 在右侧展示；
• 不同角色是否需要看到不同的系统入口。

基于这些条件，我对二级菜单、三级菜单、Hover 展开和折叠导航等不同方式进行了归类，并明确每种模式的适用场景。最终，导航不再只是视觉样式的统一，而是形成了和信息架构、用户角色及任务路径相对应的使用规则。

因此，我根据筛选范围将其区分为全局筛选、表格筛选和图表筛选，并分别定义它们在页面顶部、表头区域或独立筛选区域中的使用方式。同时，对单选、多选、层级选择、模糊搜索和搜索联想等情况进行统一规范。

弹窗设计则根据任务类型和操作风险进行区分。创建、编辑和删除虽然都属于弹窗操作，但用户承担的风险并不相同。对于删除操作，我进一步区分了可恢复的 Soft Delete 和不可恢复的 Permanent Delete，并根据风险决定是否需要二次确认、输入确认文字或提供管理员恢复机制。

这种处理方式让组件规范和实际任务建立了联系：不是因为某个组件“看起来应该这样”，而是因为用户在当前任务中需要这样的反馈和保护。

随后，我将这些问题重新标记到完整的用户使用流程中，并结合问题出现的频率、影响范围、任务重要程度和操作风险判断优化优先级。这样可以避免只根据个别反馈进行局部修改，而是找到整个产品流程中相对薄弱的环节，并将其纳入后续的设计规划。

• 基于 Zoom Global Library、Ant Design 和 Element 的基础组件规范；
• Navigation、Filter、Table、Modal、Button、Tab、Status、Pagination 等公共组件的使用规则；
• 创建、部署、编辑、删除等常见 Task Flow 的交互规范；
• 页面信息层级、角色视角、状态反馈和错误处理原则；
• 不同组件和页面之间的关联关系及 Design Pattern。

在这个项目中，我的主要贡献包括：

• 将“建立平台设计规范”的抽象需求拆解为组件、交互和任务流程三个层级；
• 梳理 Operator 和 Engineer 在复杂后台系统中的主要使用任务；
• 通过用户反馈和 AI 辅助分析，定位产品中重复出现的体验问题；
• 负责公共组件、页面布局、状态反馈和核心 Task Flow 的设计规则；
• 与 PM 和研发团队进行多轮 Review，推动设计原则从文档内容转化为具体的页面和交互方案。

这个项目的重点不是让所有页面使用完全相同的视觉样式，而是建立一套可以被设计师、研发和用户共同理解的交互规则，让用户在学会一个模块后，也能够自然地理解和使用其他模块。