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

推荐订阅源

D
DataBreaches.Net
MongoDB | Blog
MongoDB | Blog
GbyAI
GbyAI
L
LangChain Blog
B
Blog
博客园 - 三生石上(FineUI控件)
Martin Fowler
Martin Fowler
博客园 - 【当耐特】
Recent Announcements
Recent Announcements
P
Proofpoint News Feed
U
Unit 42
Last Week in AI
Last Week in AI
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
雷峰网
雷峰网
Microsoft Security Blog
Microsoft Security Blog
T
The Blog of Author Tim Ferriss
爱范儿
爱范儿
小众软件
小众软件
I
InfoQ
G
Google Developers Blog
大猫的无限游戏
大猫的无限游戏
人人都是产品经理
人人都是产品经理
C
Check Point Blog

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
原型设计,有哪些高段位的“潜规则”?
AI产品大峡谷 · 2022-11-07 · via 人人都是产品经理

原型设计是产品经理的基本功,作为产品经理,我们培养设计的意识习惯也可以从原型设计起步。有些刚入行不久的同学,有时会忽略一些“潜规则”,导致原型虽然看起来逻辑基础不错,但设计意识不足。作者在本文中,复盘总结几个典型的设计思维的缺失,欢迎阅读~

产品经理是强设计岗位,这体现在其工作的方方面面。

前两天,我们老板早上6点多突然在经营群里发条信息,说是抛出一个观点供大家讨论:产品设计环节很重要,关乎产品开发效率、业务支撑水平和经营成本,因此要高度重视,不怕投入、不怕时间长,要反复论证,只要产品设计到位,技术开发就更快、效率更高、质量更好、成本更低。

镜同学感动的差点叩谢天恩,有一说一,传统企业转型互联网公司的老板能有这个认知其实并不容易,尤其是规模做的很大之后,基于经验和习惯做事,往往是中年老板经营企业的出发点,所以说服老板也不容易,江湖甚至有言,不少公司倒闭往往都是老板不听指挥

我也不止一次的提到过,产品经理是个设计岗位,需要更多的设计思维,所以我们的日常工作都带有“设计”两字:产品设计、架构设计、流程设计、功能设计、原型设计等等。

但在实际工作中,仍有不少同学对设计的理解不够深入,一定程度上成了需求的传话筒,过多依赖业务或运营的需求描述,缺少设计的思考深度,长此以往,设计意识愈加淡薄,职业发展严重受限。

因此,有人说,产品设计思维,既是初阶产品经理快速发育的打野刀,更是高级产品经理的反伤刺甲

在现实中呢,很多产品经理对岗位的认识不够深入,甚至有些粗放的小团队在基础认知上会把产品经理等同于画原型的,这实在是劣币环境对产品行业的物理伤害,令人唏嘘。

但破圈往往需要由内向外,作为产品经理,我们培养设计的意识习惯也可以从原型设计起步,刻意练习、百炼成钢。

上周我评审团队成员的一个原型设计,该同学刚入行不久,逻辑基础不错但设计意识不足,本文复盘总结几个典型的设计思维的缺失,有些虽未明确被定义为原型设计的规范,但却称得上是高级段位设计的“潜规则”。

希望能带给你启发。

1、展示的数据,缺乏计算逻辑。

相信大家对数据展示类的设计一定不陌生,常见的就是数据统计、可视化报表等,从业务价值来看,越是复杂的业务决策越需要强力的数据支撑,显然,数据统计是很重要的产品功能。

在数据统计的设计时,产品经理应该更多地围绕业务本质去思考,主动考虑哪些数据需要汇总统计,对业务有哪些价值,如何汇总分析等,而非被动的进行数据求和或运算。

原型设计的背后是产品思考路径,在数据展示上,产品经理容易犯两个错误。

①缺乏数据统计的意识

举个简单的例子,我们在支付流水功能的设计时,很多产品同学在原型设计上展示仅仅是流水列表,并没有考虑对于“支出总计”、“收入总计”的考虑,这就是设计上需要主动迈进的一小步。

因此,我们在原型设计上,完全可以在列表页面上面增加两个红色的统计:收入总计、支出总计

②数据值显示不对

第二个错误是数据显示太随意,有的同学干脆复制每行的数据,简单粗暴,在页面原型显示上并没有计算的逻辑支撑。

再举个超级简单的例子:

假如在“交易记录”列表,有四个字段,分别是“订单金额”、“活动优惠”、“红包优惠”、“实付金额”,在列表展示时,高保真的设计应该确保:实付金额=订单金额 – 活动优惠 – 红包优惠

这是第一层的高保真。

如果再深入一层,假设你的交易流水列表有收入、支出和账户余额,那么交易记录要互相关联,根据不同订单的交易流水,你的“账户余额”要有继承关系,即上一次的账户余额应该是你下一次交易的动账前金额

又或者说,你的交易记录列表顶部有统计,比如,总支出金额,那个该字段应该等于列表记录之和。

回想下你的原型设计,只是单纯的复制列表信息,还是把计算逻辑体现出来了,镜同学认为,这样把计算逻辑正确的表达设计才是高保真,因为这样不仅展示清晰,更让你养成设计的思维、逻辑性的表达习惯。

原型设计有哪些高段位的“潜规则”。

2、列表展示未区分状态。

上面说的是数据页面的原型设计,接下来我们再看看“列表页面”。

产品同学对“列表页面”的原型设计一定不陌生,尤其是后台产品经理更是习以为常,有的同学可能会说,列表的原型有啥需要设计的的呢,按照梳理好的功能导图,把相应字段填充上去不就行了么,大不了再稍微对齐优化下样式,so easy呀。

所以很多产品经理(尤其是刚入行不久的新同学)的列表原型设计类似下图:

原型设计有哪些高段位的“潜规则”。

上面这页原型设计是团队成员画的,可能有小伙伴说,这个原型画的也不错了啊,你看布局整挺协调,列表格式也很整齐啊,算得上高保真了吧?

这里镜同学想再谈下我对“高保真”原型设计的理解,很多人在面试时也会被问到是否画高保真原型图,对高保真是怎么理解的,关于这个话题,我是这么理解的:

我觉得产品经理要学习设计高保真的原型,但高保真绝不是指色彩丰富、交互多了一些,仅此而已,镜同学觉得,高保真原型要尽可能的将业务逻辑、交互逻辑、页面元素表达到位,要努力把功能背后的设计思维体现出来,尽可能高效地指导开发。

现实中,不少应聘者对高保真原型的理解比较简单粗暴,认为高保真就是色彩更丰富,加上了页面跳转,峡谷兄弟们,有一说一,肤浅了啊。

我们看看上面的这个列表原型设计图,可以发现该页面有两个问题:一是,字段展示不规范,如,“创建时间”字段用的却是“日期格式”,其他字段也只是简单复制,没有做区分,这个是小问题,但也属于不够规范;

二是,列表展示完全体现不出来业务逻辑,关键的状态并没有做区分,如,“已禁用”的账号状态缺失、在职状态包括“在职”、“离职”也没有体现,仅仅是单纯的复制行数,让页面显得饱满而已,背后的业务逻辑和设计思维都没有体现

列表状态缺失是产品经理常犯得一个错误,回想下你的原型设计,订单列表是否按照订单状态逐一显示,支付列表又是否按照支付状态全部罗列。

事实上,关于状态的逻辑很重要,尤其是对于B端产品来说,业务状态有时甚至能多达七八个,我们产品经理还需要单独设计状态表来指导开发,这是很重要的产品设计。

但是,镜同学还是建议你在原型设计时就养成这样的规范习惯,因为这是训练产品思维,帮你形成良好的习惯,不断提升设计思维

原型设计有哪些高段位的“潜规则”。

图-↑字段规范、业务状态已优化,更体现设计思维

3、时刻牢记业务逻辑。

上周,我们团队一个产品同学在做CRM的数据统计的原型设计,其中有个功能是“客户健康状态”的堆叠条形图,希望能直观展示客户健康情况

业务场景是展示不同月份平台的客户状态分布情况,也就是每个月平台有多少A类客户,有多少B类客户,有多少C类客户。

该同学也参考了一些竞品,应该来说该功能对于用户掌握客户情况很有价值,尤其是用堆叠条形图展示,统计数据显示很直观,他第一版的界面设计如下图示:

原型设计有哪些高段位的“潜规则”。

我们可以看到上面的“堆叠条形图”,横坐标是客户数量,纵坐标是自然月份,这样的图形看着是很清晰,对用户了解客户情况也很直观。

但是,这个界面设计并不是很合格,看着色彩丰富却是低保真,因为这里面最重要的业务逻辑却没有考虑:客户数量随着用户的使用,只会越来越多,也就是该条形图应该自下而上,逐渐增加

并且,A类客户、B类客户、C类客户,每个单独的月度数据,也应该是自下而上逐层增加的。

大家可以看下上图,条形展示完全没有逻辑支撑,只是形式上的丰富,在内在设计上却是没有深度思考。

原型设计一定是围绕着背后的业务逻辑设计,所谓高保真不是单指界面的色彩丰富,而是指设计思维上的细腻深刻

原型设计有哪些高段位的“潜规则”。

图-↑ 优化后的原型设计,遵循业务逻辑

镜同学说到这里,还是想再helight一点,这也是不少产品同学的误区:原型设计绝不是产品经理的核心工作,产品思维才是竞争力内核。

但,原型设计可以也必须用产品思维来设计!

我们应该时刻牢记:原型设计本身就是设计工作,绝非只是单纯的界面堆砌,背后的驱动力一定是业务逻辑为核心的产品思维。这也是产品同学在原型设计时需要考虑的问题,

以上浅薄经验,希望对你有产品参考。

专栏作家

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

本文由@产品大峡谷 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

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