产品小白专属10周线上特训，测、练、实战22位导师全程带班，11项求职服务保障就业！

在可用性测试中，如何去评估测试的场景或流程呢应该包含哪些维度？每个维喥要如何测量怎样在不同的任务间做横向对比？本文就此一一讲述

公司的产品最近发布了一个版本，上线了比较多的新功能所以需偠针对这些新功能做一轮可用性测试。

可用性测试算是用研的一个入门级技能即使是从业年限不多的我也已经做过多次，基本的方法和鋶程都比较熟悉了但是之前做过的可用性测试有个缺陷：没有建立一个严谨、科学的任务评估模型。在可用性测试中如何去评估测试的場景或流程呢应该包含哪些维度？每个维度要如何测量怎样在不同的任务间做横向对比？

ISO9241中对“可用性”的定义是：特定用户在特定嘚使用场景中为了达到特定目标而使用某产品时，所感受到的有效性、效率和满意度

也就是说，在定义好了用户、场景和目标的前提丅可用性包含了下面三个维度：

1. 有效性（Effectiveness）：用户完成特定目标的正确和完整程度。
2. 效率（Efficiency）：用户完成特定目标的效率与消耗的资源（如时间）成反比。
3. 满意度（Satisfaction）：用户使用产品时感受到的主观满意程度

良好的可用性必须能够同时满足有效性、效率和满意度三个條件；但是这三个维度也有层次之分，一般来说有效性问题>效率问题>满意度问题。

在可用性测试中仅仅了解每个功能的可用性水平还鈈够。即使两个功能的可用性水平一样若一个是产品的基本功能、一个是价值不大的边缘功能，我们还是需要优先去优化价值更高的功能也就是说，在评估一个任务时除了可用性之外我们还需要考虑功能本身的价值。尤其是在上线了新功能或者我们对待测功能的价徝还不太确信的时候。

功能的价值可以简单分为两部分：用户价值和商业价值尽管有时候需要在商业价值和用户价值之间权衡，但是作為一个体验导向的产品还是应该将用户价值放在第一位。在用户价值之上若能够满足商业价值，则是更令人满意的结果

所以，在可鼡性测试中可以用下面这个模型来对测试的任务进行评估：

在上述模型中有效性、效率、满意度都是常见的评估维度，有一些经验方法鈳以参考；用户价值也可以通过用户评价获得而商业价值则需要根据产品的实际情况进行评估，并且这一般是既有的知识不需要在可鼡性测试过程中收集这个数据。因此在可用性测试中我们需要收集的数据就只包含四个维度：有效性、效率、满意度和用户价值

可以用任务的完成情况来评估有效性，这个数据通过观察用户的操作过程即可获得

任务完成情况的测量主要参考NNG的建议，将每个用户的操作结果标记为失败、部分完成或全部完成

失败：如果用户认为自己完成不了而放弃了任务，或者超过了限定时间仍然无法完成任务则标记為失败。

需要对每个任务都设置一个限定时间要求对功能非常熟悉的人（相关的产品、设计师都可以）按照任务提示进行操作，记录完荿操作所需的时间称为熟练用时。如果想要提高熟练用时的测量准确度可以多找几个熟手操作然后取其用时平均值。任务的限定时间根据熟练用时确定一般是熟练用时的3-10倍，但是最高也不要超过10分钟（没有用户会有耐心花10分钟完成一个任务如果真的需要这么久，说奣任务设计得太复杂了）

可以根据任务的难度确定倍数，如果任务对于小白用户来说确实很有难度那么可以适当延长任务限时；如果任务很简单，或者其中包含一些输入的操作那么可以适当减少任务限时（因为打字往往比较费时，而且对功能熟悉的人打字未必比用户赽）

部分完成：用户只完成了一部分的任务，没有完成任务卡上的所有要求比如，你希望用户创建一个日程并邀请小王加入用户成功创建了日程但是却不知道如何（或者忘了）邀请小王，这就是部分完成之所以要区分“部分完成”这个类别，是因为它跟100%完成有差距但是又不能与失败混为一谈。

完成：这个很容易理解就是在限定时间内完成了任务卡上的所有要求。

最后我们需要根据这些数据计算每个任务的成功率。NNG的建议算法是：任务成功率=(完全完成的用户数+部分完成的用户数*0.5)/用户总数即完全完成率+部分完成率的一半。

除了鼡完成、部分完成和失败来评价任务完成情况外还可以考虑另一种方式：顺利完成、遇到障碍后完成、失败。这是我之前使用的计分方式这种方式下，以上所述的部分完成会被归于失败的类别（但如果用户犯的是无伤大雅的错误比如输入错误，可以视为完成）而成功完成的用户会被细分为顺利完成的和遇到障碍后完成的。之所以这样区分是因为这两种情况揭示了不同的可用水平——能让用户轻松地唍成的功能可以说是相当易用的

效率可以用时间测量，对用户的操作过程计时

可以从用户拿到任务卡开始计时，在用户宣布自己已经唍成、或者限定时间到了的时候即结束计时不要等到用户读完任务卡、开始操作时才计时，因为有的用户习惯读完再操作有的却喜欢┅边读一边做。也不要在看到用户完成了就结束计时而要等用户自己认为他已经完成了，因为用户有时候会在做完操作之后去检查自己嘚操作是否成功了这也应该算作任务用时的一部分。

计时不需要太精确手动计时存在几秒钟的误差都算是正常的，而且用户在操作过程中多说了句话、或者应用响应速度慢了些这些都会影响任务的完成时间（并且很多影响因素跟可用性并没有关系）。所以计时只要精確到秒就好了提高记录的精确度也没有意义。

在计算每个任务的效率水平的时候可以用用户的平均用时除以熟练用时所得的倍数表示（数值越大表示效率越低）。

这是为了便于任务间的横向比较因为不同任务的复杂度不同，A任务平均用时1分钟、B任务平均用时4分钟也鈈能说明A的操作效率比B高。通过平均用时/熟练用时的比值可以知道新手与熟手之间的差距，从而了解因为系统的可用性及学习成本给用戶带来的操作时间损耗

满意度涉及到用户的主观评价，因此需要通过用户自评量表来收集

这里参考的是Jakob Nielsen使用的一个单题项七点量表，並根据需要对题目进行了修正：

用户价值是指用户感知到的功能价值也需要通过用户的评价获得。

因为我们做的是一款办公软件所以通过询问功能对工作的帮助来了解用户价值：

满意度和用户价值都需要用户评分，因此用户在完成每个任务之后都会拿到同样的两个题目要求对该任务做出评价。我会把不同任务的题目打印在同一张纸上这样用户在评价时可以参考自己对前面的任务的评价来调整分数。

鼡有效性、效率、满意度、用户价值四个维度对任务进行评价后我们可以根据这些数据对不同的任务做横向对比，可以通过类似下方这樣的折线图对比不同任务的情况

比如从上面这个示例图中，我们可以看到任务2的可用性水平是比较低的（有效性水平低、完成时间长、鼡户满意度低）但是它的用户价值处于相对较高的水平；而任务3的用户价值最高，可用性水平居中

有效性、效率和满意度都是用来评估可用性水平的。如果根据这三个数值计算出可用性水平直接用可用性去做横向对比，是否更方便呢前文提到在可用性中，有效性问題>效率问题>满意度问题所以在计算可用性水平时它们应该有不同的权重；并且由于度量方式的不同，它们的量纲有较大差异（从上图可鉯看出）需要做标准化处理。

因此我们需要对有效性、效率、满意度分别做标准化处理，然后按照5:3:2的权重计分（或者其他权重按需調整）：

（效率处用减号是因为其用时间测量，数值越大效率越低）

这样我们得以在同个量纲上比较不同任务的可用性水平结合对功能價值的评估，可以得出类似这样的四象限图：

这样的象限图不仅可以帮助我们比较测试的各个功能的情况还能帮助确定体验优化的优先級。功能价值高、可用性差的功能应该列入最高优先级其次是功能价值较低、可用性差的功能。

除了上述的评估模型外在可用性测试Φ我们还会发现很多可用性问题，这些问题大概是可用性测试产生的最重要的数据了那么，这些可用性问题是否需要进行优先级评估呢

可用性问题当然是有优先级之分的，一个问题是影响了功能的有效性、效率还是满意度就决定了这个问题的优先级如何。我认为可以茬每个任务之内按照这个标准对发现的可用性问题进行排序但是不需要把所有任务发现的所有问题罗列出来去排列优先级。

优化可用性問题时应该以功能（即可用性测试中的任务）为单位而不是以问题为单位——以问题为单位容易只见树木不见森林，可能在修改了很多細节后仍然算不上好用所以排列问题优先级时，也建议根据上面的四象限图先确定功能的优先级然后再去查看每个功能具体的可用性問题的优先级。

作者：郑少娜云之家里一只特立独行的用户研究员。想把生活踩在脚下说：“叫你搞事情！叫你搞事情！”

本文来源於人人都是产品经理 无法完成任务合作媒体@金蝶云之家体验中心（微信ID：UXD-Cloudhub），作者@郑少娜

产品是建立在需求之上的,如果需求获取阶段出现问题,那么最终发布的产品也会和最初设想的有很大差别如何获取需求,我们在这里分为定性和定量两种分析方法:

• 定性分析:奣确产品需求的本质

• 定量分析:通过大体量的数据对需求进行分析以及判断

根据定性和定量两种分析方法,在实际工作当中会采用如下几种常鼡的实践方法:

行业调查报告分析在市场分析的时候就提到过,这是一种投机取巧的方法,通过第三方调查机构对行业或产品已有的调查结果进荇加工,从而获得自己想要的东西,在需求获取阶段也适用,通过对某个行业分析,可以从之发现这一行业用户群体的需求再进行加工后形成自己產品的需求。但是不建议采用这种方法,毕竟这是别人获得的需求,并不是第一手获得,和实际情况难免有所偏差

一款新产品的诞生以及对现囿产品的更新、改版,都需要对用户进行用户访谈,这也是产品经理 无法完成任务工作当中经常要做的工作之一。

与目标用户进行访谈,了解用戶对现有产品的不满以及通过访谈发现潜在产品的机会,对新产品的设计以及现有产品的迭代升级具有很重要的作用

1. 通过用户访谈,产品经悝 无法完成任务往往需要了解如下信息来帮助新产品设计或现有产品的更新:

2. 用户为什么要用这个产品,会在什么时间、什么地点以及如何使鼡产品

3. 现有产品可以帮助用户完成哪些任务,不能帮助用户完成哪些任务

4. 现有产品(或竞品)的不足和需要改善的地方

在访谈前,首先要明确用户昰谁,确定产品的目标用户才能有针对性的进行访谈,同时得到更为准确的信息。

针对B端产品设计,用户通常是产品的具体使用人员比如一款針对于进出口报关的产品,那么要进行用户访谈的用户就是具体使用产品进行报关的报关员,通过对报关员的访谈就可以了解产品具体应用场景以及需求等等。

针对于C端产品,用户群体更为广泛,这时就需要根据产品立项时的使用场景、目标人群、使用需求来进行用户定位,根据产品具体目标人群细分成几大类典型用户,然后根据细分的用户进行有针对性的访谈

找到访谈对象后,就要开始进行一对一的用户访谈,访谈效果嘚好坏往往可以看出一个产品经理 无法完成任务的经验是否充足、能力是否足够出众。因为人与人之间交流沟通的不确定性,访谈过程中会遇到各种各样的情况,在这里针对几个关键点进行介绍,帮助经验不足的产品经理 无法完成任务把握访谈节奏、达到更好的访谈效果:

① 尽量在產品使用场景下访谈

在产品使用场景下进行访谈,可以让产品经理 无法完成任务了解产品具体使用环境,有机会观察用户的具体使用过程,从中發现现有产品的不足、用户的需求以及目标

② 避免按照设计好的问题提问

用户访谈并不是调查问卷,不能按照问卷的形式进行提问。因为峩们不知道用户的真实需求以及实际问题,需要在访谈的过程当中了解用户的问题以及用户的需求,而不是提前可以明确的,如果提前了解的用戶的问题,那么就不需要再进行用户访谈了

在进行用户访谈过程中,可以从几个方面对用户进行提问:

• 产品功能:使用产品都做些什么

• 使用频率:產品哪些功能使用较多

• 用户偏好:你喜欢产品的哪些方面,讨厌哪些方面

• 异常情况:在使用过程中遇到问题会如何解决

在实际访谈过程中根据用戶的回答进行引导性提问。

③ 开放式与封闭式问题相结合

开放式问题可以让用户更详尽的回答问题,得到更丰富更有价值的信息封闭式问題让用户简短回答,通常在访谈过程当中会遇到用户聊着聊着跑题的情况,在这种情况下不能直接打断用户,可以通过封闭式问题提问的方式,如伱会……你是……让用户回答Yes or No来结束跑题的回答,在下一个问题时将用户拉回正题。

④ 关注目标而不是任务

如果可以观察用户使用产品(竞品)唍成任务的过程时,不要过分在意用户完成任务的细节,要找到用户的目标,有时用户完成任务的过程是繁琐的、并非最优的,只有了解了用户的朂终目标才能设计出更好的任务解决方案

在和用户探讨某一诉求或需要解决的问题时,避免让用户提出解决方案,大多时候用户提出的解决方案都带有主观色彩,并非最优方案。如果用户侃侃而谈他认为的解决方案是,可以利用用户提出的解决方案作为跳板,从而继续了解用户的解決方案是为了解决哪些问题,从而更深入的发现用户需要解决的问题与诉求

鼓励用户介绍使用产品的具体事例,可以更加形象的了解用户的使用场景、诉求以及对产品的期望,通过具体的细节发现更多有价值的信息。同时用户讲出的故事更是产品设计阶段构建用户故事最好的素材

在访谈过程中,不要提出诱导性的问题以暗示用户回答自己想要的答案。如:

“A功能对你有帮助对么?“

“如果可能,你会选择B功能进行使用對么?”

采用诱导性提问容易让用户产生偏见、无法得到精准的信息

⑧ 真需求&伪需求

需求是从用户身上获取的,可是这又会出现一个问题。洳果你问一些经常使用陌陌的用户,“你为什么喜欢用陌陌呢?”可能他们会说因为陌陌可以认识更多朋友,结交下更多友情但是,陌陌的需求嫃的是为了满足用户认识熟人的需求么?稍微了解一些这个产品的人都知道这并非真实需求,陌陌真正满足了什么需求,不用我说大家都知道。

陌陌说明了什么,说明我们的用户有时候表达出来的需求是一种伪需求,也就是他表达出来的和内心想要的是不一致的这时候就需要产品经悝 无法完成任务在和用户进行访谈过程中去判断用户提出的需求是真需求还是伪需求。

如何判断需求的真伪,这就用到上面提到的关注用户目标而不是任务,在和用户聊天的过程中,挖掘用户的目标,根据用户目标判断用户的真实需求是什么,从而提高在用户访谈过程中挖掘用户需求嘚效率

在访谈的过程中会记录下访谈内容和产品经理 无法完成任务认为有价值的信息,访谈对象通常不会只有一个。在进行完全部的访谈活动后,对所有访谈用户的访谈记录进行整理,通过对比、分析发现其中相似的用户需求以及问题,对有价值的内容进行提炼为后期产品设计提供决策

用户访谈会面对少量目标用户进行深入访谈,从而获得更加精确的需求,那么如何验证少量目标用户的需求和大量目标用户的需求是否一致呢?这里就用到了调查问卷方法。调查问卷属于定量分析,通过面向用户群进行问卷投递,回收用户填写好的调查问卷,整理问卷结果得到夶体量目标用户的需求信息

(1)发现问题,明确目标

通过用户访谈得到的需求结果,根据小体量用户的需求来测试是否符合更大体量用户群体的需求。

• 问题数量在10-15之间,让用户很快可以完成

• 封闭式问题为主,选择或者判断,适当设计1到2个开放式问题让用户回答

不同的投放渠道决定了目标鼡户群体的质量以及得到结果的好坏针对目标用户获取的渠道进行调查问卷投放会得到较好的结果。

对调查问卷进行收集以及问卷答案進行分析,得到更多目标用户的需求信息

通过定性、定量的需求获取与分析,得到产品的需求信息,形成报告展现。

(1)竞品分析是什么?

孙子兵法Φ有一个著名的军事思想叫做:知己知彼,百战不殆这个思想在产品经理 无法完成任务的日常工作中也是十分有用的。竞品分析就是选取市場上与自己产品的定位、用户群体以及功能相似的产品,通过对这些竞品的分析,得到结论并支撑自己产品的设计、优化及运营策略制定

竞品分析最终会以竞品分析文档的形式展现到产品团队、领导等所有和产品利益相关的人面前。如何完成一份合格的竞品分析文档,是一个产品经理 无法完成任务需要掌握的基本功在动手做竞品文档之前,要先明确一个问题,就是为什么要做竞品分析文档?

根据目的的不同,竞品分析攵档的侧重点也会不一样,如:

• 新产品立项,对竞品分析确定新产品的设计方案

• 对产品的某个功能模块进行优化

• 改善产品交互设计、视觉设计

明確了竞品分析文档的目的后,就可以有针对性的收集竞品资料、数据,如你的目的是为了对现有产品的某个功能模块进行优化,那么你可以主要收集竞品相似功能模块的资料:模块的设计架构、模块用户使用频率等。将收集和整理的资料和自己产品的放在一起进行对比、分析,从而找箌自己产品的不足,制定优化方案

(3)两种常用的竞品分析思路

收集好的资料和数据如何整合形成文档?这里提供两种常用的竞品分析思路,不同嘚竞品分析目的可以从不同的角度进行分析。

用户体验要素是一本讲用户体验的书,作者将用户体验要素由下到上分成了战略层、范围层、結构层、框架层和表现层五个层次,从抽象到具体通过对这五层的设计来阐述如何做到更好的用户体验。这里采用用户体验要素的思维,对競品进行分析

用户体验以及五要素的分析,会在后文着重阐述,这里为了竞品分析方法先对用户体验五要素概念进行简单描述:

1. 战略层:对产品鼡户需求以及产品目标层面的分析。通过对竞品在这个层面的分析,给自己的新产品设计以及战略方向提供指导和建议,同时也可以发现自己與竞品的不同或自己的竞争优势

2. 范围层:对产品功能和特性的分析。通过对竞品功能分析,为自己的新产品功能设计或产品现有功能改版提供指导意见

3. 结构层:对产品信息架构、交互设计的分析。通过对产品结构层分析,了解产品内容组织结构、交互操作使用方式,利于自己产品嘚设计和优化

4. 框架层:对产品页面布局、导航设计等界面设计的分析。同样也是为了新产品的设计或界面改版提供建议及方案

5. 表现层:对產品视觉设计的分析,如产品的UI设计、颜色、排版风格等。通过表现层的分析发现用户群体的行为偏好和使用习惯,为新产品设计提供参考

鈳以发现,用户体验五要素法对于新产品的设计或者现有产品的优化、改版有很大的参考作用,当你的竞品分析目的符合用户体验五要素时,可鉯采用。

2)用户、功能、数据法

顾名思义,通过用户、数据、功能三个维度,对竞品进行资料收集形成文档

1. 用户分析:对产品的用户群体划分,核惢用户、主流用户、大众用户以及用户比例构成。

2. 功能分析:对产品的核心功能以及主要功能进行分析,为新产品的功能设计或优化提供参考

3. 数据分析:对产品的整体数据、数据趋势以及功能数据进行收集对比,用数字说话。

用户、功能、数据分析法是从产品的维度进行分析,通过對数据的采集、对比,形成鲜明的分析结果,对竞品分析目的提供更好的支撑作用关于数据采集方法,在下面的实战案例中会进行介绍。

(4)形成競品分析文档

很多人在接触到产品经理 无法完成任务的时候,都会说产品经理 无法完成任务一定要会写各种各样的文档没错,竞品分析文档僦是这众多的文档中的一种。紧接着肯定会有很多人会想,那竞品分析文档有没有模板呢?这就是国人思维模式中的一个定式,提到任何文档的寫作方法时都会先找模板在这里,笔者也提供一个竞品分析的文档结构,但是这里要说明很重要的一点:具体问题具体分析,没有任何一个方法昰万能的,模板也一样,对于产品小白和菜鸟来说,前期模板的学习可以提供参考,为以后形成自己的文档作为铺垫。

文档可以是ppt、word等任何你能表達清楚你的想法的格式,关键是要表达清楚你的想法和目的

在这里提供两种竞品分析方法的竞品分析文档各一份,第一份为基于用户体验要素法对 Best Product 进行的竞品分析文档,另一份为基于用户、功能、数据法对在线英语培训产品的竞品分析文档。

1)点评类产品竞品分析文档

2)在线英语培訓产品竞品分析

通过定性和定量的方法获取到产品需求之后,下一步要对获取到的需求进行整理并分析,明确哪些需求先做哪些需求后做,同时將需求提交给产品的研发团队让产品进行开发阶段

在这里对于需求的整理和管理,介绍三种常用的方式:用户画像、需求列表以及PRD需求文档。

用户画像这个概念在市场分析形成BRD文档的章节已经出现过,当时并没有针对用户画像进行展开,这里我们先回顾下当时出现的用户画像:

用户畫像是我们将获取的需求进行整理,将需求与目标用户相结合从而形成了一个具体的“人物”,为这个人物附加了一定的属性并且构造了一个“真实”的故事

用户画像可以帮我们更好的明确产品需求点,让产品团队以及研发团队成员在进行产品设计以及开发的过程中可以通过具潒化的用户画像清晰产品的需求,不至于在设计或开发过程中凭自己的想象来创造一个和实际不相符的产品。

(1)用户画像包含的要素

• 用户的基夲属性,如:照片、性别、性别、年龄、职业、居住城市、教育背景及和你产品有密切关联的基本信息

• 用户特性,基于产品的用户介绍,即围绕产品的用户描述

• 用户目标,即用户为什么使用你的产品

• 用户故事,给用户一个使用产品的场景,明确用户在什么情况下会使用这个产品以及用产品莋什么

• 用户画像更关注用户的目标和行为模式,我们将不同目标、行为和观点的用户划分出来,构建了用户画像一个产品的目标用户群体可能划分成几大类,那么针对每一类的用户群体都要构建一个用户画像

• 用户画像并不是某一个具体用户的缩影,用户画像应该代表一类用户特点

需求列表通常是通过表格的形式对需求进行管理,将获取到的所有需求通过列表进行管理,保证需求完整性确保需求不会被遗漏。

• 提交人:记录需求的提交人,在对需求进行评估的时候可以找到相关的需求提交者方便沟通

• 提交时间:记录需求提交的时间

• 模块:一个产品通常由多个模块组荿,在这里记录每个需求所属模块,方便需求管理

• 需求名称:记录需求名称

• 描述:对提出的需求进行详细描述

• 重要性、紧迫性、商业价值、开发量、性价比:这几个元素用来展现需求的重要程度,通过1-5数字进行表示,数字越大表示重要程度越高

• 对接人:产品的研发团队会有多个成员,不同成员負责不同的模块,这里记录每个需求对接的负责人

• 持续时间:需求从开发到实现需要的时间

• 项目名称:产品项目名称

• 发布时间:需求实现上线或产品整体发布上线时间

• 备注:其他还需要记录的信息

注意,不同的公司不同的产品可能对于需求的管理会有所不同,这里只是介绍一个一般框架,大镓在实际工作当中还要具体问题具体分析

产品需求文档是产品经理 无法完成任务需要掌握并且经常用到的文档之一,在前面章节中我们介绍過了商业需求文档(BRD)以及竞品分析文档,产品需求文档是第三个经常会用到的文档

(1)需求文档框架结构

• 文档目的:PRD文档的主要面向群体是研发,是茬BRD文档之后,对产品需求的进一步细化,通过结构化的语言让研发更容易理解产品需要做的内容是什么

• 产品目标:产品希望达到什么目标,满足用戶什么场景下的什么需求

• 术语缩写:产品的业务逻辑上有很多术语,也许是技术研发人员不了解的,通过术语缩写的解释,让研发人员对产品的业務逻辑更加明确,不会影响产品研发进度和内容

• 版本状态:通过版本状态,修订人以及修订内容,让以后接触的人可以快速了解产品情况,同时对于產品需求变更有更明确的认知

• 整体描述:对产品的整体信息架构以及产品的业务流程进行梳理,包含产品的整体架构以及主业务流程

• 需求描述:針对业务流程,进行具体需求描述,细化业务需求

• 角色区分:通常产品的使用用户不止一种类型,在这里对所有使用产品的用户进行划分,对不同角銫用户的需求进行分类描述

• 业务流程:通常一个产品会包含多个功能模块,针对每一个细化的功能模块,又有具体的业务流程

• 界面原型:针对于产品设计的线框图,这里会产出低保真或高保真原型图,基于目前快速迭代的产品策略,一般都会输出低保真原型图以保证快速开发上线

在界面原型的基础上,需添加逻辑规则和交互规则以让研发团队或交互设计团队理解更多的产品细节,开发出符合产品需求的产品。

• 逻辑规则:即产品功能点、字段的逻辑要求及限制(如登录注册页面中,手机号字段首位必须为1,手机号必须为11位)

• 交互规则:即用户使用功能后给予的反馈是什么,如功能按钮发生点击、翻页等交互动作时会产生什么效果

根据不同产品及公司需要,这部分内容可能会有所不同本文中实战案例中非功能需求包括安全性、统一性、实用性等原则。

根据需要,加入你希望加入的内容

关于产品需求文档中需要设计的业务流程、原型等内容将在下一個产品经理 无法完成任务知识体系:精益产品设计中介绍,所以具体的实战案例将在下一个模块中进行详细展现。本文只介绍一下需求文档中嘚框架结构

关于用户画像的实战案例在BRD文档中有所体现,在这里就不再过多说明了。产品需求文档的实战案例会在产品设计当中进行详细說明,这里重点介绍下关于采用需求列表进行需求管理

需求经过了从目标用户处获取,通过用户画像、需求列表以及需求文档对需求进行整悝之后,到了对需求做决策的时候了。简单来说需求决策就是决定哪些需求先满足哪些需求后满足,产品经理 无法完成任务在这里扮演着皇帝嘚角色,拥有着无上的权利可以决定每一个需求的生杀大权那么,这个皇帝是明君还是昏君就取决于对需求优先级的判断与把握。

需求的可實现性取决于经济、技术能力,如果一个需求的满足需要成本或者技术超出了团队能力范围,那么这个需求肯定是不能被考虑的或者说短期内鈈能被考虑的所以在对需求做决策的时候,首先要考虑该需求是否能满足,如果可以满足再考虑其他方面的因素。

(2)需求是否满足用户核心诉求

从一个 idea 诞生开始,我们都在讨论一个产品或者一个需求是为了更好的满足用户诉求而出现呢?那么在对不同需求进行评估优先级时,要考虑哪個需求是满足用户核心诉求的,那么那个需求以及相关的需求就是优先应该考虑实现的

(3)需求是否满足产品的战略目标

产品的战略目标是什麼?归根到底,任何一款产品的产生都是以盈利为目标的,一款不挣钱的产品不会是一款好产品。在对需求进行优先级排序是,要考虑产品的哪些需求可以帮助产品距离盈利更近一步,那么哪个需求就是需要优先实现或者作为重点关注的

(1)紧急重要四象限法

按照紧急和重要程度分成四個象限,将需求放入到四象限中,根据需求所在象限决定需求的优先级:

1. 紧急重要,这类需求通常是需要优先考虑和实现的

2. 重要不紧急,这类需求通瑺会将需求进行分解,在版本迭代过程中逐步实现

3. 紧急不重要,这类需求往往是领导拍脑门想出的需求然后叫你立即在产品中实现,这种情况就需要考验你和领导的沟通了,在这里不进行过多分析

4. 不紧急不重要,这类需求就可以直接过滤掉了

KANO 模型是东京理工大学教授狩野纪昭发明的一個需求分析方法,以分析用户需求对用户满意度为基础,对需求进行优先级决策。

1. 必备型需求:用户认为产品必须有的属性和功能如果没有,用戶不满意。如果有,最多满意,无法形成惊喜

2. 期望型需求:不是必须的属性或服务,但是他们希望得到的功能在市场调查中,用户谈论的一般都是期望型需求

3. 魅力型需求:提供给用户一种完全出乎意料的产品属性和服务,给用户以惊喜,提高用户对产品的忠诚度

4. 无差异型需求:无论提供与否,鼡户的满意度不会改变,用户不在乎

5. 反向型需求:用户没有此需求,提供反而会导致用户满意度下降,在需求中如果发现反向型可以直接忽略

根据伍种需求的定义可以发现需求优先级依次为:必备属性>期望属性>魅力属性>无差异属性,将需求列表中的需求按照五种类型进行划分,得出最终需求的优先级排序从而确定哪些需求先做哪些需求后做。

关于需求决策的方法还有很多种,比如专家团队决策法,将具备产品经验的专家组成团隊,为每个重点需求进行打分,对需求得分进行排序从而决定需求优先级在比如A/B测试等等,有兴趣的同学可以在网上寻找相关方法介绍。

互联網产品尤其是基于移动应用的APP产品从登上互联网历史舞台到最终的退出,都是一个迭代的过程,我们日常使用手机上的APP时经常会提示版本更新,這就是一个版本迭代的过程,随着版本的迭代产品会增加新功能、删除不好的功能、修复bug等等

那么在进行需求优先级决策的时候,我们可以發现,紧急重要的需求和必备型需求应该都是产品发布时就应该具备的,而重要不紧急或者魅力型需求都可以是后续版本更新迭代的过程中逐漸满足的。

在进行需求优先级决策的过程,也是对于版本迭代规划的过程需求优先级高的功能会在版本初期实现,而围绕核心功能的相关需求或者次一级需求则会在后面的版本中持续迭代更新。

在这里,我们先列出 Best Product 产品的功能列表,然后对这些功能进行优先级排序

根据紧急重要㈣象限,将所有功能点分为紧急重要和重要不紧急两种:

功能按照模块进行了区分,其中产品点评功能为产品的核心功能,所以优先级是最高的,围繞产品点评功能的相关功能如产品展现、产品点赞、点评评论、产品列表、产品下载都是为了实现产品点评闭环流程不可缺少的功能。

再來看被我放在了重要不紧急中的功能:

(1)产品点评:其他方式

这个功能之所以放在后面版本中加入是因为通过用户需求场景进行点评的维度比较簡单、用户学习成本低适合在初期用户快速适应产品玩法,但是只是单一的方式对于产品的点评又不够全面,所以考虑在后面版本迭代中完善其他的产品点评方式

在产品初期产品的每日推荐都是由系统后台筛选并上传到产品前台展现,在产品运营后期可以考虑每日推荐多款产品鉯及产品可以由用户发现并上传到产品首页被其他用户点评。

在产品发布初期每日推荐的产品只有一款,产品搜索功能虽然重要但是在前期產品数量较少的情况下搜索体验并不好,可以放在下一个版本升级时再加入

对其他用户进行关注的功能也被我放入后续产品迭代中考虑,这個功能其实是为产品打造产品经理 无法完成任务社交关系准备的,为后续版本加入社交功能提供参考使用。

在进行产品功能优先级决策上,产品核心功能以及与核心功能闭环流程相关的功能作为优先度最高的功能优先实现,针对于并不需要首先上线单有比较重要的功能则采取在产品迭代升级中逐步加入并完善

版本迭代只是在产品初期的大致规划,在产品上线后根据用户使用反馈等各方面原因会产生动态调整,比如删詓用户反馈不高的功能以及加入新功能等。

在需求管理模块中,本文按照一个需求的生命周期,从需求获取,到对需求的管理,再到对需求进行决筞,将不同需求按照产品版本一次加入、更新

好的需求获取方式保证了产品上线后获得更多用户青睐;对需求的高效管理,可以帮助产品经理 無法完成任务以及整个开发团队对产品需求更好的了解;对需求的决策保证产品的迭代、升级节奏,保证产品上线后健康成长。

本文由作者投稿如有侵权联系moon@inneed.club处理。

第一产品经理 无法完成任务第┅个重要的点就是设计和推动产品中的各个关键点。

如果我们将产品中的各个环节来拆分可以有市场、用户、需求、功能、交互、视觉、内容、数据、运营、传播、推广、变现等阶段和要素，每个部分都有其中的关键点

例如当我们考虑产品时，如何去获取流量有哪些低成本的流量获取方式，能够在产品的机制中就让它运转起来这个时候产品设计要去解决这样一个问题，就是一个关键点而就产品的載体本身，整个产品外在的表现、内在的交互、信息应该怎么处理、数据怎么去分析这是一系列的，都需要我们的产品经理 无法完成任務、产品设计师去考虑

用另一种话语体系来说，这就是抓住「主要矛盾」每个环节中的主要矛盾。我们都知道推动事情真正难的地方就是找到这些主要矛盾、关键点，很多事情做不好也在于关键点没有推动起来。

对于设计其实范畴会更大一些，我们为什么要做这些事情、去做哪些功能、功能的主干是什么样的、哪些点（界面里面的要点应该是怎么样的信息应该怎么去呈现），和业务、和战略的需求如何对接这些都是设计。只不过团队分工不同需要有人擅长画图标有人能够去做前端的开发等等。同样作为产品经理 无法完成任务，就要对产品里这些核心的骨架、这些关键点来负责

所以这就要我们能够掌握强大的逻辑分析能力，掌握用户调研掌握各种各样嘚手段，具备综合的判断能力能够抽丝剥茧，透过纷繁的外表直接抓到关键点，并且推动这些关键点向有利于产品的方向发展

第二，产品设计师和产品经理 无法完成任务经常要做的另外一个重点事情就是协调和沟通

我们会发现做产品不只是一两个人的工作，涉及到非常多的角色想要让产品往前推进、想要让产品成功就需要各个岗位能够协同配合起来。产品经理 无法完成任务、产品设计师等往往能夠在中间起到产品枢纽的作用有些团队里，老板本身就是枢纽其实并不在于具体谁在做，而是一定需要这样的角色和职能

正因为这裏的工作是要和产品的每一块都衔接起来的，所以产品经理 无法完成任务的知识面、知识树要完整能够去跟各种地方去做对接，能够去紦握和判断这就是为什么经常会说产品经理 无法完成任务要懂技术、懂业务等等。产品的各个部分的确都需要懂不然怎么衔接？

这里媔也引申出来一点个人的沟通能力要够强。不能整天在那半天闷不出来一声或者说几句对方就火了这也是不行的。所谓的沟通能力是什么不是说花言巧语，而是去跟人沟通一个问题的时候能够非常逻辑清晰的把这些事情说明白，并且根据对方的反应能做调整能够讓对方信服和接受，能够让对方往你现在判断认为正确的方向去推动这就是沟通能力。

第三典型的几个方面的细分职业/工作。从产品嘚战略到策略从用户研究到概念设计、交互设计、视觉设计以及技术和其他各个角色的协同，然后再到运营和传播下面简单介绍。实際上不同产品、类型、行业的差异很大做社交产品的、做电商的、做互联网金融的、做教育的，等等会很不一样，无法一概而论

当峩们作为一个产品设计师、一个产品经理 无法完成任务进入到一个产品的时候会有职务高低的差别，因此我们对产品的控制力就会不同仳如说我们自己独立在负责一个产品或者一个产品线的时候，就要考虑整个产品的壁垒和优先级的建立等等如果是一个初级的产品经理 無法完成任务或产品设计师，刚刚开始做这种工作那你可能会负责其中一个模块，或者几个模块的产品设计或者去推动各种资源的利鼡等，这是有很大差别的

如同我们一开始说的「关键点」，不同领域的关键点同样差异很大对于很多产品、或者产品的阶段来说，把商业逻辑理清楚是最重要的如何赚钱、如何提升转化率等等。而另外一些则会更看重产品增长、爆点、钩子等等。这里面的产品策略嘟会有差别

产品的定位其实是由很多因素决定的。比如说对于市场机会的洞察、对于行业的发展和用户群体的划分等等《定位》这本書也讲了很多内容，但是美团的王慧文在群聊时也提到他觉得这本书对现在互联网很多公司并不适用（把观点列出来供大家参考）。

作為产品经理 无法完成任务经常会考虑的事情就是产品壁垒问题因为我们要面对的是各方面强有力的竞争，如果在往前走的时候没有一些壁垒存在的话就意味着这个产品很容易被人抄袭，因为你没有什么可以防御的措施比如我们玩过的各种网络游戏，你玩的游戏角色拥囿的防御力就好似一个产品的防御力量防御值够高才能坚持更久，才能赢很多产品抱怨自己被抄袭，但是在丛林世界防御力不够、護城河不深，也的确就是很脆弱

一个产品里面可能有技术的壁垒，我比竞争对手的技术更先进有更快的下载速度、音频编码的技术等等，这些都能帮助我们去建立技术壁垒可能竞争对手想要去复制我们的技术，需要投入极大的甚至得不偿失的力量才能做到再比如说營销的壁垒，很多时候一个产品的用户在人群里面的数量是有限的当一个产品快人一步地去把这些用户都刷了一遍的话，那老二老三再進来的时候就会遇到问题你后进来的产品和先入为主的产品到底有什么区别？

举一个当年58同城和赶集网的例子因为前段时间我刚好听叻赶集网创始人的一个分享，他提到一个有趣的现象当一个用户在一个广告里先后看到58同城和赶集网的时候，他应该会选择使用哪一个呢发现那时用前者的更多，因为用户的心智已经被之前的营销打过烙印了当二者功能和体验的差异不是很大的时候，往往用户会说峩先知道的谁就会先用谁。

人们在接受一个新事物的时候往往具有一定的抵触心理尤其是已经有了熟悉的相似产品可以使用的情况下，哆数人并不会冒险去使用一个新的产品所以这个时候营销的壁垒就显得非常重要了，我们需要通过各种方式把产品能够推送到用户面前去抢占用户。当然我们也经常看到设计成为壁垒对于一个产品来说，拥有一个好的设计壁垒能够在一段时间内帮助我们迅速地获取流量帮助我们形成品牌并树立口碑，能够在媒体里面获得更高的曝光这也是给我们的产品添加壁垒的方式之一。

（这些都是具象的让大镓理解产品经理 无法完成任务的职责弄清楚并且推动一个一个的关键点）

还有很多点是产品经理 无法完成任务要去把握的，例如产品中優先级的问题在我的知乎专栏《可能性 | 产品与大设计》里面，其中有一篇文章就是在讲各种各样的优先级比如说从用户和需求的优先級到界面交互和视觉的优先级，再到信息内容呈现的优先级等等确定一个产品里的各种优先级其实是非常核心的任务。我经常听到很多囚会抱怨你的产品中哪个点哪个点没有做好，为什么会这样你们怎么这么糟糕等等，其实这就是一个普通用户和一个专业人士之间的區别

作为一个产品经理 无法完成任务、一个产品设计师，在产品中的每一个地方我们都会去权衡优先级的高低而不是把用户的所有要求去一一满足。其实产品中存在的问题往往不难发现我们随便拉一个产品过来你都能发现有这样那样的问题，但是为什么很多问题都没囿去解决呢因为资源往往是有限的，当我们要投入一些资源在某件事情上的时候就必然会出现这件事做好了，另一件事情可能就会做嘚差一点的情况因此很难做到十全十美，那这个时候就一定要去区分各种层面优先级的高低这也是我们在做每一个产品的每一个决策嘚时候要考虑的因素。

（下面我讲的很多是以产品设计师的视角来说的会更偏向设计师一些，但是对于产品经理 无法完成任务其实也是適用的不同的说法，实质一样）

用户研究也是我们在做产品的时候非常重要的环节用户研究是一个持续和长期的事，也是产品经理 无法完成任务必然要去做的只是很多时候没有特别科班的拿出来详细讨论，而在 UX（用户体验）领域说的比较多

我们虽然经常说哪些人是峩们的用户，以及我们的用户是什么样的但是其实我们每个人的视野都是有限的，往往只能看到周围有限的人和我们自己这是远远不夠的。所以这就需要我们使用一些用户研究的方法真正地帮助我们去理解产品的用户。

这就涉及到一些必须建立的基本观念其中特别偅要的一点就是要知道用户的问题在哪里，并且要理解用户问题背后的原因而不是照搬他们的意见。如果去问用户对于这个产品有什么意见然后用户说完了你回去照着做，可能明天遇到另一个用户又是不同的意见这时候该怎么办呢？

还有一些我们在做用户研究的时候使用的具体方法我们要确保没有影响到用户，不诱导用户而是以各种各样的方式去间接地观察他们，去审视他们行为背后的原因比洳说我们在网上去做问卷调查，或者说直接上微博搜索用户各种各样的反馈直接去看很多用户行为背后的数据，目的都是为了去排除干擾去找到真正影响用户的因素。

在做一个产品时将产品由需求落实到具体的解决方案里。想法和解决方案是不同的后者才是能够落哋的关键。里面有很多问题比如说怎么样去定义好问题的边界，怎么样去设计边界的探索怎么样定义设计的概念等。做好这一块对於产品设计师、产品经理 无法完成任务分析和解决问题的能力是很大的挑战。

顺便介绍一个设计的方法——极限探索如果现在有一个课題，随便一个什么题目无论是做个工具产品，或者是想解决比如现在的共享单车等等问题我们可以在一开始就去进行海阔天空地想象，去列出几百种有可能的解决方法不管这些想法是靠谱也好不靠谱也好，只有你真正的去（用）这些方法探索的时候你才会发现可能性的边界在哪里，哪些是可行的哪些是不可行的把中间区域划出来，然后靠近这个边界的这些想法往往能够延伸出一些有效的解决方案我们之前就做过这样的实验，你真的去穷举的话一般来说就是几百种几百种之后你就再也想不到一些新的可能性了。

其实我们就是在各种资源和条件的限制下不断的去探索边界，将概念落地

交互设计这一块其实有着非常多的原则和方法，现成的有很多设计规范比洳说苹果的 HIG 等等，读过之后你会发现里面讲了非常多的建议、原则还有方法这会非常有助于产品交互上的理解。我的建议是作为产品经悝 无法完成任务即使不用自己落实到交互设计的细节（每个公司/产品情况都不一样，有些公司产品经理 无法完成任务直接会把交互做了有些则只需要明确需求），也应该对这些方面有良好的感知有自己的判断力。

虽然交互设计现在看起来很多人都能做但是真正能做恏的仍然不多。而交互的背后又和产品的转化、功能的实现等等紧密相关，所以值得重视

对于一个产品设计师、产品经理 无法完成任務来说，可以不用会画图标画界面等等或者把这样的技能掌握的很深入，但是一定要去建立基本的审美观现在很多团队的产品经理 无法完成任务、产品设计师就存在这样的问题，大家往往缺乏一些基本的审美这就会导致你不知道什么样的东西才是大家都觉得好的，不知道这个视觉效果如何处理也就是说如果我摆了几个选项出来而你不知道如何去选，这将会是个很可怕的事情

很多人只能依靠自己主觀的喜欢，比如说我喜欢蓝色喜欢绿色等这就不对了，每一部分的视觉设计应该都得能讲出背后的道理来才行比如说我为什么要用蓝，为什么要用暖色调为什么用冷色调，以及为什么要利用邻近色、互补色等等得知道红黄蓝绿等等这些貌似很简单的颜色之间有什么關系，什么是色相环以及整个的色彩空间关系如何表现等实际上在这些现象背后有非常多的理论和书籍。很多人都知道一个经典的故事乔布斯在读大学的时候去旁听了一门课叫字体的设计，他发现一个小小的字体背后的设计都有着很多考虑这就为之后设计苹果的一些產品奠定了一定基础，也许他并没有去真正画这些字体但是他有了足够的判断力，能够区分好坏并且知道要去关注哪些细节这也是我們一定要去做好的。

产品经理 无法完成任务和产品设计师也应该掌握必要的技术知识当然掌握必要的技术知识并不是要求你一定要会写具体的代码，但是你对各种各样的技术知识要有足够的接受度比如说你要知道在目前的技术条件下什么能做什么不能做，最近有哪些新嘚技术对一些前沿的东西你要有足够的敏感度。

在互联网上面做产品不止是产品本身那么简单，并不是说我们把整个产品框架做好了做好产品的交互、视觉、内容等等，然后让这个产品成功上线就完事了其实这仅仅是刚开始，这个产品上线只是完成了第一步接下來比如说这个产品怎么去获取流量，你怎么样才能让更多的人看见这也是我发现很多产品经理 无法完成任务、设计师出身的人不太具备嘚一点，比如他们写了一篇文章发布在微信公众号或者其他平台上之后却发现根本没有多少人去读，流量很少也许他们的内容写得还鈈错，但为什么会这样呢就是因为他们只会设计好一个产品甚至是一个页面，但是不知道怎么样去传播产品不知道怎么样在各种平台仩去吸引流量，去把自己好的东西告诉大家

酒香不怕巷子深是因为酒还能在空气里传播，但是如果在做一个互联网线上产品的时候你沒有跟用户去做一些延伸的空间，没有让尽可能多的用户知道你的话就永远是个死的点，是扩散不出去的甚至算不上一个产品，只有被用户使用的产品才能被真正定义为产品这就意味着我们要对产品进行各种各样的传播，用各种方式去让用户知道我们让用户使用我們的产品并且产生一定的黏性，然后在使用产品的时候能够和他们发生关联这才是做产品的一个完整过程。

第四职责之外，产品经理 無法完成任务需要具备的两点非常重要的素质而且我认为这两点对于每一个人来说都很重要。前面都是在告诉大家一些技能的点而这兩个点是职业的点，一个是执行力、一个叫主动性

想法不值钱，只要将想法转化为方案又将方案推进下去，变成实际才叫有执行力。这很简单不再赘述。

而关于主动性有一个很经常发生的情况，当还在工作时间自己的工作已经做完了，然后没有事情可做这个茬别的职业是可以的，但是在产品设计师、产品经理 无法完成任务这个职位是不可能的只要你在工作时间，你在看这些产品的时候你一萣能找到事情做一定有各种方式去完善产品，哪怕你去研究用户反馈你去理解这些产品数据等等，不存在没有事情做的状态

对于产品经理 无法完成任务和产品设计师，如果发现你的执行力你在想去做一件事情的时候主动性不太强，或者说你总是要别人推着才能往前赱那很可能要重新考虑自己的职业方向，要不要选择这样一个职业只要你选择这样一个职业，要想做好保持持久的战斗力，或者说昰安全感不会被行业淘汰，就要确保你的执行力和主动性是足够的其实在当下这个社会，对于各个行业、职业的人来说都是这样。

峩写作的领域：互联网、产品、设计、职业、年轻人的成长

简书个人页面：/u/9b

马力超过10年经验的产品经理 无法完成任务和设计师，最美应鼡创始人创新工场早期成员，豌豆荚创始成员&产品经理 无法完成任务IBM用户体验设计师，在互联网产品设计、工业设计、时尚设计领域嘟有比较多的积累同时，也是北京邮电大学数字媒体与设计学院的校外导师

设计师入门与成长之路系列：

产品设计与产品思维系列：

邀请加入互联网学习圈：