User story，我已经写不下10年了，写的越来越不费脑子，越来越顺手，越来越麻木，越来越觉得这不是废话吗？越来越记不起“初心”了…
你懂的朋友们，如果Abandon，abandon，abandon，的中文解释是“背单词”。那么那个心情的我对User story的英文解释，理解是“As a user”“As a user”“As a user”。我一手指天一手插着腰，举头大叫，所以四级永远不会考abandon，user story的as a user味同嚼蜡，毛用没有！再后来看了Alan Klement的Job story扫盲篇，遂赶紧转身投入Job to be done的怀抱，干掉该死的“as a user”。JTBD方法的语句跟User story一样，由三个部分组成：
Situation — Motivations — Expected Outcomes
- Situation
我从高中就学不明白的状语从句When打头，先描述一堆场景，足够细致足够丰富 - Motivations
然后上动机层面而非动作层面的I want to干嘛干嘛，这里要加入很多梗细节的上下文限制描述 — 这些描述非常重要！ - Expected Outcomes
最后一句话给出此用户期待的结果。
JTBD的job story与User story方法之间的关键差异在于JTBD并不在意用户是如何完成任务的。比如某些朋友扬言要吃你亲手包的饺子，你觉得这肯定是饿了，殊不知买包也可以满足需求。所以别先着急包饺子，吃顿饺子又不能让这位朋友在她/他的朋友们中脱颖而出。买包不仅解决了饿了的基本需求，还能满足寻找温暖的期待需求和朋友圈素材的兴奋需求，一网打尽，你说气不气人。其实JS和US的目的都是在于探索“某个用户”在遇到“某个问题”时的最佳“解决方案”，当然这个最优解会收到很多背景及上下文的限制和影响。
这两者也都有局限的地方：Job story的语句并不是从人出发，从表面上看也并没有特意提及”某个用户的具体特征“；User story又太早搬出来一些假设，所以Alan Klement建议我们JTBD这个方法要想在UX领域用好，可以两者结合，选择其一进行修改：
- 比如修改user story
As a [type of user], who is [situation], I want [some action], so that [outcome] - 或者修改job story
When [situation], a [type of user] want to [motivation], so a [type of user] can [expected outcome]
这样一来，感觉这俩哥俩争什么呢？最后谁也没选上。。。
于是我又琢磨了一下午，其实互联网高速发展的这几年，各种新概念新方法层出不穷。曾经刘平同志给我上了一课，学知识要学精华，所有现象都是归于定理，所有定理都是归于一个公理。只要掌握了这一个确定的公理，吃嘛嘛香，世界平蹚。这些年全世界的互联网人都在研究人的需求，要么是铺人铺时间，呼呼呼往前傻跑，快速试错，快速迭代；要么是靠智慧，拍脑袋拍大腿琢磨人性，这时就需要各种各样的方法和定理帮助一起拍。反正就是乱哄哄，你方唱罢我登场！到头来，我想说说我对“故乡”的理解：拍法公理。
- 先说人
具体的人，越具体越好。张一，张二，张三，张四四个用户。推典型的方法推举出最大公约数的张三本人，而不是平均一个张2.5出来。这就不是user，而是产品设计的意淫。所以我支持上来就说As a user，但这个user是个真人，而不是用户画像。真人意味着不仅是人口学的属性，而是包括多个维度的信息：网络摘抄如下
1）人口学属性，如年龄、婚恋状态、收入等；
2）个人履历，如简介、照片和名字等；
3）态度和/或行为，如该人物角色的心理模型、痛点、对任务的感受等；
4）使用产品的目的和动机；
5）用户在使用产品时的行为细节和偏向；
其实这些丰富信息的补充正是Allan在Job Story里说Motivation时反复强调的force。 - 再说场景
具体的场景，越具体越好。穷尽遍历所有case。在保质的前提下，量化的标准就是句子越长越好。看看下图最右下的绿色方块。
短发
3. 预期
张三期待的结果，可以是很简单的一句话。不过这里也可以搞些事情。比如马斯洛的五层或八层心理需求理论，引入Kano的需求分析模型，或者Censydiam的用户动机分析模型。具体我就不展开讨论，放个图顿悟！
