top of page

ABB internship

提升ABB CommonUX设计系统2.0的适用范围和易用性
公司

ABB Oy, 运动控制设计团队

我的角色

UX/UI设计师

时间

5/2022 - 8/2022(4个月)

0-1.jpg
0-2.jpg

ABB和CommonUX设计系统

ABB是电气和自动化行业的世界500强企业,为制造业、公共设施等领域提供工程设备、工程方案、售前售后和工业物联网服务。

CommonUX Design System是ABB自研的设计系统,助力软件产品高效研发和品牌传播一致性。它经历了从企业级到团队级的分化,目前刚刚开启“重新整合到企业级的项目”。
在实习中,我负责团队级设计系统的优化和开发辅助工作;同时参与“整合项目”讨论和测试当中。

0-2-1.jpg

团队级设计系统

我所在团队的设计系统包括面向设计师的UI工具包、面向开发的组件代码库、和帮助传播设计系统的文档,目前它的主要用户是团队内6位UX/UI设计师。
我在实习中的工作涉及UI工具包和文档两个方面,目标是弥合设计系统和设计项目需求的差异。

我完成了……

  • 近20种UI组件的修复或优化

  • 3种移动端UI组件设计

  • 30+种组件的测试和文档

  • 100+个图标设计

  • 应用新版design tokens到团队级设计系统

下滑看我具体怎么做⬇️

TASK1 提升组件的易用性

当前组件库中,许多组件存在功能不适应项目和结构冗余的情况,以tooltip组件为例,看看我是如何解决问题的。

Task1-2.jpg

当前状态

tooltip是一个使用非常广泛、灵活的组件,适用于在桌面端添加各类说明信息。根据figma library的统计,tooltip在各类设计项目中已有超过1000个实例。

用户评价

2.0版本的tooltip在功能上有许多问题。这是项目设计师们的评价:“非常难用、难以调整的组件,有太多需要调整的层级”“预设的不同padding尺寸无法发挥作用,需要大量手动调整”

Task1-3.jpg

​问题由来

  1. 设计师在制作tooltip时没有考虑到在项目中的使用体验;

  2. 对比其他主流设计系统,ABB的tooltip需求增加了设计难度。

Task1-3.jpg

设计目标

设计目标非常显著:减少组件层级;使组件在设计项目中易于使用。但难点在于平衡组件层级与样式、功能的要求。

Task1-4.jpg

改进思路1:

我调查了其他设计系统的tooltip,发现它们的样式和功能都更加简单。如果去掉描边或者箭头,tooltip的层级可以非常简洁。
因此我提出了第一个改进选项:使部分样式和功能设计让步,简化tooltip。但经过讨论和测试,我们认为在ABB的产品情况下,保持原来的设计是必要的。

Task1-5.jpg

改进思路2:

我提出了第二个改进选项:改变组件的架构,以不同方式组合figma的功能,找到最优解。

这是最后的设计结果!

与改进前相比,它……

  • 没有削减任何功能或样式设计

  • 减少了3个层级,设计师只需将组件展开一次就能调整所有参数

  • 在使用中不需要手动调节padding

小结

这项工作提高了设计师在项目中调整组件的效率,使组件库更好用。

设计绝不只是做外观。表面上看起来新设计与旧设计没有差异,但使用体验有很大提升。
重新设计不是为了让设计前后看起来差别巨大,而是为了解决问题。

TASK2 重新设计图标

Task4.jpg
Task2-2.jpg

问题和目标

ABB图标库现在没有专人负责更新,跟不上项目需求。设计师们在每个项目中独立做的图标,存在没有完全follow指南、一致性差、区分度差、尺寸不全等问题。

我的任务是把这些图标按照ABB设计系统图标库的标准,重新制作并扩展到三种尺寸。

Task2-3.jpg

关注点

我在重新设计时主要关心以下问题:

  1. 遵循ABB品牌指南中的icon设计规范

  2. 与其他icon保持语义和视觉上的一致性

  3. 保持icon之间的区分度

  4. 注意不同尺寸间图形的区别和像素级完美

Task2-4.jpg

工作流程

1. 图标清单更新
2. 确认需要制作的
3. 学习内部的图标设计规则
4. 正式制作
5. review、测试和修改
6. 交付

Task2-5.jpg

设计结果

最终的成果成功应用到项目中,得到了项目设计师好评。

进一步我的思路、遇到了哪些困难、学到了什么➡️阅读这篇文章

TASK3 添加移动端组件

设计系统2.0的组件优先为桌面端设计,其中大部分组件可与移动端通用,因此缺失了一些只会在移动端出现的组件——其中最重要的是两个mobile UI shell组件:header和bottom navigation。
任务:为设计系统2.0添加新的移动端组件Native header和Native bottom navigation。

Task2-1.jpg

如何设计新的组件?

Task2-2.jpg

调查

首先我进行了两方面调查:
1、用例:组件设计不是从零开始的,它更像一项“整合”工作。我搜集了“库存”——过去的项目中,标题和导航栏是什么样的?这使我清楚已经存在的设计。
2、优秀参考:其他公司如何设计类似的组件?能学到什么?这里主要参考的是ios和安卓的原生组件。

Task2-3.jpg

范围

接着,主要是根据产品用例,我创建了“设计范围”——对于“需要做一个怎样的设计”做出总结。这也是我的设计指南。

很快我完成了第一个版本的原型。

Task2-4.jpg

测试

我请团队内两位有丰富移动端产品经验的设计师试用原型,之后进行讨论。我们交流了一些疑问,最后我根据反馈总结了改进方案。

设计结果

  • 向CommonUX 2.0添加了2种适应IOS、Android、平板电脑三类系统的组件,满足不同项目自定义需求

  • 其中Native header的功能有:4种层级主标题、可选副标题、可自定义按钮组、常用控件(搜索栏、标签栏)

  • Native bottom navigationr的功能有:可选入口按钮数量、可选文字标签、适应不同位数的标记、4种状态

  • 2种组件广泛应用于移动端设计项目,已被创建近300个instance

小结

这项工作扩展了设计系统组件库的范围。

调研、确定设计范围和执行环节同等重要,是不可或缺的。
快速做出原型,尽早在尽可能真实的环境下开始测试。

TASK4 测试组件并制作文档,协助开发

Task3-2.jpg

我完成了所有共30多个组件的测试和文档制作,形成可复用的记录模板和信息框架,产出的文档协助、推动了开发。

Task4-2.jpg

用户和需求

目前文档的主要用户是组件代码库的开发工程师,文档是他们的参考资料,确保开发时不遗漏组件功能和变体,提高还原度。

此外项目设计师和设计系统的设计师也是文档的用户,对于项目设计师,文档是设计指南,帮助他们针对特定use case选择和自定义组件;对于设计系统设计师,文档是backlog,帮助回忆、沟通设计组件时的想法。

Task4-3.jpg

目标

我的目标是产出全面、易懂的组件功能文档,协助开发中的沟通和设计系统传播。

针对全面这个目标,我的办法是形成一套“文档中应该包含的信息维度”。探索每个组件时都从这些角度出发,避免遗漏。

针对易懂这个目标,我为组件功能制作用例,用具像化的方式呈现功能。

Task4-4.jpg

这是其中一份档产出,这些文档是开发工作的重要参考。
对于我来说,这项工作是个很好的学习过程。我得以深入了解交互界面的基础元件是怎么工作的,现在做设计时我能更有逻辑地选择适合的交互范式,而不是仅凭模糊的感受。
进一步了解我的工作思路、我学到了什么➡️阅读这篇文章

实习小结

除了完成设计工作,我在4个月的实习中还有这两个key learnings:

1、沟通!

沟通在工作中占据的时间超出我的想象。我意识到设计作为一个承上启下的岗位,不可避免地承担较多沟通职责。我也体会到communication和storytelling的重要性。做出好的设计很重要,以恰当地信息传达方式,让其他人意识到、理解你工作的价值同等重要。

2、从更大的角度思考

设计师需要跳出自己的视野、换位思考。不论是从客户的角度出发,还是从整个团队的角度看待工作,跳出自我的边界有助于做出更具建设性的设计决定。

bottom of page