今天主要改版的对象，是一个我忍了很久，也被折磨了很久的东西 —— 腾讯云产品列表菜单。

简单介绍一下，就在登录到系统后台以后，置于顶部的一个折叠菜单，通过鼠标悬浮展开，然后菜单面板中罗列腾讯云的相关产品条目。

问题分析

因为腾讯云包含的产品数量太多，所以这个菜单做了5列，且因为还是容纳不完所以可以上下进行滚动。下面是完整的菜单截图。粗略算了下有67个产品类型，每个类型有1到20个不等的子服务，你们可以感受一下...

是不是看了已经眼花缭乱了，你们可以理解成它就是一个导航栏，如果使用腾讯云通常你不会只开通一个服务，往往会关联开启好几个不同的服务，所以经常要在服务间跳转，或者打算开通新的服务，而正常使用这个菜单的体验只能用灾难形容。

理论上，对自己启用服务熟悉的情况下，使用输入框去来搜就行了，但类似我这种非专业后端或运维的用户来讲，很多名词是没记下来的，过后不一定记得叫什么，然后只能在这个列表里翻……

关于体验上罄竹难书的问题先不继续展开，我们就直接开始分析如何对它进行优化的思路。提前声明，类似这个菜单的优化属于组件级优化，主要覆盖的方向包含 体验设计、交互设计和信息设计，通过对信息展示和交互的优化来提升菜单使用的效率。

首先梳理一遍这个组件的功能模块，如下图所示：

在这个框架下，首先拆分成了左右两栏，左边上方是快捷访问，下方是平台工具。右侧上方是访问记录、搜索，下方是产品的列表。

先抛开产品列表不谈，快捷访问这个功能在初期没启用是空的，而平台工具是相对低频的工具，所以用户前期使用必然以右侧模块为主。

最近而搜索栏距离云产品按钮距离又过长，搜索的结果又是左对齐的。不仅操作距离长，视觉聚焦的位置移动跨度也很大，周边干扰的元素又非常多，很难聚焦到关键的要素。

如果搜索的结果多，包含多个分类，那么又会根据之前的所在列生成结果，形成多列的搜索结果，并且单列超出依旧要上下滚动才能看到……

然后我们再看具体的产品列表，虽然包含5列，但你们仔细看其实每列的宽度是不一致的，而且标题左右的间距往往非常小，粘合在一起。

同时，如果我们以找出某个服务为目标按续逐一查看这些标题的话，那么浏览的顺序就是先从左侧第一列向下看，滚动完3、4屏高度以后，回到顶部开始看第二列，然后再滚动3、4屏高度再返回顶部。

这是完全不符合我们正常的 F 型浏览习惯，因为使用左右查看的话，不同分类高度不一致，很难把握住检索的完整性，会漏看或重看，过程是很折磨的，比如下面这样（已经开始气了……）：

虽然这些产品服务是根据一定的逻辑做出的排列顺序，比如数据库类产品显然靠的比较近，但好像又不完全是，我没办法去建立对这个排序规则的认知，那么内容对于我来讲就是 “无序”的。

而且每个产品的分类虽然只是文本不能点击，但是置灰的做法对于识别没有任何提升，它的权重被过度削弱不利于检索的效率。

最后还有就是部分服务属于我已经开通了的，不打快捷访问不能标记出来，这是作为新用户而言不能接受的（不管你背后有什么考虑）。

改版说明

所以，对它的优化我要做出这几点改动：

1. 优化整体布局，减少组件中模块的不规则组合感

2. 优化搜索相关的交互，提高搜索效率和体验

3. 增加对已开通产品的筛选更好的找到正在使用的服务

4. 对产品类别进行组织，构建相关的展示排序逻辑

5. 优化产品列表排列形式，顺应用户的浏览习惯

步骤1：基础框架构建

我的第一步就是重构这个组件的框架，不再做成左右两栏，而是做成上下两栏。上面是搜索和历史栏，下面是产品列表栏。

其中，搜索栏是固定悬浮视图，而产品列表栏是一个滚动视图，列表滚动不影响顶栏。并且快速访问模块打算做到产品列表内，默认情况下不开启，只有用户添加快捷方式以后，才会出现。

步骤2：构建列表的信息展示形式

前面说过，产品虽然分类多，但这些分类显然是有一定相关性的，我们可以对它们进行归类。同时，我们还要对它们进行排序，但是使用字母顺序的排序显然是不符合业务需求的，因为很多核心业务的初始文字都是非常靠后的字母，如云服务、平台、数据等，所以排序是根据服务的热门程度和重要性来定的。

所以在列表的展示里，我要按传统一点的导航来制作，左侧放合并的1级分类导航（大致加的，不是很严谨，忽略这个细节），右侧放对应的产品列表，可以通过左侧导航快速进行大分类的页面滚动定位。并且，确保浏览的顺序是符合 F 型的先左右，后向下的单列排序模式。

步骤3：开始正式制作细节的原型

有了框架的规划，下一步开始具体的制作。首先就是确定这个菜单要做多大的问题，原来的设计中，菜单用的大概是1280px的宽，但实际使用过程中，我们如果用笔记本经常会缩小窗口，菜单也没有做窗口自适应，导致右侧内容展示不全，比如下面这样。

所以，我定义菜单的初始宽度为 980px，减少可视区域的宽度，提升浏览效率。因为腾讯云内容页本身支持响应式，那么没理由不让这个菜单不支持，所以我的设计结构也要确保这个响应式可用。

接着就是在这个在这个画布中完成对应的原型设计，因为产品数量太多，属于沿用原本12px的字号，以及在列表中使用教小的间距，确保显示的密度和数量够大。

其中，移除掉图标的应用，实际测试下来，图标在整个组件范围里没有起到任何作用，我们不可能通过它来识别模块，也不需要它在这个场景下提升视觉氛围或者效果。下图是加了和没加的区别。

而之后建立的信息检索逻辑，就是先从列表中的标题列开始看起，找到对应的大类再进入下级列表查看。即使是用普通的 F型逐一排查，页不需要来回进行滚动。

步骤4：对相关交互的拓展

之后完成相关的交互的操作，首先就是搜索和启用服务的筛选，它们的筛选结果样式是基本一致的。

然后是关于响应的应用，宽度上缩小后产品列表可以排列到第二行去，时间关系我就不做解释了。

最后，改完以后，我们再简单做个对比

结尾

时间关系其实还有很多想试的改法没空做了，暂时就用最好实现的版本来完成。

这里也有一点想法要提供的，就是对于面向 SaaS使用的产品，一些模块的设计和规划，是要向“可用性”看齐的，而不是完全根据“业务指导”，否则最基础的可用性缺失那么其它的规划就都没有意义。

后面有机会再对官网页面和系统中其它的管理页面做优化思路的分享，有什么云服务产品使用体验中想吐槽的，也可以私信发给我。

如果想要深入学习提升变强，就快来B端产品设计全能班学习吧，感受一把投入学习的快乐！

即刻预约立刻开学～