这是一款汇量科技内部使用的产品，我在职的时候，MaxCloud 正在进行设计升级，我很荣幸能够参与这次升级。我在项目中承担了应用管理模块相关的设计体验优化工作，并且取得了而一些有效的成果。

项目背景

MaxCloud 是汇量科技内部用于管理混合云环境部署的 DevOps 工具，运维人员每天需要花费 3 小时以上的时间对其负责的应用进行创建、管理，因此提升平台的操作效率，可以有效提高运维人员的有效工作时长，提升运维效率。

它是一款为运维人员打造的产品。这款产品的的核心就是应用管理，后续的应用组管理、定时任务、问题清单都是基于应用管理可以部署和管理应用而存在。

优化思路

我加入的时候，尚且处于项目初期，因此我参与了设计方案的大体规划的讨论，制定了一套比较规范化、标准化的设计方案流程。

核心我认为在于洞察和分析，这一步对我当时来说是最难的，因为那时候我还不怎么理解业务，就需要参与各种用户调研和讨论，多数名词都听得我云里雾里，但是利用当时的 AI 技术以及和其他同事们沟通的机会，我想我很快适应了过来。在这一步，我们希望搞清楚如果要优化，那要优化什么，我们希望不是流于形式，而是真的具备优化的价值。

后续便是设计实施与验证，这在我当时看来很新鲜，也很有趣，也事实证明了有验证的设计更有挑战性和乐趣。

用户调研

由于汇量在广州等地都有分部，因此我们有些会议在线上，有些会议在线下，我们和运维一起交流沟通，我们很多时候并没有刻意的引导他们去表达什么，运维人员大多提到技术问题都喜欢侃侃而谈，我们很多时候只需要把他们拉回正轨，而不需要怎么引导，他们就自然而然地给出了我们想问的问题的答案。

用户调研期间我们收获了很多的反馈，我们使用了钉钉进行了会议录制，把文档整理出来把问题分发给每一个模块的设计师。

  • 首先是创建应用，我们注意到运维人员认为创建应用还是不太好用，主要表现在选择资源这个部分，过多的资源种类、上下滚动的布局导致体验十分的糟糕；

  • 然后是创建后的页面浏览，运维人员反馈他们在这个页面的任务是承接下一个操作——处理故障，但是他们很多时候真的找不到故障，应用太多了；

  • 最后就是处理故障，这部分其实是我们和运维人员沟通的结果，我们希望在产品中引入一些 AI 的东西，但是要让运维人员满意，例如在这里可以引入一些智能化的手段。

设计策略

我们已经发现了问题，现在要做的是解决问题。我和同事们一起思考大体的设计方向，例如创建该如何优化等等，这一步其实提供的一个大概的可能设计路径，我们可能会不断调整。

后续我和同事们便开始了实际的设计实施过程。我将创建、信息展示和 AI 智能化方面 3 个内容在下面为你一一呈现出来。

创建应用优化

现状分析

创建应用在之前就有数据埋点，我们可以很清楚地了解到现在的平均创建时间是多少，这不但可以让我们直到现在有多么“糟糕”，也可以用于我们的后续验证。

除此之外，我们也发现了一些细节，起初在测试环境中我们看到创建的应用大概只有 5-10 个资源，但是正式环境中，运维们往往会在一个应用中包含 30 个以上的资源（甚至远超 30 个），这超乎我们的想象，也更能理解为什么用户提及到了上下滚动的问题。

竞品分析

应用（或者说是开发说的 Bundle）是 MaxCloud 的独创，因此想要找到完美匹配的竞品可以说是不可能的，但这并不妨碍我们寻找一些类似功能或是业务的产品，去看看他们是如何处理资源的管理的，例如国内最大的几家云服务产品。

我们发现阿里云对资源管理提供的方式最有借鉴的价值，百度云采取直接使用代码的交互方式，灵活但不高效、直观（这正是我们为什么要做成 Bundle 的原因），火山云过于依赖 Helm 模板，完全不提供自定义的可能。

阿里云这种表格的结构非常符合我们对于资源信息的字段，但是它并非完美。我们发现它的多选完全无法了解已经选择了什么，特别是我切换了筛选条件之后；使用标签（label）筛选又只能选择一个标签，这并不符合我们运维人员的实际业务逻辑。

所以我们得出结论：我们要基于表格的结构，压缩该页面，同时增加选择状态显示、标签的多选等操作。选择阿里云的交互还有一个理由，那就是我们的技术人员几乎都有使用阿里云服务的经验，这是一次相对较大的改版，这么做更容易让他们接受。

设计执行

接下来，我们开始执行设计，从导航、表单结构等多方面下手，并且重点优化选择资源这一模块。

优化导航

我花了一些时间优化导航样式，原有的样式被运维吐槽“太像步骤条了，我以为是分步的”，说明我们对单选的视觉化处理有问题，因此我做了几次调整，除此之外，还增加了一些信息，让运维人员更好上手和理解不同创建方式之间的差异。

针对这种不长但是信息录入量却比较大的表达，其实也是容易发生漏项现象的，因此我又增加了一个侧边目录，并且可以把校验的结果反馈在这里，如果有“红色”出现，那么就说明这里有问题。

优化布局结构

这里有一些基础信息，他们是一个比较短小的表单，原本的结构是一个横向密铺的结构，或许是为了节约纵向空间，但是我觉得这些表单数量并不多（最多的也只有 8 个），就算完全纵向排列占据的空间也很有限，但是却可以很有效地提升录入效率，因此我把它改成了纵向布局的结构。

在选择资源这里，我也没有含糊，原本的资源类型选择是横向布局位于顶部的，显然这不符合用户习惯，因此我把它放在了左侧，用户点击起来更方便了。

你或许还注意到了侧边的资源类型边上还有一个徽标计数器，这便是我为了解决阿里云的资源选择交互无法看到已选中的资源做出的解决方案，利用这种方式，用户可以一眼看出哪些那些资源类型下有我选择的资源，点击即可跳转。

除此之外，如你所见，我修改为了表格结构，这有很多好处。现在表格的高度可以是固定的，多余的内容我可以进行分页处理，有效阻止因为资源过带来的上下滚动；运维现在选择资源的交互流程也更合理了，原本他们要点击添加按钮后在一个超极长的下拉菜单中选择，现在不需要了。

资源选择优化

除了刚才对布局的一些优化外，其实还有很多细节可以展开说。

在之前的版本，MaxCloud 就提供了推荐资源功能，会根据用户已经选择的资源推荐可能需要的依赖资源，但之前必须要用户手动勾选，这里除了强化了标签的样式，我还增加了一个开关，用户可以自动选择上推荐资源，进一步提速。

我还增加了筛选功能，你可以看到可以筛选资源的名称、以及其字段信息，例如所属的项目、集群、命名空间等等，这都是为了更好的让运维人员选择资源。

说到筛选，就不得不提到 label 选择资源的方式，原本的结构是一个利用命令行编写筛选代码的结构，为此还需要提供一个帮助说明，新的方式与阿里云很类似，但是我们提供了更灵活的方案，后续的验证中，运维们也是很满意的。

应用列表与修复

应用列表的查看应用和修复故障是一个完整的业务流程，因此我把他们合并在一起来介绍。

现状分析

我首先先花了一些去了解，用户到底在这页面做什么，怎么做的。我询问了运维同事们，他们和我反馈了他们是如何使用这个功能的。

对于 MaxCloud，应用列表的价值在于找到不健康的资源，修复故障的操作在于调整 Yaml 文件。所以我们是从这里入手，来进行优化的。

强化资源信息显示

在应用列表页面，想要突出应用资源效果，其实我做了许多版本的尝试，最后利用轻量的颜色横幅来达到的目的。

在这种状态下，包含不健康资源的应用卡片可以说是一目了然，只需要打开这个页面就可以一眼看到，但是又不会影响正常的画面信息阅读，这是我很满意的一点。

但是单纯这样还是远远不够的，我还增加了一套排序方式，可以从 2 个角度来说，一是故障应用前置，二是故障资源置顶，让信息出现在首屏。同时我还单独开了一个叫做故障的分页，帮助运维人员更好的筛选。

引入智能化

故障修复的智能化是一个很有讨论话题的地方，在这里我和运维人员做了很多的沟通。原因不在于 AI 效果是不是很好，而是 AI 要怎么用他们可以接受。

梳理 AI 的边界

在当时，是没有现在的 Agent、RAG 技术的，只有提示词工程，但其实这都不重要，因为即使到了现在，这些云服务产品都不允许 AI 直接上手修改代码，这个代码的错误成本不是一个按钮点击跳错了页面页面一样，代价不是很大，可能带来的后果是恐怖的。

就像我说的，我在这里花了不少时间和运维一起讨论，明确到底什么可以 AI，什么不可以。特别是在 2023 年，那时候各大企业也不知道该如何利用 AI 赋能。

你会发现我明确要求了 AI 可以做什么，不可以做什么，例如绝对不允许 AI 直接上手修改 Yaml，但是 AI 可以参与问题检查，这都是我们讨论出来的结果。

我利用 AI 帮助运维了解报错故障，以及提供了问题建议甚至是定位可能的错误问题代码区域，但是把真正决策的权力交给“人”而不是 AI。开个玩笑话，人可以“背锅”，AI 不可以，不是吗？

总结与复盘

这个项目我大概做了 2 个月的时间，在我离职后，我依然和这些运维、开发人员有一些联系，成为了很不错的朋友。也因此收获到了不少很好的评价，也了解到了我的数据是有正向反馈的。

这个项目是我参与的第一个大型 Saas 产品的体验优化，对我来说是完全新颖的、有趣的。我在这个过程中学到了很多关于运维部署的业务逻辑，同时认识了不少出色的技术同事，我深刻的体会到了一个 B 端产品在企业内部支持的过程中，用户调研有多么直接且有效。

在当时，我也参与了整个设计组件库的搭建（是的，我真的很喜欢组件库），利用 MUI 的可配置化样式，最后我们打造了一套设计与开发同步的完美的组件库，就像你看到的一样，它很有科技感也很酷，很符合一款云端产品的质感，再次感谢其他的设计同事和开发人员！