大总管默默

有很多读者想要了解关于组件更新和优化的工作流程和经验,我最近经常会收到如下问题:

– 😵 组件的更新需要怎样的工作流程呢?

– 😟 组件在更新与维护的过程中,设计与前端要如何配合呢?

– 🤔 组件设计师和其他设计师的工作有什么区别呢?

 

其实组件库的建设和优化工作其实并没有绝对的标准,只有适合自己团队的工作流程,才是真正有效和实用的。具体到每一个组件的更新优化,我的经验是:从「发现组件的存在的问题」到「将组件进行更新和修复」,优化流程大致会被归纳成五个步骤:

Step 1.  搜集组件问题及优化需求

Step 2.  探究分析组件的优化方案

Step 3.  设计优化方案并进行评审

Step 4.  开发方案完成并进行验收

Step 5.  发布上线并同步组件更新

图片

 

STEP 1 搜集

搜集组件问题及优化需求

如果你希望你的组件库可以与时俱进、赋能业务,定期搜集组件问题和设计师们的使用反馈就很有必要。通常组件问题和需求可能来源于:

– 设计师 / 开发在使用组件做业务时发现的组件问题;

– 设计师 / 开发发现其他优秀的组件库案例中有值得借鉴之处;

– 设计师在使用组件的过程中觉得不方便、不易用

– 产品的用户反馈某些功能或局部模块在使用时体验不好等等。

收集和整理问题需要一张需求列表。你可以通过需求类型、完成状态、负责人等方面对需求进行描述。同时你也需要对需求定义优先级,确定排期和完成时间。下图为需求列表的基础示例:

图片

·  参与人员:使用组件的设计师和前端开发。

·  所用时间:不定期反馈和收集。

·  所用工具:公共的开放文档或看板(比如语雀文档、数据表、讨论区等)对收集需求会有一定帮助,可以使其他设计师在做设计的过程中,遇到组件问题就自发填写需求列表,实时共享。组件负责人将需求归类整理、做好排期即可。

 

📋 TIPS:

1.群策群力,用制度约束行为

收集组件问题需要使用组件的所有设计师群策群力,但是设计师遇到问题忙着做需求来不及记录是常有的事情。因此必要时可以采用简单的制度来做约束,比如每个设计师每月必须提交 1-2 个组件设计优化想法,或者每季度评审「组件问题查缺补漏」一二三名,给予精神或物质奖励。

2.评估需求,不是所有需求都值得优化

你需要判断这些需求的真伪和轻重缓急。并不是所有的组件设计需求都需要被立即优化,区分优先级和做好排期很重要。你可以参考以下内容对需求进行综合评估:

– 设计和开发当前可用资源

– 设计优化内容难易程度

– 组件在业务中出现的频率

– 业务需求的紧急程度

– 组件的通用程度和扩展性等等

3.指定到人,每个需求进度易追查

如果组件设计小组人数充足,组件负责人也可以安排指定的组件设计师来完成对应需求,因此需要指定到专人,并在表单中有体现,便于联系和实时沟通。

 

STEP 2 探究

探究分析组件的优化方案

这需要对你上一步搜集到的问题和需求进行分析和研究。对于业务组件的研究,我的建议是:一定要带入到业务场景进行考虑。你可以通过两个方面来做组件分析和研究:

一是竞品中类似的业务场景:收集和分析同类产品或类似功能场景下的实际应用案例。已经成熟的产品会更有说服力,也更值得被参考。

二是其他组件库的解决方案:收集和分析其他优秀设计系统 / 组件库中的同款组件案例,熟知的如 Ant Design、Material Design、Lightening Design、Carbon Design、SAP Fiori Design 等等。

当然你也需要综合应用一切可行的设计方法和工具,通过学习竞品、研读文章、与有经验的设计师交流讨论(也欢迎向我提问和讨论😊)、做 AB Test 等方法,研究合理的解决方案。

·  参与人员:指定的组件设计师。

·  所用时间:2-3 天。

·  所用工具:公共的开放文档或设计文档。

 

STEP 3 设计

设计优化方案并进行评审

当设计师根据上一步的研究分析,产出优化后的组件设计稿,就可以组织或邀请团队中其他设计师(尤其是组件问题的提出者)和开发对组件设计方案进行检验和评审。

评审通过后,进入组件的代码开发阶段;评审不通过,收集意见再进行修改、更新和二次评审。

·  参与人员:组件设计师、使用组件的设计师和前端开发。

·  所用时间:2-3 天。

·  所用工具:公共的开放文档或设计文档、线上或线下会议。

 

📋 TIPS:

1.有理有据,分析过程要保留

「组件优化的评审」比「业务需求设计评审」更加注重设计分析依据。因为组件评审人以设计师为主,而业务需求的评审人以业务和产品为主。设计师们之间的交流更需要有充分的证据和思考流程。

2.建立标准,评估更快捷

你可以根据组件库的设计原则,建立组件设计的评审标准,根据标准和原则来进行设计评审,可以有效避免不必要的争论。

3.业务先行,先完成业务需求

有时组件设计和业务设计是同时进行的,任何时候都要遵守「业务先行」的规则。组件设计师可以先配合业务设计师,完成当前业务的需求,之后再将组件进行通用性沉淀。业务应用也是对组件最好的检验场景。

 

STEP 4 开发

开发方案完成并进行验收

这一步由开发将组件的优化方案落实到代码,完成组件。开发完成后,需由组件设计师进行走查。完成的内容和质量反馈可以补充到上文所提到的「组件优化需求列表」中,易于追查。

·  参与人员:组件设计师、前端开发。

·  所用时间:2-3 天。

·  所用工具:公共的开放文档、开发稿、线上或线下会议。

 

STEP 5 发布

发布上线并同步组件更新

组件的上新「发布」包括几件事情:

一是将组件库的设计 Toolkits 线上开发使用库进行更新;

二是补充和编写组件更新后的使用规范;

三是团队的更新事项同步,要做到所有成员的使用版本保持最新和统一。

·  参与人员:组件设计师、使用组件的设计师和前端开发。

·  所用时间:1-2 天。

·  所用工具:公共的开放文档、线上及线下组件库、线上或线下会议。

 

📋 TIPS:

1.规则简洁,好记才好用

关于组件的使用规则,我们曾经在文章:如何让「设计规范」被有效执行和落地?一文中做出过详细的讲解,设计规范的内容表达方式要「接地气」,拒绝「假大空」,好记才好用。

2.定期同步,有规律、可预期

有规律地同步组件优化进度。可以以周会的形式,将本周更新的组件内容同步给团队中的所有成员;或者以月报的形式,每月通过邮件发布组件工作和优化进度,以达到全员知晓。

3.重在稳定,避免频繁更新

组件库的更新和迭代的时间不宜过于频繁,小的修改和优化,比如组件的局部细节调整、次要颜色的色号更新等可以以周 / 月为单位进行统一迭代;大的优化和升级,比如设计风格更新导致的主题色、圆角、交互形式的优化则推荐以年为单位进行更新。

 

原文链接:长弓小子(公众号)

作者:元尧

转载请注明:学UI网 » 工作经验|设计组件的更新和优化,需要哪些流程?

登录收藏
 
你可能喜欢的:
APP中的折叠菜单应该如何设计?先看这份设计解析APP中的折叠菜单应该如何设计?先看这份设计解析
设计进阶:一个案例,掌握设计价值密码设计进阶:一个案例,掌握设计价值密码
设计师做方案还要解方程?是不是有大毛病设计师做方案还要解方程?是不是有大毛病
设计基础(4):B端中后台管理系统色彩体系设计基础(4):B端中后台管理系统色彩体系
如果吃亏是福,你想要几次?如果吃亏是福,你想要几次?
如何从体验层面提升NPS——好感体系设计如何从体验层面提升NPS——好感体系设计
我是万万没想到,这么复杂的效果,竟然是用这么简单的工具做出来!我是万万没想到,这么复杂的效果,竟然是用这么简单的工具做出来!
B类新品场景设计B类新品场景设计
想要优化好UI作品,这14个设计细节一定要检查到位!想要优化好UI作品,这14个设计细节一定要检查到位!
探索节日运营新思路探索节日运营新思路