《启示录》一对好基友，产品经理与用户体验设计师的恩怨情仇

2016-11-11 13:00:00

第一本感触深刻的产品书，本来是在看交互设计的主题阅读。误打误撞到这一本《启示录》，作者Marty Cagan是享有世界声誉的产品管理专家，曾担任Netscape副总裁、eBay产品管理及设计高级副总裁。

虽然是产品经理视角的，但是从对于人员、流程、管理3个角度的分析得是满满的干货：

人员：是指负责定义和开发产品的团队成员的角色和职责。
流程：是指探索、开发富有创意的产品时，反复应用的步骤和成功的实践经验。
产品：是指富有创意的产品具有的鲜明特性。

全书内容超多，而且有很多整理的条目知识，比如：

成功的产品的十条规律：

产品经理的任务是探索产品的价值、可用性、可行性。
探索（定义）产品需要产品经理、交互设计师、软件架构师通力合作。
开发人员不擅长用户体验设计，因为开发人员脑子里想的是实现模型，而用户看重的是产品的概念模型。
用户体验设计就是交互设计、视觉设计（对硬件设备来说，则是工业设计）。
功能（产品需求）和用户体验设计密不可分。
产品创意必须尽早地、反复地接受目标用户的试用，以便获取有效的用户体验。
为了验证产品的价值和可用性，必须尽早地、反复地请目标用户测试产品创意。
采用高保真的产品原型是全体团队成员了解用户需求和用户体验最有效的途径。
产品经理的目标是在最短的时间内把握复杂的市场/用户需求。确定产品的基本要求：价值、可用性、可行性。
一旦认定产品符合以上基本要求，它就是一个完整的概念，去掉任何因素，都不可能达到预期的结果。

总体来讲，本书讲得是探索（定义）产品的过程不可避免的2个问题的解答：

采用什么技术来更好地解决产品要解决的问题？
设计什么样的用户体验？

精简的答案是：成功的产品基于以下两点认识：深入理解用户需求，以及明白什么样的解决方案在现阶段是可行的。

除了知识点，在www.svpg.com上，作者还放出了所有书中涉及的资料及示例，免费且无须注册。涉及机会评估(opportunity assessment)、产品原则（product principle）、产品策略（product strategy）、产品路线图（product roadmap）、产品说明文档（product spec）、产品原型（prototype）、人物角色（persona）和产品原型测试（prototype testing）等内容。

为了尽量摘录本书的大部分重点，本文将整书的内容摘录为5部分，并在下级目录中用[]标识知识点，请大家检阅自己需要的知识点进行阅读。另，在书评的整理过程中有些偏重UX视角，请大家参考：
公司产品团队的职责是什么
用户体验设计做什么
产品经理做什么
产品调研及验证
老炮经验大放送

超级产品经理

《启示录: 打造用户喜爱的产品》
豆瓣 8.5

① 公司产品团队的职责是什么

[ 产品经理 ]

产品经理职责1：评估产品机会（product opportunity）。许多公司借助市场需求文档（market requirements document，MRD）来完成这项工作。我更愿意使用一种简化的方法，我称之为机会评估（opportunity assessment）。
产品经理职责2：定义要开发的产品。确定有价值且符合公司发展要求的产品机会后，还需要探索产品的解决方案，包括基本的产品特征和功能、产品的用户体验、产品的发布标准。这是产品经理的核心职责。有些公司借助产品需求文档（product requirements document，PRD）来完成这项工作，也有人称其为产品说明文档或功能说明文档。同样，我主张采用简化的文档，围绕产品原型来展开这项工作。

[ 用户体验设计师 ]

用户体验设计团队由多种角色组成，稍后我会详细说明。这里只谈谈最关键的角色：交互设计师（也称为信息架构师、用户界面设计师、用户体验架构师）。

交互设计师负责深入理解目标用户，设计有价值的、可用的功能，以及用户导航和产品使用流程。交互设计师与产品经理密切合作，将功能与设计相结合，满足用户需求。目标是确保产品同时具有可用性和价值（可用性指的是用户明白如何使用产品，价值指的是用户对产品的渴求程度）。

一位交互设计师大约可以支持2位产品经理的工作，一位视觉设计师可以支持4位交互设计师的工作。

[ 项目管理人员 ] [ 运维团队 ]

略过。

[ 开发团队 ]

开发团队最了解哪些产品构思是可行的，他们负责产品的开发与实现。作为产品经理，你很快能体会到，只有与开发团队融洽合作，才有可能开发出合格的产品。

与开发团队合作应该遵循以下原则：在产品管理上为开发团队预留20%的自主时间，让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统性能，避免“需要停下来重写代码”的情形发生。

[ 产品营销人员 ]

产品经理负责详细定义待开发的产品，让真实的用户测试产品。产品营销人员负责向外界宣传和推广产品，负责产品发布，为拓展市场销售渠道、组织重点营销活动（如在线营销）、促进产品销售提供支持。

产品经理和产品营销人员应该经常沟通、展开合作。一方面，营销人员是产品经理获取产品需求的重要来源；另一方面，产品经理是营销人员获取市场营销信息的重要来源。

② 用户体验设计做什么

设计界应该向所有产品团队（特别是产品经理）宣传产品设计的重要性和价值。
好产品必须提供舒适的用户体验。舒适的用户体验是产品管理和用户体验设计共同作用的结果。
交互设计：在理解目标用户的基础上设计有价值的、可用的目标功能、用户导航和产品使用流程。
交互设计师通常用线框绘制产品需求，然后交给视觉设计师。
视觉设计：根据线框设计可见的用户界面（页面），包括严格的布局、颜色和字体设置等。
视觉设计能够传达并唤起产品蕴含的情感（其重要性常常被低估）。
原型制作：迅速制作融合了产品经理和设计师创意的产品原型，让用户试用，并根据反馈意见反复修正原型。
对小型产品来说，可以让一位设计师身兼多职。例如只有三个人：一位产品经理、一位交互设计师（同时负责用户研究）、一位视觉设计师（同时负责开发原型）。
交互设计不能外包：
1. 深入理解用户需求非常费时间，需要多个项目的经验积累。设计公司没时间深入了解客户需求，就算他们做到了，这些经验也很难保存下来，用到下一个版本里。
2. 交互设计师必须现场深度参与项目开发，从立项直到产品发布。开发和测试过程中会出现各种细节问题，必须有一名交互设计师迅速作出决定。
3. 产品的用户体验是公司的核心竞争力，必须在内部完成。如果让我选择，质量检验更适合外包。
只要团队中有一位称职的交互设计师，视觉设计也可以外包，毕竟视觉设计公司很多，完全可以满足需求。
至于原型制作，你可以从开发团队借个帮手来做。要让他明白原型代码和产品代码毫无关系，原型代码绝不能用在实际产品里。最好直截了当告诉他，原型的所有代码都是要废弃的。

③ 产品经理做什么

[ 评估产品经理工作 ]

常常有人问我如何评估产品经理的工作业绩。我相信唯一正确的评价标准是看产品本身是否成功。我知道这个答案难以让人满意，因为评估产品表现的方式难以确定。是按收益计算，还是按利润计算？是按用户数量计算，还是按页面访问量计算？这些指标从不同方面反映了产品的情况，但无法全面反映产品经理的业绩。

最近出现了一种考察业绩的新指标：用户净推荐值（net promoter score，NPS）。

它的原理如下。调查用户是否愿意向他人推荐你的产品，满分是10分。选择9～10分的客户称为推荐者（他们会告诉朋友非常喜欢产品，相当于在为你做宣传推广）；选择7～8分的是中立分子；选择0～6分的称为贬损者，他们不但不推荐产品，反而会在朋友面前诋毁产品。计算出推荐者所占的比例，再减掉贬损者的比例，就得到了NPS，它反映用户对产品的态度。

产品管理部门应被提升到与开发部门和市场部门相等的级别，因为产品管理和用户体验设计必须紧密合作。

[ 关于开发资源的忠告 ]

“永远不要告诉别人怎么做。告诉他们做什么，他们自然会发挥天赋，给你惊喜。”
——乔治·史密斯·巴顿

产品经理收集需求时，常听到客户建议“如何做”产品，而不是产品应该“做什么”，毕竟思考问题的解决方法是人类的本性。如果产品经理试着思考产品要做什么，就会惊讶地发现实现方法如此之多。客户其实不必考虑解决问题的途径。他们不知道什么可行，预先想出方案更是难上加难。
产品经理习惯于告诉用户体验设计师如何设计产品，却忘了告诉他们产品要“做什么”。这是普遍存在于用户体验设计中的问题。在很多公司里，用户体验设计师是稀有资源，通常在产品需求说明文档完成之后才参与产品设计，这限制了设计师的作用。用户体验设计师应该在产品经理分析目标市场、思考解决方案的初期阶段就发挥作用。
你留给用户体验设计师和开发人员的空间越大，他们就越有可能打造出用户喜爱的产品。

[ 评估产品机会 ]

评估产品机会的目的在于：淘汰馊主意，避免浪费时间和金钱；挑选合适的产品机会，团结团队，理解产品，整合资源。
为了评估产品机会，我要求产品经理回答如下十个问题。

产品要解决什么问题？（产品价值）
为谁解决这个问题？（目标市场）
成功的机会有多大？（市场规模）
怎样判断产品成功与否？（度量指标或收益指标）
有哪些同类产品？（竞争格局）
为什么我们最适合做这个产品？（竞争优势）
时机合适吗？（市场时机）
如何把产品推向市场？（营销组合策略）
成功的必要条件是什么？（解决方案要满足的条件）
根据以上问题，给出评估结论。（继续或放弃）以上问题并不涉及具体的解决方案。机会评估只讨论待解决的问题，不应涉及具体解决方案。将来有大把的时间来考虑解决方案，现在是认真考虑要解决什么问题的时候。产品经理往往把待解决的问题和解决方案放在一起考虑，当具体解决方案遇到困难时，他们会放弃产品机会。这是典型的“把洗澡水和孩子一起泼掉”的做法。

说白了，产品公司的任务就是挑选合适的产品机会，然后向用户提供实用的解决方案。产品经理负责评估各种创意，在公司投入宝贵的时间和金钱之前，淘汰蹩脚的创意，找出对公司最有利的机会。产品的机会评估结果出来后，与高管讨论，决定是否开发此产品。如果决定继续开发，了解高管的想法，有助于你进一步开展工作。

举例来说，100位打算注册使用产品的用户最后只有9人顺利完成注册，如果设法把人数提高到18，就能让产品的收益翻倍。这种改进往往很容易实现，只要做一些原型测试和用户测试，很快就能找出存在的问题，想出解决方案。

每到一家公司工作，我都会让CFO给我引荐一位财务部门的同事。他们往往能为我提供有用的信息，助我一臂之力。这种帮助主要表现在以下三个方面。

帮助你了解产品
帮助你了解用户
确认商业上的可行性

[ 产品原则制定 ]

每次加入新团队，我要做的第一件事就是制定产品原则。制定产品原则意味着决定什么重要、什么不重要，哪些原则是根本的、战略性的，哪些是临时的、战术性的。

产品原则不是产品功能的清单，不依赖于任何单独的产品，它是整个产品线的战略指南，是公司的价值宣言。好的产品原则甚至可以激发设计产品的灵感。

产品原则是否公开因公司而异。它既可以用做团队内部的指导工具，像是产品战略文档，也可以公开给客户、合作伙伴、投资人，用于向公众宣传公司的理念。

制定产品原则时容易出现两类错误。第一类是原则过于空泛，失去了指导作用。第二类是把设计原则误当成产品原则，比如，为用户提供清晰的导航路径（方便用户完成下一步操作）属于常见的设计原则，不是产品原则。

务必认真分析产品目标的优先级（从最重要到最不重要逐项排序），让团队达成共识。切不可囫囵吞枣地把所有目标都贴上“关键”和“重要”的标签。

[ 定义产品说明文档 ]

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

产品说明文档应该完整地描述用户体验——不只是用户需求，还包括交互设计和视觉设计。用户需求和用户体验是密不可分的。
产品说明文档必须准确地描述软件的行为。文字和图片的表达能力实在有限，不足以完成这项任务。
产品说明文档的受众较广——开发人员、测试人员、客服人员、市场营销人员、运维人员、销售人员、管理层等等。因此，产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。
产品说明文档应该可以修改。虽然进入开发阶段后，应该尽量避免修改产品说明文档，但总有意想不到的问题出现，需要修改产品说明文档以适应新情况。
撰写产品说明文档的过程中会出现许多衍生物，比如，按优先级排列的需求列表、线框图、实体模型，但应该有一个主体来代表产品，避免混淆不清，版本错乱。在我看来，只有一种形式的产品说明文档可以满足以上所有要求，那就是高保真产品原型。

[ 产品评审团 ]

成立产品评审团的目的是决定产品战略方向，从宏观上监督公司产品的研发流程，合理地配置资源。产品评审团不制订公司的商业战略，而是在给定商业战略的条件下，提出与之相匹配的产品战略。产品评审团的决策直接影响企业的运营。

产品评审团由公司各个部门的管理者组成。虽然各个公司的情况不同，但通常都包括以下人员。

首席执行官/首席运营官/部门总经理
产品管理总监/副总监
用户体验设计总监/副总监
市场总监/副总监
开发总监/副总监
网站运营总监/副总监
客户服务总监/副总监
产品评审团的工作效果很大程度上

它根据研发产品的四个里程碑来评审产品，制定决策：

评审产品战略和产品路线图，启动评估产品机会的工作，即选择值得投入精力的产品，请产品经理开始评估产品机会。
根据评估产品机会的结果，决定是否开始定义产品的解决方案。
评审产品原型、用户测试结果、成本估算明细，决定是否开始开发产品。
评审最终产品、产品品质、发布计划、社会效应，决定是否发布产品。

④ 产品调研及验证

[ 特约用户 ]

方法很简单，在项目的开始阶段物色至少六位积极、活跃、乐于分享的目标用户（可以先招募8～10人，然后从中筛选），要求是他们在产品的目标用户中具有一定影响力。至于他们是否使用过公司原有的产品并不重要，只要他们认为未来的产品可以解决他们手头亟待解决的问题就行。

产品经理需要确保特约用户是产品的潜在目标用户。我们很容易把产品尝鲜者（early adopter）误当成特约用户。产品尝鲜者常常能容忍产品的不足和缺陷，根据他们的建议研发的产品，很可能只适合他们自己，无法满足大众的需求。

[ 市场调研 ]

用户调查：
网络降低了用户调查的难度，提高了调查的效率，以至于现在几乎所有产品都要求做用户调查。做用户调查要注意两点：

设计调查问卷需要技巧和经验，不是一件容易的事。要结合具体情景，仔细设置问题，如果调查问卷措辞不清、先入为主，其他部门的同事就会质疑调查结果。
调查结果为获得解决方案提供了一条途径，但不是解决方案本身。哪怕所有用户都回答喜欢X特性，我们还是可以通过提供Y特性更实际地解决他们的需求。

产品使用分析：
如果你的产品是网站，有很多实用的工具可以分析用户访问网站的行为。这些工具正确安装和配置后即可使用，非常划算。越早使用分析工具越好，不断地观察学习，然后调整产品。

数据挖掘：
收集数据的渠道很多，除了上面提到的产品使用分析，还有用户的账单和账户信息、产品数据等。

拜访用户：
没有一种方法可以替代前往用户使用产品的场所（家、办公室）实地考察的作用。

合理地利用市场调研工具和方法可以回答以下几个关键问题：

谁是目标用户？
用户会怎样使用产品？
用户能想明白怎样使用产品吗？障碍在哪里？
用户为什么选用你的产品？
用户喜欢产品的哪些特点？
用户希望如何改进产品，增加哪些功能？市场调研的局限性

注意，虽然以上这些问题很重要，但它们不直接回答最根本的产品问题：打造什么产品？
市场调研结果可以作为研发产品的依据和参考，但不能决定产品研发的方向。

[ 产品人物角色 ]

人物角色又称为用户特征记录（user profile），是指通过与用户沟通交流，确定典型的目标用户类型，在理解各类目标用户的特征的基础上建立的人物原型。人物角色是合理地描述用户特征的人格化虚拟原型，重点关注用户的行为、态度、目标。

设计界似乎已经广泛采用了人物角色，我见过的大多数设计团队都在使用这种工具。不同团队创建人物角色的方法不同，有些正规，有些灵活，但在我看来，他们都很出色。营销团队甚至也开始在产品宣传中使用人物角色。虽然两者使用人物角色的方法类似且富有成效，但目的不同，不能混为一谈。营销团队使用人物角色是为了找准目标消费者，激发消费需求；产品设计师则是为了分析用户的需求与在线行为。

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

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

人物角色可以用来筛选重要的产品功能。假设目标用户是“玛丽”，就该添加对“玛丽”重要的功能；如果某项功能只是针对“山姆”的，就该被淘汰。人物角色既有助于决定谁是目标用户，也有助于决定谁不是目标用户，两者同样重要。面面倶到的产品往往一无是处，使用人物角色可以避免犯这种错误。2. 产品团队常常把自己的需求当成用户需求，我在别处讨论过这个问题，使用人物角色可以避免犯这类的错误。
许多产品的用户类型不止一种。如果只是简单地针对每种用户添加功能，结果会是一团乱麻。这主要是设计上的问题，使用人物角色有助于对用户类型的优先级进行排序，识别需要重点考虑用户体验的地方。
有了人物角色，可以方便地向团队描述产品的目标用户是谁，他们怎样使用产品，他们关心产品的哪些方面。
和产品原则一样，人物角色可以帮助团队成员达成共识。产品发布之前有数以千计的细节问题要解决，产品经理和设计师不可能事必躬亲。如果产品经理、设计师、文案创作人员、开发人员、测试人员在产品原则和人物角色上达成共识，解决问题的效率会更高。

需要的注意事项：

有些产品团队创建人物角色后就把它束之高阁，回避为产品挑选关键人物角色的难题。宣称产品老少皆宜是自欺欺人。每个发布周期，我总是竭尽全力让产品经理集中精力关注一类关键人物角色。这并不是说该版本对其他用户就没价值、不可用，而是强调每次应该针对一类目标用户，把产品的优势发挥到极致。
有些产品团队不花时间与用户交流，只是基于想象和刻板的印象创建人物角色。我在这方面栽过不少跟头，没接触真实用户之前，我不会先入为主地下结论。与目标用户面对面交流是创建人物角色必不可少的环节。
邀请用户参加产品原型测试，我们常常面临这样一个问题：是不是只挑选关键人物角色范围内的用户参加测试？当然应该测试关键人物角色对产品的反应，但实际使用产品的人不可能完全与关键人物角色的设定相符，所以还需要测试范围外多样化用户参加。

[ 高保真原型 ]

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

所以我建议大家尝试高保真原型，与其花几个星期撰写冗长的Word文档，既没人读，也无法测试，还不如和设计师一起创建产品原型。把产品原型拿给团队检查，交给目标用户测试。也许要反复修改多次才能确定原型，但现在修改总比开发几个月做出糟糕的产品强。

在软件开发过程中，有很多工作可以同时进行。比如，我一直认为需求调研和产品设计（用户体验设计）是互相影响的，应该同步展开。

[ 基本产品 ]

我号召产品团队放弃老式的产品设计方式。比如，不再试图定义最终产品，转而定义只满足基本要求（价值、可用性、可行性）的产品，简称基本产品。一旦基本产品定义完成，通过了用户测试，它就是一个不可分割的整体，去掉任何元素，都不可能获得预期的效果。

产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少，因而是非常重要的。
邀请一位开发人员（比如架构师或主程序员）参与设计原型。请他检查原型，帮助产品经理和设计师估算各种功能的直接成本和间接成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能。等产品原型确定时，他详细估算出所有产品功能的时间成本。这样一来，各项功能孰去孰留已经明了，而且对各方都是透明的，开发团队心里也有底了。
请真实用户验证（测试）产品原型，这一点至关重要。在产品团队全力开发产品前，产品经理和设计师必须确信产品是用户需要的，然而仅仅相信还不够，必须通过用户测试来验证。这好比不能仅仅因为开发人员相信代码没问题，就允许发布代码一样，必须对代码展开测试。
设计产品时一定要考虑哪些功能是最重要的，争取设计出只满足基本要求的、不可删减的产品。就像我从前的老板常说的——断腿的狗打不了猎。

[ 产品验证 ]

即证明产品的价值、可用性、可行性。

过去验证产品的代价不菲，而且困难重重。通常只有生产成本极高的产品才会这样做，比如汽车。如今创建仿真原型的成本已经非常低了，如果还有不做产品验证的团队，我会感到非常惊讶。

可行性测试：
首先要明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。有些方案通向死胡同，但总有些是可行的。重点是让开发人员寻找产品设计里那些难以克服的障碍，现在发现远比损失了时间和资金后发现来得好。

可用性测试：
可用性测试往往能发现没能成功实现的产品需求，如果测试得当的话，甚至能发现原本被忽略的产品需求。最好规划多次迭代测试，确保实现最佳的用户体验效果。一定要请真实的用户来试用可用性原型，从目标用户那里可以得到宝贵的反馈信息。虽然产品经理和设计师也能从设计和使用原型的过程中掌握大量信息，但这些都不能代替让真实用户体验原型的作用。为了测试可用性，即使要模拟复杂的后台处理过程也是值得的，关键是要评估用户体验的实际效果。

价值测试：
请注意，为了测试可用性，即使要模拟复杂的后台处理过程也是值得的，关键是要评估用户体验的实际效果。

简单的产品也许在纸上画画原型就够了，但对于大多数采用复杂用户界面、运用新技术的产品来说，必须借助产品原型评估设计是否符合要求。不同的产品有不同的原型，比如，常见的原型是可点击的页面，当然，原型也可能是物理设备，或是软件与硬件的结合。无论哪种形式的原型都必须足够真实（高保真），可以提供给目标用户测试，并获取有效的用户反馈信息。

原型测试：
如果公司设有用户研究团队和可用性测试团队，产品经理一定要争取让他们参与自己的项目。这些人是宝贵的资源，即使他们太忙分不开身，与他们建立良好的私人关系也会令产品经理受益匪浅。
有些公司允许拨款外聘专业公司开展用户研究，但这类外包服务要价不菲，通常测试十位用户需要一两万美元。产品经理不大可能展开大规模的测试。

更新原型：

有人认为必须请6～8位测试者完整地测试一遍原型，完成测试任务，回答问题后，才能下结论。我不这样看，只要对测试反馈迅速做出响应，就能显著加快完善产品的速度。你不用等到连续受到八位用户的打击后，才意识到需要解决问题。只要两三个用户反映了同一个情况，就动手解决吧。相对于判断设计缺陷来说，判断原型测试何时结束更难一些。通常，如果有连续六位测试者理解和欣赏产品的价值，而且能完成关键的测试项目，就算完成了原型测试任务。
如果你发现没法让测试者对原型产生兴趣，或是无法让原型变得足够简单易用，让测试者理解其价值，应该立马收手，放弃这个产品创意。有些产品经理不愿承认失败，但我认为，这为公司省下了一大笔成本，避免浪费资金开发失败的产品。原型测试的整个过程听起来很复杂，但其实可以做到简单高效。只要带上笔记本或原型，找一位还没用过的用户试用一下，你会发现远比你想象的简单。

⑤ 老炮经验大放送

[ 创业型公司的产品管理 ]

我想介绍一种截然不同的产品设计方式，采用这种方式不仅能提高产品的成功率，还能大幅节约创业成本。创业初期只设三个职位：产品经理、交互设计师和原型开发人员。为节约成本，公司创始人可以亲自担任产品经理，交互设计师也可以由原型开发人员兼任，只要有人负责承担这三项工作（产品管理、交互设计、原型制作）即可。这个团队可以快速展开产品设计，迭代修改。

这种产品设计流程的两个关键点：

创建体现用户体验的高保真原型；
邀请真实的目标用户验证产品原型。

在迭代设计产品原型的过程中，通常会产生很多版本，这很正常，因为创意每天都会变化，有时是小的变动，有时是大的改进。随着迭代的深入，产品会渐趋完善。这个过程通常需要从几周到两个月不等的时间。采用这种方式的优势在于：可以获得通过市场检验的产品设计；用鲜活的产品原型代替死板的产品说明文档作为开发产品的基础；加深团队对产品需求和后续工作的理解。

确定产品原型后，再招聘程序员进行开发。有了产品原型（代替产品说明文档），开发人员可以更直观、高效地领会产品设计和开发要求。这将大大缩短开发时间。

[ 苹果公司给我的启示 ]

硬件为软件服务
软件为用户体验服务：所有公司都把用户体验挂在嘴边，只有苹果公司把它放在心里。苹果公司的所有工作都围绕着产品的可用性、交互设计、视觉设计、工业设计展开。研发一款iPhone手机要两年半时间，设计用户体验几乎占了大部分时间。
用户体验为情感服务如果非要举出苹果公司成功的秘诀，我相信是这一点：他们比谁都清楚是什么让消费者为产品疯狂，他们知道怎样抓住用户的情感需求。
产品为真正的需求服务手机并非苹果公司首创，但他们挖掘出尚未被满足的用户需求。市面上的手机品种成百上千，却没几款让人爱不释手。十几年不变的语音邮件系统、不兼容的地址簿、蹩脚的网页浏览器和电子邮箱，只会让用户抓狂。苹果公司逐一完善这些功能，成功的产品应运而生。在数码音乐播放器领域，他们做得一样出色。