浅谈产品方法论的二三事
一套正确的方法论对于产品设计整个过程来说十分重要,可以有效地针对不同场景去处理解决问题,本篇文章作者分享了有关产品方法论的相关内容,从四个方面详细讲述了其中的要点以及具体的方法,一起来学习一下吧,希望对你有帮助。
提起「模板」,其实质是一种别人解决问题的「方法论」,是针对特定场景的标准化处理办法。与其去想着如何套用别人的方法论,不如去创建自己的方法论。一套自己掌握的方法论,是更适用我们个人的成长体系、能力模型、所处环境的。
一、为自己的设计辩护
“伟大的设计往往取决于你怎么说”在《设计师要懂沟通术》中尤其令人印象深刻。
无论是从事UI设计、交互设计亦或是用户体验设计,当然还包括产品设计,沟通在实际场景中是十分重要的,因为你面对的需求方,一方面往往是不具备专业素养的,另一方面很难在短时间内与你达成共情。
而对于产品设计,也是一直高频出现的场景。无论是需求的发起方,还是方案设计的交付方,三方之间通信的桥梁无他,就是沟通。
1. 面对不同角色,说不同的话
设计出一套优秀的产品方案是很困难的,描述设计同样不是一件容易的事情。
我们所面对的都是和我们所持不同立场的一群人,需求评审的强度往往不亚于一场辩论。
产品经理向要每一位开发,测试以及很多没有产品设计经验的需求方去阐明自己产品的设计方案,并且要让他们信服自己是对的,这群人很可能包括方案的你的老板或者其他决策者。
通常情况下没有相关专业知识储备的决策者会选择那个听上去最合理的方案,所以方案的表述对于最终方案的确立至关重要。
2. 需要关注评审中的沟通技巧
初入职场的产品经理和经验更丰富的产品经理之间的差距不仅仅是他们解决问题的能力,还有一点还在于他们能否用一种让人心服口服、并促使人们同意的方式来阐述他们的方案是怎么解决问题的。
从理论来说,最好的方案应该被推崇,然而事实并非如此,需求评审很容易变成方案的批判会,每个人都好像是在告诉产品经理这个方案不够好,需要怎么去调整。
最终,那些能够说服别人“这样的方案更合理”的人会脱颖而出。
所以产品如果没有办法说服别人为什么他们要这么做,就不得不按照他们不同意的方式去修改方案,原因很大程度都是因为他们没有办法去为自己的方案进行更有理由,更加充分的辩护。
3. 说服别人,有时候比方案本身更重要
有些人可能会觉得,这么主观的决策有失公允,甚至成了需求评审的辩护大会,各自说各自的一套陈词,那么对于一些有着出色能力却不善言辞的产品经理而言,打击无疑是巨大的。
因为我们需要保障产品的一致性,例如产品的核心操作方式保持一致,这样就可以有效地降低用户的学习成本,避免不必要的思考等等因素。
我们这种所谓面面俱到的考虑,并不会让所有的人受益。在产品开发生命周期的各个角色当中,每个人都在为自身的利益在争取,产品所面对的,其实是多方面、多维度的矛盾。
所以我们不得不去依仗沟通的技巧,去完成产品的这些考虑。
4. 一点感悟
我不会去讲述,你该如何如何去做,每个人的性格、处事方式、面对的场景都是不同且复杂的,相当于在含有无限个参数的X元Y次方程中寻找一个最优解。本文更多的是强调沟通的重要性。
实践——反馈——总结方法论——实践验证——纠偏——完善自己的方法论。
提炼出别人方法论里的长期不变的部分,作为“公理”,作为日常解决问题推理的起点。
产品就是对现实世界的建模。
二、去伪存真,挖掘深层次的需求带来更好的用户体验
俗话说不打无准备之战,在我们评审或者分享我们的设计时,光靠沟通技巧肯定是不足以去支撑的。
做产品最重要的就是去挖掘需求,在实际工作中,我们有来自各业务方的需求,有内部系统的需求等,但并不是所有的需求都是真实的。
同样做产品不要被表面需求所蒙蔽,比如当我们去分析一个东西的时候,需要不断去剖析背后的真实想法。
1. 提出假设
我们设定一个需求场景:用户A在上海工作,安排明天去出差,需要买一张火车票去北京。
我们可以知道用户A的基础需求:买一张从北京去往上海的火车票我们需要提供的能力。
创造出一个能买火车票的平台,使得用户可以完成在平台上完成查询,购买,订单等基本功能。
那这样就足够了吗?
2. 开始不断挖掘需求背后的故事
当然满足基本需求是已经完成了,那如果我们能提供更好的服务会怎么样呢?
下面开始挖掘上层需求:不仅可以查询到当天各列车的信息,同时包括车次、途径各站点及发车时间、票价、剩余座位、车次状态等。
那我们如果提供这样的服务会怎样呢?用户A可以借助这些信息,更合理的安排自己的行程。
再如果,我们提供了价格更优,行程时间更短的特价机票呢,用户是否会选择修改出行方式呢?通过良好的服务为他的下一次出行选择本平台而创造潜在的机会,就会带来长期-低频的留存。
三、正确看待马斯洛需求层次理论
1. 如何分析真正的需求
美国心理学家亚伯拉罕·马斯洛(Maslow.A.H.)从人类动机的角度提出需求层次理论,该理论强调人的动机是由人的需求决定的。
而且人在每一个时期,都会有一种需求占主导地位,而其他需求处于从属地位。
人的需求分成生理需求、安全需求、归属与爱、尊重需求和自我实现五个层次。我们通过需求层次理论做支持,以便于我们更好的分析。
想要获得商业化的前提就是让用户接受我们的价值,在我们的产品中体会到获得感并能够持续使用产品,并探索出产品性能与用户满意度之间的良好关系。
每个层次的概念或者说明网上已经有很多了,在此也就不再深入赘述,建议多结合业务或实践去理解,而不是生搬硬套,这样能更好的加深印象。
现有网上的马斯洛需求层次理论是多少层,各说不一,有坚持最基础5层的,也有6层的甚至7层、8层理论。
2. 众说纷纭的“马斯洛需求层次理论”
- 6层理论——在自我实现的上层新增《自我超越》的需求,以达到心流体验。游戏策划肯定知道,游戏设计中很重要的一个设计就是心流,心流是指人们在当下的一种情绪体验,此时此刻,人们对某一活动或事物表现出浓厚的兴趣并完全投入其中。精神分析学家 弗洛伊德在《心理动力论》中提到的精神三大部分,本我、自我、超我用来解释意识和潜意识的形成和相互关系,也是支持6层理论的基础。
- 7层理论——在5层的基础上,自我实现的需求前增加求知需求和审美需求,其实也就是将成长性的需求更加的细化所建立的。
- 8曾理论——在7层的基础上,增加自我超越的层级。
完整版本的马斯洛需求层次理论是多少层,各说不一,也不用争论,我们做工作,应该形成自己的一套思维体系和完善方法论,马斯洛需求层次理论只是一种借鉴。
况且,需求分类不止有马斯洛进行过分类,还有很多分类方法,我们做产品不光要有人本主义理念,唯物主义也有其产品哲学参考价值的。
我们的产品落在哪个层级上面,针对这个区间,再进行详细和科学的分析,才是更合理的。
四、以用户为中心的思想去解决问题
1. 什么是以用户为中心
接下来我想介绍一下以用户为中心的产品设计理念,UCD(User-Centered Design) 译为“以用户为中心的设计”,这是一种设计方法,也是我在做产品初期、对产品意识形态都比较模糊的时候作为一种启蒙的解决方案模型。
我之所以使用这套理念,是因为在我的产品初期阶段,习惯于先去夯实产品基本功底,比如很重要的产品原型的设计能力,但最重要的是我刚开始工作的职责范围还需要肩负起交互设计师的内容(当然也可能是很多公司的常态)。
UCD的方式不局限于界面设计或设计技巧,而是通过不断融合用户的思维,将初期阶段的产品设计不光局限于功能设计上。
UCD 的核心思想非常简单:在开发产品的每一个环节,都把用户列入思考范围。UCD 提供的是多阶段问题解决方案的模式化思想,要产品owner站在用户的角度去思考,如何使用产品进行分析与假设,还要模拟出在真实的使用环境下进行测试、并不断“校正”产品。
2. UCD设计的主要流程
一个完整的设计开发项目大致分为6个阶段:
1)第一阶段:基础调研——寻找和评估机会。
①竞品分析 ②市场调研 ③决策因素 ④创新 or 优化 ⑤商业可能性
这个阶段的产品输出是MRD市场需求文档,包括用户调研数据,市场分析数据,竞品分析报告等。
不过根据个人实际工作经验来说,这个阶段不会由新人去或者说在现在版本迭代这么快速的进程中,这个阶段往往是由老板或者你的上司决定,你所做的不过是些无足轻重的辅助材料。
2)第二阶段:定义产品——广泛听取意见,收集用户需求,规划产品走向,探索出具有功能性和设计性的产品。
Kano模型作为分析用户需求对用户满意影响的工具,在此阶段可以很好的解决对于用户需求优先级的排列。从而确定你的产品MVP(最简化可行产品)形态,从而对你的用户进行告知,并根据用户对你的反馈来不断修正你的需求。
这个阶段的产品输出是PRD中的需求说明部分,包括内容excel的规划清单等。
3)第三阶段:交互设计——功能之间的缝合剂。
此阶段交互非UI交互,而是功能交互,你需要将需要实现的功能通过线框图进行串联并说明功能间的交互方式,能够让开发团队对整个产品有个大致的方向。
这个阶段的产品输出是PRD中的交互设计部分,包括线框图等。
4)第四阶段:原型设计——描述用户界面中元素及之间的逻辑和关联,形成一套完整的、可模拟的产品原型。
更注重UI交互,交互的元素颗粒度更细,如果说上一阶段是系统/功能之间的交互,那么此阶段就是组件/元素之间的交互。
这个阶段的产品输出是PRD中的交互设计部分。
5)第五阶段:详细优化——不断打磨细节,将设计中的要素标明。
需要将你的设计抽丝剥茧般的描述出来,你描述的越细致,后期同开发的矛盾越少,返工的几率也就越小。
这个阶段的产品输出是PRD中的功能描述部分,一般需求文字结合设计图进行详细的描述。
6)第六阶段:微调维护——进行可用性测试,评审通过后开始Debug你的产品形态,直至输出完整产品。
这个阶段的产品输出是产品上线前的验收与上线后宣讲等准备工作等。
与其他产品设计理念不同,UCD 对用户使用产品能做什么、想做什么、需要做什么的思考方式来优化产品,而不是强迫用户改变使用习惯来适应产品。
五、后记
在软件工程中,设计模式是一套代码设计【经验的总结】而产品方法论是一种思维模式,可以类比于软件工程中的设计模式,在需求设计中【合理的】运用方法论可以[巧妙的解决很多问题],但又不完全相同,方法论没有具象的框架,需要在抽象的世界中不断具象需求,以应对各种未知的挑战。