知识分享

  • 首页
  • 市场分析
  • 需求分析
  • UI设计
  • 产品运营
  • 产品设计
  • 项目管理
  • 新玩意儿
不积跬步无以至千里
不要停留,欣赏沿途的风景
  1. 首页
  2. 产品设计
  3. 正文

面向对象的产品观(1):抽象思维

2020年12月21日 198点热度 0人点赞 0条评论

编辑导语:产品的设计分为多个步骤和层面,从为什么要做这个产品到这个产品带给用户的意义,从抽象思维到具象等等;本文作者分享了关于面向对象的产品观中的抽象思维,我们一起来看一下。

产品设计难么?

相信每一个人的心中都会有不同的答案。

而我曾经认为产品设计是非常简单的一件事情,无非就是看两本经典书籍,学习一点交互设计知识,懂一点市场就可以做出让人直呼好家伙的产品。

后来,现实的毒打让我明白了我的浅薄;要做出一个好的产品需要对市场的精准把控,对需求的深刻理解,对功能的精细设计,对细节的精益求精才能达成;缺少任意一个环节,换来的都将是现实无情的毒打。

而要想做好一个产品,必须要有一套切实可行的完整方法论!

我相信很多的产品大牛到最后都可以形成一套自己的方法论;而对于我本人来说,构建产品需要经过以下五个层面(构建这个词的内涵远超设计,后续的文章都我将用构建来描述产品设计过程):

这五个看起来有点拗口的层面,来源于我做码农时期每天都要用户的一种思维方式:面向对象思想。

这套脱胎于面向对象的产品构建方法,我就很大言不惭的称其为:面向对象的产品观。

当然可能很多人看到这里心里已经骂开了,做产品就做产品,扯什么面向对象思想,这不装逼会死么?

但是在我看来,不论你做的是哪一类的产品,不管是社交、电商还是直播类产品,究其本质其实都是软件产品。

而软件产品的开发早就有了一套名为:面向对象思想的底层思想;这套思想经过了一代又一代的计算机大师,经过几十年的不断发展,完善,现在已经写入到了程序员的基因中,如果你不懂面向对象甚至都不能够开发程序!

一套如此牛叉的方法论我相信不但能指导编程,同样可以指导我们做好产品构建的工作。

正如古语所云:他山之石,可以攻玉。

我本人在做产品的过程中就走过很多的弯路,直到我在某一天突发奇想般的将面向对象的思想套用到产品构建的过程中;之后就如同打开了新世界的大门,原来面向对象的思想与产品构建的结合是如此的顺滑,就如同肉片遇到了辣椒,番茄遇到了鸡蛋,一切都是那么的刚刚好。

但是面向对象的思想是如此的博大精深,我作为一个勉强及格的码农,外加一个半路出家的产品经理,实在很难通过短短的文字就阐述明白面向对象的产品构建流程的全部精髓;接下来也只是抛砖引玉,写一点自己这些天来领悟到的一些皮毛,还请各位看官莫要见笑。

下面我们正文开始。

正文最初,就由我向大家阐述一下面向对象的产品构建流程的具体内容。

首先,在我看来构建一款产品是一个将从具象到抽象再到具象的一个过程。

说人话就是,构建产品要先了解具体的人的行为,然后从行为中抽象出他们的需求,然后再将需求分解为可行的功能,再将功能组合为各自独立又互有关联的模块,再将这些模块通过一定的顺序进行连接;最后生产出一个具象的,看得见摸得着的,能够满足需求的产品。

这个过程,需要经过抽象,分解,组合,连接,具象五个层面;从抽象开始,到具象结束。

抽象:确定产品愿景。

抽象解决了Why的问题,让你弄明白为什么要做这个产品。

做产品最终的目标都是满足用户需求,创造用户价值。抽象就是指如何使用面向对象的思维去找到用户需求,确定产品最终目标。

抽象是一个自下而上的过程。

首先你要找到你所服务的人群,然后抽象出人群共有的特征,形成不同的子类;然后根据每一个子类的特征,抽象出不同的基类;最后,分析不同类之间的共有需求,抽象出产品的最终愿景,这个最终愿景就是产品最终的努力方向。

抽象又分为特征抽象与行为抽象。

抽象是构建产品过程的第一步,也是最为重要,最为核心的一步;毕竟只有找到了方向才能保证你走在正确的道路上,就像往东走到不了喜马拉雅。

分解:确定产品功能。

分解解决了What的问题,也就是搞明白这个产品要做什么。

分解是一个自上而下的过程。

从产品的愿景开始不断的向下进行分解。如我们的用户有哪些类,每一个类的共同需求是什么?每一个类又有多少独立的对象,每一个对象的需求又是什么?针对这些需求又有哪一些解决方法?

分解又分为纵向分解与横向分解。

分解的要点是:原子性、一致性、隔离性、持久性。

分解的原则是:相互独立不重复,完全穷尽无遗漏。

组合:将功能组合为一个一个的模块。

组合、连接、具象三个层面解决的都是How的问题,也就是如何去构建这个产品。

分解后功能是零散的,不成体系的,需要根据不同的用例,场景去进行组合,形成具体的模块。

组合根据不同的功能特点又可以分为搭架子和装组件。

组合的要点是:高内聚、低耦合;也就是说同一个用例的功能全部组合为一个独立的模块,不同的模块之间尽量减少关联,模块之间通过连接进行信息传输。

连接:让信息在你的产品中有序流动。

任何一个软件产品都是一个信息不断流动的动态系统。要让信息流动起来,就要将各个独立的模块有序连接起来。

连接又可以分为内循环与外循环。

模块之间的连接十分繁复,为了保证连接的有序,连接流又分成了基本流,备选流以及异常流,不同的连接流相互独立又互有关联。

在进行连接时,需要考虑各种不同流的走向以及各自的结果。

具象:用户体验设计。

具象是用户真正可以感知的部分,也是整个产品构建过程中的最后一步。

具象化最重要的关注点就是用户体验。

用户体验同样分为两部分:交互设计与信息架构。

用户体验设计是目前相关文献最多,广大产品经理研究的最多的一个方向。

我在这里也就不再展开论述了。

面向对象的方法在用户体验设计的工程中的运用可以极大的提升设计工作的效率,并且可以指导设计师做出更容易落地的产品。

5个层面中抽象是最底层,具象是最上层。构建产品就是从最下到最上构建的过程。

在实际构建的过程中,5个层面中任意一步在执行时都可能发现新的问题或者不足;当然发现这些不足时,都可以回溯到上一步,然后在上一步根据反馈及时修正。

五个层面既可以按照正常的从下至上的构建,也随时可以从上至下的回溯。

构建产品是一个非常复杂,非常耗时的一个过程,接下来我还会用几篇文章来详细阐释面向对象的产品构建的5个层面。

一、产品构建第一层:抽象思维

在之前的篇幅中,我们大略聊了一下面向对象的产品观的产品五层面;现在我们来聊一聊构建产品五层面的第一层:抽象。

抽象层回答了最重要的WHY的问题。

抽象产品构建的最底层,是一切的基础,正所谓基础不牢,地动山摇。做不好抽象,就不要妄谈做出好的产品。

抽象这个词来源于一个我从小到大被说烂的名词:抽象思维。

关于抽象思维是什么?我直接给出百度百科的解释:

抽象思维,又称词的思维或者逻辑思维,是指用词进行判断、推理并得出结论的过程;抽象思维以词为中介来反映现实,这是思维的最本质特征,也是人的思维和动物心理的根本区别。

以上文字摘录于百度百科 – 抽象思维词条。

如百度百科所说,抽象思维是一种将现实转化为人类更便于理解和传播的内容的一种转换思维。

抽象思维的核心在于转换。

运用在产品构建过程中,抽象思维就是从发现问题转换为解决问题。

产品经理们在刚入行的时候基本都听说过一种观点:发现问题是产品经理最底层的能力。

实际上呢?在我看来发现问题从来不是问题,就像现在只要你有兴趣上网去随便搜索一下网民们对微信的吐槽、对所在城市的吐槽,你会发现网民们的吐槽加起来连地球一圈然后再绕道连上月球都绰绰有余。

这说明什么问题?说明这个世界从来不缺发现问题的眼睛,缺的是解决问题的手段!

我认为的产品构建的抽象思维就是将现实存在的问题转化为通过软件系统来解决的手段的过程。

那么如何才能将问题转换为手段呢?在我看来我们可以通过以下步骤进行操作。PS:这种方式仅限于转换为软件产品的手段,其他类型的手段我本人并没有实践过,请慎重使用。

我眼中的转换4步骤:

下面我们一步一步的来说。

1. 确定问题

确定问题看似非常简单,就像前文所说的,任何人都可以发现成堆的问题。所以关键不是如何去发现问题,而是如何去判断问题的价值。

问题的价值可以从两个方面去判断:问题的覆盖人数,问题的商业前景。

1)覆盖人数

这个很好理解,就是到底有多少人会碰到同样的问题;打个比方如果你是一个资深吸血鬼爱好者,你想要解决随时合法合理的睡棺材的问题,我想用脚指头你也想得出来全世界有这个兴趣的人估计不会超过1000人,这个问题的覆盖人数就相当感人了。

所以,在确定问题时,一定要注意这个问题要足够的大众化,要有足够多的人都会碰到同样的问题。

而且,这个问题要有足够的刚性,不解决就吃不香睡不好。

不然这个问题能带来的价值也不大。

2)商业前景

这个就更好理解了,任何产品的终极目标都是赚钱。一个不能赚钱的产品就是花钱做慈善,一个脑子正常的人基本不会做这件事情。

如何去确定一个产品的商业前景呢?在这里我应用一下俞军老师给出的公式:

商业价值 = 愿付价格 -企业成本

愿付价格 =(新体验 -旧体验)- 替换成本

这个公式其实解释的非常明白了,商业价值取决于一个用户愿意为你的产品付出的价格,而这个价格又取决于你提供的新的解决方案能否替换掉已有的解决方案,并且他选择的成本要足够的低。

最后我总结一下确定问题的两个要素:覆盖人数足够多,商业价值足够大的问题,就是一个值得深挖的好问题。

2. 锁定人群

确定了问题之后,我们下一步要做的,是锁定问题覆盖的目标人群。

问题覆盖的人群是很广阔的,各个人群之间基于各自不同的特点必然会出现多个有相同特征的分群,现阶段的目标就是锁定不同的用户分群。

关于目标分群,大拿俞军曾经说过,用户不是真实的人,用户是需求的集合体。这句话一直深以为然。同样一个人,在不同的情景,扮演不同的角色的时候,他所产生的需求是完全不一样的。

打个比方:

翠花白天是公司雷厉风行的高级白领,每天要管理十来号手下,随时经手的都是上千万的大单,这个时候她需要什么?她需要一个随时管理自己订单和手下的工具,能随时查看每天的业绩报表,查看手下今天是不是摸了鱼。

而回到家里之后,她是一个2岁孩子的妈妈,每天要做的就是换尿布,喂吃饭,哄睡觉;这时候她最需要的是什么呢?她最需要哄娃神器,让娃乖乖睡觉,乖乖吃饭。

你看同样一个人,他面对着完全不同的情景时,他的需求都是完全不一样的。

所以,我们锁定目标人群的时候不能很粗鲁的根据年龄、工作、收入情况等进行简单划分;而是要找到人群共有的特征,共同的行为,只要特征和行为都是一致的,那他们就是同一类人群。

正如一句老话说的:一种动物看起来像鸭子,叫起来像鸭子,吃起来还是像鸭子,那么它就是鸭子。

那么我们如何进行人群的划分呢?

这时候请出我们系列文章的主角:面向对象思想;划分人群使用的方法是面向对象最底层的特性:抽象。

概括来说就是抽象出人群中共有的特征以及行为,根据各自的特点的不同,将他们划分为不同的分类。

这个过程的目标是确定1至3个主要的类,需要三层抽象才能完成。

  • 首先我们要根据第一步确定的问题找到影响到的人群;
  • 然后抽象出人群的属性,然后根据不同属性的状态将不同的人群抽象为不同的子类;
  • 最后抽象出子类中共有的特点,形成基类。

这样解释实在太过于抽象,不像人话;我举个例子来说好了,就说我们大家都耳熟能详的淘宝。

淘宝的目标群体基本已经覆盖了全国男女老幼,这么大规模的群体必然会产生有非常多各自相同特点的群体;这些群体经过抽象之后就可以形成各种不同的类,如时尚达人、家庭主妇、数码先锋、球鞋专家等等;另外还有小店店主、店铺客服、天猫店掌柜等多个多个有之前分类截然不同的细分分类。

这些细分分类都我都将他们统一的称为:子类。

而不论是是时尚达人还是家庭主妇,他们都有一个共同的特点,那就是他们都是来淘宝买东西的,所以他们又可以抽象为一个更大的类:买家;而与他们截然不同的小店店主,店铺客服等又可以抽象为大类:卖家;这种囊括了多个子类共有特征的类,我称其为:基类。

这就是我所说的锁定人群的三层抽象。

在实际抽象分析的过程中,又需要进行两种不同类型的抽象:特征抽象和行为抽象。

接下来我分别阐释一下各自的逻辑。

1)特征抽象

在面向对象的思想中,有一句至理名言:万物皆对象。而一个对象均由两个部分组成:特征以及行为。

所谓的特征抽象就是将人的特征抽象为简单的词汇描述,如性别、年龄、受教育程度等;每一个词汇都可以赋予不同的值,如性别男、年龄18等;赋予了值的对象就成为了一个可以被精确描述的用户画像。

一个人的特征可以大致的分为四个大类:自然属性、社会属性、消费属性、兴趣属性。

本人所做的用户画像模板

2)行为抽象

与特征抽象类似,行为抽象是将人的行为抽象为抽象为简单的词汇描述,如下单、加购物车、聊天等;每一个行为词汇也都可以输入不同的值,如下单衣服、加电脑入购车等,根据输入值的不同,会形成完全不同的用户需求。

用户行为分析模板

特征与行为是用户的一体两面,缺一不可,一般来说不同特征的用户都会有不同的行为逻辑;在进行用户分析时,一定要将特征与行为结合分析。

分析需求:

在完成了前两步的工作之后,实际上分析需求已经是一件非常简单的事情了。

就像用户抽象一样,根据不同用户的特点以及行为,可以轻松的分析出他们在实际情况中会遇到的问题;然后根据用户抽象的层次向上抽象共性问题,得出子类会遇到什么样的问题;最后根据抽象子类的问题向上抽象共性问题,得出基类会遇到的问题。

还是举淘宝的例子,在淘宝上出现之前,一个消费者遇到的问题有什么?家庭主妇想买生活用品要去超市,数码先锋买电脑要去电脑城。

如果家庭主妇既要买毛巾,又要买电脑怎么办呢?她就需要去完超市去电脑城,这些地方不但离家远,而且有营业时间限制,必须在它的营业时间里走到商场完成购物并且在它关门之前走出来。

他们的遇到的共性问题就是商场营业时间太短,东西品类过少,地方太远。

经过抽象之后的需求就是:我希望可以有一个地方可以24小时营业,而且可以买到任何我能想到的商品,同时还不要我走很远。

同样,一个贩卖东西的小店主以及店铺员工又遇到什么问题呢?需要在专门的地点租下门面,而且店面还不能全天营业,每天只能赚半天钱,同时商铺人流量和城市与地段关联极大,能服务的客户也只能是附近3公里内的人;店铺员工每天都要到专门的地方去上班,不但路途遥远,还要每天挤公交坐地铁。

他们遇到的共性问题就是:商场离家远,不能获取太多的客户,营业时间有限制。

经过抽象之后的需求就是:我希望有一个地方可以让我24小时营业,不用我每天出门走很远,最好还能带来全国各地的客人。

最后我们将两种基类用户的需求结合一分析,就可以提炼成我们产品的最终目标:愿景。

提炼愿景:

所谓的愿景就是抽象所有基类的底层需求,并进行将它转换为切实可行的解决方案。

同样还是说淘宝,经过我前面的分析,相信读者们都已经知道他的最终愿景是什么了吧。

现在让我们大声的说出来:一个可以24小时营业的线上大卖场!

愿景就是产品最终形态的简略描述。

一个好的愿景一定要直白、简单、便于记忆与传播,只有这样才可以让产品开发团队的 成员在短时间记住并贯彻实施;一个太长太拗口的愿景可能连提出人自己都记不住,更别提让团队成员记住并传播了。

以上就是我对于抽象层的理解,这篇文章一不小心就写了几千字,但是抽象是一个非常大的话题,写一本书也不一定可以完全说明白里面所有的关节;这篇文章就当抛砖引玉,希望可以启发一下大家的思考。

面向对象的产品观是一个非常大的话题,一篇文章的篇幅实在是无法完全的阐释清楚里面所有的内容。

未来如果有机会,我再来和大家一起分享面向对象产品观其他层面的内容。

谢谢阅读。

 

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

题图来自Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!

标签: 暂无
最后更新:2020年12月21日

小虾米

同理心,洞察力!

点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复
最新 热点 随机
最新 热点 随机
我在椰树直播间,花了三分钱 东方甄选走红这一年 京东自营开始踩刹车 “单车刺客”6.5元一小时!共享单车平台还是赚不到钱,你被刺了吗? 政务CRM-CRM在政务行业的应用现状 Temu的砍一刀,迷倒了美国人 社交媒体围攻BOSS直聘 组件应用 | 个人主页头部,应该如何设计? 远程技术团队,操作回顾会怎么开? 我在网上卖“土”,年入5000万 增长模型:产品增长的通用思维框架 “大人”,榜单时代变了 汽水音乐一周年:“抖音BGM播放器”的起与落 一个方法论,搞懂支付的一切 密码强度计有哪些局限性? 618回归“价格战”:京东淘宝进入存量竞争,小红书、视频号深入电商直播 兴趣电商未来会超过货架电商吗? 直播带货再难造神:天涯重启失败,7天只卖了36万 鏖战13年后,线上超市的肉搏还在继续 最佳的阅读一行是多少字最合适?
被集市收割、被买家嫌弃,“摆摊后浪”有点惨蓝领用工招聘平台的数字化建设思路干货分享:WMS系统—PDA的应用iOS 17,能否守住「iOS神话」?系统功能设计:网络加速器系统产品需求设计电商扫盲第一讲:GMV的底层逻辑打造一个基于本地社区的闲置交易平台,你看好吗?东南亚出海洞察:去东南亚为直播电商开荒,没有超头主播,货品供给不足……定金+尾款模式背后的套路天涯老用户的自救,让我明白情怀是最不值钱的东西抖音上线酒店日历房,其他平台会慌吗?从需求到设计开发,产品质量问题如何分析靠咱们看腻的电视剧,爱奇艺和腾讯在东南亚成了顶流如何让你的“对内B端产品”看起来有价值?设计走查知多少产品思考:视觉冲击!以图片展示金额,“省钱卡”这样玩就对了多多买菜为什么比美团买菜要便宜?都在骂网暴,为什么网暴一直没有停过韩国漂流记:明星在面前,咖啡在手里,中国互联网公司在广告墙自动驾驶风口退潮的深层逻辑
如何从0-1搭建ETL? 新消费:发于B端,终于C端 不适合做AB实验的场景下,如何做出有品质的产品决策? KANO & PSM:分析需求与定价 现代人每天会看150次手机?过剩的信息究竟是如何引人焦虑的? 快更新!支付宝真“瘦身”了! 微交互设计一定要知道的8种类型! 利用Axure中继器实现多选树组件 为什么拼多多与Costco都在卖车? 贴吧年轻化创意玩法探索:虚拟形象设计 内容社区的三个电商陷阱 2021-2022 设计趋势 · 数字未来篇 网易云音乐的烦恼游戏 你不会还以为“刘畊宏女孩”们只是在跳健身操吧? 以一个失败的产品功能为例,聊聊福格行为模型 本地生活,不会成为下一个“电商” 互联网时代的创作(下):作品缺乏内在的对抗,更多是对外的讨好 微日志:每天“被捅喉咙”发现的有趣设计迭代 从战略到执行:业务领先模型 BLM 战略篇「战略意图」 如何设计SaaS商业模式

COPYRIGHT © 2023 知识分享. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang