Hi，我是元尧。记得将我设为星标 ⭐️ ，不错过日后每一条来自大厂的经验分享。
欢迎长按下图二维码加我微信，带你进设计师交流群，与上万设计师一起交流成长！
「👇 添加好友请备注：设计交流」
我们都知道，组件设计并不是一蹴而就的，每一个组件都要经历几次甚至几十次的优化和迭代，才能更好地为业务和产品提供支持。不过，在这些迭代工作的过程中也一定会产生一些问题，比如：🙁 如何发现真实有效的组件设计问题，确保改进组件是必要的？🙁 当使用组件的设计师发现了一些组件设计得并不完善、用法规则并不全面等问题后，如何反馈问题？🙁 使用组件的设计师不愿意主动反馈组件的问题，该怎么办？
对于这些问题，我总结出了几个实用经验，分享给你——![]()
WHY
为什么需要建立
组件问题的反馈机制？
每个组件设计团队都应该有一套属于团队的组件问题反馈及收集机制。这套机制的意义在于：
帮助组件设计师从业务设计师那里收集到现有组件存在的问题和优化需求，以便组件可以紧紧跟随业务需求的变化进行补充和调整，让组件的迭代更加有效且合理。
而制定这个反馈机制的突破口就在于：
使用组件的设计师是否能够主动上报自己遇到的组件问题、自觉贡献自己关于组件的想法。
虽说组件设计是全组设计师都应该有所参与的工作，但根据我以往做组件的经验来看，如果只是靠大家的自觉性，那基本上就只有那些对组件有极其迫切的更新要求的设计师会提出一些问题和需求，其它设计师很少会主动反馈自己遇到的组件问题。因此想要建立组件问题反馈机制，还需要有一定的技巧和方法。
![]()
HOW
如何建立
组件问题的反馈机制？
经过几年来的一系列的方法测试，我最终沉淀了以下两个最为有效的工作方法：
方法 1
激发大家反馈问题的主动性。
通过一些强制手段或奖励机制来激励大家的主动性，帮助大家克服惰性。
比如：每个季度的工作收尾时，从几个维度对设计师参与组件工作的进行评比，可以看看：
- 谁发现的组件设计问题或 Bug 最多；
- 谁提出的组件改进意见和想法最多；
- 谁被采纳和实现的组件优化方案最多等等
评比总结出前 1、2、3名，分别给予不同的奖励 / 奖品。
再比如：将组件设计问题的发现与上报变成每位设计师硬性的专业考核指标：
每个业务设计师都需要在每个季度至少提出 2 条组件设计优化建议 / 所发现的使用问题，并最终被采纳、优化和实现到了组件中。
没有完成指标的设计师，要相应扣减绩效分数。
方法 2
简化反馈问题的流程和机制。
反馈问题的流程和渠道越简单越好。我在一开始采用的方式相对复杂：
我自己编写了一套组件问题反馈的文档模版，然后让其他业务设计师在遇到问题时就按照模板去填写问题内容，提交组件优化需求。
但很快我就发现，由于要填写的内容太多，每个组件问题和需求的差异性又很大，所以大家在填写时总会有各种疑问，提交需求的积极性也会受到打击。于是便取消了模版填写机制，改成了：
业务设计师可以直接将问题提给组件设计的负责人，方法不限（比如通过钉钉或者面对面聊天的方式都可以），再由组件的负责人对问题进行的统计和归类。
而这样做的也还有很多其他的好处：
- 更高效：便于组件设计师和业务设计师直接针对组件问题进行及时沟通，有些问题可能并不真的是组件设计上需要优化和解决的通用问题，组件设计师可以基于现有的组件规则和资源，第一时间给出更有效的解决方案。
- 更清晰：组件设计师会按照业务设计师提出的组件问题类型、难易程度、紧急程度等方面对组件的优化设计工作进行排期和标签化处理。这样组件的优化需求在归类时也会更加清晰。
并不是越全面的机制越有效。组件的建设工作，其实更多是人与人之间的互动与协助。而想要克服人性的弱点与缺陷，简单直接或许才是王道。
如果你在组件工作中遇到了其他棘手的问题，也欢迎来我的知识星球，这里大概是你能找到的最全面、专业和实用的学习资料库了。我会用我本人在大厂搭建两个组件库的实践经验，从概念到实践案例，手把手、一对一的解决你关于组件的所有设计和工作问题，识别二维码加入：
B 端设计系统和组件设计是值得每一位设计师都深入研究的课题。如果你想了解更多关于 B 端设计组件相关的内容，在公众号后台留言 “组件” 可以看到，这里有很全面、专业、系统的组件知识供你阅读：如果你还有其他设计、工作、作品集、面试相关的问题，欢迎向我提问。如果你想加入设计师交流群，也可以识别二维码👇👇👇添加我的微信。添加好友请备注：设计交流。
了解更多设计理念和设计方法
