这本书应该很多人至少听过，在用户体验的书里算是比较好懂，至少比《About Face》简单多了。
最近和知识星球的小伙伴重温这本书，我又有了更多新的理解。
这本书虽然说的还是那五大要素，但文中一些隐隐透出的观点，让我对体验设计工作，甚至对项目协作，有了全新的认知。其中有些部分，让我对过去一些疏忽的观念，有了不同的领悟。
这本书由于年代和社会环境的差异，国内的读者会觉得有点难与自己的工作环境一一对照。
战略层相当于 CEO 的工作
范围层相当于项目经理的工作
结构层相当于产品经理的工作
框架层相当于交互设计的工作
表现层相当于视觉设计的工作
虽然原书把「交互设计」写在了「结构层」，把「界面设计」写在了「框架层」，但这只是用词的差异而已。从文中描述与图示来看，结构层的「交互设计」更像是流程设计，而「框架层」的「界面设计」更像是交互设计。
书中也说了，这些分层都是从产品本身去考量的，与职位分工无关。小公司里一人负责多个层次很正常，大公司里好几个人负责一个层次也有可能，岗位划分全凭人事部或老板本人的随手规划。很多新人会问我：产品设计是做什么的？产品经理要不要画线框图？公司没有用研流程怎么办？
如果很明确是自己来负责那当然要做；如果不明确是谁来做，但又与自己直接相关的，如果有空也应该主动负责。
这不是内卷不内卷的问题，而是为了最终的项目成果，没必要太过纠结于职责划分。P.S. 当然，如果工作环境过于死板，那么另当别论。这五个层次，理想状态是先决定了最下面的决策层后，再一一向上推导。但是「理想」就意味着「不可能」，所以实际情况总是下层只做了一部分，上层就要逐步开始动起来。这是为了缩减时间成本，而不得不让上下游之间肯定存在一些信息不对称。
这就是为什么，很多做执行落地的人，会感觉领导很多事情没有想清楚，或者想的方向和自己不一样。例如：领导要求给产品增加社交功能，虽然这个产品明显和社交扯不上关系。执行团队发现战略目标有问题后，肯定试图改变策略层，然而这是难度是相当高高，要不然 2016 年的「支付鸨」事件怎么会出现？我不相信上线前支付宝的产品经理和设计师都没发现问题，为了这个改版肯定没少掉头发，但是结果还是得按照战略层的计划来走。
从五大层次看，就是要上层顺应下层才能保证目标一致，否则你一句我一句的，项目很容易失去方向。虽然决策者面应该多听听执行者的建议，但顶多只是辅助参考而已。
作为项目执行者，是可以向决策者提合理的建议，但不要寄希望于对方会听从甚至解释，因为一个高效的团队应该有明确的职责边界。
决策者可能有没说出口的理由，或者哪怕真的方向错误又怎样？大不了像「支付鸨」那样被用户口水骂回去，反正担责任的是领导，自己工资照拿。只要专业过关，项目还是可以放到作品集里，只是让外行人看起来没那么有面子。我发现很多老板，尤其是中小企业里，专业经验一般又自信过头的那种，特别喜欢对方案的一些细节指手画脚。按钮用什么颜色、文案用哪几个字、加载动画用哪种样式……枝端末节的小事都要管。
搞得底下的人心力交瘁，最后看着惨不忍睹的方案也没办法。其实他们未必那么在意按钮的颜色，只是脑子里想着战略目标是让用户眼前一亮，所以张口就直接说出要会闪光的大红色，甚至还能找个模板来：你跟他解释效果很土，他却想：只要能达到自己的策略目标，审美算什么？
于是对方不但更加坚定了自己的立场，而且还心想：这小设计师果然商业头脑不够，我得多盯着些。
想办法把讨论重心转移到战略层，不断向强调目标以达成共识，然后再慢慢推导出具体方案。总之就是不要和老板对着干，先从战略层统一目标再说。仔细思考了用户体验五大层次后，我发现工作上既要知变通又要讲原则。
变通是说对于没人负责的部分，需要勇于承担。当然风险与收益并存，但是对于大部分公司来说结果比规则更重要。原则是说对于明确是别人负责的部分，不要只能建议不能干涉，有时宁愿一起犯点小错误，也要保证整个系统的顺畅运行。这本书精读起来，还是能发现不少内容。如果你没空仔细阅读或者自己想不清楚，我整理好了 PPT 将在下周三的直播分享，欢迎参加：
上图是部分 PPT 缩略图，扫码后还有一小章的免费试看。老规矩，我的大部分付费内容都是对知识星球的会员免费的：
如果你只是想要多认识一些同行，也可以加入我们无广告的纯粹体验研讨微信群：