CodeArts —— 华为云
CodeArts 是华为云的一站式 DevOps 平台——需求、代码托管、代码检查、流水线、构建、测试和发布，汇在一条生产线上。它源自华为自己三十年的工程实践，并作为云服务向外部团队提供。
- 角色
- UI 设计师
- 团队
- 华为云 · UCD
- 时间
- 2021–2022
- 成果
- 平台视觉系统、多端规范、2023 iF 设计奖
背景
CodeArts 是一个平台，托起二十多个不同的工具——代码检查、构建、测试、流水线、部署，以及交付生命周期的其余环节。它一开始并不叫这个名字：它以 DevCloud 之名发布，是华为内部工程实践的封装、对外开放，到 2021 年已经长成这次改版所覆盖的整条工具链。
有两个问题让平台变得不一致。每个服务团队按自己的节奏发版，而已有的设计规范落后于技术需求，各团队的理解也不一致。导航深度、层级、工具栏逻辑、界面密度，都因工具而异，用户在平台里移动时得反复重新学习界面。
这就是这次改版要修的：不是任何单个界面长什么样，而是用一套共享的、最新的设计规范，替换掉已经不适合平台的旧规范——一次从 DevCloud 到 CodeArts 的品牌重塑，以及它底下的视觉与结构系统，横跨桌面、移动和平板。
难的从来不是某一个界面；难的是在许多独立运作的团队之间，让同一套语言保持连贯。
这次改变，落在整个表面上
不是单个界面——是整套工作集。仪表盘、看板、流水线、代码评审：旧的 DevCloud 标志和扁平的灰色界面框架，在各处被同一套 CodeArts 标识和布局规则替换。
- 改版前 · DevCloud
九个界面，九套略有不同的页头、工具栏和卡片处理——每个服务团队对品牌的各自解读。
- 改版后 · CodeArts
同样的九个界面，一套身份、一套页头模式、一套卡片语言——一眼看去是同一个产品。
起点
诊断对应上从平台用户处独立收集到的八条反复出现的抱怨。我把它们归入四个设计方向，并把每一个都转译为服务团队可落地的策略。
布局没把重要的东西凸显出来——想找我关心的信息很难。
希望优先级更清晰——现在所有信息都在抢注意力。
希望它看起来是真正用心设计过的，而不只是能用。
希望它看起来清新、干净、有意思。
颜色搭配不够协调。
缺少一种技术感、让人投入的感觉——和我的角色不搭。
界面元素显得过时，不够精致。
希望它的行为方式贴近现实。
统一每个服务的导航结构和样式。
一套系统化的规范和组件集，配更宽的颜色层级。
用色块和卡片，让信息一眼可读。
去掉多余的线条、阴影和装饰性碎片。
在每个服务上统一表格和工具栏的模式。
把每个服务都迁到同一个共享组件库上。
对设计和工程都做一致性检查。
给单个组件加上插画和动效。
我的贡献
我是平台视觉改版的主 UI 设计师，与一位 UX 设计师协作，并在资深设计的指导下工作。我撰写了视觉规范中相当一部分内容，也参与了承载它的组件库 DevUI。规范跨越许多模块；这里展示其中五个——颜色、阴影、圆角、字体和间距——它们跨桌面、移动和平板发布。
更难的部分，是在独立运作的服务团队之间让这套标准活下去：评审落地、处理边界情况，并在真实产品暴露出缺口时更新规则。整个过程里，我交付了 50 多个高保真原型，并对照不断演进的标准评审了其他团队的产出。这套规范对每个服务团队都是强制的。上线前，包括我在内的设计师会对每个落地实现给出通过/不通过的结论，按间距、色值等维度标注不通过的问题，并逐项追踪到关闭。
这份工作实际包含什么
- 撰写
写标准：许多个模块的视觉指南，这里展示五个，外加参与那个让它们可用的组件库。
- 为场景做规范
同一个 token 在手机上和在宽屏桌面上的行为并不一样。颜色、阴影和圆角是按设备场景分别规范的，而不是全局定一次。
- 治理
对照标准评审其他团队的产出，并在某个产品有规范没预料到的正当理由时，扩展这套标准。
规范中的五个模块
从一份更大的规范中选出的模块，每个都带有使用规则和范例，供团队在产品和设备场景之间应用这套系统。
发生了什么改变
一项由独立用研团队开展、并与项目团队共享的发布后问卷表明，在六项指标上相比此前的界面有所改善。
用户问卷——相比上一版的改善幅度
同期的项目材料还报告了 770 多个新增平台注册。CodeArts IDE 后来获得 2023 年 iF 设计奖iF DesignCodeArts — iF Design Award 2023 winner listingOfficial award listing, category Software Development / IDE, crediting the Huawei Technologies design team.。我被列入官方设计团队；我直接负责的部分包括 DevPocket 移动端界面和更广的平台 UI 系统，而不是整个 IDE 桌面产品。
四年之后
什么留了下来
CodeArts 至今仍在线上，仍由华为云积极开发，这让它成了这份作品集里少数几个我能在多年后回头验证“那些决定到底站不站得住”的地方。有些站住了。导航层级——对每个服务，一、二、三级都用同一套一致的模式——留了下来。它解决的那个问题，曾随着平台变大越来越糟，而不是越来越好。
什么不得不演进
有些没站住，而且我还在那儿的时候就发现了。圆角先坏：一个全局单值在卡片上看着对，放到嵌套弹层的尺寸上就看着不对，于是规范不得不长出一条按层级区分的规则。标签页文字从用户那儿反馈回来，说在真实工作条件下难以辨读——不是在评审里。这两次都是中心设计团队写的规则，被真实使用纠正了——这是规范正常运作的方式，不是它的失败。一套系统到底好不好，要到多年之后、当有人不得不加进一个你从未规划过的东西时，才见分晓。
反思
Flow 教会我在一个产品内部搭建系统。CodeArts 教会我更难的版本：在产品之间维护一套标准，横跨那些有自己截止日期、也有理由偏离的团队。定义标准只是一半的工作；另一半是评审、协商和修订。
它也第一次给了我证据：有用的问题不是一个设计在发布当天对不对，而是我离开之后，别人能不能继续用下去——修正错的地方，并扩展到当初没人规划过的场景。这也是我至今在工作中会先问的问题，哪怕那份工作和软件毫无关系。