By 陶国恩Gary     gary_pm@foxmail.com

—————————————作者的几句话——————————————

笔者是一位大四的在校大学生，半岁的产品经理，从两年前便决定以后要成为一只安静而凶猛的产品狗。本文是自己的PM知识学习手记，想通过这种方式帮助自己沉淀一年多以来所获得的知识和思考，同时也希望能够获得线上众多大神的指正。因此文中的知识和观点不一定值得大家参考（反而很欢迎大家吐槽拍砖><），它只是我个人现阶段知识的一种总结和呈现，或许只是正确的废话，但也也期盼能够为大家带来启发！

由于是个人较长时间学习阅读后的总结，所以文章的部分内容可能摘录或受启发于某些文章、书籍却不自知，对于自己还记得或者保留了链接的内容我会在文中附上，如果大家有发现内容有相关信息源而我未注明的，请一定要在评论中指出，衷心感谢！

如果资料原作者拒绝转载，相关内容也会马上删除

最后，如果大家希望转载本文，请在评论区注明去向，并在转载中注明作者即可。建议大家持续关注本文，因为本文还会不断更新哦~（因为我也在不断成长哈哈）如果评论区中出现精彩的分享和建议，也会加入到手记中方便大家学习~

—————————————废话结束，正文来鸟————————————

由于文章太长超过了简书的字数限制...后半部分将放在《产品经理学习手记②》//www.greatytc.com/p/73fec01244a3

产品经理的核心职责：评估商业机会、定义产品概念、促成产品诞生

每一个PM都应该是“创业”，无论需求来自于Boss还是用户，PM都是产品的第一责任人，因此必须对产品的商业价值和用户价值负责，对应的核心职责就是评估商业机会以及定义产品概念。

评估商业机会

商业机会分为两个层面：盈利层、战略层，对于创业公司或者中小型公司而言，PM首先需要评估的盈利层的商业机会，亦即是产品是否具有较为清晰的、可实现的、闭环的商业模式，是否具有盈利可能并拥有何种规模的盈利前景。深入来说，需要考虑的问题包括：收入的（潜在）来源和（潜在）成本结构；收入来源的增长性、稳定性和可持续性；成本的变化趋势和优化机会等等。一句话来说，PM评估盈利层的商业机会，自然就是判断产品投入到市场后将来是否可以赚到钱。

但对于大公司而言，部分产品的诞生很可能就是出于战略目的而非盈利的，举例说BAT旗下就有很多这样赚不了钱甚至需要烧钱养着的产品，但绝不能说它们就是坏产品，他们往往是企业战略中非常重要的一环（如360的三级火箭模型）。PM在评估战略层的商业机会时，需要考虑更多的竞争因素，因为不少战略性产品正是为了狙击对手或者防止对手独大而诞生，除此之外对企业的整体战略也需要有更深层的了解，思考产品的核心任务会是什么（流量入口？探索新市场？打造生态链？），在接下来定义产品时聚焦该任务。

定义产品概念（待完成）

在传统行业，市场营销的发展阶段是与社会的生产力水平相同步的，从物质极度匮乏年代的生产主导观点阶段逐步演变成生产力极度发达年代的用户中心营销阶段和社会营销阶段。IT行业尽管发展速度远超传统行业，但依然可以看见当中的产品开发-营销思想走过了相同的发展路径。小米的成功及其所谓的互联网思维，我认为很大程度上是对“用户中心营销”和“社会营销”的实践和再表达。

一句话来说，产品成功的首要前提必然是满足用户的特定需求。因此定义产品概念时首先需要探索的就是：

需求的大方向是？

目标用户是谁？

在何种场景下目标用户产生需求？

需求具体是什么？（强度、频率、起/终点）

需求的解决方案是否存在？以何种形式存在（现实 or IT）？

满足需求能否换取或衍生商业回报？

需求很难从一开始便完全理清，更重要的是确定该需求存在且具有商业价值，设定「问题的边界」，往后便是推导解决方案，事实上「问题定义-解决方案」的探索是个螺旋上升的过程，逐渐从模糊到具体，从广泛到精准，事实证明越精准的需求和高效的解决方案，越能刺中用户的痛点，而堆砌需求和功能（不是从一个需求出发进行深挖和拓展）往往都必死无疑。

产品的解决方案需要考虑的是：

解决方案的大方向（头脑风暴）？

现有解决方案及其优缺点？

探索新研究解决方案可能需要了解的知识？

跨领域的近似方案研究

具体的解决方案？

解决方案的实现方式？

解决方案的所需条件和已有资源？

一句话总结，就是具竞争力的解决方案是什么、能不能持续做到？

强需求、好方案基本上可以决定一个产品能够赢得用户的喜爱，但还有一个关键的问题，就是产品自身是否具有生命力，互联网时代产品很难死（尤其是工具类产品），但不死≠有生命力。如果产品以等于或快速竞争对手的速度保持生长，就等于慢性死亡，而要做到这一点最关键的就是商业的可持续性。可持续性可能来自于盈利，也可能来自于持续创造战略价值，具体而言包括以下因素：

产品能创造商业价值的资本是？（流量、数据、购买等）

资本的价值大小？（优质流量、大数据、高终身价值）

解决方案的成本结构和变化趋势？

产品运营及推广的成本？

外部合作可能带来的收入或成本减免？

是否存在非商业因素的潜在风险（政治、社会舆论等）

IDEA HCD TOOLKIT（感谢前腾讯CDC设计师朱晨的翻译）中提到，好的设计汇聚在三盏聚光灯的重叠位置，这三种聚光灯分别是：

用户需求

技术可行性

商业可持续性

当我们在定义产品概念时，同样应该时时追问自己，手中的产品设计是否已经处于那个最狭小的重叠区域，还是游离在外？

促成产品诞生

当产品的概念逐渐清晰明确，PM便要进入下一场更加持久的战斗——将产品概念传递给团队，在持续的开发、测试、迭代中一步步推进产品的实现了。过程的第一步是将产品的概念逐步具象化、并尽可能清晰具体地传递到程序猿、射鸡湿的脑海中。这也是信息架构图、界面线框图、交互原型等产品文档出现的原因。具象和沟通时目的，文档只是工具，因此并非所有产品团队都对文档锱铢必较，往往小型灵活的团队更习惯面对面快速沟通，但普遍来说文档能力还是PM的一项重要基本功，需要多多修炼。

即使有了产品文档，沟通也未必一帆风顺，程序员的工程思维和专业表述、设计师的感性思维和美学追求极易产生各种问题（其实我认为这种问题80%都要怪在PM头上，幸好我最喜欢的就是做程序员和设计师之间的沟通协调工作~），因此PM的沟通技巧也必须练成大师级

再往后说，产品上线前的坎还有各种测试、内部宣讲、上线准备等等，PM都必须一步一脚印地陪着产品走过。这里突然想到一个比喻，就是PM其实是产品的妈妈（孩子他爸自然是Boss），而开发、设计、测试、推广、运营等团队成员就是孩子成长路上的老师，最终将孩子送入社会接受考验。孩子有没有成就、受不受欢迎当然有老师的责任，但陪伴孩子一辈子、对他负全责的应该就只有PM了吧。

什么是好产品（待完成）

好的产品最重要的评判标准，是具有「核心能力」，也就是解决用户某一方面需求的能力，这个能力不止来自于功能，还来自于性能，后者是PM常常忽略的点。创造核心能力的关键是「技术突破点」。

但技术拓展的方向有很多，首先就是要定目标，这个目标首先是外部进行同类评测时关注的硬指标，这一点能领先市场，产品就已经利于不败之地。其后要关注小众、极端的能力，他们是极端用户一直渴望却在大多数情况下得不到满足的东西，一旦做好就很有机会赢得口碑，而且谁知道今天的极端需求会不会在未来成为大众需求呢？

做产品不要想着耍小聪明去硬留客户、或者将用户硬圈在自己的产品内，高端用户可以看得出背后的小算盘，心中会产生极不好的印象，所以满足高端用户一定是要靠真诚，靠平常心和平等心态，任何傲慢和狡猾都会带来负面口碑的。

从结果上评判一个功能好不好用，不光光是看用量、流量多少，还要看用过的用户是否感到恰如其分，是否会感到心满意足。

好的产品除了要生长，还要修剪。发现产品的不足，最简单的方法就是产品天天用。天天去看，去论坛，去博客、去订阅、去搜相关的评论。产品经理要敏感点，找出你的产品不足之处。有的产品经理说找不出来很奇怪，上线的时候坚持三个月天天用，问题是有限的，一天发现一个，解决掉，这样慢慢的已经开始逼近你那个很有口碑的点了。这个工作一定要PM自己亲自去做，不能假手于人。主

产品经理的成长

素养

产品感（热情、产品思维、逻辑思维、小白模式）

产品感是一个产品经理最根本、最核心的能力，产品感的好坏很大程度上决定PM的能力，我认为产品感具体包括了这几要素：

热情

对产品和做产品这件事的热爱，决定了一个PM对产品的投入程度（无论是工作还是生活）。一个对产品富有热情的PM，平常对不同领域的产品都会有充分的关注和思考，这种关注和思考的积极性将极大地影响他作为PM的成长速度和产品思维的深度。

产品思维

产品思维的基础理念是：事事皆产品，无论是一个杯子还是一张传单、一次理发还是一次募捐，事事皆可用产品思维来衡量，来推理设计。产品思维的落脚点（分析对象），是用户、场景、需求、价值，需求来自于特定用户+特定场景的结合，而价值则是解决方案满足需求后的结果，这四个思考维度又有各自的标准：

用户：数量及增长趋势、商业价值

场景：是否常见、前置条件、重要程度

需求：频率、强度、缓急、当前的满足程度

价值：三种维度（可复合）——有乐（愉悦的体验，如有趣、好味，常见于社交、娱乐类产品）、有用（实现具体的功能，常见于工具类产品）、有益（对用户带来正面效用，常见于健康、教育类产品）

当然，产品思维除了用于分析，更重要的是在创造、执行的过程中同样发挥着重要的作用，我认为当中包括：

user-centered：用户及其需求是一切产品的中心（市场推广活动往往是business-centered，如今越发不受待见）

solution-oriented：设计应该是一个「问题-解决方案」螺旋式上升的过程，定义问题和限制是构思解决方案的必要条件，但绝不等于要等问题彻底定义清楚在开始讨论解决方案，必须要意识到设计就是要不停面对新问题>分析问题>设计方案，不停循环，所以要敢于尝试，坚持不懈。

MVP精神+快速迭代：互联网时代产品开发不再像过去那种「跨栏式前进」，面对复杂多变的用户需求和市场环境，最好的产品开发方式就是MVP验证可信性和需求+快速迭代迅速响应用户，对于无法迭代的产品，一定要尝试灰度测试或者试运行。

逻辑思维

我所理解的逻辑，其实就是关系（静态）+流程（动态）

关系是事物之间组织方式，决定了事物之间的关联（并列、互斥、从属、无关等等）和整体的架构（金字塔原理）；而流程则是事物之间的因果（涉及一些逻辑推理的方法论，这里不详述，个人认为最重要的就是because-so , if-then两种关系）、先后步骤等等。回到PM身上，逻辑思维是所以如此重要是因为PM的日常工作当中处处需要用到逻辑思维：从用户研究结果推理用户深层需求、将后台流程向工程师详细解析、设计产品信息架构等等……缜密锐利的逻辑思维是好PM必不可少的神兵利器之一。

小白模式

所谓小白模式，就是在体验产品时（尤其是自家的产品时）能够瞬间转变角色成为啥都不知道的小白级用户，这样的用户或许不是产品的主流用户，但一定是测试产品各种可用性问题的最佳用户，他们所碰到的无数问题中的任意一个，可能此时此刻也在困扰着许许多多的主流用户，因此要改善用户体验，「进入小白模式」也是必不可少的能力之一，网传马化腾、周鸿祎两位神级PM都具有瞬间进入小白模式的神技。

领导力（洞察力+沟通力+影响力）

领导力在我的理解当中就是带领团队团结、快速地朝正确的方向前进，当中首要任务便是利用洞察力为团队明晰正确的方向，随后再利用沟通力、影响力保障团队内互助互信、高效运作。

洞察力

这里主要指的是宏观洞察力，这种洞察可能来自对用户需求、行业前景的了解与系统化思考，可能来自于不断分析好的产品、好的商业模式来逐渐提高的“品味”，还可能来自于跨行业资讯、时政动态、生活场景所激发的灵感，四个字总结——多看多想。

沟通力

实现有效沟通、建立良好关系的前提，是认识到人际沟通中「情绪>理性」，再可靠的例证、再合理的推论在敌对、不信任的情绪下也难以被接受，相反地，当我们认识到与团队沟通时首先关注对方的情绪时，将更容易取到事半功倍的效果。

其次PM在工作中主要的沟通对象是开发团队和运营推广团队，我认为最重要的一步是让他们「知其然，更知其所以然」。PM是无实权的CEO，对其他团队成员拥有发号施令的天然职权，团队成员并不仅仅是只是PM或者BOSS想法的执行者，程序猿和射鸡湿最怕的是原因不明、要求不清的需求（尤其是突然要加的需求），因为执行起来迷茫，完成后更容易返工。所以最好的沟通方式，或许就是将需求详细解释、并和沟通对象再简单推演一遍，有时候他们还能提出比原来更好的解决方案，毕竟他们才是执行的行家。

最后是就长期而言，建立友好的个人的关系可能是提升沟通力的重要一步，不同岗位的成员身上可能会呈现不同的气质，与他们沟通时要尝试接纳并融入这种气质，理解他们的思维方式和角度，多关注他们所喜欢的产品和人，对提高沟通质量和个人素养都会非常有用。

影响力

关于影响力的「术」，神书《影响力》上已经有很详实的介绍，一共有九大原理：

对比原理：对比会使两件事物在我们认知中的差距>实际差距

互惠原理：受恩就会想报答——主动机遇非常自然的好处

相互退让：狮子大开口再逐步退让

承偌和一致：人有让自己行动前后一致、遵守承诺的趋势——0~1>1~10

社会认同：人判断是非的标准之一是别人怎么想、怎么做——制造榜样和潮流

喜好：通过与他人喜爱的人、事、物关联就可以赢得他的好感

权威：权威是影响力最典型的来源

短缺：论激励作用，害怕失去某种东西的想法>希望得到同等价值东西的想法

影响力的「法」，我相信其实就是之前提到的「洞察力」和「沟通力」，试想一下当你一次次洞察先机带领团队走向胜利、日常和团队成员相处融洽沟通畅通无阻，又怎能不一呼百应呢。

最后是影响力的「道」，我非常赞成知乎上的这个精彩回答by 毛斌超：

第一，初级——比人强。 能人所不能。成为领域专家。能解决别人解决不了的问题。这是兄长。——让人从事上服你。

第二，中级——做榜样。为人所不为。正人先正己，以身作则。我能做到，你有什么做不到。这是老师。——让人从理上服你。

第三，高级——帮人忙。成人所不成。帮别人做出成绩，让别人成功。这是伯乐。——让人从心上服你。

知识积累&学习能力

知识的积累吸收无疑是又一项「一生的修炼」，我相信一个菜鸟级PM如果不对设计、编程、运营、市场这些领域有基础的知识积累，不是干不好而是根本干不下去。而对于熟练级PM，他所要积累的知识可能更多地来自于行业、来自于市场、来自于团队管理。大神级的PM在我的理解中已经不再需要投放精力在具体的执行技能和管理任务上，而是上升到积累对人性、对社会的洞察当中，个体行为和社会行为的最终交汇点是人性和文化，捕捉不了这两点，就不可能打造出和微信、小米一样伟大的互联网产品。

在这个信息严重过载的年代，找到信息源真的是不要太容易，关键是看的越多往往沉淀的越少，此时此刻正在重新沉淀的我深有体会，下笔写的时候此前看过的无数文章全部都忘了（还好我有保存链接！），证明它们其实都没有「入脑」。个人喜欢的积累方式有两种，一种是以保存原文链接的方式建立分类知识库，随时可以复习查看；另外一种是使用经典的学习方法「费曼技巧」，简单来说就用「教」的方式来 「学」，「教」得不清楚证明还没理解透，回头重新复习然后再尝试「教」，当然这里的「教」更多是一种模拟，不一定还真的找某个人来当学生听你讲。

文档能力

文档是PM与老板、团队成员乃至外部利益相关方沟通的工具，它仅仅是工具而非目的。靠谱的好文档能够帮助整个开发团队都理清思路，清楚执行的方向和要求，问题在于有很多的文档花费了大量的时间去撰写，但很快就要更新修改、或者缺少关键信息和解决方案，吃力不讨好，对于小团队而言或许频繁的面对面交流或许更有效率，对于较大的团队而言高保真原型或许会更加直观可读。当然正是因为好文档太少，所以撰写文档更应该是每一个PM都修好的基本功。

细节追求

对细节的无限挑剔是大(bian)神(tai)级PM的必备技能，乔布斯对细节有多挑剔大家都听说过，感动人的用户体验正是由一个个体贴的细节所构成的。挑剔的能力我认为主要来自于两个方面，一是眼光要够高，看懂（不是看过）好东西的次数多了，「鉴赏力」便能够迅速提高，足以区分好的设计和坏的设计；二是感受（五觉到情感）的颗粒度要尽量小，尤其是要流程、动作步骤尽量细分、放缓，这样能更容易察觉细节。

需要警惕的是PM不能在早期沉溺在细节当中，毕竟设计细节可以交给专业的UX人员去细扣，毕竟产品价值>用户体验，更重要的是确保产品能够满足用户需求创造价值，而且细节做不好后期还能修正，产品方向错了后果不堪设想。

耐力+毅力

产品经理可能是团队当中受气最多的一位（产品狗不是白叫的嘛），这里的耐力既指承受压力的耐力，也指产品因各种原因未能成功时坚守的耐性，还有面对无限开发循环始终坚持不懈的毅力。很多人都说产品经理是个浮躁的圈子，相信也是受整个互联网行业的风气所影响，但产品经理的修行和产品的成长其实都是一个漫长的路途，天子卓绝如乔老大也不是搞砸过。潜龙在渊，总有翱翔之日。

技术能力

不懂技术的PM，对自己和对产品来说都非常危险。

（个人）执行力

或许是产品经理最重要的两项能力之一（另外一项是产品感），因此放到了压轴的位置。我所理解的执行力是：在任何情况下，最快速度、最大程度地实现目标的能力。计划很丰满，现实很骨感，原定的目标和计划在具体落实的过程中必然会碰到各种各样的阻碍。常言道听天命，尽人事，执行力就是尽人事的能力。

执行力是很多种素质的综合体现，但我相信最重要的是三点：

永远乐观：没有困难解决不了，只是解决方式和时间精力的问题

寻找最优可行方案：1.溯源推理找出原方案的的核心需求是什么？2.明白一个只有60分的可行替代方案比一个100分但无法实现的方案更有意义

明确最核心的任务：80/20原则，投入80%的时间经理去完成最重要的20%的事情，其余的能干就干、能推就推

其实后面两点有一个共同的内核——取舍

成长方式（待完成）

产品开发流程与文档

开发流程（待完成）

产品文档（文档类别主要参考 产品经理@唐杰的杰出产品经理电子书）

文档关系之间的生动比喻By唐杰（不太喜欢这篇文章的行文，但的确有干货）：「以装修房子作比喻，信息结构就是材料内容，产品结构就是设计样式，原型就是效果图，PRD就是施工明细。」

信息架构图

信息架构图是产品需求文档的第一步，其作用是列出产品功能的信息内容组织逻辑，将有助于我们设计接下来的功能细节和后台开发者设计数据库。

画信息架构图一般用思维导图工具即可，关键是逻辑清晰易懂，但画的时候一定要注意「相互独立、完全穷尽」的原则。另外对于WEB产品而言，除了有根据产品功能进行划分的画法外，还可以按照用户角色（如浏览者、管理员）来进行划分。

其实画图只是一种呈现形式，关键还是信息架构的设计，这个在下文的交互设计部分会有更详细的介绍。

功能架构图

功能结构图是一种将产品原型以结构化的方式展现的图表，目的就是梳理产品结构逻辑，让我们清楚的知道产品有几个频道，频道下面有没有子频道或者有多少个页面，这些页面里又有哪些功能模块，这些功能模块里又有哪些元素。

关于信息架构图和功能架构图的关系是我个人经常搞混的地方，此处引用知乎中觅路客对《PRD 中的「信息结构」与「功能结构」有哪些区别？》的回答，也欢迎大家指教！

————————————引用——————————————

在PRD中，信息结构是供开发建数据库的参考依据。

这里可以引用UML里面的类的概念，一个类包含属性和方法，而信息就是类的属性，举个例子，博客系统有最主要的文章类，评论类，文章类包含的信息有：标题、作者、发布时间、摘要、正文、访问量等，评论类包含的信息有评论者头像、昵称、回复内容、邮箱、QQ等，部分信息结构图如下：

用个用例图表示功能，可能更容易理解，如下图：

中间的是功能，两边的是角色，功能和角色加起来就是用例，功能是个逻辑结构，按模块分，比如以上会员中心是博客系统的一个模块，其功能结构就是：

功能结构可以根据需要来确定详细程度，例如会员中心是一个大的功能模块，也可以叫做一个功能。内容管理又可以细分，比如细分成编辑、删除、添加功能。
———————————引用结束—————————————

个人总结：信息是内容，功能是行动

原型设计图

原型设计图就是将此前已经规划好的信息内容和产品功能从抽象的概念转化为具体的图画，并考虑上述这些内容的布局排版、交互关系，是产品开发过程当中一个非常重要的沟通工具和展现工具，在早期阶段甚至可以直接将原型图给到用户面前来进行价值测试或可行性测试。

原型图的类型从简单到复杂依次为手绘原型（又称为纸上原型）、灰模原型和交互原型，具体示例如下：

手绘原型：着重体现产品布局轮廓，是很多设计流程当中都推崇的原型设计方法，胜在简单、易变更、方便发挥创意；

灰模原型：进一步细化展示界面设计，但视觉元素粗糙而且缺乏交互效果；

交互原型（又被成为高保真原型）：通过Axure RP之类的交互原型软件制作出来的产品原型，在功能需求和交互需求的表现上，几乎和正式产品是一致的，所以有时交互原型也被称为产品Demo版。

常用的原型设计软件：Axure RP（高保真）、Balsamiq Mockups（低保真）、UIDesigner（鹅厂CDC出品的原型工具）等等，另外如今国内外也有不少靠谱的线上原型平台，简单易用而且支持协作，大家可以搜搜~

原型文档之视觉化叙述（归纳自用户体验草图设计：工具手册第4章）

1.故事板就是用视觉化材料说明一段时间内的交互顺序

1.1故事板无需描绘用户的每一个动作，只需要选择当中的「关键画面」

1.2每一帧「关键画面」都代表一个状态，而连续帧之间的空白则包含了用户行为及其带来的每一个细小的变化，不是每一个都值得展示，但设计师一定要考虑周到。

1.3为每一帧添加注释帮助不熟悉的人也能理解，注释就是说明两帧之间的动作

1.4顺序故事板：界面1+动作A=界面2，界面2+动作B=界面3……

1.5故事板的关键难点在于决定哪些草图作为关键帧

2.状态转变图是一种视觉化描述一段时间内状态、转变及决策路径的方法

2.1抽象状态转变图：着重于展现用户活动流程，内容包括状态（哪个界面，文字说明即可）

2.2视觉界面状态转变图：界面以视觉化方式呈现，提供了更多的界面细节

2.3带注释的状态转变图：包含解释性文字的图

2.4带索引的状态转变图：抽象状态转变图+备选的界面，是最复杂的故事板，一组状态转变图可能会被替代为“代号”而不用完整地出现在主线中

3.分支故事板是说视觉化材料说明一段时间内的交互决策

3.1分支故事板内包含多个用户任务的交互流程

3.2用索引来管理多个交互流程：一个“元界面”+序号，序号内再是各个用户任务的交互流程，保证单个任务内的流程清晰易读又保留了和其他任务的关系。

4.叙述性故事板是讲述一段时间内关于使用情景的故事（一部关于产品场景的“电影”）

4.1常见的取景方式

4.11超远景（全景）：显示环境、地点等细节

4.12远景：显示出完整的一个人

4.13中景：显示出一个人的头和肩

4.14过肩镜头：从一个人肩后看过去（略大于用户视角）

4.15主观镜头（POV）：用户视角

4.16近景：显示人拿着的设备的界面细节

4.2画出故事板草图

4.21画出故事板的框架（5个或以上的方框，5个最好）

4.22设计故事线，需要考虑以下问题

4.221这个行为发生在什么场景下？

4.222用户遇到了什么问题？

4.223人们尝试做的任务是什么？

4.224场景中出现了哪些人，他们的动作是什么？

4.225他们使用的是什么物品或电子设备？

4.226对每个电子系统来说，可能的输入和输出是什么？

4.227人们和/或设备如何解决了问题？

4.23故事板设计：第一帧开始，二三帧发展，第四帧高潮，第五帧结束，需要先用文字在方框下写清故事发生了什么

4.24画出定场镜头：用超远景表现场景细节，但没必要太精细，如果有多个不同的场景，也可以画出第一帧

4.25选择合适的镜头来继续故事版的绘制：利用上述的取景方式来完成其他画面，一般是远-近-远的发展顺序

4.26突出动作和行动：利用箭头、符号等装饰物来凸显角色在故事中的感受、动作或行动，是重要的视觉注释

4.3向他人展示并获取反馈，不断迭代，让别人更好理解你的故事

注：也可以用真实的照片来讲述故事，总体形式类似，但是可以用办公工具、画画来进行加工说明，毕竟现实世界未必能完全展示你的故事内容

用例文档

Use Case用例是一种开发团队中可视化传递需求信息的载体，简单来说就是以「用户+场景」的方式来呈现具体的需求，将系统的功能展现为用户在使用产品达成目的的过程。

用例文档最核心的组成部分是用例描述文档和用户流程图，而用例图是否必须尚存疑问

用例描述文档

用例名称：简要说明用例内容和代号

用例描述：简要的描述一下本用例的需求(作用和目的)

参与者：与本用例相关的角色（使用或管理）

前置条件：参与或操作(执行)本用例的前提条件，或者所处的状态

后置条件：执行完毕后的结果或者状态

正常操作流程：描述各步骤都顺利完成时的流程

可选工作流程：描述出错、异常状态下的流程

修改历史记录（可选）：注明修改时间、原因、修改人

状态（可选）：等待审查、审查中、通过审查、未通过审查

用户流程图

个人认为画流程图的关键在于是否足够细心、做到穷举情况和步骤（极端的情况很容易被遗漏），同时保证逻辑上的闭环，暂时没找到特别好用的方法，只能是将所有支线主线都推理一遍一步步来了。

画流程图的工具：Visio、PPT、思维导图软件、最近也开始流行在线的画图工具了

产品需求的起点——用户调研

如果产品经理也有七宗罪，那么第一宗罪一定是傲慢（或者说是自负），无数心怀“人人都是产品经理”理念的PM、创业者或普通用户都会再未曾深入接触受众（甚至未定义目标受众）、了解用户想法和行为时便自以为“洞察了用户需求”，我也不例外，这是对他人的傲慢、对自身的自负。用户调研是消灭这第一宗罪的唯一方法，也是定义产品需求的真正起点。

用户调研的价值与局限

用户调研的价值在于挖掘挖掘用户的深层需求以及探索满足需求的可能方案，而最大的局限是——用户调研本身是很难直接实现这两个任务的。用户调研是产品团队与用户之间沟通的借口，通过用户调研，我们通常可以捕捉到用户的行为习惯（行动路径、使用背景）、主观且外显的观点（表层需求、对产品的认知及印象、槽点），但在通往用研两大价值的路上，我们还会碰到三只凶猛的拦路虎：1）调研方法和操作失误带来的结果误差；2）受调研者的表达表里不一、实际行动与主观想法不一带来的误差；3）调研结果呈现的用户对现状和当前解决方案的行为动作和态度（更快的马）。

质量监控（待完成）

用户调研的方法

问卷调查

最常见的用研方式之一，成本度速度快，长于定量而弱于定性，因此特别适用于调研：

1）使用目的；

2）用户的使用行为习惯；

3）用户的态度和观点；

4）用户群的人口学信息；

但如果调研的目的是挖掘用户潜在的、模糊的需求时，问卷调查几乎无法直接解答

调查步骤

①确定样本

②确定问卷结构及维度

完整问卷结构

标题

说明（字越少越好，只要必要信息）

过滤性问题（排除非目标用户）（可选）

问卷正文

被访者人口学信息

感谢词

访问记录，问卷编号（可选）

③设计问句

明确每个问题可以产生的实际指导价值

每次只提一个问题，问句简单明确

避免过于专业化的问题和用语（降低用户理解成本和误差）

避免笼统、抽象，尽量量化

尽可能避免令被访者难看、禁忌、敏感的问题

避免主观引导（提前假定好坏）

④设置选项

定性选项

定类：男/女，知道/知道但不想用/用过

定序：满意/一般/不满意

定量选项

定距：偏好度评分

定比：愿意支付的价格

选项设置注意事项

原则：穷举、排他、准确、简练

多选题最好提供「其他」选项

可以考虑设置选项顺序随机

选项的变化方向：负向正/正向负、预设方向

量表中是否允许有中立态度（偶数or奇数选项）

多选的选项上限

⑤分析方式

定性分析

百分比

众数

频数分析

交叉分析

定量分析

平均数

方差

相关（均值检验、回归、聚类）

⑥试访问

访问方法

每道题选完，请受访者说明选择原因，确认对题目和选项没有误解

需到停顿或迟疑，要注意是否措辞太专业、不准确，或者没有提供合适的选项

大概记录填写问卷的时间，判断是否过长

最后询问对整个问卷的看法，是否能够判断问卷的大致意思

执行细节

观察回收情况是否有异常，例如用户对问卷不感兴趣（投放用户不准确）、用户太积极（受奖品吸引）

通过对小范围试问的结果分析，可以预先确定正式问卷的分析方法乃至代码

⑦其他细节

移动端问卷尽量少设置开放性问题

尽量少用书面语

用户访谈

核心：了解他人的“鲜活”的经历

访谈内容

背景

事件（体验产品）

感受（评价或反思意义）

什么是一个合格的访谈

信度：多次表述一致——信度来源于信任，展现「真我」（为减轻受访者压力，可选择到比较熟悉的公共场所）

效度：问到痛点——关注用户背后的故事

访谈技巧——追问

切忌：无意义的关联假设、限制性逼问、对方尴尬的问题、主观评价（何不食肉糜）

追问什么？：不懂的概念、具体的时间、特别的词语

追问时机：

（1）开始时尽量不要追问，以免造成压迫感

（2）具体细节可以及时追问

（3）关键概念可以先记下来再问

访谈技巧——其他技巧

少说多听，别怕（短时间）沉默：是犹豫？是思考？

关注受访者情绪

跟随，跟随（但不能跑题）

关系：避免教导或矫正型关系（访谈者主观地进行限制）

观察法

观察的维度

环境

在哪里

有什么

和什么元素相关联？为什么

行为

动作（步骤）：手脚的举动，为什么？

眼睛移动：注意力在哪里

身体姿势：表达什么

情绪

面部表情

语言用字

想法

表达出来的

隐藏的

稳态互动

人际圈如何互动

新的互动对象的来源

关系的维系、发展、变化

人际互动中心点（主要围绕什么开展互动）

关键方式

蛛丝马迹

观察对象感到"新奇"的事物

观察者感到"新奇"的事物

观察出什么

放开自己，进入用户的世界

他们真实世界的信息

他们核心任务和任务流程

理解用户的生活理念

他们考虑的问题和关注点

他们的价值观和动机

设计机遇

目前完成任务（问题）的方式（手段、工具）和其误差/缺陷

什么是超出他们预期的事情？

他们抱怨背后的期待

二手资料

行业报告：艾瑞&CNNIC+搜索引擎

个人报告、评测，相似竞品分析

观察者分析师报告：比较分析

社会人口学统计年鉴（国家新增人口，互联网新增人口，缺口在那里？）

学术研究文献

角色模型

角色模型Persona是目前很多产品开发团队都会使用的用研方法，也是互联网用户调研不同于传统市场调研的方法之一，简而言之就是根据当前调研得到的资料，虚构出一些典型的用户角色，所谓典型，可能是产品的目标用户、潜在用户，也可能是完全不用产品的用户（用于建立产品边界）。建立用户模型的目的在于利用这些「活生生」的角色来帮助团队挖掘需求、理解用户需求和主要任务流程、激发创新灵感和帮助团队成员之间达成共识。

Persona这种方法诞生的原因在于，区分用户的方式不再是传统市场区分中的人口学信息，而是用户使用产品时的行为模式，一位开宝马的富翁和一个刚学会用电脑的小学生可能同样是QQ的新手用户，连开启音视频聊天都不会，他们都应该被归入一种角色，来指导后续面向新手用户的产品设计。

关于建立用户角色，推荐网易UEDC的博客《Persona——Web人物角色介绍》，有时间的话可以阅读经典书籍《赢在用户》

这里简单提炼一下要点：

人物角色不是用户细分(按人口学信息细分)、不是平均用户（需要的是典型用户类型，不是定量分析得出比例和趋向）、不是真实角色（不是特定的、真实存在用户，而是一个糅合相关行为特征的虚拟人物）

建立方式包括：定性人物角色、经定量验证的定性人物角色、定量人物角色，核心区别在于多大程度地利用定量分析去区分用户共性、差异性和相关性，确保模型的正确（例如到底有几类典型用户、该用户的特性组合适合正确）

根据用户特性搭建角色雏形后，还有尽可能地丰富用户的各种背景信息，使其更加活灵活现，更像是一个真实存在的用户，这有利于后续的角色代入工作。

用户角色是一种交流可视化的交流工具，必须持续使用、不断更新，才能真正发挥这种方法的价值。

产品（原型）测试——可用性测试、价值测试

不同于上述的用研方式着重用于产品开发前的阶段，可用性测试和价值测试一般出现在产品开发启动了之后，简单来说将已经做好的原型或者测试版本给到真实用户的手中，了解这个产品对他们是否有用、是否好用，当中价值测试主要验证用户是否真的对该产品感兴趣，而可用性测试则关注当前版本的用户体验情况。

无论是价值测试还是可用性测试，都是越早进行越好，因为问题越早被用户发现，团队就能尽快修正，这点与快速迭代、MVP精神是想通的。

测试者

产品（原型）测试的第一个要点是必须由真实的目标用户来进行，质量>数量，可以根据已经建立的角色模型来物色测试者，按《点石成金》中的观点，每版本测试人数在3~6个左右就可以，然后优先处理测试者反馈中多次出现的问题，极个别的用户问题可以暂时留到下个版本看看测试的结果再决定是否处理。

测试准备

理想的测试环境最好有单项透明镜、闭路电视、摄像机、录屏软件甚至眼动仪，但其实简单起来只要有一台电脑有张白纸也就差不多了，有时候搞得太大阵仗反而会让测试者感到紧张和不安。

其次参与测试的人员一般也不宜太多，一个主持人一个记录者就差不多了，但观察的人则多多益善，任何感兴趣的团队成员（开发、设计、运营、市场等）都欢迎他们来观察测试的过程，因为他们可能会结合自己的专长进行分析，同时了解用户反映也有助于他们后续的工作。

毫无疑问需要测试的内容和问题应该事先准备好，如果是测试单一功能模块，那么无需将原型全部完成再展示给测试者，只要在测试者可能对其他功能感兴趣时询问他们:「你想得到什么？」、「你预计会见到什么？」并记录下来即可。

最后是要帮用户做好心理准备，向他们强调测试的是产品而非他们个人，因此请放心说出真实的想法和问题。

开始测试

测试开始前，了解测试者当前是用哪种解决方案来满足该需求的（如果他压根没这需求有可能你找错人了），是怎么用的，这些问题如果等到测试后再问，测试者的回答可能会受到影响，因此最好是在测试前先问好。

测试的第一步，是问用户在看到第一个页面后有何感想，联想到什么内容，对哪一步分感兴趣，常言道「一见钟情」，产品带给用户的第一印象非常关键，如果开始具体的测试任务后再问用户，用户很可能会遗忘或者感到混乱。

测试过程中，最好让测试者采用「有声思考」的方式来传递自己的感受和想法；同时测试专员应避免提供一切的提示，也不要提关于设计细节的问题，因为测试的重点是产品是否有价值、是否轻松使用，用户有关界面、交互的抱怨仅作为一种参考意见即可，不是测试的重点。另外还有一个需要考虑的点是，是否允许用户主动结束测试，当用户对产品感到无趣、无意义时他们探索的意愿会大大降低，同时这也是对产品价值的一种反映，因此测试团队应该考虑是否允许用户主动终结测试。

在测试结束后，应该设置问题帮助测试者重新回顾整个测试，找出当中他们印象特别深刻的点，了解他们对这款产品的评价等等。当然还要对他们表达感谢并提供适当的礼物了~

可用性测试的10条准则：

一、状态可见原则

用户在网页上的任何操作，不论是单击、滚动还是按下键盘，页面应即时给出反馈。“即时”是指，页面响应时间小于用户能忍受的等待时间。

二、环境贴切原则

网页的一切表现和表述，应该尽可能贴近用户所在的环境（年龄、学历、文化、时代背景），而不要使用第二世界的语言。《iPhone人机交互指南》里提到的隐喻与拟物化是很好的实践。此外，还应该使用易懂和约定俗成的表达。

三、撤销重做原则

为了避免用户的误用和误击，网页应提供撤销和重做功能。

四、一致性原则

同一用语、功能、操作保持一致。

五、防错原则

通过网页的设计、重组或特别安排，防止用户出错。

六、易取原则

好记性不如烂笔头。尽可能减少用户回忆负担，把需要记忆的内容摆上台面。

七、灵活高效原则

中级用户的数量远高于初级和高级用户数。为大多数用户设计，不要低估，也不可轻视，保持灵活高效。

八、易扫原则

互联网用户浏览网页的动作不是读，不是看，而是扫。易扫，意味着突出重点，弱化和剔除无关信息。

九、容错原则

帮助用户从错误中恢复，将损失降到最低。如果无法自动挽回，则提供详尽的说明文字和指导方向，而非代码，比如404。

十、人性化帮助原则

帮助性提示最好的方式是：1、无需提示；2、一次性提示；3、常驻提示；4；帮助文档。

体验设计

设计的层次：功能、优化、情感

无论是单一产品的设计还是某个功能点、交互方式甚至是服务的设计，无不遵循功能-优化-情感的发展路径不断演变。以大家熟悉的饮料为例子，水是承载“解渴”这一功能最原始最低成本的产品，但水淡而无味，于是逐渐便出现了果汁、可乐等在口感、味道上有所优化的产品，而世界知名的奢侈饮料“依云水”则是承载了高贵、格调的情感诉求。关于设计的进化，我认为有两个点是不能忽视的：

1.在前一阶段上达到平均值以上的表现，是达到下一阶段的必要条件：倘若可乐越喝越口渴、依云水口味奇怪，那么无论优化再好、情感再强烈都不可能赢得用户的喜爱。

2.高阶设计的出现不代表低阶设计的末日：高阶设计往往意味着更高的开发成本、维持成本，最终导致的是用户的分层而非全部迁移，消灭低阶设计的会是替代品而非同类优品。

用户体验要素（待完成）

用户体验是什么？

信息传递+用户操作

信息传递=格式塔+信息量选择（less is more）+视觉

格式塔：将信息分类，再按格式塔组织

信息量选择：单一任务、逐次沉陷

视觉：字体选择、留白、配色

用户操作=操作路径+单个操作难度+易错率

简化操作路径

减少多余动作：没必要的按钮（从心理路径推演）、系统完成（我的位置）

——————————————未完待续么么哒——————————————

由于文章太长超过了简书的字数限制...后半部分将放在《产品经理学习手记②》//www.greatytc.com/p/73fec01244a3