Project 3

项目背景

入职后接到的第一个产品需求：负责跟进“DataHub2.0至3.0”产品升级中的设计需求。在跟进2个月时间DataHub3.0（以下缩写DH3.0）的产品需求后，发现一些问题：
1.不同产品之间设计人力分配不平衡；
2.组件调整级别的需求，花费过多设计人力；
3.设计规范不完整，影响了设计产出效率。
以上反应了设计师在工作流程中的“效率”问题，随着以后需求的叠加，想要把时间人力用在高优的需求上，需要解决上述问题。

产品简介

DataHub是一款数据接入与数据治理产品，提升数据研发效率、降低管理成本，为企业数据提供全面保障。

前期准备

构思：

根据当前的工作流程，除了解决设计侧的效率问题，我还想能够从上下游找到提升效率的点：
设计侧：面对上面提到的问题，对于设计侧主要原因是在产出时有太多的“变数”，从而影响了效率，比如：同一组件重复设计、缺乏一致规范导致过多决策时间。通过设计规范以及figma组件库可以解决设计侧的问题。并且为了在设计内部能够保持一致的步调，需要将产出的结果落成文档便于再次查阅。
产品侧：对于“组件级别调整”类型的需求，产品经理可以直接使用组件库进行搭建原型图，设计师进行审核即可交付开发。除此之外的需求仍然需要设计师人力。
开发侧：由于技术壁垒较高，我想从合作方式上入手 —— 降低开发人员认知成本统一组件命名。建立组件库也是提升开发人员效率的一种方式，可复用的内容多了，效率提升了。

调研：

与产品经理以及开发人员交流，了解方案的可行性。主要想要了解的是：部门的计划与产品阶段、建立与使用组件库会需要多少开发成本。沟通后明确：
1.DH3.0是处于mvp阶段的产品，体验要求不高无需投入过多的设计人力，可以和产品经理沟通清楚人力介入的场景；
2.开发人员使用element前端框架搭建网站，设计师可以通过上传设计规范控制前端样式，对新产品开发成本不高。

项目目标

整理数据产品基础“设计规范”，保证设计输出的一致性，以DH3.0为试点提升mvp阶段产品的设计产出效率。

整理过程

Step1 整理全部组件：

为了平台产品的一致性，将平台所有产品中用到的组件梳理出来，按照element上组件的类别来区分再加以补充。但由于业务的特殊性，也会有一些element上缺少的组件样式，将其归类为“业务组件”，放置在通用组件后去处理。在过程中可以发现很多组件都有多余的样式以及缺少样式的情况，我将其记录下来，在定好规范后统一整理。

Step2 基础组件：

将梳理出来的最主要的“基础通用组件”进行整理优化，主要是布局（栅格）/颜色/字体，由他们决定组件的基础样式，以及界面的基本形态。

Step3 通用组件与规范：

这一步按照产品中组件使用的频率产出组件与其使用规范，完成后再将组件其制定成Figma的组件库便于使用。并制定了组件

Step4 会议同步：

最后需要将完成的组件同步给工作流程中每个环节的负责人。不能让同事们一次接收太多需要·“小步前进”，我在完成高优先级“通用组件”后与相关人员进行了一次同步，因为已完成的内容对于mvp阶段的需求是已经足够的了。

最终影响

对内：我在处理DH3.0的需求效率更高了，还有额外的时间去处理其他的产品需求；对于新开发的产品也能够使用这套组件库搭建，相较于设计DH3.0设计师花费大量时间进行风格尝试，工期缩短了近一半。
对外：在完成规范后，非同一个部门的新产品要开发上线由于没有设计支持，产品经理使用了我们的组件库进行MVP阶段的产品搭建并投入开发。

思考总结

最后分享了一下自己的经验：
在产品阶段在迭代速度开始放缓时，设计师相对熟悉业务后开始着手整理设计规范。此时更具备规范落地的条件，同时设计师对于产品也更有经验能够按需整理。
‍
以及对于我的影响：
做设计规范对自己的提升，包含收集信息能力，归纳总结能力，沟通能力等。B端的设计规范想要落地其实并不是靠设计师这一环节努力就可以的，设计规范的建立本身就考验设计团队包括设计能力以及推动落地的能力；一个设计规范能够成为团队内的共识是多方共同协作的结果，这些对我来说收获是巨大的，也是难得的一次自我提升机会。

“灯塔”数据产品“组件库”整理