经验|B 端组件设计的“好”与“坏”,该如何评估?
我们在设计B端的组件时,常常会有个问题:如何判断一个组件的设计是 '好' 还是 '不好' 呢?”,有没有什么数据或者标准可以参考?这篇文章,作者分享了三个判断角度,希望能帮到大家。
最近有很多同学来问我:“对于 B 端业务的组件设计而言,有哪些数据或者标准可以判断一个组件的设计是 ‘好’ 还是 ‘不好’ 呢?”
我们这里要聊的组件设计,重点是指具备业务属性的“业务组件”,而并非通用的 “基础组件”。
关于“基础组件”和“业务组件”的区别,一部分基础概念可以看文章:https://www.woshipm.com/pd/5439619.html
如何判断一个业务组件的优劣,可以从以下三个方面来看:
一、协作侧
—— 组件是否能够为设计和开发做提效
能够提升产研效率是组件的本质作用。高质量的组件能够在业务产研的过程中节约大量的人力成本,并保证产出物的基础质量。
组件在协作侧的检验指标通常包括但不限于:
1. 组件的易学性
也即组件的使用方式是否能让组件的使用者一学就会,组件的使用规则是否容易被记住。你可以定期收集设计师和开发对于组件的使用反馈,也可以通过定期给大家出一个关于组件使用方式的问答题小考卷,来检验组件规范的难易程度、收集大家对于组件的掌握情况。
2. 产研速度提升率
产研的速度提升可以从设计师和开发的工作时长来看,你需要定期统计大家在该业务需求中的工时变化,看看哪些是组件带来的帮助。
3. 产研质量提升率
产研的质量提升可以从设计稿的设计质量和开发对于设计稿的还原度来看,你需要收集这些产出物中的问题类型和数量,看看组件的使用是否减少了问题的产生。
4. 组件的解绑次数
这是指组件在业务产研过程中被拆开、打散后使用的次数。拆开的次数多,可能意味着组件的灵活性还有待提升。Figma 的设计组件库的管理者可以通过组件库数据表盘来分析组件解绑的次数、场景和原因。其他设计协同软件如果无此功能,也可以通过收集组件使用者的反馈来盘点。
二、业务侧
—— 组件是否完成业务目标、解决业务问题
我们已知业务组件存在的核心价值就是:服务于业务需求,解决业务问题、实现业务目标。
因此,组件的评估也可以与业务目标的评估指标相关联,比如你对于组件 A 的检验标准和指标就可以是:
- 组件 A 是否解决了 XXXX 的业务问题,减少了 X% 的客诉率;
- 组件 A 是否能够解决产品在不同终端的自适应问题,提升产品在移动端的用户体验和好评率 X% 等等。
组件在业务侧的检验指标通常包括但不限于:
1. 用户的满意度
可通过用户访谈和问卷获得,成本较高。如果能够收集到用户在使用产品时的反馈和客诉,也可从中盘点和筛选出与组件相关的问题进行分析。
2. 业务的完成度
可以通过对于业务方的询问和业务方给出的反馈来看,也可以从业务指标的完成情况来评估有多少成果是与组件设计相关的。
三、专业侧
—— 组件是否符合设计专业水准
这里指的是组件自身的设计水平,是从设计专业性的角度来评估组件的视觉效果、交互方式等基本属性是否合理。
组件在专业侧的检验指标包括但不限于:
1. 组件交互的易用性
可以通过 KLM 模型(Keystroke-level Model)来做判断。
2. 组件视觉的美观性
可以通过业内通用的设计原则、法则来判断,看看组件是否符合基本的设计原理,具备基础的美观性。
专栏作家
元尧,微信公众号:长弓小子,人人都是产品经理专栏作家。一线互联网大厂B端体验设计师,清华大学美术学院本硕连读。曾负责国内最大开源组件库Ant Design组件的设计和运营工作,目前负责国际业务线B端产品体验设计和组件库的搭建工作。
本文原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
- 目前还没评论,等你发挥!