需求来源也许只有leader的一句话，也许只是一封邮件，甚至可能只是一条qq消息。但是往往话越少，需要做的也就更多。
需求的正常描述语句是：我需要增加/修改某个功能/页面；例子，领导给你说，小王，把我的桌子收拾一下。
目标的描述语句是：我希望获得某种收益；例子，领导告诉你，小王，我希望能够及时找到自己想要的文件。
区别在哪里？做需求，你只用把桌子的东西摆整齐，笔记本和文件摆在一起，桌子擦一遍就可以了；实现目标，你需要把每种文件分类，草稿纸堆一边，合同堆一遍，笔记本又得堆一遍。
领导只有一句话，我怎么才能知道目标呢？逆向推到，从结论到原因，从现象到本质。一个功能一般只有一个目标，一个目标可以对应多个功能，这也是敏捷开发中强调的用户故事。
《用户体验要素》对需求划分了五层，大多数人只会在框架层和表现层思考问题。拿到需求就想着该怎么设计交互，这个按钮放在哪里，那个表单应该怎么排列。越表层的东西越应该放在最后去思考，拔高自己的层次。思考用户为什么会有这样的需求，学会思考，多多在生活中尝试这样的逆向思考，为什么火车站的餐饮口味都非常一般？为什么现在的大学生都要自学编程？透过现象看到本质是你从功能经理到PM的第一步。
理解用户真正的使用目标后还是需要回溯到需求，从需求适用的场景去思考如何设计一个完备的功能。
为什么需要落实到某一个具体的场景？最大的好处是带入用户的体验感，其次是遍历所有的可能性，避免设计方案有所遗漏。
需求是用户目标的落地方案，一个目标一定可以通过多个需求来满足，如何选择最优的体验以及在资源有限的情况下选择效益最高的功能是PM最核心的技能。
根据《交互设计精髓4》的介绍，应该是用户调研。从市场调研到persona的建立，是场景化的前提。很遗憾的是，大多数功能经理以及产品经理都很很少有机会去做一次专业的用户调研。
那么，比较折中的方案就是自己去使用产品或则在产品没交付前去试用原型。当然，人都难以避免会带入主观性，所以得及时刹车，避免过度设计和满足不存在的需求。
市面上有一套比较成熟的方案，5W2H法可以协助我们及时矫正。
场景化本身并不是一件多困难的事情，但是大多数产品往往会习惯性忽视这一步，这也是为什么我们的PRD会经常被开发挑战的原因。
不能落实到用户具体的使用场景就会出现设计遗漏，举一个经典的例子，某个导航类的app一个核心流程就是帮助用户换乘地铁，app此时会在界面上标识换乘地铁的终点站，只有带入用户场景才知道，在匆忙换乘的期间，你第一眼看到的一定是下一站的几个大字。
如何快速让你知道换乘地铁的方向？Where？When？两个核心指标可以快速带入用户的场景。
