Login Now 不知道你有没有这种感觉——聊到产品设计，大家总爱把“用户体验五要素”挂在嘴边。战略层、范围层、结构层、框架层、表现层，这五个词顺口溜一样，张嘴就来。很多产品分析、竞品分析，也习惯按这五个维度一层层拆解下去。
但真要落到具体判断上，比如框架层到底做得好不好，反倒容易说不清楚。因为五个要素本来就是环环相扣的，想单独拎出框架层来讨论，得先看看上面几层给它留下了什么。
先简单回顾一下这五层到底在说什么。
战略层，是企业和用户分别对产品有什么期望，目标是什么，这是最底层的动机。
范围层，基于目标，产品需要有哪些功能和内容。
结构层，相当于抽象和具体之间的分界线，决策开始偏向抽象。它确定用户会看到哪些选项，以及这些选项以什么模式、什么顺序出现。也就是说，结构层关注的是用户如何到达某个页面，做完事之后又能去哪里。
框架层，开始落到具体的按钮、控件、图片、文本区域的位置上。它优化的是页面设计布局——哪些组件该放在哪儿，同样的内容用什么样的方式去呈现最合适。
表现层，是视觉、听觉、触觉层面的体验设计，也是用户最直接感受到的那一层。
框架层，说白了，就是界面设计、导航设计和信息设计交织在一起的那个层面。
不过话说回来，现在设计系统越来越成熟，用户习惯也培养得差不多了，不管是竞品分析还是自己落地设计，真要在这五层上做出什么突破性的创新，其实挺难的。也正因为这样，我反倒觉得，把框架层是不是“合理”这件事琢磨清楚，比追求花哨的“创新”更有价值。前阵子做过一个项目，借着它复盘一下，聊聊到底怎么判断框架层是不是做到了位，是不是符合产品目标和企业目标。
一、怎么确定框架层
框架层的好坏，很大程度上取决于上层给它的输入质量。如果上层给出的信息是一样的，那在同等条件下，怎么找到更合适的框架层？
这里得先设一个前提：你负责的可能是整个产品，也可能只是一个模块，但这不影响，底层逻辑是通的。我们就假设一个情况——你要为一个新产品搭一套底层的框架逻辑，该从哪里开始。
第一步，从战略层指定的用户目标和产品目标里，把设计目标拎出来。
这里面最难平衡的，就是产品和用户之间的拉扯。最近做的项目是车载HMI，刚好可以拿来说说。车企和用户，立场天然不同。
企业的目标很直接：尽可能压低成本，实现最大回报，把车卖好。要实现这个目标，就得在别的方向上使劲——比如大幅提升用户体验，成本又低，还能带来新颖感、功能感、科技感，这些都能给用户带来不一样的感受。
用户的目标呢？买一辆质优价廉的车。很多人看车先看品牌、行业评价、油耗、操控感、外观造型、价格，最后综合各种因素选一辆性价比最高的。尤其现在年轻购车群体，对智能科技体验的要求更高，同等价位下，他们更愿意为“好用又有趣”的科技感买单。说到底，用户希望通过智能化的车载系统，让出行体验变得更顺畅、更舒服，他们想要的功能往往是“小而精”。
你看，这两个目标是有冲突的。作为设计师，我们得在这两者之间找到落脚点。我的经验是：以企业目标为主，用户目标为辅。先满足企业那一系列需求，再尽可能通过优化流程框架、界面交互，去贴近用户的目标。做乙方的时候，这种思维就更明显了——你得站在对方角度想问题。如果我是一家车企，我想做HMI，什么样的设计和框架能在未来三到五年内满足市场需求，还能让用户愿意掏钱？这样去想，双方的合作才能顺畅。
第二步，根据范围层，把整个使用流程里能优化、能打动的点理出来。
企业会给出需求清单，告诉你需要哪些模块、哪些功能，通常还会附带一堆生态系统的PPT。说实话，这些PPT看多了会发现，大家长得都差不多，基本就是把手机上的应用和功能搬过来，想搞一个“车载版手机”。
可问题是，车机中控的硬件肯定不如手机，硬要塞进去这么多功能，卡顿是家常便饭。但企业为了卖点、为了提升车辆竞争力，又必须把功能往里加，不管好不好用，先得有。至于这部分怎么优化，后面有机会再展开聊，毕竟需求往往来自企业高层，设计师能干预的有限。
举个例子，为了突出科技感，语音功能几乎是必不可少的。那怎么通过语音把整个车载场景串联起来，就是设计上可以发力的地方。要实现这个目标，就得想清楚：语音功能到底长什么样？可以放在哪些位置？用什么风格？有没有状态变化？语音的交互样式会不会影响到其他应用层级？它跟其他层级的信息之间会不会打架？
这些细节，都得在框架层落位之前反复推敲。
第三步，根据结构层，思考信息传达的层次感，以及怎么把设计目标落实到交互上。
比如，为了突出车载场景，是不是应该尽可能多地展示地图？那音乐还能不能同时显示？能不能放一些快捷操作按钮，减少用户的操作步骤？应用中状态发生变化时，是不是也该同步展示出对应的快捷操作？怎么展示才既满足企业要求，又切中用户痛点？每个应用在车载场景下的流程怎么优化，才能让体验更顺畅？
第二步和第三步的每一个细节，背后都有大量的推导过程。你考虑的条件越多，最后出来的框架就越“立得住”，越经得起推敲。
二、怎么评价框架的合理性
框架的制定，往往不是纯理性的产物，它会受到各种不可控因素的拉扯——领导意见、甲方需求、各方压力，设计师很多时候是在夹缝里找到平衡点。但即便在这样的限制下，定下来的框架还是得经得起检验，不能出现矛盾，比如A状态一变，B状态就没法操作了。
怎么评价框架是否合理？可以从这几个角度入手。
第一，层次优先级合理吗？
车载HMI是一整套车载ROM，里面有应用层、车控层等等，这些层会设定优先级，低优先级的会被高优先级的遮挡。判断优先级是否合理，得看两点：一是需求本身的重要程度；二是交互的形态和性质。比如，消息通知通常是小窗口样式，不会遮挡太多内容，属于临时状态，显示固定时间后会自动消失，这种层的优先级就可以适当提高，因为它不会对主线操作造成太大干扰。
第二，层级之间的跳转是否顺畅、合理。
拿手机来举例更好理解。比如在A应用里，点一条新闻跳到了B应用，那怎么返回A应用？这两个层级之间的关系会不会有问题？会不会因为B的层级不够高，点开之后没法在A的上层正常显示？这些都要提前考虑清楚。
第三，尽量降低系统层级，同时提供快速返回主页的操作。
假如没有快速操作，系统层级堆到七八层，用户就得一层一层关闭应用才能回到主页，这在车载场景下是很危险的，也会让体验变得非常糟糕。
第四，结合设计目标，回头看框架有没有达到预期。
最后，回到最初的设计目标。不管是追求便捷、高效、智能，还是简洁，主页的布局和结构都应该能体现出这些特质。但无论怎么变，导航和多媒体始终是车上最核心的模块，它们的优先级不能丢。
很多时候，框架层不太被单独拿出来细说，大概是因为手机系统已经太成熟了，大家觉得没什么好聊的。但车载环境的特殊性，让这个领域还留有不少空白，手机和车机的联动也是很多厂商在摸索的方向。真希望未来的驾驶体验，能越来越友好，越来越懂人。