真正的世界不在你的书或地图中，而是在外面。 ——《霍比特人1：意外之旅》

从来没有人告诉我产品经理应该在实际操作中怎么做。有的时候你可能完成了需求文档，就每天呆坐在位置上等待开发完成需求；有时候你可能并不知道自己要做哪些事情，而只能看着产品经理的第X本书，奉为宝典，期待书里给出一个答案。我第一次介入项目，并开始做分配的第一个需求时，意识到自己显然不能再依靠书上的知识混日子了，而是应该从零开始了解整个过程。

不管是参与到一个项目中，或是创业，或是自己组织一个业余项目，都面临一个问题：开始了之后，我应该怎么继续下去？

不管是哪一种，都必须意识到做一件事情必须是有流程的，做产品并非是凭借持久的热情和激情推动，并非是通过自我内心的驱动力和成就感去推动，大部分时候团队会进入倦怠期，因此流程化是一个比较好的选择。当然，流程这东西有时候好，有时候也容易成为阻碍，这是后话。

所以，一个产品经理刚开始介入到一个项目的时候，一定要注意对于流程的理解和掌握，任何项目都依赖制度和流程去推动。流程就好像是地图上的线路，从北京到深圳要如何走呢？高速路上可能会出现许多标识，提示我们：离深圳还有100公里。当我们顺利到达深圳，则流程就结束了，任务也完成了。

流程的重要性并非是在于指明一个方向，更是在于确定一个共同的目标，并在整个项目时间点进行分割，安排各项事务，并设立项目的里程碑。比如我刚入职的时候，不明确自己的职责是什么，还自以为是地画了一个甘特图表达自己对于手里需求的重视。实际上，这些事情应该是项目领导去制定，而我们参与其中，大家一起按照流程同步前进即可。

什么是项目？

项目可以是一个产品，可以是一个功能，可以是一个活动，项目可以是任何一个东西——但项目不能缺乏目标。项目目标确立意味着整个团队拥有了前进的方向和目标。曹操望梅止渴的故事，就是一个小项目，可以戏谑地称之为：“行军缺乏水需要尽快撤退保证军心稳定之寻找看不见的梅子项目”，目标就是“稳定军心，尽快回到大本营”。

项目目标很重要，并需要每个人都明确地了解这个目标。

我在项目中的定位是什么？

不同的项目会有不同的人员角色配置，所以产品经理一定要明确自己的职责和定位。如果有项目经理存在，一般产品经理就不需要负责项目的大小事务及推动项目进展，只需要专心搞好用户体验即可；如果并没有配置项目经理，则需要产品经理承担这部分的责任。

不仅如此，产品经理还要了解自己负责的需求是什么，这个需求是否和其他的产品经理有交集，需要和哪些开发人员及设计师去沟通，需要哪些资源和支持，这些都需要在项目之处了解清楚，不然有可能并没提前评估工作，陷入困境。

除了项目之前的准备，还需要明确产品经理在整个项目过程中有哪些职责，一般是这样：

• 制定Feature List，并排好优先级

• 与项目其他成员宣讲Feature List，并重新根据开发计划调整优先级

• 敲定了Feature List之后，开发人员、产品经理等相关成员需要输出各自的计划和方案

• 输入方案之后，产品经理撰写需求文档并进行评审

• 评审通过之后与开发、测试等需求相关的人员进行评审及宣讲需求文档的具体内容和功能

• 在开发过程中，保持与相关人员的沟通，并随时体验产品，保持体验和需求文档一致

• 在测试环节，产品经理需要和测试工程师一起保证产品质量和体验过关

• 发布前，产品经理则需要确保功能体验良好，并输出后续的计划。

从0到1 —— 先接触用户

产品经理离用户有多远？

日常查看用户反馈和建议时，我常常遇到这样一个问题，如何去有效地判断哪些反馈和意见时需要我这边进行处理的，如何安排优先级？

面对一大堆ID，我着实犯难了。对于他们，我没有现成的用户个人资料，不了解他们的场景和使用问题，不了解该如何重现对应的Bug，不了解他们急切反馈的需求是否真的已经影响了整个产品的使用，不了解还有一些喜欢发送一些负面字眼的用户，究竟时遇到了什么问题，让太慢如此恼羞成怒。每当看到反馈意见，我都不得不反复思量，逐条验证和思考。有时候，不得不感叹，产品经理满嘴离不开“用户”这个词，但实际上，我对用户了解有多深入透彻呢？

产品经理总是喜欢使用新奇的玩意。当我使用iPhone 5的时候，绝对想不到还有许多使用iPhone 4的用户，他们反馈的闪退和卡顿，是我无法体会的感受；当我习惯使用某个功能时，绝对想不到许多用户根本不理解那个按钮的意思，大部分人很担心这个功能会造成不可逆的破坏；当我身处于各种WiFi网络的环境下，想不到普通用户对于流量的珍惜。有一天，我在公交车上观察到有个人每次登录QQ都会再退出一次，连续好几次，就是担心iOS后台推送的消息会消耗流量。虽然退出帐号的方式并不能减少流量，但每个人用户对于产品功能的认知深深震撼了我。

用户群体非常复杂，如果需要给每个人列一个标签，估计会列出一大串来。对于用户群体的复杂性，很多产品经理无法很好地理解。举个例子，许多人都抱怨人多，但却不知道自己所在城市有多少人，甚至不知道全国有15亿人时一个什么概念。很多人生活在一个500万的人的城市，每天接触的人不超过500个，他就很难想象一万个人大概是多少，他们会说，大概就比现在稍微拥挤一点吧。但是到了春运的时候，看到整个火车站排了那么多人，才会惊讶整个城市原来可以容纳这么多人。

产品经理其实对于用户群体人数不是很敏感，尤其是缺少用户调研经验的产品经理，用户的概念只是一串数字而已：增长了1.3%、下降了5.4%、新增了XXX万用户。我常常和一些朋友开玩笑：国内的互联网公司简简单单地推出一款产品，动不动就上百万的用户群，对于一些国外团队来说，真的是望尘莫及，羡慕死了。在大公司做产品经理更容易对数字麻木，因为极少有产品需要艰难地成长，想尽办法新增用户，大部分时候都是依靠各种资源推广，轻松地就达到了目标。同时，用户数越庞大的产品，用户反馈越多越杂，产品经理需要大量精力去处理这些问题。所以，大部分时候，产品经理离真实的用户场景远着呢！

彼得·德鲁克(Peter F. Drucker)在《创新与企业家精神》谈到：但是，真正缺乏的，是有人愿意倾听，愿意将每个人都挂在嘴边的信念——“产品或服务的目的是满足顾客的需求”真正当做一回事。

产品经理满口提到的都是用户，大部分时候是从自己的生活经验出发，或者是通过猜想和观察去获得用户的经验。这样的方式不仅没有合理性，也不具备普遍性。观察方法是用户调研中最简单的方法，往往大部分时候用户的行为和表现不能直接用于论据，因为这些行为很有可能不具备普遍意义，而且行为很难推断动机。

史玉柱在他的自述新书中提到一个案例：去年9月份《巨人》里一个失败的修改案例，就是调整拉车的颜色。为什么会做这个决策呢？当时有玩家提意见说为什么我总是拉白车，别人都紫车。于是《巨人》的产品策划就听取了玩家的意见，就取消了随机性。

这个决策看起来很合理，用户提出别人都是紫车，我是白车，很不公平。如果我是《巨人》的产品经理，我可能也会做类似的事情。对于产品经理来说，不就是一个颜色嘛，从技术角度来看，很容易实现。通过调整这个颜色满足了用户的需求，很合理。但实际上，这就是一个只看到表面的决策——用户觉得不爽，不一定是产品的问题，很有可能是其他因素影响。从技术视角来看，颜色是否随机就是修改一个简单的函数，但从产品视角就需要确认这个产品调整颜色带来的后果。

史玉柱后来说道，本来玩家之前还有企盼，取消了车之间的差距后，再一看，没人来拉车了。后来又改了回来，改回来后，拉车的人气又起来了。

用户的心思很难琢磨，今天是一个颜色修改的问题，明天说不定还有其他的问题。每一个产品经理都会遇到类似的“陷阱”，看起来是一个很容易满足的产品需求，但大部分时候用户没有准确地说出内心真正想要的东西，往往产品经理没有深入思考，很容易就被用户误导，做出了错误的决策。

那么，应该如何有效地保证满足用户的需求，又避免被误导做出错误的决策呢？

到用户中去：找到你的核心用户

史蒂夫穆德（Steve Mulder）在《赢在用户》中提到：

• 用户的目标和我的目标不一样。
• 用户的关注点和我的关注点不一样。
• 用户和用户也不完全一样。

正是因为有这三点问题，所以产品经理在日常思考的过程中难免陷入到为自己设计的惯性思维。当然，并非产品经理不能成为用户，而是因为每个产品都有特定的用户群体，而往往这些用户不是产品经理一个人所能代表的。因为日常缺少接触真实用户场景的机会，所以大部分时候产品经理只能依靠自己的生活经验去判断用户场景，这种决策环境往往不会带来真正打动用户的改变。

不仅如此，一个产品的用户群有共同性，也有差异性。如果只是单纯满足共同性，产品决策很容易，只需要满足一种情况，但往往这种很容易满足的功能，不会带来产品经理希望看到的那种结果。很有可能用户对此的评价是：

• 哦，又多了一个新功能
• 还行吧
• 感觉有点多余了

万一这个功能做得不够好，有一些小问题，用户的反馈就不那么客气了：

• 这个新功能好烂啊
• 还不修复之前的Bug，现在又出来一堆问题
• 产品经理脑子进水了吗？

在处理共性与差异性的问题上，产品的改版是最容易受到用户反馈的。对于一个新产品来说，产品经理发现很多功能并没有真正有效地满足用户需求，于是希望通过改版去引导用户使用新功能，获得更加好的体验（当然，也包括产品自身获得更多商业价值），但用户却部这样认为。有些用户会抗拒这种改变，找产品经理哭诉要求改回原来的版本；有些用户欢迎改变，但往往没几天也开始加入到吐槽队列中；有些用户则没有表达态度，默默地使用着。豆瓣是一个神奇的网站，每次改版都被用户吐槽。继2012年12月豆瓣针对首页进行了改版之后，2013年9月又进行了一次改版。与之前改版不一样，这次并没有提供一个“返回旧版”的按钮。毫无疑问，用户开始了一轮吐槽。

图1豆瓣最新改版页面

老版本的首页是一个推荐信息页面，而“友邻广播”则是单独一个选项。新版本则把两者结合成“首页”，并加入了一些主题内容，允许用户去订阅。从产品本意来说，通过定制化的主题，增强内容的可读性和UGC质量，是一个非常好的出发点。但是这就有一个问题，是否所有的用户都非常关注首页的订阅内容？

这就是共同性和差异性在这里的体现。削弱了友邻广播，对于喜欢通过豆瓣交朋友的人来说，大量的订阅内容很可能会成为一种困扰；增强了内容可读性，对于通过豆瓣获取信息的人来说，这是一个非常好的改变。对于习惯于旧版的人来说，这次改版没有提供“回到旧版”的按钮，则会表达地比较激进。

不同的用户之间有着许多的差异性，产品经理在其中就需要不断调整方向，尽量保持平衡，满足主流用户的体验。正如钟摆的两端，一端是用户需求，一端是产品方向，每一次改版都是在寻找最佳的中间点。但这个中间点并非是一个明明确确的点，恰如赤道往北23.5度一定是北回归线那般精确，而是在每一个产品决策中进行取舍——这就引发了一个问题：产品经理每次做决策的时候，是否会出现摇摆的问题？

什么时候应该考虑用户利益，从用户角度去改善；什么时候应该牺牲部分体验，而增强产品的商业价值，的确不是特别可以把握。即使是乔布斯，也需要有一个参考系去判断，哪些时候应该选择保证最佳的体验，哪些时候应该适当弱化功能。

张小龙曾经说iPhone的设计非常符合人性，“足够自然”。不仅是因为触摸符合人的天性，home键做成硬件按钮，足够简单明了。但正是这样的设计，引发了其他问题：

• 触摸设计，忽略了用户喜欢按键的反馈体验
• Home硬件按钮容易损坏

即便是站在人文与科技路口的乔布斯，也在决策过程中不得不做出选择。正如iPhone开始流行的时候，大部分用户不会使用iTunes和iPhone进行同步，人们很难想象，为什么不应该是U盘式的体验，直接拖动文件到手机即可？但iTunes的设计理念是鼓励用户通过商店直接购买音乐传输到iPhone，而不是先下载音乐再放到iPhone中。此外，“同步”的概念很难被用户接受，为什么每次连上iPhone，都会打开iTunes进行同步操作？

正是这样的情境下，国内衍生出了许多类iTunes的服务，例如91助手，通过更符合国内用户的使用习惯，帮助用户管理iPhone。正是看准了iTunes在用户体验上的缺失，91助手等产品快速成长，通过广告等商业模式积累起了产品的价值。2013年7月，91助手被百度用19亿美金收购，让人咂舌。

没有最完美的产品，只有变幻的用户群和市场环境，因此对于用户的研究是每个互联网公司都必须十分关注的问题。lina是一名资深用户研究员，她曾和我谈起在一些互联网公司中，虽然安排了用户研究这样的岗位，但是大部分时候用户研究成为一个寻找论据的工具，而非是一个长期积累用户数据、分析用户习惯的过程。

正如上文所说，在用户价值和商业价值之间，产品经理常常需要做出决策。如何做出最佳决策，尤其是关乎用户体验的决策。一千个人眼里有一千个哈姆雷特，每个人都有自己的生活体验，因此在决策过程中，每个人都发表自己的观点，少见有一致的决策方向（即便是一致的方向，其实并不代表是最正确的决策）。这个时候，用户研究人员就出场了，他们负责根据需求进行可用性分析，寻找用户进行快速测试，判断哪个决策才是最佳选择。

“这很容易失去用户研究的意义！”我在日常的产品开发过程中，也深刻地感受到一个问题：如果用户研究仅仅是为了做出决策，那么用户研究的价值究竟有多大？作为一个有点偏执的产品经理，我曾经对于用户研究抱有深深的怀疑。

2012年时，我曾经和负责用户研究的同事一起参加用户访谈。在访谈过程中，我发现大部分时候用户研究人员为了尽快输出结果，常常需要用户进入到一个特定的情境中，然后让用户进行选择。如果失去了场景，选择是否有意义呢？

有一个有趣的故事可以分享。当年Sony引入BoomBox的概念时，他们着急了一些潜在的消费者，组成焦点小组来讨论这个新产品应该是什么颜色的。当时有两种选择，黑色或者是黄色。经过一番深入地讨论之后，用户一致认为消费者更喜欢黄色的Box。

先打断这个故事，如果各位是产品经理，这个时候你是否就可以把这个用户调研结果拿来成为一个说服老板的理由了呢？这就是把用户研究当成寻找论据的问题，大部分时候，用户表达和他们真正想要的不一定是同样的东西。

那个故事的结尾很有趣，主办方为了感谢这群用户，允许他们带走一台BoomBox。让人震惊的是，这群用户都不约而同地选择了黑色，而不是他们之前口口声称的黄色。

因此，我特别赞同《赢在用户》一书中对于用户研究的态度。SteveMulder和ZivYaar在书中描述了这样一个定位：

1.项目伊始，通过用户研究建立人物角色，并赋予这几个人物角色一些特定的资料和任务特征。

2.项目过程中，通过这几个角色人物进行有效的考虑。假如这个功能这样做，这几个角色会有哪些反应，会导致什么后果？

3.产品灰度过程过程中，针对用户群进行验证，人物角色是否有效？

4.根据用户反馈重新调整人物角色，为整个项目发展及后续新产品的提供更多思路，例如商业价值等。

在这样一个过程中，用户研究就不再是一个沦为决策工具的应急手段，而是成为项目及产品的支柱。通过对于用户的深入研究，不仅对现有的产品有参考意义，对于后续团队发展和新产品规划也有对应的积极意义。

用户调研的方法

明确了用户研究在整个项目中的作用，产品经理就应该配合用户研究同事一起关注用户研究和人物角色的创立。根据用户研究方法来看，可以分为两种：

• 定性研究
• 定量研究

定性研究，即从小规模的样本中发现问题或者真实的用户想法。这种研究方法不会证明任何事情，但是能反应这样一种事实：即用户在使用产品的过程中有可能遇到这样那样的问题和一些困惑。通过建立在用户角度的阐述，产品经理可以了解到之前没有想过的一些使用场景和体验问题。值得注意的是，这些有可能只是一个表象，而非是真实问题的根源。因此，产品经理在获得了这些信息之后，需要去伪存真，深入了解问题的本质。正是因为样本较小，所以通过定性研究获得的信息，需要通过另一种方式去论证——定量研究。

与定性研究不同，定量研究注重针对特定问题的深入了解，而前者主要是获得一些不了解的信息。定量研究是通过大量的样本来测试和证明某些事情的方法。对于定量研究来说，样本的数量和准确性，往往决定了结论的合理性。通过对于“数据库”的统计分析，产品经理可以通过统计学的原理获得一些有效且相对可靠的结论。

换句话说，定性研究是为了了解用户使用的问题，注重于WHY（为什么会这样？）；而定量研究则是为了验证猜想和论证问题，注重于WHAT（事实上这个产品功能在使用过程中有哪些问题）。简而言之，定性研究和定量研究并非是独立互斥的方法，往往可以一起使用。前者发掘出用户说了什么，后者证明用户实际上做了什么。正如Sony Boom Box的案例，定性研究只能判断用户喜欢黄色甚于黑色。如果通过大量的数据分析，可能会得到一个相反的结论，用户可能更喜欢黑色。

当用户说的和用户实际做的事情出现了矛盾之后，其实就引入了一个新的用户研究方法问题：这两种研究方法究竟应该如何有效地运用到产品日常用户研究中？当用户声称喜欢黄色，事实却选择了黑色之后，产品经理应该如何决策呢？

结合史玉柱谈及的《巨人》拉车颜色的问题，如果当时做一个定量研究，用户一定会选择要拉紫色的车子，不要白色。因为前者比较稀缺，而后者比较普遍；如果此时不做定量，而是做定性研究，估计用户才会说自己为什么想要紫色的车——两种研究方法各有弊端，就需要用户研究人员和产品经理善于设计用户调研的方案，综合考虑得出最合理的相对客观的结论。

产品经理该如何利用用户调研方法？

李明远,曾经在博客中如此描述产品经理对于用户研究的态度：

很多人是带着自己知道的结果去证明自己想的应该是对的，这不是调研，调研是对已知事实部分有未知结果和发展的（是帮助形成思路、启发而不是具体决定的），是用于防止决策错误和片面思维，而不是单纯以此形成决策的（所以为什么我们过去总是让新做产品pm的同事去做大量的调研分享，这不是抓苦力呀）；

我们做产品调研，和做统计调研的区别就是，我们是主要调研失败、尚未成功而不是主要调研已经成功的（看得失而已，不要为“所得”动），那不是产品部的工作，是商业分析部之类的工作，他们是统计分析，我们是摸排探索。

这段话让人印象深刻。产品经理并非需要了解成功的经验，并站在经验主义的角度去看事物——毕竟用户和场景都会会变化的。往往失败需要花时间精力进行调研。彼得·德鲁克在《创新与企业家精神》中亦谈到“意外的失败”对于创新的意义：

分析虽然严谨——它需要进行测试、试验和评估——但必须建立在对变化、机遇和新情况的认知上，还要敏锐地察觉到大多数人仍然十分确信的所谓现实与实际现实之间不一致的地方。这需要人们愿意承认：“我所知道的仍然不足以进行分析，但我会去发掘。我将走出办公室，四处观察，提出问题，并用心聆听。”意外事件能使我们跳出先入为主的观念、假设以及原先确定之事，所以它是创新取之不尽的源泉。

IBM公司的历史同样表明，只要对意外的成功加以重视，就能产生效果。IBM之所以有今天的辉煌，在很大程度上是两度（而非一次）利用意外成功的结果。20世纪30年代初期，IBM几乎要完蛋了。它倾其所有资金设计了第一台银行专用的电动机械记账机，但是在30年代初的大萧条时期，美国银行并不想添置任何新设备。即使在那时，IBM也不曾实施减员政策，于是它继续制造这种机器，并将成品囤积在仓库里。

就在IBM处于低谷时——故事就这么展开了。一天，IBM的创始人老托马斯·沃森（ThomasWatson）参加一个晚宴，碰巧坐在一位女士旁边。当她得知他的名字时，说道：“你就是IBM的沃森先生吗？你的销售经理为何拒绝向我展示你们的机器呢？”一位女士要记账机做什么？老沃森有点丈二和尚摸不着头脑。当她告诉老沃森自己是纽约公共图书馆馆长时，他仍旧迷惑不解，因为他从未去过公共图书馆。但是第二天早上，图书馆一开门，他就出现在那里。

当时，图书馆拥有数目相当可观的政府拨款。两个小时后，当沃森走出图书馆时，手中拿着一份足够支付下个月工资的订单。后来，他只要谈起这个故事，就会笑着补充一句：“我当场创建了一项新政策：先交款，后送货。”

因此，用户研究并非只是简单地套用方法那么简单，大部分时候产品经理和用户研究人员一定要明确每一次用户调研的方案和目标。平时我使用产品时，常常会有一些困惑，询问一些朋友，会用最简单的“人之常情”来告诉我一个答案。例如，年轻的用户比年老的用户更喜欢消费不等于年轻的用户消费金额比年老用户高，但通过“理所当然”的分析，我从身边获得答案往往充满了经验主义的回答。比如用户时常反馈想要主题，于是产品经理通过大量调研，分析了喜欢主题的用户群体，于是投其所好设计了好几款主题——一段时间后，发现默认主题依然时使用率最高的，而众望所归的主题并没有特别引人关注。

那么，我们可以断定丰富主题的功能时错误的吗？我认为这里饱含许多因素：入口的可见度（有可能大部分用户没找到对应入口呢！）；主题的排序（大部分时候用户偷懒就懒得去选择）；主题的风格（用户想要的并非此类风格？）……还有另一种猜想：用户喜欢主题并非是自己喜欢，而是想给其他人看，而该功能没有满足。正是因为有如此多的因素，所以产品经理需要确认最关键的问题和每一次用研的目标，而不能理所当然地否决自己最初的判断：主题功能是有用的，要么就是没用的。

彼得·德鲁克给予了我另一种视角：产品功能没有发挥预想的效果，有可能并非是功能没有存在的意义，而有可能是新的机会。在创新中有三种情况值得考虑：

• 意外事件
• 不协调事件
• 认知变化

上面对于主题功能的困惑就是一个意外事件，如果产品经理可以做调研，及时调整主题功能，有可能获得成功。与“理所当然”的思维不同，传统思维告诉我们，失败、意外应该被归结于运气、时机等因素，但彼得德鲁克则认为，这些事情的本质是需求没有得到满足，而且尚未有产品可以满足对应的需求，如果找到真实的用户场景和需求，有可能找到一个利基市场。

从失败中探寻到机遇，与巴菲特的投资理念“在别人贪婪的时候恐惧，在别人恐惧的时候贪婪”有着异曲同工之妙。

因此产品用研对于产品经理来说，其实一个手电筒。当你需要探索未知领域，从黑暗的失败深渊找到产品成功的曙光，从经验主义的认知中跳出来找到创新之源时，用户调研可以给予你很多灵感并指明方向。正如我前文所说，我对于一些互联网公司的用户研究方式表达怀疑，但用户研究依然是产品经理值得关注的方法；如果真正想要做一个反馈用户心声，为用户设计为中心的产品，那就在团队建设之初就开始投入用户研究的资源吧！

建立人物角色，确立核心用户

建立人物角色并非是一朝一夕之事，也并非是临时抱佛脚的措施，人物角色的创立有实际的意义。当产品经理通过大量分析确认了几个核心用户角色之后，相当于为产品经理做决策时提供了一种有效的参考。这几个核心角色，可以代表核心用户群的一些特征。角色的创建无疑为整个用户数据提供了基本的维度，用户数据不再是杂乱无章的，而是可以归纳分类的。虽然每个用户都是独立的个人，有着差异性——但从社会学研究方法来看，人的群体化属性依然奏效，因此通过核心人物角色去代表群体特征，简化了用户研究分析流程，但得到的结论依然可靠。

不仅如此，角色创立并非是应急之用，而应该成为一个模型，通过这个模型可以规避一些“不符合用户场景”的设计，并成为决策的一个参考物，贯穿整个项目始终。

对于创业团队来说，核心用户角色的创立更有深远的意义。大部分时候创业团队需要在市场中发掘用户未被满足的需求和机遇，但苦于没有一种有效的方法去接触用户（毕竟用户研究是一个很花费资源的事情）。如果建立了基本的角色模型，创业团队根据一些行为数据可以比较有效地了解市场，及时调整决策，不断投石问路找到最佳的切入点。

创建人物角色可以没有场景，独立存在。日常使用人物角色的目标是产品团队的每一次决策都可以通过用户连接起来。考虑到不同的产品和功能，不同的阶段和产品目标，都有各自的使用场景，因此，人物角色要注重独立，避免场景化太明显，导致人物角色的使用带有偏差。

图2《赢在用户》核心人物角色设计模版

按照《赢在用户》一书中建立人物角色文档的方法，人物角色的展示可以有很多的形式。SteveMulder和ZivYaar提供了一个人物角色文档的模版：

• 人物角色的姓名、照片、语录和关键差异列表，特别明显地标识出来，作为人物角色的一幅快照来使用。

• 描述性的简介、完整的关键差异（通常是用户目标的列表）和对于这个人物角色的商业目的，是第二个版块，占用这个页面最大的一块版面。

• 使人物角色充实起来的细节，比如个人信息、行业信息和计算机和互联网使用情况，安排在剩下的区域内。

• 确定人物角色的信息优先级，去掉不必要的内容。

通过建立人物角色文档可以让一些场景更加具体化，让人容易接受。

既然我们已经知道如何运用人物角色的方法，那么对于产品经理来说，面临一个新的大问题：哪些人是我们的核心用户群？

柯南道尔（SirArthurIgnatiusConanDoyle）在《血字研究》中描绘了福尔摩斯超强的洞察力：

“正是如此。因为我有那么一种利用直觉分析事物的能力。间或也会遇到一件稍微复杂的案件，那么，我就得奔波一番，亲自出马侦查。你知道，我有许多特殊的知识，把这些知识应用到案件上去，就能使问题迎刃而解。那篇文章里所提到的几点推断法则虽曾惹起你的讪笑，但在实际工作中，对我却有着无比的价值。观察能力是我的第二天性。咱们初次会面时，我就对你说过，你是从阿富汗来的，你当时好象还很惊讶哩。”

“没问题，一定有人告诉过你。”

“没有那回事。我当时一看就知道你是从阿富汗来的。由于长久以来的习惯，一系列的思索飞也似地掠过我的脑际，因此在我得出结论时，竟未觉察得出结论所经的步骤。但是，这中间是有着一定的步骤的。在你这件事上，我的推理过程是这样的：‘这一位先生，具有医务工作者的风度，但却是一副军人气概。那么，显见他是个军医。他是刚从热带回来，因为他脸色黝黑，但是，从他手腕的皮肤黑白分明看来，这并不是他原来的肤色。他面容憔悴，这就清楚地说明他是久病初愈而又历尽了艰苦。他左臂受过伤，现在动作品来还有些僵硬不便。试问，一个英国的军医在热带地方历尽艰苦，并且臂部负过伤，这能在什么地方呢？自然只有在阿富汗了。’这一连串的思想，历时不到一秒钟，因此我便脱口说出你是从阿富汗来的，你当时还感到惊讶哩。”

如果产品经理可以像福尔摩斯一样拥有如此强大的洞察力和推理能力，那还需要创建什么人物角色呢？不过福尔摩斯的洞察力并非是针对群体，而是个体，对于大部分产品经理来说，即便学习到了福尔摩斯的能力，也不一定可以快速地说出产品的核心用户群体是哪些人。

用户群是一个很有趣的研究方向——目前业界内有许多关于用户群体的研究书籍，巴拉巴西在《爆发》提到，93%的用户行为都是可以被预测的；詹姆斯·索罗维基则在《群体的智慧》描述了群体决策的质量在很多时候超过群体中的单个个体的决策质量……群体的研究意义对于产品来说，非常重要，因为这可以提供一个参考，即群体的共性是什么，群体的反应会是怎么样一个过程。正如《引爆点》一书所说，流行并非是个体行为，而是个体引发的群体行为。如果一款互联网产品可以准确地掌握群体的行为逻辑，那么成为一款流行的产品只是时日问题。但遗憾的是，大部分时候用户群体的行为很难判断。因为群体的经验并非是固定不变的，会受到很多因素影响，不同的情境、不同的中间分子会产生不一样的效果。

除了群体的行为，个体的差异性值得产品经理关注。在产品运营初期，或者是在做日常的用户调研时，常常会遇到用户反馈一些非常细节的问题，有时候产品经理会觉得这些问题很细小，并不在意；有时候则时在产品组内部做小小的调研，发现没有类似的问题，则忽略了用户反馈的一些小细节。但很有可能，这个个体的差异背后代表着一个群体都受到了类似的影响。在腾讯内部，一个产品如果有一个用户反馈Bug，那就会乘以对应的数量级，预测上万或者是百万数量级的用户受到影响。通过这种方式，让产品经理注重用户反馈的问题，起到良好的预警效果。

正是因为群体行为无法预测，个体反馈很难判断多少用户受到影响，所以产品经理在寻负责产品的核心用户群时，往往需要借助数据分析及一些专业咨询公司的帮助。

 

用户调研：区分真需求和伪需求

蒂姆·罗斯（TimRoth）在美剧《别对我说谎》（lietome）中饰演了一位可以通过观察“微表情”来判断对方是否说谎的专家。剧中描绘了多种判断对方是否说谎的方法，例如：当对方在说话的时候，眼睛不自觉地往右上看。假如蒂姆·罗斯饰演的莱特漫博士做产品经理参加用户调研，是否可以准确地把握用户需求呢？

在前几章我多次提及“伪需求”这个概念，不仅仅是因为伪需求很容易造成产品经理误解用户真实需求，更是因为大部分时候伪需求有这样一种影响力：当产品经理从用户反馈中获得一个需求，例如“用户希望加上一个快速查找的功能”，于是产品经理就会通过定量的方法去询问用户：你们是否想要一个快速查找的功能？大部分情况下，用户当然喜闻乐见新增加一个功能，而且理由也足够充分，这个功能可以方便用户快速找到对应的目标，没有人会拒绝，他们会表示“多多益善”。但实际情况呢？当时一致拍手称赞，想要新增查找功能的用户，从来都不用这个功能，而且会抱怨因为这个功能的入口存在，影响了原来的操作体验。

伪需求是这样一种需求，它缺乏真实使用场景，一般都属于拍脑袋的行为。假如一个情侣应用找单身男做用户调研，把功能说的天花乱坠，单身男肯定会表示，他会使用这个应用。对于产品经理来说，这个调研很满意，全国有20%的单身男，说明这个市场潜力非常巨大——但是，单身男使用情侣应用的前提是，他真的有一个女朋友。缺乏场景下的需求，都很容易迷惑了所有人的判断。

除此之外，需求需要区分表象和本质。因为用户在表达的时候，往往是最真实的反应，连莱特曼博士也无法判断用户是否说谎。大部分时候，产品经理听到用户反馈的需求，往往是用户在自己的经验上做出的判断和描述。

在日常用户调研的过程中，因为时间、流程及调研方式的限制，往往很多时候无法获得最准确的结论，而是获得许多素材。我参加一次用户调研访谈，询问用户是否会使用iPhone通讯录右侧的字母检索条。当时用户都反馈，他们了解这个功能，知道该怎么用。于是我又询问，假如你的好友都是按照这种形式进行排列，你是否会觉得可以很方便地找到对应的好友？用户再次表示，他们可以很方便地通过这个功能查找好友。于是，用户调研的结论是：大部分用户通过iPhone通讯录的教育，会使用右边的字母检索条，并且欢迎把这个功能应用到现在产品中。

随时用户调研人员又安排了一次可用性测试，发现用户在“指导”下知道如何使用这个功能，并且表示可以很快找到对应的好友。于是，这个功能就排期进行开发了。

事实上，经过数据统计发现一个很凄惨的事实：人们并非像当时说得那样如此“热爱”这个功能，使用该功能的比例大大低于产品经理的猜想。相信许多人已经发现了这个案例的问题所在：想用和愿意用并非是对等的关系。

在得知了实际使用数据之后，我从中发现几个有趣的点：

• 当你阐述功能的好处时，用户往往不会拒绝。

• 用户表达自己会用，不代表真实场景下，他们真的会使用。

• 产品设计的操作路径，不一定是用户最喜欢的；有时候，用户有自己的关键路径，而这条路径往往不是最短的那条。

• 习惯的力量是可怕的。

当你阐述功能的好处时，用户往往不会拒绝。在用户调研中，常常会遇到这样的情况。如果用户不用该功能，调研人员则会反问：为什么不用这个功能呢？它可以做很多事情。用户则会放弃坚持回答：我会使用的；如果用户使用该功能，调研人员则不在深入了解，默认这个态度为用户的赞同。不管出于何种原因，此类引导谬误常常会影响用户的判断，制造一种假象，即用户真的会使用该功能。

《晋书·惠帝纪》中描述了晋惠帝对于天下饥荒的态度：何不食肉糜？用户调研过程中，常常会遇到“何不食肉糜”的问题。许多情况下，产品经理会好奇用户为什么不用这些“棒极了”的功能；出于掩饰自己无知的心理，大部分时候用户往往会遮盖自己真实的情况，赞同产品经理的引导。

这个问题主要是因为产品经理在用户调研中过于积极，缺乏观察，有先入为主的情况存在，影响了调研的真实性。

用户表达自己会用，不代表真实场景下，他们真的会使用。正如前文所说，需求需要结合场景。如果剥离场景，大部分时候用户会出现言行不一矛盾。

早在19世纪30年代，美国心理学家理查德·拉皮尔（RichardLaPiere）就意识到一个人的态度与行为并不总是很牢固地联系在一起。LaPiere得出这样的结论：如果你想预测一个人在面对某一真实的特定情景或特定人物时将如何表现的话，对假设性情景的口头回答（即用户的态度）是远远不够的。

《启示录》的作者MartyCagan提供了一个简单的评判方法：可以向用户提出一个问题，“你是否愿意把产品推荐给同事（或其他你在意的任何人）”，之后我们再让用户以推荐值自己打分，0代表极不愿推荐，10代表相当愿意推荐。答案很简单，只有用户打9-10分才是真心大爱，表示用户真的会“掏钱”使用我们的产品；用户打5-7分只是出于礼貌的敷衍你，表示对我们的产品根本不感冒。

通过这种方式可以比较好地判断用户是否言行一致，符合产品经理的预期。

产品设计的操作路径，不一定是用户最喜欢的路径在日常讨论中，常常发现一些很有趣的现象，即用户都有自己的“关键路径”。例如前文曾经提到“通过Google打开百度进行搜索”的事例。JimKalbach在《DesigningScreensUsingCoresandPaths》提到”计划外的路径”，让人深思：

想象一下，当你隔着一片草坪想要到达对面的巴士站时，你是绕着草坪四周的人行道走过去，还是从中间穿过去呢？假如草地是干的，也没有被禁止进入，那么你很可能会选择最近的路线——穿过草坪直接走到巴士站。如果之前有不少人也这么干过，就会出现一条“走出来的路”。这种计划外的道路连接了两点之间的最短距离，我们周围到处是这样的例子。在城市规划中，它们被称为“交通需求线”(desirepaths esirelines)，意思是人的自然行为和人为规划路线间的差异。

在产品日常使用中，常常会出现这样的情况。产品经理及交互设计师在产品设计之初就定义了一条“道路”，希望用户可以老老实实地根据这条道路一步一步达到对应的功能，但很有可能这条道路不起作用。皮克斯的动画电影《赛车总动员》描绘了这样一个剧情：美国66号公路（USRoute66）曾经是贯穿中西部的主干道，但因为洲际公路的兴起，这条道路逐渐失去价值，人们不再经过这条曾经辉煌的公路。

实际上，如果一个产品一开始没有明确整个路径的设计，很有可能整个规划都会如66号公路一样，成为被遗弃的路径。

“不要一上来就从主页和整体导航方案来开始，而要从核心内容入手，由内而外来设计。“

JimKalbach在文中引用信息架构师AreHalland的观点，并把该原则拓展到产品设计交互原则中。但我要提出一个问题，为什么大部分时候这个原则不一定起作用？用户为什么会选择产品设计之外的路径和最短的路径？

影响用户选择路径的因素有很多，有可能是用户一开始接触的路径并非是常用路径，有可能是因为页面层级过深，这些在接下来的产品设计章节继续深入。

总之，用户调研过程常常会见到用户使用非正常路径的情况，产品经理一定要关注这样的情况，很有可能这个操作的背后暗示了这样一句话：你们产品的交互设计糟透了。

习惯的力量是可怕的观察用户使用产品的时候，常常会发现许多用户的使用习惯不符合产品经理的预期。例如许多IM产品提供了一个“最近表情”的面板，希望可以帮助用户尽快地找到表情，但大部分时候用户依然尊重原有的习惯，一页一页地滚动表情面板查找想要的表情。从操作方式来看，选择最近表情只需要三步就可以发送表情，而滚动面板查找则需要五步，但用户下意识地都选择了最常用的方式：直接查找，而且他们觉得很快捷。

这个事情深深影响我对于用户行为的理解，有的时候，用户的行为已经被深深写入到神经链路，下意识地通过习惯影响行为。在功能机时代，常常会发现一个很有意思的事情，我身边的人都学会了盲打，即他们打字的时候不需要看手机键盘，也可以准确地找到想要打出的字，这一行为被广泛用于考试作弊（注意，请勿模仿）。但是到了智能输入法时代，盲打失效了，大部分人不得不查看屏幕上显示的究竟是哪个词语。虽然智能输入法提高了人们打字的效率，但受到词库的影响，词语的顺序发生改变，让人很难通过习惯的行为去快速选字。

要么是最短的操作，要么是最熟练的操作。人天生就会适应于各种环境，正是这一种适应力造成了许多情况下的意外之行为。产品经理如果缺少生活体验，接触用户较少，很难理解用户的习惯行为如何形成并准确地优化产品体验。大部分时候，产品经理只能通过推断，选择产品设计需要合理的操作，而忽略合情的操作。因此，遭遇习惯力量的抗拒时，常常会有一些争议：我们究竟需不需要调整为用户习惯的方式？

用户调研就是如此有趣的过程，产品经理可以观察到许多有趣的事情。正是因为有如此多的问题和不合理的情况，所以产品经理在关注用户需求时，一定要倾听用户背后的故事，减少主观的理解。伪需求和真需求的判断，最关键的辨别方法就是先观察，多倾听，把产品使用融入情境，深入了解用户使用场景，而非武断地判断。

在《怪诞行为学》中，艾瑞里描绘了多种人们“非理性”的状态。在产品使用过程中，非理性的状态同样存在。产品经理在日常调研过程中，对于这些“非理性”的用户行为应该给予重视，而非主观地忽略。正如前文所说，用户反馈的需求千奇百怪，但无外乎三种情况：

1.伪需求，缺乏场景的描述和建议

2.真实存在的需求，但并不是本质问题

3.根本需求，触达本质

其中第二种需求是最让产品经理头疼的问题，通过上面我列举的一些经验来看，想要透过表象找到本质并非易事，也无法通过用户调研方法有效地找到最根本的问题。我们能做的，无非是结合用研即猜想，通过灰度方式去试错，像福尔摩斯一样发现线索。正如福尔摩斯在《四签名》中所言：

不要让一个人的特质影响你的判断能力，这是最重要的。