设计经验十步打造一篇好

　　PRD是一个不断变化的文档，从项目启动时起你就要在PRD中跟踪所有的功能。
　　PRD描述的是你公司即将创建的这个产品。它体现了整个产品团队的努力，以及公司的销售人员、市场以及顾客的支持与努力。对于一个公司来说，打造一个更重要、更高水准的产品是十分艰难的。
　　产品需求文档的目的，或者说产品规则的目的，是为了清楚的准确无误的表达产品的目的、特征、功能以及行为。产品团队需要利用这份需求文档去创建一个产品并测试它，所以它需要提供给他们足够完整的信息。
　　PRD写得好，不一定会诞生一个成功的产品，但PRD写得不好，它几乎不可能会产生一个好的产品。
　　PRD VS MRD
　　我们在这里做一个产品需求和市场需求（通常被称作MRD）的比较。简单说来，市场需求描述的是机遇或者市场需求，而产品需求描述的则是一个因机遇或需求产生的产品。
　　PRD VS Product Strategy & Roadmap
　　Product strategy（市场策略）描绘的是一个蓝图，比如说在2-5年之后，你的产品要走向哪；Roadmap（产品路线图）则描绘了到这里的各种步骤，而PRD描绘的是沿着这条路所推出的一款特定产品。
　　十步打造一篇好PRD
　　这篇文章的目的就是为了描述一个被证实过的、可重复使用的，创建一篇好PRD的的过程。文章中讲的十步都不容易，但它们能帮助你诞生一个特别棒的PRD。这个过程所花费的时间很大程度取决于你产品的尺寸和复杂度，以及你就这些知识和所需技能的准备程度。
　　第一步：做你的家庭作业
　　你PRD的目标是想出一款特定的产品。为了想出这款产品，你必须做家庭作业。这意味着你需要去研究你的顾客，你的竞争对手，你的团队能力，以及可能用到的技术设备。
　　从顾客、用户、竞争对手、行业分析、你的产品团队、销售人员、市场、公司执行力、以及其他任何对这个问题有见解和有可能解决方法的同事着手。
　　需要准备的还有很多，同样需要注意的是，使你的团队信服产品最后能成功是你能力中一个十分重要的因素，这是你自信程度的体现，如果你的家庭作业做得好，你将越来越自信，越来越使人信服。
　　第二步：确定产品目标
　　每一个好的产品都是从尝试实现一个需求开始。你必须对那个需求有一个十分明确的理解，并且知道你的产品如何解决那个需求。
　　产品经理建立一套清楚的、简洁的价值主张是十分有必要的，这能够让她轻松的和每个人沟通——产品团队成员、公司决策人员、顾客、销售人员——这个产品真正的点在哪里。
　　但是很少有产品有这样一个非常清楚的价值主张。想想＂电梯法则＂测试，如果你有机会和你公司的CEO搭乘同一部电梯，她问你，你产品的点是什么？你能在电梯上升之前回答这个问题吗？如果不能，你还有工作要做。
　　也许这个产品没有重点，也许尝试做了很多事情但没有什么脱颖而出。也许你认为是重大的事，可在客户那却没有任何响应。有可能你的产品正在尝试解决一个non-problem，也许你已经有了技术却仍然在尝试申请。
　　在产品策略中，产品是如何帮助用户的？价值主张中应该把这点弄清楚。然而你不需要谈到每一个小功能，就一个清楚的价值主张而言，少即是多。
　　产品需求应将产品的目标，以及目标如何被衡量明确讲清楚。同时这个目标应该确定优先顺序。
　　例如，你的目标可能是：1）很容易使用；2）零售价格低于100$；3）和之前发行的保持一致。然后你要详细阐述你将如何衡量这些目标。一个物品确定具体零售价格，这是很简单的。对于＂很容易使用＂这点，你需要去详细说明，产品需要的可用性应该达到一个什么样的水平。这通常是根据目标用户界定的。可用性工程师会根据所给的用户类型来评估产品的可用性。他们同样会评估可用性问题的严重性，你也许会详细说明这里将不会有主要的可用性事件。
　　关键是让每个相关人员清楚，成功的产品看起来是什么样子，并在平衡设计与实施时为产品团队提供引导。
　　第三步：确定用户特征、目标和任务
　　现在既然你已经理解了你想要解决的问题是什么，就可以开始对目标和顾客做一个深入的理解。在这个步骤中，和你的产品设计师一起紧密工作很重要。
　　用户特征
　　在这个阶段，产品经理将会遇见很多目标客户，并会花大量的时间来获得第一手的观察和讨论结果。现在我们需要将用户类型和客户分类，并确定谁是主要用户。
　　例如，你正在构建一个像eBay一样的产品销售平台，你知道你有买方和卖方，其中你有低流量／低频用户和高流量／高频用户。不难想象还有一些其他不常见的用户类型，例如企业购买代理人，会为他们公司买一些东西。
　　产品经理和设计师首先需要去做的事——确定最重要的用户，然后尝试用大量的细节将其描绘出来，以便你能够利用这些特征来指引你设计产品。这些特征有时候被称之为＂用户角色模型＂，然而当他们是虚假的时候，你应该尽可能的将他们描绘得客观、逼真、合理。这主要是为了构思出一个能够抓住这类用户本质的原型。
　　这里有一个例子：
　　Leon，超级卖家，46岁，男，住在弗雷斯诺，经营着一个小小的摩托车零部件业务。然而他这个小商店几乎所有的销售都来自于eBay，在eBay上他平均每个月卖掉400件东西。摩托车相关的大部分东西他都卖，但是卖得最好的是哈雷戴维森的挂包，他自己有两辆大的哈雷，他同时开着一辆1933年的丰田皮卡。Leon结婚了并有两个十几岁的儿子。
　　Leon买电脑仅仅是为了使用eBay，除了eBay和邮件，其余东西很少用。至今为止，Leon在eBay已经卖了3年了，他已经知道他需要什么来提高销售。他有一个引以为荣的超过5000的反馈评价。当eBay站点上发生变化时，让他来适应这个差别和变化是相对困难的。
　　Leon已经建立好一套规则：星期一他将商品上架，周五之前大部分拍卖结束，收到款项的几个小时之内把商品寄出去。
　　希望这些描述有助于你了解Leon，知道他来自于哪里。当我们考虑新功能的时候，我们就应该问我们自己，Leon对于这些新功能的反应可能会是什么样子，为了让他成功使用这些新功能我们应该做什么。
　　将用户范围缩小至关键人群是至关重要的。尝试去取悦每个人是没用的，并且反而会没取悦到任何人，所以重要的是去试着想出一些最重要的、最普遍的特征。同样的，如果你没有试着去准确的描绘你的目标人群，你就只会有一个抽象概念，并且很难理解你的顾客会如何反应。你会倾向于认为你的顾客比真实的他更喜欢你。
　　用户目标
　　一旦我们确认并描绘出了我们主要的用户类型，我们就需要去确认每个用户在使用这个产品时的主要愿望和目标。这听起来可能很简单，但要去理清根本性的问题并解决，其实是很具挑战性的，尤其是当你周围所有人都来告诉你，他们认为的、他们想要的解决方案时。
　　从CEO到推销员，到工程师，到顾客，他们每一个人都十分乐意来＂帮助＂你想出解决方案。他们会告诉你，在这个地方需要加一个按钮或者快捷键，或者增加一个具体的功能，因为你的竞争对手有这个功能，或者换一个颜色因为他们不喜欢这个颜色。
　　如果给予产品经理和设计师时间和自由来思考备选方案，他们常常能够想出更好的解决方法。
　　最好的解决方法源自于对问题的清楚认知。每个用户特征的目标可能不同，所以重要的是根据用户相关的特征来寻找目标。很有可能针对某一个问题所需要的功能，并不是主要用户特征的目标之一。
　　任务
　　手里边有了用户特征和与他们相关的目标之后，我们就可以设计任务来帮助这些人实现他们的目标。这是产品规范过程中的核心，也是创造力与创新尽可能被激励和提高的地方。
　　许多优秀的产品仅仅是用一种新的更好的方法解决了一个现有问题。有时候这来自于新科技的应用，但大部分是来自于洞察力——洞察力导致新方法。
　　举个例子，TiVo采纳了录制TV节目中的老问题并提出了一个完全新的方法，让顾客轻松实现他们的目标，并且建立了一种完全新的电子设备。
　　我们已经谈论了目标和任务，但我们还没有提及功能。这是因为功能支持的应该是映射了客户目标的任务需求。你会经常发现许多功能映射的或者是低优先级目标，或者完全是一个额外的功能。
　　你有充分的理由去掉任何功能，比如你能够以使所需的功能更容易溢出的名义。令人讽刺的是，拥有的功能越少，产品看起来就越强大。这是因为拥有的功能越少，客户实际去探索和使用的功能就越多，成功使用得越多，他们就越觉得你的产品强大。这个理由如此有悖常理，因为我们不是每个东西都像我们的目标客户，和不在我们这个行业的客户相比，我们更愿意花费更多的时间来探索新功能，忍受复杂度。
　　第四步：定义你的产品原则
　　现在你可以在你的需求和用户体验中构思一些具体的想法了。然而，你将面临数不清的决定与权衡，最好你能有一套标准，以便为你的产品作出最好的决定。
　　在大部分团队里，每一个产品团队成员的脑子里都有一些自己对于产品好的标准的想法，但是很少有两个人有同样的想法，这些差异最终会导致令人不愉快的意外。
　　尝试并制定一系列的产品原则来指引整个团队贯穿整个项目是十分有价值的。这个原则应该细致到你的领域和你的具体项目。
　　拿TiVO来举一个例子。当团队启动这个产品后，建立了以下产品原则并且跨团队共享：
　　它是娱乐化的
　　它是TV
　　它是录像机
　　一切都是光滑的妥帖的
　　没有方法或深的层次结构
　　尊重每个电视观众的隐私
　　这是一个强大的设备,就像一个电视
　　这些原则大大影响了产品定义，并且很多情况下加大了实施的困难，但毫无争议，它们是产品成功的根源。
　　相似的是，eBay的原则也是如此：1）容易使用；2）安全；3）有趣
　　你可以看到像这样的产品目标，它是如何给整个团队提供一个恒定的指南，当他们在整个项目进度中不得不面对许多决定的时候。
　　第五步：原型和测试产品概念
　　这才是你真正开始构思产品概念的阶段。这一阶段你要尽可能的有创造力并且创新。
　　产品团队犯的最大最常见的错误之一是对于他们的产品规范过于自信，他们不断推进并会考虑调整产品，如果有必要的话，在得到beta反馈后。但当然beta不是重大改变的时候，因此也就不奇怪很多第一代产品发布后会不达标。
　　然而，对于大部分产品来说，你可以在这个阶段用各式的原型来做大量的产品验证测试。
　　首先，仔细考虑你可能需要的三种测试形式：
　　可行性测试：
　　一个直接的问题是不管你的产品短期内是否会建起来，你的工程师和架构师应该积极参与调查技术和探索可能的方法。一些路可能是死路，但有希望其他方法被证实是可行的。
　　最重要的是，如果研发团队认为在这个产品时间周期内，有不可逾越的障碍，现在清楚这点比之后再发现这点好。
　　可用性测试：
　　为了想出产品中功能的各种呈现方式，你的设计师（产品设计师）将和你紧密结合在一起工作，以便于不同的用户都能够明白如何实际使用产品。
　　可用性测试常常会揭露一些产品需求中忽略的东西，同时如果做得好的话，没必要和原始思路一样确定产品需求。在你想出一个成功的用户体验之前你应该设计多重交互方式。
　　可用性原型的目的是为了有东西可以给真人测试，可用性测试是从你的目标顾客中得到高质量的产品反馈的艺术与科学。尽管产品经理和设计师会利用原型并且从中学到很多，但是仍然无法替代将原型放到真实的目标客户群前。
　　产品概念测试：
　　最后，知道了你产品是可行的，可用的还不够，真正重要的是你的产品是否是用户想要买的东西。比如，他们到底有多喜欢，你正在做的这个东西的价值？这个测试通常与可用性测试结合在一起。
　　对于一些小的产品点来说，将你的想法画在纸上就够了。但是对于大部分带有复杂的交互方式以及新技术的产品来说，为了评估这个产品是否满足了产品目标，各种形式的原型是十分有必要的。
　　原型可能是一个物理设备，或者是一个软体产品的快速组装版。关键在于它需要足够的现实，你能在真实的目标客户身上测试原型，并且他们能够给你高质量的反馈。
　　在过去，设计原型有两大主要障碍。好的原型设计工具的缺乏，意味着需要很长一段时间来构建原型。另一个问题是，在无意识的管理中，并没有理解原型的构建与实际产品之间的差异，团队带着实践过程中可预见的坏结果，被迫使用原型作为最后产品的基础。
　　今天，许多杰出的原型设计工具使得工程师和设计师能够迅速构建功能原型，有效模仿未来产品，如果有必要，可以形成实际用户测试基础。
　　此外，今天大部分的管理者已经理解了构建一个模型和构建实际的产品还是有很大区别的——正如建造一座房子的模型和打造真正的家。
　　在你推进并且实际构建产品之前，很难去强调，证实你的产品概念的价值。一旦真正的研发开始，是很难作出重大的改变的，而且改变的代价也会增加得不可思议。
　　第六步：确认并且质疑你的设想
　　一旦你认为你理解了你想要解决的问题，你就可以确认并且质疑你的设想。作出假设很容易，甚至都没有意识到它们，确保你在PRD中没有一叶障目。
　　天文学最开始被定义为太阳和行星如何围绕着地球旋转的研究，这个定义中的假设就使得一些人得不到正确的答案。
　　第七步：写下来
　　你需要把这些过程全部写下来。大部分的PRD是WORD文档，但是有一些是WIIKI站点，一些是PPT，一些写在白板上。媒介和样式远远没有内容重要。不过，PRD能易于被整个团队读到是至关重要的，它不能丢失，并且PRD需要以一种不断被更新的形式贯穿项目始终。
　　记住，一个对话是在两个人之间，而PRD则需与整个团队交流。
　　同样需要牢记于心，并且与PRD同样重要的是，真正关键的是将产品运输出去。没有什么比那更重要。所以不要担心你PRD的漂亮程度或者厚度。所以只要它是可阅读的，能够理解的，内容才是关键。
　　PRD由四部分组成：
　　产品目标
　　你的工作是描绘目标。团队需要知道他们瞄准的是什么，目标需要被描述得尽可能清楚，确定你的描述涵盖了：
　　你想要解决的问题，而不是解决方法
　　产品是为了谁？公司，顾客，用户
　　细节很重要，但大的蓝图必须清楚
　　描述故事
　　当头脑风暴环节或者口头说明或讨论会产生更好的书面需求，如果它们没有被写进PRD里，它们就会遗漏。
　　特征
　　产品需求规则的主体当然是需求本身。需求的具体情况完全取决于你的领域，但是不论你在哪个行业，你的产品团队都会受益于一份将需求，而不是解决方案，表达清楚、明确的需求文档。
　　描述交互设计和用例中每一个层级的每个特征。你必须非常清楚每个功能是什么，用户体验应该是什么样，同时给研发团队留出足够多的空间。
　　同样重要的是确认你的哪些需求对应是被哪个特征支持的。这是＂需求的可追溯性＂纪律中的一部分，对于关键重大的产品来说，这通常是一个正式的过程。但每个产品规则都会受益于清楚的识别哪些需求支持哪些产品目标。如果有人决定去砍掉一个需求，可能很困难去理解砍掉的这个功能对于全局的影响。从需求到目标之间的映射有助于清楚的说明这点。
　　发布标准
　　发布标准只是挥挥手而已，但是一个好的PRD会充分考虑到真正的最低需求是什么，对于每个发布标准，其中通常包括：
　　性能
　　可伸缩性
　　可靠性
　　可用性
　　可支持性
　　本地化
　　日程安排
　　最困难的部分之一是描述产品所需要的时间范围。只列一个随意的日期是没用的，应该描述时间的背景和动机，以及描述一个目标窗口。
　　你想要整个团队带着正确的市场产品，和你一样积极的来达到那个目标窗口。
　　第八步：确定优先顺序
　　除了明确需求，给需求中的每一项确定优先顺序以及等级次序也是很重要的。大部分的产品经理，如果他们给所有的需求排序，就会简单的给每一个需求标为＂must-have＂、＂high-want＂或者＂nice to have＂。（或者一些相似的分类系统）
　　分类是重要的，不能掉以轻心。产品经理应该对任何标有＂must-have＂的东西持有非常高的把控。这就意味着即便只是一个＂must-have＂功能没有准备好，这个产品也不应该被运输出去。所以我们应该把注意力放在任何标注了＂must-have＂的功能上，这些功能直接反应了这个产品的核心价值主张。
　　＂high-want＂功能是重要的，在发货之前如果来得及，这些特征你全都想要，但又不乐意为了这些特征将产品延期。
　　＂nice to have＂功能对于产品团队来说是十分有用的，即使它们中的大多数在以后的版本中才被实现，但至少在将来，某个合适的地方，产品会被设计来处理这些功能。
　　需求分类是必须的，但还不够。还需要在每个优先顺序分类中，给每个需求从1到N排定等级次序。对于此有两个原因：
　　首先，上市时间永远是一个问题，时间表经常调整，为了上市你可能经常会被强迫来砍掉一些功能。你特别不想要产品团队先实现那些容易的功能，然后以几个不那么重要的功能准备好了，可客户真正关心的功能却被砍掉了而结终。
　　其次，在设计和实施阶段，随着问题的出现和解决，团队会学到很多，很有可能你也会识别并增加额外的重要功能。这个时候，优先顺序就能帮助你知道，砍掉哪些功能来容纳更加重要的功能。
　　关键是如果产品经理不根据这些功能在一个成功产品中的重要性，来确定优先顺序和等级的话，其余不相关因素就会影响功能点以及功能的顺序。
　　整个PRD的过程应该是一个思维不断被调整和打磨的过程。敏锐的思维等于可持续化的愿景。模糊的思维等于失败的产品。现在决定比在战斗的中心决定要容易得多，它同样能够帮助工程师想出一个发展方案。时间可能会改变优先顺序，这是好的，只需确定在PRD中有记载这些变化。
　　第九步：测试完整性
　　现在你已经有了一个完整PRD的草图，你需要来测试这个PRD的完整性。一个工程师能够完全了解这个产品的目标吗？QA团队能够得到足够的信息来设计测试方案以及写下他们的测试案例吗？
　　一旦利益干系人已经全部看了这个PRD，确认了需要增加的细节或者阐明的部分，并且这些问题已经得到解决，你就可以从这个PRD中建立一个产品了。
　　第十步：管理产品
　　在产品实施的过程中，即便是最好的PRD，也会有无穷无尽的问题需要确认。解决需求中的全部问题，在PRD中指明相关人员。如果PRD中没有写，那就补上去。你的工作就是快速解决所有的问题以及事件，并且将决定记录在PRD中。
　　如果你做好了你的工作并且保持PRD的准确性，任何的项目评审准备起来都十分简单，只需要从PRD中选取合适的部分。
　　PRD是一个不断变化的文档，从项目启动时起你就要在PRD中跟踪所有的功能。
　　最后你可能会发现你需要在PRD中增加一些额外的话题。如果你觉得为了实现你的目标，PRD中这些额外的东西是必要的，那就无论怎样也要加上它们。