惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Recent Announcements
Recent Announcements
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
MongoDB | Blog
MongoDB | Blog
H
Help Net Security
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
人人都是产品经理
人人都是产品经理
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
The GitHub Blog
The GitHub Blog
V
V2EX
Microsoft Security Blog
Microsoft Security Blog
V
Visual Studio Blog
A
About on SuperTechFans
博客园_首页
L
LangChain Blog
量子位
雷峰网
雷峰网
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Jina AI
Jina AI
月光博客
月光博客
阮一峰的网络日志
阮一峰的网络日志
博客园 - 聂微东
Microsoft Azure Blog
Microsoft Azure Blog
M
MIT News - Artificial intelligence
N
Netflix TechBlog - Medium

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
经验|B 端组件设计的“好”与“坏”,该如何评估?
元尧 · 2023-09-28 · via 人人都是产品经理

我们在设计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 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。