ABB internship
An online workshop platform based on multi-device collaboration in the form of game cards.
Info
UXDA, Group work in 7
Contribution
UX Design, Visual Design, User research
Duration
7/2022 - 9/2022 (8 weeks)
ABB和CommonUX设计系统
ABB是电气和自动化行业的世界500强企业，为制造业、公共设施等领域提供工程设备、工程方案、售前售后和工业物联网服务。
CommonUX Design System是ABB自研的设计系统，助力软件产品高效研发和品牌传播一致性。它经历了从企业级到团队级的分化，目前刚刚开启“重新整合到企业级的项目”。
在实习中，我负责团队级设计系统的优化和开发辅助工作；同时参与“整合项目”讨论和测试当中。
团队级设计系统
我所在团队的设计系统包括面向设计师的UI工具包、面向开发的组件代码库、和帮助传播设计系统的文档，目前它的主要用户是团队内6位UX/UI设计师。
我在实习中的工作涉及UI工具包和文档两个方面，目标是弥合设计系统和设计项目需求的差异。
我完成了……
-
近20种UI组件的修复或优化
-
3种移动端UI组件设计
-
30+种组件的测试和文档
-
100+个图标设计
-
应用新版design tokens到团队级设计系统
下滑看我具体怎么做⬇️
Design Process
当前组件库中，许多组件存在功能不适应项目和结构冗余的情况，以tooltip组件为例，看看我是如何解决问题的。
当前状态
tooltip是一个使用非常广泛、灵活的组件，适用于在桌面端添加各类说明信息。根据figma library的统计，tooltip在各类设计项目中已有超过1000个实例。
用户评价
2.0版本的tooltip在功能上有许多问题。这是项目设计师们的评价：“非常难用、难以调整的组件，有太多需要调整的层级”“预设的不同padding尺寸无法发挥作用，需要大量手动调整”
问题由来
-
设计师在制作tooltip时没有考虑到在项目中的使用体验；
-
对比其他主流设计系统，ABB的tooltip需求增加了设计难度。
设计目标
设计目标非常显著：减少组件层级；使组件在设计项目中易于使用。但难点在于平衡组件层级与样式、功能的要求。
改进思路1：
我调查了其他设计系统的tooltip，发现它们的样式和功能都更加简单。如果去掉描边或者箭头，tooltip的层级可以非常简洁。
因此我提出了第一个改进选项：使部分样式和功能设计让步，简化tooltip。但经过讨论和测试，我们认为在ABB的产品情况下，保持原来的设计是必要的。
改进思路2：
我提出了第二个改进选项：改变组件的架构，以不同方式组合figma的功能，找到最优解。
这是最后的设计结果！
与改进前相比，它……
-
没有削减任何功能或样式设计
-
减少了3个层级，设计师只需将组件展开一次就能调整所有参数
-
在使用中不需要手动调节padding
小结
这项工作提高了设计师在项目中调整组件的效率，使组件库更好用。
设计绝不只是做外观。表面上看起来新设计与旧设计没有差异，但使用体验有很大提升。
重新设计不是为了让设计前后看起来差别巨大，而是为了解决问题。
Design Process
问题和目标
ABB图标库现在没有专人负责更新，跟不上项目需求。设计师们在每个项目中独立做的图标，存在没有完全follow指南、一致性差、区分度差、尺寸不全等问题。
我的任务是把这些图标按照ABB设计系统图标库的标准，重新制作并扩展到三种尺寸。
关注点
我在重新设计时主要关心以下问题：
-
遵循ABB品牌指南中的icon设计规范
-
与其他icon保持语义和视觉上的一致性
-
保持icon之间的区分度
-
注意不同尺寸间图形的区别和像素级完美
工作流程
1. 图标清单更新
2. 确认需要制作的
3. 学习内部的图标设计规则
4. 正式制作
5. review、测试和修改
6. 交付
设计结果
最终的成果成功应用到项目中，得到了项目设计师好评。
Design Process
设计系统2.0的组件优先为桌面端设计，其中大部分组件可与移动端通用，因此缺失了一些只会在移动端出现的组件——其中最重要的是两个mobile UI shell组件：header和bottom navigation。
任务：为设计系统2.0添加新的移动端组件Native header和Native bottom navigation。
如何设计新的组件？
调查
首先我进行了两方面调查：
1、用例：组件设计不是从零开始的，它更像一项“整合”工作。我搜集了“库存”——过去的项目中，标题和导航栏是什么样的？这使我清楚已经存在的设计。
2、优秀参考：其他公司如何设计类似的组件？能学到什么？这里主要参考的是ios和安卓的原生组件。
范围
接着，主要是根据产品用例，我创建了“设计范围”——对于“需要做一个怎样的设计”做出总结。这也是我的设计指南。
很快我完成了第一个版本的原型。
测试
我请团队内两位有丰富移动端产品经验的设计师试用原型，之后进行讨论。我们交流了一些疑问，最后我根据反馈总结了改进方案。
设计结果
-
向CommonUX 2.0添加了2种适应IOS、Android、平板电脑三类系统的组件，满足不同项目自定义需求
-
其中Native header的功能有：4种层级主标题、可选副标题、可自定义按钮组、常用控件（搜索栏、标签栏）
-
Native bottom navigationr的功能有：可选入口按钮数量、可选文字标签、适应不同位数的标记、4种状态
-
2种组件广泛应用于移动端设计项目，已被创建近300个instance
小结
这项工作扩展了设计系统组件库的范围。
调研、确定设计范围和执行环节同等重要，是不可或缺的。
快速做出原型，尽早在尽可能真实的环境下开始测试。
Design Process
我完成了所有共30多个组件的测试和文档制作，形成可复用的记录模板和信息框架，产出的文档协助、推动了开发。
用户和需求
目前文档的主要用户是组件代码库的开发工程师，文档是他们的参考资料，确保开发时不遗漏组件功能和变体，提高还原度。
此外项目设计师和设计系统的设计师也是文档的用户，对于项目设计师，文档是设计指南，帮助他们针对特定use case选择和自定义组件；对于设计系统设计师，文档是backlog，帮助回忆、沟通设计组件时的想法。
目标
我的目标是产出全面、易懂的组件功能文档，协助开发中的沟通和设计系统传播。
针对全面这个目标，我的办法是形成一套“文档中应该包含的信息维度”。探索每个组件时都从这些角度出发，避免遗漏。
针对易懂这个目标，我为组件功能制作用例，用具像化的方式呈现功能。
这是其中一份档产出，这些文档是开发工作的重要参考。
对于我来说，这项工作是个很好的学习过程。我得以深入了解交互界面的基础元件是怎么工作的，现在做设计时我能更有逻辑地选择适合的交互范式，而不是仅凭模糊的感受。
进一步了解我的工作思路、我学到了什么➡️阅读这篇文章
实习小结
除了完成设计工作，我在4个月的实习中还有这两个key learnings：
1、沟通！
沟通在工作中占据的时间超出我的想象。我意识到设计作为一个承上启下的岗位，不可避免地承担较多沟通职责。我也体会到communication和storytelling的重要性。做出好的设计很重要，以恰当地信息传达方式，让其他人意识到、理解你工作的价值同等重要。
2、从更大的角度思考
设计师需要跳出自己的视野、换位思考。不论是从客户的角度出发，还是从整个团队的角度看待工作，跳出自我的边界有助于做出更具建设性的设计决定。
