从 UCloud 控制台，看 B 端产品体验设计

让用户熟悉的控制台

您听说过平均脸的概念吗？人类学家弗朗西斯•高尔顿（ Francis Galton ）偶然发现，将许多的人像合成后，看起来会比任何一张更友善。越是对一张脸感觉熟悉，那么在认知过程中大脑所需的处理资源就越少， 也就越没有负担，容易亲近。

图片来源： http://faceresearch.org/

随着公司业务的不断发展，UCloud 的产品已经跨过了单纯满足用户功能需求的阶段，用户对于控制台使用体验上的要求在不断提高。正如大部分 B 端产品一样，云产品控制台的本质是一种工具。工具的意义在于帮助用户达到最终想要的结果，无关乎流量、使用时长，甚至用户粘性。因此，在视觉上需要减少对于用户的负担和干扰。体验良好的控制台 UI 就如同平均的脸,围绕这一想法，我们在设计过程中重点关注了三个层面的问题，尽量在视觉上做到简单、熟悉。

色彩

国人受文化和习惯的影响，更适应浅色的界面。在整体色彩上我们选择了以白色为主的设计。但由于色彩比较淡，在测试过程中，一些用户会产生视觉疲劳的问题，我们又专门对文字和背景颜色的对比度进行了优化。

优化后的版本 优化前的版本

在整体配色较浅的基础上，为了更加美观，我们还对核心操作按钮等位置进行了优化，使用了高饱和度的品牌色。就好比平均的脸只耐看，第二性征强的脸更吸引人。高饱和度的按钮就好像女性的长睫毛、男性的高鼻梁一样，能够提升界面的吸引力。也帮助这些高频操作更容易被辨识。

布局

在布局方面，由于云计算产品的展示内容较多，各产品的操作逻辑也不相同，老版本上用户可能需要对每个产品独立进行学习，造成了额外的学习成本。新版借鉴了用户熟悉的标签、卡片（画框）和文件路径等概念，尽量将所有产品的操作方式纳入到同一体系内。

以云主机页面为例，所有功能都可以保持相同的页面体结构，且每个页面的交互方式都是一致的。

过程中也经历了反复的测试与迭代。例如在标签设计的过程中，原本标签头部和主体内容的背景是分离的。但在测试中发现，有些用户无法将分离的头部和内容联系起来，故在后续方案中做了调整。

内容

内容的展示上，我们也围绕减轻认知负担做了有许多优化和定义。以文字来说，或许大家听说过前两年的一则趣闻：我们在学生时代都曾为印刷得密密麻麻的试卷而头疼过，而杭州的一所小学，在某次五年级的数学考试中放大了试卷的字号和行距，学生的考试成绩也随之提高了。

图片来源： http://news.sina.com.cn/s/wh/2017-11-23/doc-ifypathz5329709.shtml

舒适的字体和间距比例能够减少大脑在加工信息时的负担，在美国甚至有专门的国家标准（ ANSI/HFS 100-1988 ）。但文字也不是越大越好，访问 UCloud 控制台的终端屏幕分辨率并不高，很大一部分还处于 720P 的水准，但这些用户仍希望能够在一屏内显示更多的数据。为了回应用户需求，兼顾阅读体验，我们制定了自己的字体规范。

其它

除了整体的色彩、布局和内容外，我们还对许多细节和超过 60 个控件进行了更新。例如，老版本的时间选择控件需要分开选择起始和结束时间，时间选择上也不够灵活。同时每次选择完成后需要点击三次确认按钮。新版本中优化了这一问题。

让同事轻松的控制台

在设计领域有许多以用户为中心做设计（ UCD —— User Centered Design ）的方法论，但对如何服务商业目标鲜有考虑。如同一篇很棒的设计文章中说的一样，UCD 和 BCD （ Business Centered Design / 以商业为中心的设计）似乎是矛盾的两个方向。就好像技术出众，但少有问津的产品屡见不鲜。而设计出色，叫好不叫座的产品也不少。不兼顾体验与商业的设计很难成功。

例如产品经理希望尽量减少研发和设计的投入，快速拼搭一个有品质保障的 MVP （最小可行产品）进行市场验证。如果新的控制台 UI 框架能够让设计、前端和产品的同事使用起来更轻松、高效，就可以快速且持续地缩短产品开发周期，抓住稍纵即逝的商业机会并降低研发成本。

为了兼顾商业考量，我们在提升体验的基础上，引入了原子设计的概念。并配合实际情况，做了一定调整。UCloud 的控制台 UI 框架分为了四个层次，依次为：原子、组件、模块和页面。

原子

原子层包含有颜色、字体、阴影、间距等基本样式。拿颜色举例来说，设计过程中严格限制颜色的使用，所有颜色不以具体色值定义，而使用有限的颜色代号。如此一来，所有页面元素使用统一而规范的颜色代号，需要对色彩进行调整时，仅需要改变代号对应的色值即可，无需分别替换修改。

组件

组件层顾名思义，是各类组件的集合。为了适应公司内部的组织架构，增强灵活性，我们将组件分为通用组件和业务组件两类。由于云计算产品五花八门，时常需要用到一些特殊组件。而公司用户体验中心（ UEC ）资源有限，如果所有组件都需要 UEC 设计和测试，会对产品开发和上线的时间产生影响。故对于特定产品的特殊组件，可以交给该产品团队自行设计，待有更多使用场景且打磨优化后再纳入通用组件中，交给 UEC 统一维护和管理。

同时在组件设计的过程中，我们重点考虑了组件的通用性问题。比如文本组件，看似无需专门设计，但除了原子层的样式定义外，我们还对于文本的换行逻辑、隐藏逻辑、最大行数等做了定义。这一考量能够让组件的使用者不必纠结于展示效果的问题，将精力放在业务本身上。在多语言适配的工作中也可以大幅节省开发成本。

模块

模块即是前文中提到的卡片。是基于实际使用场景产生的组件的集合。这些集合包裹在拥有统一规范和标准的卡片内，有相同的展示逻辑。

页面

即为整合后的页面。所有页面的结构是一致的，可分为全局导航、页内导航和容器视图三个部分。容器即是卡片的容器。

Sketch 插件

配合原子化设计概念，为了方便设计师和产品经理的使用，我们还提供了一套基于 sketch 的插件工具，并定期与规范以及前端代码同步。

UI 框架、平衡与利他

基于上述思想，经过多次的迭代与改进，全新的 UCloud 控制台 UI 框架已日臻完善。该框架是一个二合一的系统。既是一套成体系的视觉和交互设计规范，又是一套基于 React 的前端开发组件库。

UCloud 控制台 UI 框架是平衡了体验设计和商业后的自然结果。它能够适配各种功能和使用场景，不因内容变化而产生额外的适配工作。设计师和产品经理都能独立拼装出高质量的页面，也便于开发者的开发和维护。该设计规范符合用户的理解，操作线性、尽量减少逻辑分支，提供了良好的视觉感受和操作体验。也收获了用户的好评。

而对于内部开发效率的提升同样显著，交互、视觉、前端都免去了大量的重复性消耗。

过程中，我们也深刻感受到了利他思考的重要性。“ Deep experts hate nothing more than politicking ”——这是体验设计专家 Jakob Nielsen 对于 B 端产品用户的评价。如果要给 B 端产品用户（特别是技术产品用户）画像，那么这句话一定是用户画像的核心。B 端设计是利他的。利他即是利己。

写在最后

UCloud 控制台 UI 框架并不是一蹴而就的，也经历了许多困难与反复，在此需要特别感谢前端团队的付出，这一项目也是双方共同努力的结果。