Enterprise DevOps
2024
这是一个面向产研团队的 DevOps 后台系统，覆盖 CI/CD 流水线、环境管理、监控告警和交付状态。改版要让产品、开发、测试、发布和运维在同一工作台中看见交付状态，完成各自的高频任务。
我负责产品界面设计，工作包括需求梳理、角色访谈、信息架构、流程设计、视觉系统与开发跟进。
这次不是从零搭建新工具，而是在既有交付链路上重排信息和操作。设计要同时照顾不同角色的工作节奏：工作台先给全局状态，进入 Process 后再展开具体配置；因此我把页面、状态、组件和交互规则一起整理，而不是只交付一套视觉稿。
从一句「好看一些」重新定义问题
项目最初收到的诉求是「把系统做得更好看，也让更多人愿意用」。访谈和旧版审查很快暴露出视觉之外的问题：模块组织缺少顺序，交付状态不直观，操作路径也过长，不同角色还要在多个页面之间拼接信息。我把改版目标落到可以检查的任务上：减少操作错误和学习成本，让交付状态更早出现，并检查不同角色能否在同一工作台中完成高频任务。
把多角色诉求还原成任务链
这套 DevOps 平台同时服务多种角色。产品经理关心版本进度，开发需要分支编译和日志，测试关注报告与缺陷，发布和运维则要确认环境、部署状态和告警。我通过访谈把这些需求整理成角色—任务—状态链，再判断哪些信息应全局可见，哪些只在具体流程中展开。这一步避免了后台继续按组织模块堆叠菜单。
三条贯穿方案的设计原则
最终方案由三条原则约束：信息跟着任务顺序出现，打破原有的模块菜单；高频入口和交付状态提前展示，减少来回查找；统一组件与状态语言，让浅色、深色以及后续模块扩展保持一致。
决策一：简化全局结构
旧版侧栏缺少清晰分组，页面顶部又叠加大量标签和操作按钮。改版后，我用可扩展的侧栏承载稳定模块，把页面级操作收拢到统一工具栏，并减少同时暴露的入口。用户进入页面后先看到当前任务需要的内容，其余功能按上下文展开。
决策二：让工作台承担系统全局感
高频用户不应该每次都从导航重新寻找项目。工作台把当前项目、历史访问、待处理任务和交付指标集中到一个入口；Dashboard 再把发布、部署、代码、缺陷、测试与运维数据组织成可扫描的状态概览。这样既缩短个人操作路径，也让管理者能够在不进入具体配置页的情况下判断交付风险。
决策三：让流程状态可见、可操作
Process 是改版中最复杂的部分。原有流程把查看、编辑和执行拆散在多个步骤中，用户难以确认自己处于什么状态。我将工具操作整合进同一上下文，用颜色和标注区分等待、运行中、成功、失败、冻结等状态，并通过可视化编辑和统一表单降低创建任务的门槛。浮层只承载临时操作，避免每次调整都打断主流程。
把一次改版沉淀为双主题设计系统
深色模式重新校准了层级、对比度和视觉刺激，没有直接反相浅色界面。圆角、间距和图标等视觉语言随后被整理为可复用组件和 Token，并建立「先复用、再扩展、最后新增」的组件决策流程。页面、组件库和 Token 一起交付，团队可以继续维护。
最终方案与复盘
最终方案覆盖了工作台、流程管理、发布部署、质量数据和团队级设计系统。方案让不同角色可以在同一个工作台查看进度、处理任务，组件与 Token 也按复用流程整理，便于后续模块继续使用。