《腾讯产品法》个人总结4：产品设计（上）

1 设计流程

1.1 传统设计 VS 精益设计

在传统产品设计工作中，整个产品设计体系遵循一个漫长、严谨的论证设计流程，如图所示，传统流程体系是把所有环节线性串联，后一项工作必须在前一项工作结束后才能启动，以此确保各环节的质量可靠及流程严谨可控。

传统产品设计流程图.png

不过可控的另一面意味着适应变化能力薄弱。尤其当下互联网产品竞争愈渐激烈，按传统流程从用户研究到发布，很可能闭门造车几个月出来的产品却已落后于大环境，投入的开发成本打了水漂。因此，传统产品设计周期长、适应力弱的特点越来越不适用于当下的互联网产品。产品人急需一种更加高效、更具适应力的产品设计体系。
精益产品设计就是在这种大背景下出现的全新产品设计体系。精益产品设计流程把传统产品设计流程高度简化，将很多原本处于串联关系的流程并行运作起来。如图所示，它强调用户反馈与产品迭代紧密结合，通过不断“反馈--迭代”的开发循环，建立更贴近用户需求的设计机制。

精益产品设计流程图.png

接下来我们来看下一般互联网及移动互联网项目的开发流程。它们主要包含六个阶段：立项、需求、开发、体验、测试以及发布。
（1）立项阶段
该阶段是最重要的，它要回答“做还是不做”“为什么要做”的问题。不过相比“为什么做这个产品”，弄清“不做这个产品有什么损失”“最大风险和最糟的结果是什么”更重要。
在分析项目可行性的同时，分析项目风险和不可行性将有助于我们全面洞察需求和市场，进而做出正确的立项判断。通常在立项阶段，产品策划需要进行需求和市场分析，提交市场分析报告（MRD）和产品策划初稿。
（2）需求阶段
该阶段要回答“这个产品具体是什么”的问题。在立项阶段确立产品方向后，我们需要快速找到那个对的产品模型。这一阶段的主要任务包括用户研究、需求场景分析、打造MVP以及设计产品的规则、架构、流程、交互等。它是一个将产品抽象概念具体化的过程。
（3）开发、体验、测试、发布阶段
开发阶段对应“如何将产品做出来”，体验、测试与发布阶段则对应“在不同范围搜集用户反馈”。通过接受用户对“产品实际用起来怎么样”的反馈，产品得以持续迭代发展。
值得注意的是，这六大阶段并不是单纯的串联关系。它们在时间线上彼此影响、相互牵连。比如，立项阶段的讨论常常要提前涉及技术开发、运营等一系列问题；而需求阶段的方案选择也依赖于开发、运营的实现，测试与发布阶段的工作也应及早介入流程之中。
此外，相比常规互联网产品，大型游戏产品的开发制作流程更为漫长和复杂，因此其项目开发流程也与上述流程差异较大。腾讯互动娱乐业务事业群在开发集成游戏时采用的流程为：Integrated Game Development（简称IGD，集成游戏开发），其核心思路是自建审查节点，通过GR（Gate Review，关卡译审）、TDR（Technical Design Review，技术设计译审）等重要评审活动，构建产品反馈体系，及时发现项目问题。

2 用户研究

2.1 如何获取真实的用户反馈

产品的需求分析阶段如果没有引入用户研究，那就和闭门造车无异，后果严重。不过更常见的情况是，有的产品用户研究也做了，该访谈也访谈过，该发问卷也发过，但最后发现没什么作用，对产品设计实际帮助不大。
甚至还有一种更糟糕的情况：通过用户研究跟用户确认过的某个产品方案，真正推出时，用户反馈和用户研究结果差异巨大。用户研究的时候用户说会购买、很喜欢，但产品实际投入市场后根本无人问津。
那么，如何才能获取到真实的用户反馈呢？抓住两个要点即可：

2.1.1 选用对的用户研究方式

• 需求挖掘的策略阶段，尽量避免用问卷这种以封闭式问题为主的用户研究方式，定量的问卷数据不会显示潜在的需求，这时候定性的访谈会更有效。
• 产品进入开发阶段，会纠结于两个不同方案的可行性时，采用A/B Test（A/B测试）进行用户研究测试获取反馈就是不错的方法。
• 产品发布上线后，确认用户满意度和流失根本原因时，定量和定性的方式都是可行的，可以结合使用。

此外，用户研究并不局限于访谈或问卷等与用户直接交流的方式。亲自深入产品应用的场景，暗中观察用户行为是更好的选择。
网络检索或潜伏在产品相关的论坛、讨论群中观察用户的关注点，分析他们的好恶、思维模型等，也是获取用户真实反馈的有效方式。

2.1.2 遵循一些用户研究技巧

（1）问卷设计时获取真实反馈的技巧
1）别考验用户的耐心：问卷设计的问题量尽可能少、一次只问明白一个重点即可，多次发放小问卷胜于一次性让用户答一张大问卷。
2）选项的完整和独立：多个答案选项之间一定要各自独立、完全穷尽，独立意味着没有交叠部分；穷尽意味着提供的选项要覆盖所有可能性，不会出现用户被迫从选项中挑一个的情况，比如“不记得了”也是一种可能。
3）避免模糊用语：例如，答案中出现“经常、偶尔”等词语，就是有问题的。因为对不同人来说“经常、偶尔”的定义是不同的，有人认为每天才是经常，有人可能觉得一个月一两次也是经常。
4）问卷数据清洗：把一些明显紊乱、无效的数据清理排除掉再进行问卷数据统计。
（2）访谈时获取真实反馈的技巧
1）第三方立场：在访谈的最开始亮出第三方立场，表明自己是受产品设计者委托来进行的调研；即使不是第三方也要扮演第三方，打死也别承认这个产品就是你自己设计的。
2）由浅入深：访谈的话题层次由浅入深，别一上来就问敏感话题，用一些简单易答或活跃气氛的问题作为开场白，再步步深入更正式和敏感的话题。
3）聚光灯留给用户：用用户语言说话，避免专业名词，用户研究不是产品设计者的炫技场。要尽量保持无我状态，任何让你和用户产生距离的表达都要克制。让用户感觉“我的反馈很重要”。
4）及时确认和追问：当不能辨别用户的意思时，一定要做进一步确认。比如问用户“不好意思，我理解你的意思是说······这样对吗？”当发现用户跑题或用一些模糊不清的话语简单带过问题时，要及时追问下去。比如用户说“挺好的”“不太喜欢”，要具体问清好或不好的具体感觉是什么，针对那一方面而言。
5）关注隐蔽信息：有时候用户说了什么不是最重要的，一些没说出口的东西才是用户研究需要关注的重点。比如用户在谈到某个话题时传递出了异样的情绪，或者用户的思考模式异于你的预期，这些细节背后隐藏的东西都值得思考和挖掘，它们更具价值。
6）避免诱导：尽量避免提出封闭式问题。
7）保持专注和耐心：不要急着推进你的问题，给用户一些思考和停顿的时间。为了获得认同感流露出任何情绪都是不专业的表现。

2.2 建立用户模型

基于2.1小节，我们已经完成了“获取足量真实的用户反馈”。接下来我们回归目标--在MVP尚未形成的需求挖掘阶段，用户研究目标就是在真实数据基础上提炼出影响产品的最核心的因子，根据核心因子为用户分类，建立用户模型。
核心因子提炼需要一个比较长时间的抽象过程，它的结果取决于产品设计者对用户的理解程度。不同的设计者可能会以完全不同的核心因子去定义同一类产品。
案例1：女装服饰类产品
核心因子：消费能力+潮流敏感度
纵轴：消费能力的高低
横轴：潮流敏感度的强弱

某女装服饰产品建立的用户模型图.png

案例2：手机安全产品（腾讯手机管家）
核心因子：使用主动性+对手机安全产品的使用熟练度
纵轴：主动或被动
横轴：经验的多少

腾讯手机管家建立的用户模型图.png

Tips：
1）蝌蚪是什么都不懂的用户；
2）考拉是大概有概念，但是不关心不关注产品的用户；
3）穿山甲是了解手机用法，而且有探索精神的用户；
4）河马是极客用户，不信任任何安全软件，自己全部搞定。

3 需求场景分析

通过对需求、市场的分析，我们已经明确了“为谁而做”“要做一个什么样的产品”和“它将解决什么问题”，但在需求和战略阶段，这些分析都是抽象而非具体的。
一个产品具体应该是什么样，到这里我们暂时还只有一个轮廓型的认识。因此，在撩起袖子大干一场之前，我们还需要作一轮全面的需求场景分析，其目的是为了消除产品解决方案的片面性和局限性，为设计最小可行性产品做好准备。
谈到需求场景分析时，我们需要从角色、场景、方案三个维度进行分析，具体的需求场景分析模型图如下图所示，一般来说，用户模型分析工作和需求场景分析常同步进行。

需求场景分析模型图.png

##3.1 场景分析
场景分析首先要从角色类型着手。因为同一角色在不同时间、地点、情境下，会有不同层次的需求。简单来说，对于一个30岁左右的商务用户而言，同样是打车出行的需求，在日常上下班时间、周末或异地出差时都有差异；对于一个大学生用户而言，同样是听音乐的需求，在运动健身时、图书馆复习时或晚上睡觉前，也是有差异的。
案例3：QQ同步助手在2012年改版时主要的角色和场景
通信录同步产品QQ同步助手在2012年改版时，主要的角色和场景如下表所示：

QQ同步助手需求场景分析表.png

对工具类产品来说，产品要解决的问题很清楚，用户在人口学、社会学方面的因素如性别、年龄等对产品影响不大，所以可以选择按需求场景划分用户模型。但如果你做的是一款社交、运动、音乐或电商类产品，角色分类时就必须考虑人口学、社会学甚至心理学方面的影响因素。
此外，定义角色和场景的优先级也很重要，它将有助于我们设计产品的交互路径。我们通常会针对优先级最高的场景来设计产品的核心动线。对同步助手来说，最重要的角色是A类换机用户和B类备份防丢失用户；在A类用户的场景中，又以A1、A2为最高优先级；在B类用户的场景中，以B1位最高优先级。产品主页“一键同步”按钮正是针对这些高优先级场景而设计的。

3.2 方案分析

方案是用户解决问题的具体方法，它包含当前用户选择的常用方案和备选方案。在实际工作中，可以使用类似下图的表格，运用金字塔结构的思考方式，将所有需求场景穷举出来。穷举意味着场景间各自独立、没有遗漏。

需求场景分析表.png

注意，在填写方案时，必须依循完整的操作路径，沿着用户完成任务的闭环路径走一遍，记录所有过程中的行为步骤：“场景触发-A行动-B行动-C行动-D行动-问题解决”。为确保操作路径完全闭环，需要特别关注路径的起点和终点。起点由具体场景触发，它是引发后面一系列行动的动机，终点则指向问题的完结。
案例4：QQ音乐“听歌识曲”
以QQ音乐“听歌识曲”为例，在没有这一功能前，人们解决“听歌识曲”问题的需求场景分析如下表。其中一种常用方案可以记录为：“凭记忆辨认-想不起来-向朋友哼唱-得到答复-手机搜索歌曲并确认-问题解决”。前面对应的场景描述了行为的触发点：听到或脑海中浮响起某段音乐。

QQ音乐“听歌识曲”需求场景分析表.png

而使用“听歌识曲”功能后，方案变成了“手机打开App-进入听歌识曲-问题解决”。产品提供的新方案大大提升了解决方案的效率。一个有趣的状况是，越是需求明确的问题，在没有推出好的产品解决方案时，常用方案的操作路径都比较繁琐，并且存在显著的共性。

上一篇：《腾讯产品法》个人总结3：洞见需求
下一篇：《腾讯产品法》个人总结5：产品设计（下）