用户需求研究 1¶
什么是用户？¶
用户不是人，而是多个需求的集合。某个产品完全满足了某个人在某个场景下的某类需求，那么就可以说该场景下的这个人就是产品的一个用户
用户的五个属性 11¶
异质性：每一个用户的偏好、认知、拥有的资源是不一样的，
情境性：没有情境就没有用户，同一用户在不同的情境下会有不容的反应和行为
可塑性：用户的偏好和认知会随着外界不同的信息刺激发生变化和演化
自利性：追求个人总效用最大化
有限理性：虽然追求理性，但是能力有限、判断经常出错，所以只能做到有限的程度
UCD VS BCD 4¶
UCD(User Centered Design): 以用户为中心的产品设计
BCD(Boss Centered Design): 以老板为中心的产品设计
谁最了解用户，谁最有发言权！
为什么了解用户¶
涉及到方向性问题的时候，在混沌的信息中，在开放的无边界的信息中，找到适合的方向，这本身不是A/B测试能搞定的事情
基于对用户的深刻洞察，才能谈价值发现，产品规划，产品设计，上线运营等。
同理心地图¶
同理心地图给设计团队提供了一个思考框架,是帮助团队整理对用户的认识的一项工具。它帮助团队整合所观察和调研到的人和事物,并协助挖提出对用户深层次的理解目标、需求、观点、痛处、态度、行为）同时,同理心地图也是一个团队协同设计的工具,确保每位团队成员对使用者的理解都是相同的。
empathy_map¶
用户故事 6¶
用户故事的用途是以用户的视角描述其通过使用软件产品想要实现的任务和获得的价值。故事不同于传统需求规格说明书,以简化的形式促进团队交流,降低修改成本、灵活调整接受变化,同时故事以验收驱动的定义形式让所有干系人入对最终的目标建立共识。
以用户的语言来描述用户故事，以识别真正的用户故事而不是解决方案
即：用户故事——谁，在什么情况下，碰到了什么问题，有什么感受和情绪，现在又是怎么做的，现在的做法中又有哪些痛点，等等。 9
用户故事可分为三个层次：
“主题”用户故事
“大”用户故事
“可开发”的用户故事
用户故事的INVEST原则¶
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。
用户生态¶
在任何一个产品领域，用户都是多种多样的。所以，第二步我们要梳理用户生态。你需要了解，在产品所涉及的领域中，有哪几种用户，他们之间的关系是什么。
还要注意三点：
颗粒度：某种用户可以继续细分，但分到什么程度，还没有定论，需要根据实际情况进行分析。比如家长要不要细分为爸爸和妈妈。
考虑边界：不同的用户和产品发生的关系有强有弱，最广义的用户，是指所有和产品有关系的人。那么，用户是否都要纳入我们日常的用户生态图，就是你需要考虑的“边界”。
优先级：已经被画在用户生态图中的用户，也是有重要、有次要，我们肯定是先照顾最重要的。
用户画像¶
用户画像，我们要用一些关键特征来描述一个重要的用户群体。它可以帮助整个产品创新团队时刻牢记我们的产品是为谁服务的。
用户画像包含：
基本信息，给这类用户的代表起个看起来真实的名字，选一个照片，设定性别、年龄、职业、日常的兴趣爱好。
描述用户的特定信息，也就是与产品领域相关的信息，比如生活方式、价值取向、心理预期等。
选几句在收集用户故事的时候，听到的用户说的有代表性的话，增强真实感。
用户旅程¶
如果说用户画像是静态的，那我们最后做的用户旅程，就是让用户“动起来”。
选一个重要的用户，思考他在解决相应问题的时候，都会碰到什么状况，做什么事，有什么感受和情绪。这时候，“有没有产品”依然不是重点，重点还是关注用户的言行举止。
用户旅程分为三段：
做某事前的准备；
做某事的过程；
做完某事之后。
用户旅程地图¶
用户旅程地图(User Journey Map是和用户画像 persona)相辅相成的工具,用户画像代表的是具体的族群,而体验地图是分析这个族群为了实现某个目标而经历的过程的可视化呈现工具。它用于了解和解决客户需求和痛点,在这个过程中用户可能会使用多个设备和渠道(例如网站,手机app,社交媒体,电话,线下客等)
阶段:用户实现某个目标所经历的具体步骤
行动:每一个步骤下用户所产生的具体行为习惯
想法:用户在这个过程中的想法和体会
情感曲线:用户在这个过程中不同阶段的情感波动
机会点:我们洞察到的能够改进的机会
改进点:将每个改进点对应的相应的责任人身上
故事板 7¶
故事板可以帮助用户预测并探索产品的用户体验，透过故事板的情境模拟以利设计师在设计过程中能去推测出使用者在使用过程中可能会遇上的问题，且帮助了解用户目前与问题相关的动机和经验，便于设计师能更进一步确立设计目标
同期群分析（Cohort Analysis）¶
主要目的是分析相似群体随时间的变化(比如用户的回访)随看开发迭代的演进,产品上线第一个月使用你的产品的用户与第五个月使用你产品的用户感受到的体验是很不一样的。 我们把在同一个时间段(产品阶段)使用产品的用户划为同一期,针对他们的分析叫做同期群分析
需要了解到什么度¶
至少在你们公司，你应该是你们公司用户的专家，即其他人想要了解用户对某些场景或问题的看法时，如果想到咨询一个人的话，第一个想到的是你，那么你就是你们公司的用户专家。可以不断的问自己一个问题“自己是否可以称为用户专家，是否足够的洞察用户”，这需要时间的积累，在实践中回答这个问题，并不断的通过实践给出一个肯定的答案。
怎么衡量了解的度¶
最简单直接的方法是假设验证法，即给定一个场景，给出你对用户的判断，然后以实际结果验证你的判断。不断的实践来提高对用户判断的准确度。
当给出任何场景，你对用户的判断八九不离十，知道用户是否存在这个问题？多少用户存在这个问题？用户当前是怎么解决这个问题的？是否值得做？做了之后用户是否能从原来的习惯中迁移过来？
指标 4¶
需求量、强度、频次、痛点、Arpu、期望、现有解决方案
需求量：大众、小众
强度：刚需、弱需 越刚越容易付费
频次：高、低频
need_analysis¶
痛点：解决某个需求时很难受的地方
Arpu：用户价值。烧饼一两块、化妆品百来块、增高药上万
期望：超预期。才能拉新。
lawyer_analysis¶
为了需求找技术。
研究内容 4¶
用户特征：性别、年龄、职业、地域、学历、消费能力。TOFA（传统/时尚、节俭/花钱）
需求情景：在什么时候用，用的时候会发生什么？饿了么，来不及停止接单、在意配送时间准时保。
需求动机：聊天、结婚、约炮？微信熟人、陌陌陌生人不需加好友。
显性/隐性需求：隐性又是更重要
关注因素：在意什么？菜品口味、价格、送餐速度、干净卫生。大众用综合排序
认知过程：不知道》知道》了解》产生兴趣》学习
行为习惯：用户通常怎么做？由于认知决定。SICAS(Sense、Interest、Communication、Action、Share) FOGG(motivation、ability、trigger)
行为心理：为何这么做？货比三家、怕吃亏上当。
使用过程：用户使用你产品或服务的过程。
决定因素：重大行为的决策。陌陌上找你喝酒，怕是酒托、仙人跳..
需求情景–情节¶
主线：筛选饭店、点餐、支付、等餐、就餐。
分支：
筛选饭店的方式：搜索、好评、默认推荐
查看送餐小哥什么时候能送到?要不要催促下?
饭到了很难吃,要不要给个差评?
异常：退餐流程,这个流程中,又可以细分出N个情景
用户体验、满意度、需求满足程度
产品不同,研究的内容和方法也会有差异,需要活学活用。
这条线上的每一个点,都会关联到你的业务流程设计,产品功能设计,运营策略,付费转化策略,营销推广的策略和N个细节。
产品的每一个细节,都跟用户需求有着千丝万缕的联系。大到产品定位规划,商业模式,竞争策略,小到每一句营销的文案编写,UI设计图那个字需要加大加粗,某个位置需要一个小图标。
洞察用户时常犯错误¶
1）以偏概全，因自己或周边人经常遇到某些场景，就以为绝大多数人会遇到类似场景，很感性的认知。举例：你朋友圈的热点可能真的只是你朋友圈的热点，在你父母那，在你高中同学那，在别的行业的大学同学那，甚至同行业同事那里，大家的热点都是有差异的。
2）常识性错误，比如我们知道一般老板会查看下属工作情况，老板也更关心公司的业绩统计数据，然后我们就可能认为下属资料和业绩统计分析会有较高的用户重合度，其实不一定，因为查看下属资料这个大概率是管理员做，但统计分析这种业务员也可以查看，甚至是老板指派专人管理。
3）过于相信数据，比如AI技术可以实现一些功能的自动化，我们通过自动化的开关来判定用户有没有使用，也通过用户对自动化数据的修改来判断用户是否真的将自动化使用起来。但数据表现都很好，不代表用户满意，用户可能只是不知道你给他自动做来那么多事情，甚至知道了，也觉得数据是错的，但选择忽略而已，需要更多的从用户真实的反馈中得到。
4）静态的看待用户的行为，无论我们做用户访谈，还是用户调研，得出的数据和内容是基于当时用户状态及对产品的了解，而用户在产品或服务使用的过程中，是会随时间的变化而变化的。比如对于C端用户勋章挑战类的功能，刚开始可能用户比较喜欢，参与度较高，但随着参与次数的提升，部分用户会有疲劳感，这在产品的设计中，就要考虑随时间周期变化的用户的反馈。
如何将用户需求转换为产品需求？¶
首先保持二八原则，只有普遍用户的需求，才能内化为产品的需求。比如某个需求就一个用户需要，其他大多数用户都不需要，你就不需要做。
通过现象看本质，收集用户需求以后，多为自己几个为什么，找到用户的动机。
例如：用户在沙漠中需要水，你就要问自己用户为什么需要水？用户有可能口渴了，那这时候你给他水就好，如果用户是因为太热，你能不能给他防晒服，甚至考虑一下用户体验，觉得防晒服太麻烦，提供防晒霜。有时候一个人并不能完全洞察用户的动机，需要团队的其他人员一起头脑风暴，甚至多问提这个需求的原始用户几个为什么，直到找到真正动机为止，然后结合产品本身衡量需求的性价比，最后综合团队实力，需求急切度确定最终产品需求。
需求提取 3¶
“如果我最初问消费者他们想要什么，他们应该是会告诉我，‘要一匹更快的马！’”
——这是亨利·福特的一句经典名言，如今我们在《乔布斯传》里又见到了它。
客户需求有显性需求和隐性需求两大类。我们通过市场调查得知的往往都是一些诸如“我要一匹更快的马”这类显性需求。客户的显性需求并不是客户真正的需求。企业需要根据所收集的显性需求信息进行深度挖掘和捕获，以了解客户的隐性需求是什么，进而分析出客户的真正需求是什么（例如：用更短的时间、更快地到达目的地）。这就是一个需求分析的过程。
Y 模型 12¶
Y 模型¶
配图中你可以看到一个大写的字母 Y，有三个线段、四个节点。
“节点 1”代表的是用户需求场景，经常被简称为用户需求。这是起点，是表象，是表面的需求，是用户的观点和行为。
“节点 2”是用户需求背后的目标和动机，是用户言行的原因。不过产品经理在思考用户目标时也要综合考虑公司、产品的目标。
“节点 3”是产品功能，是解决方案，是技术人员能看懂的描述。
“节点 4”是人性与价值观，或者说是用户心智，是需求的最深层体现，是需求的本质。
Y 模型的不同阶段，各自需要回答一些问题，可以总结为 6 个 W 和 3 个 H。
“节点 1”这个阶段的问题主要是 Who（目标用户是谁）、What（需求表现为什么）和 Where/When（何时何地，什么情况下）。
“节点 1”到“节点 2”和“节点 2”到“节点 4”这个阶段，对应的是对用户需求的层层深入。这个阶段要回答 Why 这个问题——要不停地往下深入挖掘需求，了解用户为什么会有这样的言行、为什么会有这样的目标和动机。
“节点 4”到“节点 2”再到“节点 3”的过程中，你要想清楚 How——也就是要想清楚问题应该怎么解决。这个叫浅出，先深入后浅出。
“节点 3”中，要回答 Which、How many、How much 三个问题。
Which 是指选哪一个方案，做哪一个功能，这背后其实是对价值的判断，比如怎么评估性价比和优先级。How many 是指这一次做多少个功能，考验的是对迭代周期，产品包大小的把控。How much 原意是多少钱，这里引申为多少资源，是对时间、金钱、团队等资源的评估。
在一个不成熟的领域或全新的市场，只做“节点 1、2、3”是玩得转的。但表层需求很快就会被相似的跟进产品满足，随着市场的成熟，产品很快会陷入同质化竞争和价格战，最终整个市场变成红海。而破局的方法就在“节点 4”（用户心智）。
作为初创团队，你要做的重要事情只有两件，一是和用户交流，二是开发产品。 ———保罗·格雷厄姆
创新会面临两大风险，一是市场风险，就是说你做的产品有没有人需要，二是技术风险，就是说你能不能把东西做出来。
和用户交流，就是 Y 模型的前半段，是解决市场风险，对应的心法就是用心听；而开发产品，就是 Y 模型的后半段，是解决技术风险，对应的心法是不要照着做。
用户访谈¶
在求职和工作中会有什么作用呢？
在求职中，用户访谈是说服面试官的武器。
在面试中，面试官可能会质疑你需求的合理性。例如，面试官可能会说：“我觉得你这个约别人骑行的需求是个伪需求。”如果你没有做用户访谈，那么你只能说：“我觉着这个需求肯定是存在的，因为我就有这个需求。”这样是不是显得底气不足？但是，如果你做过用户访谈，你就可以自信地说：“这个需求确实存在，因为我访谈了20 个目标用户，其中85%的用户提到自己有这个需求，主要场景有两个，一个是当自己不会修车时可以找人帮忙，另一个是他们觉得一个人骑行很无聊。”这样的回答是不是更有说服力？
在工作中，用户访谈是验证需求合理性的方法之一。
作为产品经理，我们要“发现需求”，而不是“创造需求”。这就要求我们通过科学、严谨的方法去挖掘需求，而不是用拍脑袋的方式决定有什么需求。比较严谨的方式有两种，一种是数据分析，另一种是用户访谈。因此，在掌握了用户访谈的方法后，我们就可以在以后的工作中设计出更符合用户预期的产品。