编辑导语:更新和优化设计组件需要哪些流程？作者将优化过程概括为收集、探索、设计、开发、发布五个过程，并做了详细的分析。让我们看一看。
很多读者想了解组件更新优化的工作流程和体验。最近经常收到读者和粉丝的以下问题:
组件更新需要什么样的工作流程？在更新和维护组件的过程中，设计和前端应该如何配合？组件设计师的工作和其他设计师的工作有什么区别？
其实构件库的构建和优化并没有绝对的标准。只有适合自己团队的工作流程才是真正有效实用的。至于各个组件的更新优化，我的经验是:从“发现组件存在的问题”到“更新修复组件”，优化过程大致可以概括为五个步骤:
搜集组件问题及优化需求探究分析组件的优化方案设计优化方案并进行评审开发方案完成并进行验收发布上线并同步组件更新
收集组件问题和优化需求，探索分析组件的优化方案，设计审核优化方案，完成开发方案，在线受理发布，同步组件更新。
01收集组件问题和优化要求
如果想让自己的组件库与时俱进，为业务赋能，定期收集组件问题和设计师的反馈是很有必要的。通常，组件问题和需求可能来自:
设计人员/开发人员在使用商业组件时发现了组件问题。设计者/开发者发现其他优秀的组件库案例也有可借鉴之处。设计师在使用组件的过程中觉得不方便，产品不好用。某些功能或某些模块在使用时体验不佳，等等。
收集和整理问题需要一个需求列表。可以通过需求类型、完成状态、负责人等来描述需求。同时，你还需要定义需求的优先级，确定调度和完成时间。下图是需求列表的基本示例:
参与人员：使用组件的设计师和前端开发所用时间：不定期反馈和收集所用工具：公共的开放文档或看板（比如语雀文档、数据表、讨论区等）对收集需求会有一定帮助，可以使其他设计师在做设计的过程中，遇到组件问题就自发填写需求列表，实时共享。组件负责人将需求归类整理、做好排期即可参与者:使用组件的设计师和前端开发花费的时间:不定期的反馈和用于收集的工具:公开的公开文档或广告牌(如语言鸟文档、数据表、论坛等。)会在一定程度上帮助收集需求，以便其他设计师在设计过程中遇到组件问题时，可以自发填写需求列表，实时分享。负责组件的人能把需求整理出来，安排好。
技巧
1)**协力，用制度约束行为。
收集组件问题需要所有使用组件的设计人员的共同努力。然而，设计师经常会遇到问题，忙着做需求而没有时间记录。所以必要时可以采用简单的制度来约束。比如每个设计师每个月必须提交1-2个组件设计优化的想法，或者每个季度评审一两个或三个“组件问题检查与修复”，给予精神或物质奖励。
2)评估需求，不是所有的需求都值得优化。
你需要判断这些需求的真实性和优先级。并非所有的组件设计要求都需要立即优化，因此重要的是要确定优先级和时间表。您可以参考以下内容对需求进行综合评估:
并对当前可用的资源进行设计和开发，对内容、组件的难易程度、业务发生的频率、业务需求的紧急程度、组件的通用性和扩展性等进行设计和优化。
3)分配到人，每个需求的进度都很容易追溯。
如果组件设计团队人数充足，组件负责人也可以安排指定的组件设计师完成相应的需求，所以需要指定专人，体现在表格中，方便联系和实时沟通。
02探索和分析组件的优化方案
这就需要对你上一步收集到的问题和需求进行分析和研究。对于业务组件的研究，我的建议是:一定要将其纳入业务场景考虑。
你可以通过两个方面来做组件分析和研究:
竞品中的相似业务场景:收集分析同类产品或相似功能场景中的实际应用案例。成熟的产品会更有说服力，更值得参考。其他构件库的解决方案:从其他优秀的设计系统/构件库中收集并分析相同的构件案例，如蚂蚁设计、材料设计、轻量化设计、碳素设计、SAP费奥里设计等。
当然，你还需要综合运用一切可行的设计方法和工具，通过学习竞品、阅读文章、与有经验的设计师交流讨论(也请向我提问和讨论)、做AB测试，研究出合理的解决方案。
参与者:指定组件设计者花费的时间:2-3天使用的工具:公开的开放文档或设计文档。
03设计和评审优化方案。
当设计人员根据前期的研究分析产生优化的组件设计稿时，可以组织或邀请团队中的其他设计人员(尤其是组件问题的提出者)和开发人员对组件设计方案进行考察和评审。
通过评审后，进入组件的代码开发阶段；如果评审失败，将收集意见进行修改、更新和第二次评审。
参加人员:组件设计师，使用组件和前端开发的设计师时间:2-3天使用的工具:公开的开放文档或设计文档，线上或线下会议。
技巧
1)有正当理由，分析过程要保留。
组件优化的评审比业务需求设计的评审更注重设计分析的基础。因为组件评审者主要是设计师，而业务需求评审者主要是业务和产品。设计师之间的沟通需要充分的证据和思考过程。
2)建立标准，让评估更快。
可以根据组件库的设计原则建立组件设计的评价标准，根据标准和原则进行设计评价，可以有效避免不必要的***。
3)业务第一，先完成业务需求。
有时候组件设计和业务设计是同时进行的，任何时候都要遵守“业务第一”的规则。组件设计师可以和业务设计师合作，先完成当前业务的需求，再沉淀组件的通用性。业务应用也是组件的最佳测试场景。
04开发计划完成并通过验收。
在这一步中，开发将把组件的优化方案实现到代码中，以完成组件。开发完成后，组件设计人员需要进行走查。完成的内容和质量反馈可以添加到上面提到的“组件优化需求列表”中，很容易追溯。
参加人员:组件设计师，前端开发时间:2-3天使用工具:公开开放文档，开发草稿，线上或线下会议。
05在线发布并同步组件更新。
该组件的新“版本”包括几项内容:
一是更新组件库和在线开发使用库的设计工具包；
二是补充编写更新的组件使用规范；
第三，团队的更新项要同步，所有成员的使用版本要保持最新和统一。
参加人员:组件设计师，使用组件和前端开发的设计师时间:1-2天使用的工具:公开的开放文档，线上线下的组件库，线上或线下的会议。
技巧
1)规则简洁，易记，易用。
关于组件的使用规则，我们曾经在文章中写过:如何让“设计规范”得到有效的执行和落实？在这篇文章中已经做了详细的解释。设计说明书的内容表达要接地气，拒绝“假大空”，这样才容易记忆和使用。
2)定期同步，定期，可预测。
定期同步组件的优化进度。可以以周会的形式将本周更新的组件内容同步给团队所有成员；或者以月报的形式，每月通过邮件发布组件工作和优化进度，让全体员工都知道。
3)注重稳定性，避免频繁更新。
组件更新迭代的时间不要太频繁，小的修改和优化，比如调整组件的局部细节，更新二次色的色号，可以每周/每月迭代一次。重大优化升级，如设计风格更新导致的主题颜色、圆角、交互形式的优化，建议每年更新。
作者:姚远，微信微信官方账号:长弓小子
本文由@姚远原创发布。每个人都是产品经理。未经许可，禁止***。
来自Unsplash的图像，基于CC0协议。
本文来自眼泪是回忆的常客投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/577260.html
微信扫一扫 
