怎样做好产品设计策划？（产品设计策划指南分析）

前面几章我们讲述了当我们开始想要策划一款产品的时候，首先我们需要认识、感知产品的用户，对用户有了正确认识才能找到我们产品所面对的目标用户。

找到了目标用户之后再分析他们所处的环境，使用的场景以及当下所产生的需求。通过简单的需求评估、需求分层、以及痛点公式等我们可以分析用户需求的真实性以及值不值得我们去做。

最后我们才能够针对这些需求设计一些解决问题的方案。

补充需求

所有用户需求及内部需求收集完之后我们会形成一个需求池。当需求变得繁多时，如果没有对需求进行有效管理以及优先级的评判那么产品规划将变成一团乱麻。

所以在产品方案设计阶段我们首先要知道需求的轻重缓急，知道哪些是我们现在应该做的，哪些是放在以后我们可以慢慢优化的。评估需求之前我们先通过以下三个方法查漏补缺，补充需求，明确需求的范围。

第一个方法是同类场景横推法，想一想这个需求是用户在什么情况下会产生的？有没有存在类似的场景呢？比如前面提到的线上问诊这个行为会发生在用户已经发病的情况下，那么还有没有类似的场景，是否可以思考用户在复诊的过程中会不会也希望使用线上问诊的方式呢？

第二个方法是特定场景纵向分析法，想一想这个需求的场景中，存在哪些关联行为可以提供支持？还是线上问诊这个行为，我们提供了问诊之后顺着需求链思考，用户是不是会有预约就诊这类的需求？这个场景如果打通是不是能帮助用户更好地解决问题？

第三个方法是行为目的深究法，这个方法就是产品经理的内心中不断问自己，这真的是用户确实需要的功能吗？这样做真的能解决用户的问题吗？

需求三要素

在进入需求管理阶段，我们要明确需求的三要素，问题、业务背景以及对应的解决方案。

了解清楚用户目前面对的问题是什么，线下是如何解决这个问题的，以及对这个问题有一个范围界定的精确定义。对问题有一定的认识后才能深究问题产生的背景，充分了解用户所处的场景。

在这个过程中除了需要搞清楚业务场景、业务术语以及业务环境（比如就诊行为的一些专业名词和流程等）以外，我们可以尝试询问用户希望给出的解决方案用以评估用户目前的认知水平和对问题的认识。

根据以上的反馈再形成完整的解决方案，值得注意的是给出方案的同时我们务必要有解决问题的方法以及实际成本的评估，这也是对后续方案采纳的重要考量因素之一。

还原需求

在评估需求的优先级之前，我们还有两件事要做。首先我们不妨做多点工作确认需求的真实性。吾日三省吾身，产品经理每天三省的问题应该就是：

1.要解决的问题是什么？–这里面的核心问题是什么，这个核心问题又带来了什么样的衍生问题，在这个核心问题中有没有包含细分的问题。

2.用户的场景是什么？–比如我们要做一个手机快捷多任务切换的交互方案，那么就要去想用户是在通知朋友的时候、看视频打发时间的时候还是查看资讯时要回信息的时候最需要用到多任务切换这个功能呢？

3.用户的环境是什么？—环境对产品的使用也会有很大的影响，比如用户在车上使用、在出行过程中使用手机是否只能进行单手交互？交互的过程中是不是不容易按到手机上方的按钮？

思考这些问题帮助我们在面对繁多的需求池时也能保持清醒，清楚知道自己在做什么需求，产品会有什么样的改变。

需求分类

接下来我们需要对需求进行有序的分类。首先我们可以有三个比较大得分类分别是：功能型需求、数据需求以及非功能需求。

功能型需求一般指有具体完成内容的需求，比如登录行为、线上问诊行为、商城购物等等。这些行为根据不用的场景我们还可以细分为：使用场景、维护场景以及运营场景。

非功能需求一般指为满足用户业务需求而必须具有且除功能需求以外的特性，包括系统的性能、可靠性、可维护性等等。像我们常看到的要求系统需满足2W人同时在线使用、页面反应时间不能超过2秒这些就是常见的品质类非功能需求。

数据需求一般指的是数值系统的设计以及报表监控指标的设计等等。

不同类别的需求尽量不要放在同一个维度评判优先级，在产品的不同阶段对不同类型的需求也有不同优先级。产品迭代的初期，我们更重视功能型需求的建设，这个时期就像一个拓荒的时期，需要快速做出功能实现需求占领用户；在产品日渐成熟稳定之后，为了维持稳定的运营情况，非功能性需求的保障就变得尤为重要，这时候我们就要重点评估新的功能需求对系统性能以及稳定等各方面的影响。

需求评估、优先级划分

完成了以上工作，我们终于进入需求评估的阶段。正如前面所说，当需求变得繁多时，如果没有对需求进行有效管理以及优先级的评判那么产品规划就会变成一团乱麻。那么如何有效评估需求的优先级呢？在这里我重点讲四个最实用的方法。

第一个方法是卡诺模型（KANO），在KANO模型中定义了三个层次的用户需求：基本型需求、期望型需求和兴奋型需求。

基本型需求指用户认为产品“必须有”的属性或功能。例如一个摄影软件最基本的就是要支持拍照功能，但客户并不会因为你有拍照功能就对你感到满意，充其量只是满足了基本要求。

期望型需求是指提供“比较优秀”的属性或功能，期望型需求通常是一个产品的加分项，比如一个摄影软件支持多种调整图片的工具，不但支持傻瓜式的滤镜也能在这个基础上进行参数的调整，这样用户就会感觉很满意，当没有这些功能时用户就会感觉不满意。

兴奋型需求是指提供给用户一些完全出乎意料的产品属性，使用户产生惊喜。兴奋点和惊喜点常常是一些被用户无意中发现的需求，顾客在看到这些功能之前并不知道自己需要他们。还是刚才摄影软件的例子，如果在拍人时会有与拍景色时完全不同的表现效果，那么用户在潜意识中就会产生惊喜，同样也会越发提升用户的忠诚度。

在应用这个模型的时候首先我们要搞清楚我们的需求到底会放在图中哪一个界限哪一个点，由图中可以看出，右下方的箭头一旦实现了一定的数据的必须功能，就无法再通过增加这类功能来提高客户的满意度了。无论增加多少功能，客户满意度都不会超过中点以上。左上方的箭头指示实现了一小部分就能明显提升客户满意度，这就是一个产品中的杀手锏功能。中间的箭头代表期望型功能的增加和客户满意度呈线性增长，所以这类需求越多越好。

第二个方法是RFM模型，这个模型是衡量客户价值和客户创利能力的重要工具。我们实现任何的需求做任何的功能升级都是围绕创利这一目标的，这里的利不一定代表实际的资金收入，也可以是流量、口碑等间接创利的东西。

RFM三个字母分别代表了最近一次消费、消费频率以及消费金额，我们可以把这个模型转换为对需求价值的评估，从而确定优先级。R代表实现这个需求能够吸引多少用户回头使用你的产品？F代表实现该需求能够增加客户访问、使用产品或者消费的次数吗？M代表实现该需求能够增加客户的直接消费（现金）或间接消费（PV）吗？

我们可以用1-10分去量化这三个维度，把需求放在这个模型中，得出3个维度的评分，评分越高代表优先级也越高。

第三个方法是上一章提到的痛点模型，通过对需求的持续性、厌恶程度、可替代度的分值量化，同样把这三个维度用1-10分去量化，然后计算出需求的强烈程度，有限解决强烈的需求。因这个方法在上一章有详细的讲述，所以在这里不展开分析过程。

第四个方法是重要性象限判断，这个方法是由麦肯锡提出，根据事件的重要性和紧迫性为坐标轴，可以将所有事情区分在四个象限中：重要且紧急、重要不紧急、不重要但紧急、不重要不紧急。对所有事件分类后，才能做更好地分析处理。

但这个方法其实是具有争论性的，原因在于重要与紧急的定义没有一个大致统一的定义，所以只能根据不同公司的不同情况按照你认为的重要与紧急去进行区分，在这里我就不展开讲述。

场景、问题与方案

分清楚了需求的优先级，这时候我们就把优先级高的需求挑选出来，重点分析这个需求当前的场景、问题以及解决的方案。

在这个阶段，我们可以借助UML中的工具帮助我们进行系统地分析。通过图中的问题可以帮助我们快速思考这个需求对应的场景中目前的做法是怎么样的？期望通过解决方案带来什么样的改进？这个思考的过程一方面帮助我们理清思路，另外一方面也能够形成一个较为完善的用例（USE CASE）。

用户实例

用例是一个UML中非常重要的概念，用例是对一组动作序列的抽象描述，系统执行这些动作序列得到相应的结果。这个定义可能有点拗口，我们可以理解成用例其实就是为了实现一个目标所需要的人机交互流程。比如我们常用的理财软件中存在“提款”这样一个实例，我们首先需要登录到理财软件，然后点击提现按钮，输入提现金额，输入密码，转账至银行卡这样一系列的流程，这个过程的描述就是一个用例。

但是在这个用例中，我们还必须考虑可能发生的各种其他情况，比如提取的余额不足、输入密码错误等等，这些可能发生的情况（包括正常的和异常的）就被称为用例的场景，场景也被称为用例的实例。

下图为一个用例的详细描述过程，实际工作中我们挑选需要填写的项目即可。

那么用例有什么好处呢？用例方法的有点就是完全站在用户的角度上来描述系统的功能，我们可以把系统看成一个黑箱，不需要关心系统内部是如何完成它所提供的功能，我们可以使用用例与实例来表述系统的功能性需求。对于一个完整的实例而言，我们需要补充这个用例当前发生的场景以及前置后置条件。前置条件代表完成这个用例需要得到什么的支持，比如我们提现这个用例首先得成功登录软件、判断银行账户没有被冻结、绑定了银行卡等等，后置条件代表这个用例完成后需要产出什么，比如提现后我们的银行卡内需要能查询到提现出来的金额。

流程图

有了这样一条条具像化的实例，我们能够轻松把业务流程图转化成人机交互的流程，明确每个阶段的产出物以及关注的重点信息。这种人机交互的流程展示一方面来说可以帮助我们查漏补缺，梳理现有流程，找到不合理可优化的地方，从而改善流程；另外一方面也帮助我们能够轻松完成后续的原型设计。

制作原型的第一步需要根据上述得到的流程图把每个页面模块中的功能以及跳转流程做一个直观的展示，同样也是帮助我们梳理思路发现问题的方式，在这个环节也许你能看到某些功能放在同一个页面同一个优先级是否合理？某些功能是否另外一些功能的分支功能？通过这样的模块功能展示图可以帮助我们更合理安排每个页面的功能布局以及流程设计的可用性检验。

原型制作与UI实现

最后终于到了产品经理日常工作中一个很重要的环节，产品原型的制作。原型是产品、交互设计师与开发工程师之间沟通最好的工具，当我们有了上述几个图表的铺垫，相信大家在制作原型时会感到异常的轻松。

我们可以根据模块功能展示图思考真实使用时页面信息的架构、元素的摆放以及每个页面之间的连接跳转和交互方式。原型有几种不同的选择，我们可以选择输出交互式原型或者流程式的原型、低保真原型以及高保真的原型，这些根据每个人的时间以及团队的习惯都可以有不同的选择，我建立落入实际开发阶段可以使用流程式的原型进行详细的开发评审，在展示想法以及效果评估阶段可以采用高保真的原型进行效果演示；

最后一步是把原型图交给UI设计师形成设计稿，看到最终呈现的界面效果。

在最后，我们补充一个概念叫MVP模型，即最小可行产品。当我们开发一个全新的产品实现一个全新的想法时，没有必要把所有东西都做得尽善尽美再落入市场等待检验，我们可以通过一个最小可行性产品，保留最核心的几个功能去掉一些锦上添花的功能，尽快上线验证用户以及市场的反馈，通过MVP产品实行快速的迭代，逐步完善。同样值得注意的是最小可行性产品往往是确定了一个方向之后，从一个方案开始经过快速迭代优化形成更好的产品，并非每次上线都根据市场的反馈对产品进行大刀阔斧的调整。