很多书都会告诉我们做需求要从目标/场景到功能到交互到视觉，但实际工作中，除非是超大型+超长周期发布的产品（比如Office），大部分产品需求都是随意出现的，它可能来自用户、可能来自老板、可能来自运营…可能是关于视觉的、可能是关于页面的、可能是关于交互的、可能是关于功能的。
所以，不能确定问题的时候，就反向回归到场景和目标。e.g.:一般而言，用户反应字号字体不适，有可能是反映了页面中元素的主次关系出现了问题。
但在处理用户反馈时，也要注意实现成本，找一些轻快的方式，避免「过度实现」。e.g.:也许用户真的只是觉得字号有点小而已。
-
有些时候，场景可能都对，但目标不对，一切都白搭。
e.g. 1：豌豆荚应用内搜索，场景都OK，但目标出现了问题。视频网站想要的只是APP下载量，豌豆荚给它们带去的播放量量级实在太少了，所以对方没有理由特意为你开放接口。
e.g. 2：老板想要加某个功能，要确认背后的需求究竟是用户使用时长还是使用频次。目标抓不对，场景想得再对也没用。
竞品分析不用过多关注视觉和交互，多分析功能和结构。同样一个搜索框、同样一个删除/添加的交互，可以参考的APP多的是，不必太过关注竞品怎么做。
泛信息类产品的需求优先级，按照信息来源、信息加工、信息发现、信息消费到最后用户来源的顺序去筛选。如果信息来源都存在问题没解决，就别去想信息消费上的需求了。
同样的，泛信息类产品建立壁垒的方式也是按照这个顺序，优先抢占来源（e.g.:豆瓣阅读的排他协议）。
