今天继续为大家更新《启示录-如何打造用户喜爱的产品》 

第17章

产品人物角色

Personas for Product Management

理解目标用户

产品管理的核心在于制定决策——应该抓住哪些机会 ,解决什么问题，哪些功能最有价值，谁是主要用户。有决策就有失误，但要打造成功的产品必须保证大部分决策是正确的。

人物角色又称为用户特征记录(user profile)，是指通过与用户沟通交流，确定典型的目标用户类型，在理解各类目标用户的特征的基础上建立的人物原型。人物角色是合理地描述用户特征的人格化虚拟原型，重点关注用户的行为、态度、目标。这个概念最早出现在艾伦.库珀( Alan Cooper)的著作《交互设计之路》里。

设计界似乎已经广泛采用了人物角色，我见过的大多数设计团队都在使用这种工具。不同团队创建人物角色的方法不同，有些正规，有些灵活，但在我看来，  他们都很出色。

营销团队甚至也开始在产品宣传中使用人物角色。  虽然两者使用人物角色的方法类似且富有成效，但目的不同，不能混为一谈。营销团队使用人物角色是为了找准目标消费者，激发消费需求；产品设计师则是为了分析用户的需求与在线行为。

人物角色对产品经理而言同样有用。创建人物角色的工作越早开始越好，但很遗憾，它往往被搁置，直到探索(定义)产品的最后阶段才发挥作用。原因在于创建人物角色的工作多由产品设计师完成，而产品设计师在团队中发挥作用的时间通常都太迟。

为了发掘潜在的人物角色，产品经理必须深入参与创建人物角色的工作，尤其要亲自参加用户交流和用户调查。产品经理、交互设计师、用户研究团队(如果有的话)之间必须密切合作。这项工作千万不能外包。产品经理应该参与所有的产品可用性测试，抓住一切机会与用户交流，深入了解目标用户。

作为产品管理的工具，人物角色的主要用途如下。

1.人物角色可以用来筛选重要的产品功能。假设目标用户是“玛丽”，就该添加对“玛丽”重要的功能；如果某项功能只是针对“山姆”的，就该被淘汰。人物角色既有助于决定谁是目标用户，也有助于决定谁不是目标用户，两者同样重要。面面俱到的产品往往一无是处，  使用人物角色可以避免犯这种错误。

2.产品团队常常把自己的需求当成用户需求，我在别处讨论过这个问题，使用人物角色可以避免犯这类的错误。

3.许多产品的用户类型不止一种。如果只是简单地针对每种用户添加功能，结果会是一团乱麻。这主要是设计上的问题，使用人物角色有助于对用户类型的优先级进行排序,  识别需要重点考虑用户体验的地方。

4.有了人物角色，可以方便地向团队描述产品的目标用户是谁，他们怎样使用产品，他们关心产品的哪些方面。

5.和产品原则一样，人物角色可以帮助团队成员达成共识。产品发布之前有数以千计的细节问题要解决，产品经理和设计师不可能事必躬亲。如果产品经理、设计师、文案创作人员、开发人员、测试人员在产品原则和人物角色上达成共识，解决问题的效率会更高。

以上是使用人物角色的优点，下 面谈谈注意事项。

1.有些产品团队创建人物角色后就把它束之高阁，回避为产品挑选关键人物角色的难题。宣称产品老少皆宜是自欺欺人。每个发布周期，我总是竭尽全力让产品经理集中精力关注一类关键人物角色。这并不是说该版本对其他用户就没价值、不可用，而是强调每次应该针对一类目标用户，把产品的优势发挥到极致。

2.有些产品团队不花时间与用户交流，只是基于想象和刻板的印象创建人物角色。我在这方面裁过不少跟头，没接触真实用户之前，我不会先入为主地下结论。与目标用户面对面交流是创建人物角色必不可少的环节。

3.邀请用户参加产品原型测试，我们常常面临这样一个问题：是不是只挑选关键人物角色范围内的用户参加测试?当然应该测试关键人物角色对产品的反应，但实际使用产品的人不可能完全与关键人物角色的设定相符，所以还需要测试范围外的用户。我建议邀请多样化的用户参与产品原型测试。

第18章

重新定义产品说明文档

Reinventing the Product Spec

安息吧，纸质说明文档

我认为产品说明文档的形式早就该改革了。有人说敏捷方法已经解决了这个问题：干脆放弃产品说明文档。虽然这样做存在一些问题，但我认为他们的方向没错。

讨论如何改革前，先来看看现今纸质的产品说明文档存在的问题。产品说明文档包含的范围很广，名称五花八门，有产品需求文档、市场需求文档、业务需求文档、功能规格书等等。内容覆盖范围、详细程度、文档本身的质量差别很大，就连形式也变化多端，有的是Word文档，有的是电子表格，有的是Wiki页面，还有的是用专业需求管理工具生成的。这些不同的文档本来作用各不相同，但是随着时间流逝，彼此间的界线越来越模糊。

我确实读过几份很不错的产品说明文档，  但大部分产品说明文档既没有提供必要的细节，也不包含关键信息，更不能解决问题，虽然花费了大量时间撰写，却很少有人阅读。更要命的是，对管理层和产品团队来说，产品说明文档很容易成为一个幌子，仿佛一切都进展顺利。

产品经理的核心责任是确保向开发团队交付具有成功潜力的产品说明文档。认同这一点的人只要仔细审视产品是如何定义的，就不得不承认现有产品说明文档存在不足之处。

我认为理想的产品说明文档应该满足以下要求。

1.产品说明文档应该完整地描述用户体验——不只是用户需求，还包括交互设计和视觉设计。希望大家已经明白用户需求和用户体验是密不可分的。

2.产品说明文档必须准确地描述软件的行为。文字和图片的表达能力实在有限，不足以完成这项任务。

3.产品说明文档的受众较广一开发 人员、测试人员、客服人员、市场营销人员、运维人员、销售人员、管理层等等。因此，产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。

4.产品说明文档应该可以修改。虽然进入开发阶段后，应该尽量避免修改产品说明文档，但总有意想不到的问题出现，需要修改产品说明文档以适应新情况。

5.撰写产品说明文档的过程中会出现许多衍生物，比如，按优先级排列的需求列表、线框图、实体模型，但应该有一个主体来代表产品，避免混淆不清，版本错乱。

在我看来，只有一种形式的产品说明文档可以满足以上所有要求，那就是高保真产品原型。

“高保真”的含义是原型应该真实地体现用户体验。除了描绘用户界面的某些细微之处以外，我不建议使用“纸上原型”。如今使用工具创建高保真原型既简单又快捷，成本也不高，没理由不这么做。  为了获得接近真实的用户体验，甚至应该模拟后台处理流程和某些数据。

过去几年，我的想法一直在改变。以前我认为原型只需要包含关键的用户体验组件，现在我要求原型尽可能地体现产品细节一包括所有的页面和主要的用例。尽管还是会出现一些意想不到的错误和极端状况，但原型毕竟能让产品团队更直观地把握设计要求，其优势完全可以弥补增加的成本。

当然仅仅有原型是不够的，因为有些产品行为不容易用原型体现，  比如业务逻辑(税务表单和运费等)、发布要求(性能表现、  可靠性、扩展性等)、平台交付要求(安装要求、浏览器兼容性等)。用例可以作为有效的补充，用来描述重要的产品行为。另外，如何展示补充的说明文档也值得考虑。最理想的方法是在原型上增加注释，不过这种技术还没有实现，退而求其次，我建议使用Wiki或内部网站。这样团队成员可以随时读到最新的信息，再不用浪费时间查找版本混乱的纸质文档。网站可以定期通知大家产品说明文档的更新情况，方便大家提问和讨论，并保存所有决策记录。

当然，产品说明文档的主体应该是高保真原型，由它体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计。

在我看来，除了符合以上要求外，高保真原型最突出的优势是可以用于测试。你可以把它放到真实用户面前，观察他们是否清楚如何使用(可用性)，是否渴望使用你的产品(价值)。只有通过这两项测试，产品说明文档才算合格，产品才值得开发。如果等到质检或公开测试阶段再验证，就太迟了。

我保证如果你尝试一次，创建体现功能和用户体验的高保真原型，产品团队一定会拥护这种做法。开发人员是最直接的受益者，因为他们终于看到了明确有效的产品说明，遇到不清楚的地方，随时可以参考。测试部门的工作也变得容易了，因为他们终于知道什么样的测试结果是正常的。市场部门、销售部门和客服部门也会很高兴提前了解产品。管理层也会支持这种做法，因为向投资者、董事会成员和商业伙伴展示产品时，产品原型远比PPT来得有效。高保真原型的优势还不止于此。

最让人吃惊的是，使用高保真原型可以大大缩短产品.上市时间。没错，我知道这听起来不可思议，但只要我稍稍解释传统软件开发的情况，你就能理解了。因为传统的产品说明文档起不到应有的作用(不完整、含糊不清，特别是未经测试)，而且几乎没有确定关键细节，也不解决实际困难，必须等到开发阶段这些问题才能得到解决。这导致项目要么被迫反复调整(产品说明文档不断变更，造成项目延期、士气低落)，要么开发人员只能凭空猜测，交付的产品一团糟，用户不得不等待下一个版本或多个补 丁发布后才 能使用。无论哪种情况，产品上市的时间都将推迟。

所以我建议大家尝试高保真原型，与其花几个星期撰写冗长的Word文档，既没人读，也无法测试，还不如和设计师一

起创建产品原型。把产品原型拿给团队检查，交给目标用户测试。也许要反复修改多次才能确定原型，但现在修改总比开发几个月做出糟糕的产品强。等产品原型确定后，用它代替产品说明文档交付开发，  看看会有什么结果。

想要了解更多产品经理学习知识和技能，和百人产品经理一起交流读书，请添加“ycc0607”。