1. 为什么“用户体验要素”值得反复拆解产品经理圈子里有个挺有意思的现象几乎所有人都听过《用户体验要素》这本书但真正能把里面那套五层模型落到日常需求评审、原型设计和上线复盘里的人其实不多。更多人记住的是那句“用户体验就是产品好不好用”然后继续在需求文档里堆功能点。我自己带过几个从零到一的产品项目也接手过一些“功能齐全但用户就是不买账”的烂摊子踩过的坑让我越来越确信一件事——用户体验不是界面美化也不是交互细节的堆砌它是一套从战略到表现的完整决策链条。你跳过任何一层后面都得用更高的成本补回来。这篇文章我想聊的不是读书笔记而是把“用户体验要素”这套框架拆成能直接上手用的东西。核心关键词就三个用户体验、五层模型、产品设计。我会讲清楚这五层分别解决什么问题、每一层的产出物长什么样、层与层之间怎么衔接以及在实际项目中怎么用这套框架去排查问题。不管你是刚入行的产品助理还是做了几年但总觉得“差点意思”的交互设计师或者是一个需要把控产品方向的创业者这套东西都能帮你把模糊的“体验不好”翻译成具体的、可执行的改进项。先说一个我自己的判断大部分产品的体验问题根源不在执行层而在战略层和范围层没想清楚。表现层的问题最容易被发现也最容易被当成全部问题来治结果就是改了一版又一版UI用户该走还是走。五层模型最大的价值就是逼着你从下往上检查而不是从上往下瞎猜。2. 五层模型到底在解决什么问题2.1 从抽象到具体的决策漏斗《用户体验要素》里把用户体验拆成五个层级战略层、范围层、结构层、框架层、表现层。很多人把它理解成一个瀑布式的开发流程先做完战略再做范围一层层往下推。这个理解不算错但容易让人误以为必须严格按顺序来。实际上它更像一个决策漏斗——越往下的层级越抽象越往上的层级越具体每一层都在回答一个核心问题。战略层回答的是“我们为什么要做这个产品用户想从中得到什么”。范围层回答的是“我们要做哪些功能不做哪些功能”。结构层回答的是“这些功能怎么组织用户怎么在信息之间穿梭”。框架层回答的是“界面上的元素怎么摆放导航怎么设计”。表现层回答的是“最终呈现给用户的视觉和感知是什么样的”。我习惯用一个类比来解释盖房子。战略层是“这房子给谁住、用来干嘛”范围层是“要几个房间、有没有车库”结构层是“房间怎么连通、动线怎么走”框架层是“家具摆在哪、开关装在哪”表现层是“墙面刷什么颜色、地板用什么材质”。你不会在没想清楚给谁住之前就开始挑瓷砖但现实中很多产品就是这么干的。2.2 每一层的核心产出物光知道五层的名字没用得知道每一层该产出什么。我整理了一个对照表这是我在实际项目中反复用的检查清单层级核心问题典型产出物常见失误战略层为什么做、为谁做用户画像、产品目标、成功指标目标模糊用“提升体验”当目标范围层做什么、不做什么功能列表、需求优先级、内容清单功能蔓延什么都想要结构层怎么组织、怎么流转信息架构图、流程图、交互逻辑分类混乱用户找不到东西框架层怎么摆放、怎么引导线框图、导航设计、界面布局信息层级不清重点不突出表现层长什么样、感觉如何视觉稿、设计规范、动效方案风格不统一视觉压过功能这张表我建议你打印出来贴在工位上。每次需求评审或者方案讨论卡壳的时候对照一下大概率能定位到是哪一层没对齐。比如团队在争论按钮放左边还是右边这其实是框架层的问题但如果战略层的目标用户都没定义清楚这个争论就没有判断标准最后只能靠“我觉得”来收场。2.3 为什么不能跳层跳层是产品设计里最常见的隐性成本。我见过一个项目战略层只写了一句“做一个面向年轻人的社交产品”然后直接跳到表现层开始画界面风格很潮、动效很炫上线后留存率惨不忍睹。复盘的时候发现范围层没定义清楚核心功能是什么结构层没想明白用户怎么建立关系框架层没解决冷启动时内容从哪来的问题。表现层做得再好也撑不起一个空壳。跳层的另一个表现是“用表现层的问题掩盖结构层的问题”。比如用户反馈“找不到某个功能”产品团队的第一反应往往是“那我们把入口放大一点、颜色调亮一点”。这可能在短期内有效但如果根本原因是信息架构不合理放大入口只是让用户更快地走进死胡同。正确的做法是回到结构层重新审视分类逻辑和导航路径。注意五层模型不是让你每次做需求都从战略层重新推导一遍。对于成熟产品的迭代战略层和范围层通常是稳定的你只需要在结构层、框架层、表现层里做调整。但如果是新产品或者大版本重构从下往上完整走一遍是值得的。3. 战略层把“用户想要”翻译成“产品目标”3.1 用户需求不是问出来的战略层最核心的两件事定义用户需求定义产品目标。听起来简单做起来最难。因为用户需求往往不是用户直接说出来的。亨利·福特那句“如果我问用户想要什么他们会说想要一匹更快的马”被引用烂了但道理是对的。用户能描述的是他们遇到的问题不是解决方案。我在实际项目中用的是一个“三层追问法”。第一层问“你遇到了什么不方便”第二层问“这个问题在什么场景下发生”第三层问“如果这个问题解决了你的感受会有什么变化”。举个例子用户说“你们的搜索功能不好用”这是第一层。追问下去发现是在商品数量超过一定量之后搜索结果排序不符合预期这是第二层。再追问发现用户真正在意的是“快速找到符合预算且评价好的选项”这是第三层。到了第三层你才知道要优化的不是搜索框的样式而是排序算法和筛选条件的设计。这个方法的要点是不要问用户“你想要什么功能”而是问“你在什么场景下遇到了什么阻碍”。功能是解决方案场景和阻碍才是需求本身。3.2 产品目标要可衡量“提升用户体验”不是产品目标因为它没法衡量。战略层的产品目标必须是具体的、可量化的。我通常会把目标分成三类用户目标、业务目标、技术目标。用户目标关注的是用户行为和感受的变化比如“新用户首次完成核心操作的时间从3分钟降到1分钟以内”。业务目标关注的是商业指标比如“注册转化率提升15%”。技术目标关注的是系统能力比如“页面加载时间控制在2秒以内”。这三类目标之间往往存在张力比如为了提升注册转化率把流程简化可能会牺牲一些用户信息的完整性。战略层的作用就是把这些张力摆到桌面上让团队知道优先级是什么。实操心得战略层的目标不要超过三个。超过三个等于没有重点。我见过一个项目的战略文档写了八个目标结果每个季度都在调整优先级团队疲于奔命。后来砍到两个核心目标反而推进得更快。3.3 用户画像要具体到能吵架用户画像不是画一个卡通人物写上“张三28岁白领”就完事了。好的用户画像应该具体到团队能为了“这个功能张三会不会用”而吵架。我习惯用“场景行为痛点”的结构来描述用户画像。比如“通勤场景下的内容消费者”每天早上8点到9点在地铁上单手操作手机网络信号不稳定主要行为是快速浏览标题和短内容痛点是加载慢、操作复杂、内容太长看不完。这个画像一出来很多设计决策就有了依据——按钮要大、操作要少、内容要短、加载要快。如果团队在争论要不要加一个复杂的手势操作对照这个画像就知道答案了。战略层还有一个容易被忽略的产出物不做什么。明确列出“我们不为哪些用户服务”“我们不解决哪些问题”这比列出要做什么更能统一团队认知。我见过太多产品因为想讨好所有人最后谁都没讨好。4. 范围层功能取舍的决策框架4.1 功能列表不是越长越好范围层的核心任务是决定“做什么”和“不做什么”。大部分团队在这一层的典型问题是功能蔓延——每个需求评审都有人提“顺便把这个也做了吧”结果版本越做越大上线时间一推再推核心功能反而没打磨好。我用的方法是“功能价值矩阵”。横轴是“用户价值”纵轴是“实现成本”把每个候选功能放进四个象限高价值低成本优先做、高价值高成本规划做、低价值低成本有空做、低价值高成本不做。这个矩阵的关键是“用户价值”的评估标准要统一不能凭感觉打分。评估用户价值的时候我会问三个问题这个功能能帮用户完成什么任务不做这个功能用户有没有替代方案这个功能影响的是核心用户还是边缘用户三个问题的答案越具体打分越靠谱。4.2 需求优先级不是拍脑袋优先级排序是范围层最容易引发争论的环节。产品说这个重要技术说那个做不了设计说另一个体验更好。我的经验是把优先级判断拆成可量化的维度让争论有据可依。我常用的维度有四个用户覆盖度影响多少用户、使用频率用户多久用一次、业务影响对核心指标的影响程度、实现复杂度技术成本和依赖关系。每个维度按1到5分打分加权求和。权重根据产品阶段调整——早期产品更看重用户覆盖度和使用频率成熟产品更看重业务影响。这个方法不能保证结果绝对正确但能让讨论从“我觉得”变成“数据说”。而且打分的过程本身就能暴露很多信息比如技术团队在评估复杂度的时候可能会提出更简单的替代方案。4.3 内容清单和功能清单一样重要范围层不只是功能列表还包括内容清单。特别是内容型产品内容的质量、数量、更新频率直接决定了用户体验。我见过一个知识付费产品功能做得很完善但内容更新跟不上用户来了发现没什么可看的很快就流失了。内容清单要明确内容从哪来UGC还是PGC、内容怎么分类、内容怎么更新、内容质量怎么把控。这些问题如果在范围层没想清楚到了结构层和框架层就会变成无解的难题。比如UGC内容如果没有审核机制到了表现层就会出现大量低质量内容影响整体体验。常见问题范围层和结构层的边界在哪里我的判断标准是范围层回答“有什么”结构层回答“怎么组织”。比如“有文章、视频、音频三种内容形式”是范围层“这三种内容怎么分类、怎么关联、怎么推荐”是结构层。5. 结构层让用户不迷路的信息架构5.1 信息架构的三种组织方式结构层的核心是信息架构和交互设计。信息架构解决的是“内容怎么分类”交互设计解决的是“用户怎么操作”。这两件事经常被混在一起讨论但它们的判断标准不同。信息架构的好坏看用户能不能找到东西交互设计的好坏看用户能不能顺畅完成任务。信息架构有三种基本的组织方式层级式、矩阵式、线性式。层级式最常见适合内容有明确从属关系的场景比如电商分类。矩阵式适合内容可以从多个维度访问的场景比如按价格和按品牌都能筛选。线性式适合有固定顺序的场景比如注册流程。选择哪种方式取决于用户的心智模型。用户在想找某个东西的时候脑子里通常已经有一个分类预期。如果你的分类和用户的预期不一致用户就会迷路。我常用的验证方法是“卡片分类法”把内容项写在卡片上让目标用户自己分组看看他们的分类逻辑和你的设计是否一致。5.2 交互流程要画到“异常路径”画流程图的时候大部分人只画正常路径用户打开页面、点击按钮、完成任务。但真正影响体验的往往是异常路径网络断了怎么办、输入错误怎么办、权限不够怎么办、内容为空怎么办。这些异常路径如果在结构层没考虑到到了开发阶段就会变成临时补丁体验很难保证。我习惯在流程图里用不同颜色标注正常路径和异常路径异常路径至少要考虑四种情况加载失败、输入无效、权限不足、内容为空。每种情况都要有明确的用户提示和下一步操作建议。比如内容为空的时候是显示“暂无内容”还是推荐其他内容是引导用户去创建内容还是返回上一页这些决策在结构层就要定下来。5.3 结构层的验证方法结构层的方案怎么验证最常用的方法是树状测试和可用性测试。树状测试是给用户一个任务让他在信息架构树里找到目标内容看能不能找到、需要几步找到。可用性测试是让用户实际操作原型观察他在哪里犹豫、在哪里出错。这两种方法我都在项目里用过说句实在话树状测试更适合验证分类逻辑可用性测试更适合验证交互流程。如果时间有限优先做可用性测试因为用户的实际操作行为比分类偏好更能暴露问题。测试样本不用多5到8个目标用户就能发现大部分严重问题。实操心得做可用性测试的时候不要问用户“你觉得这个设计怎么样”而是给一个具体任务比如“你想买一双跑步鞋预算500以内请找到符合条件的商品”。观察他的操作路径记录他在哪里停顿超过3秒、在哪里点了返回、在哪里皱眉头。这些行为信号比口头反馈可靠得多。6. 框架层界面上的每一像素都有理由6.1 线框图的三个层次框架层的产出物主要是线框图。线框图不是随便画几个框它要解决三个层次的问题信息层级、导航路径、操作入口。信息层级决定用户先看到什么、后看到什么。导航路径决定用户怎么在页面之间跳转。操作入口决定用户在哪里完成核心操作。我画线框图的时候会遵循一个原则一个页面只解决一个核心任务。如果一个页面上有多个同等重要的任务用户就会分心。比如商品详情页的核心任务是“让用户决定买不买”那么加入购物车和立即购买就是核心操作其他如分享、收藏、客服都是辅助操作在视觉权重上要明确区分。线框图阶段不要纠结颜色和字体那是表现层的事。框架层关注的是布局和层级。我见过太多团队在线框图阶段就开始争论按钮颜色结果结构问题被掩盖了。6.2 导航设计的常见陷阱导航设计是框架层最容易出问题的地方。常见的陷阱有三个导航层级过深、导航标签含义模糊、导航状态不清晰。导航层级过深是指用户要点击很多次才能到达目标页面。移动端一般建议不超过三层桌面端可以适当放宽。如果层级确实很深就要考虑用搜索、快捷入口、推荐等方式来缩短路径。导航标签含义模糊是指用户看了不知道点进去是什么。比如“更多”“其他”“相关”这种标签用户无法预判内容。好的标签应该是具体的、用户能理解的比如“相似商品”“购买过的人还看了”。导航状态不清晰是指用户不知道自己当前在哪个位置。面包屑导航、高亮当前菜单项、页面标题都是解决这个问题的常用手段。特别是移动端用户很容易迷失清晰的导航状态能显著降低焦虑感。6.3 框架层的检查清单框架层方案完成后我会用一份检查清单过一遍用户第一眼看到的是不是最重要的信息核心操作是否在拇指可触达的范围内移动端页面之间的跳转逻辑是否一致返回操作是否符合用户预期空状态、加载状态、错误状态是否都有设计信息密度是否适合目标用户的使用场景这份清单看起来简单但能筛掉大部分框架层的低级错误。特别是空状态和错误状态很多团队只设计正常状态用户遇到异常时看到一片空白或者一堆报错代码体验直接崩掉。7. 表现层视觉不只是好看7.1 视觉设计的三个功能表现层是最容易被误解的一层。很多人觉得表现层就是“把界面做好看”但实际上视觉设计承担着三个功能引导注意力、传达信息层级、建立情感连接。引导注意力是指通过颜色、大小、对比度等手段让用户的视线按照你期望的顺序移动。比如电商详情页用户第一眼应该看到商品图片第二眼看到价格和核心卖点第三眼看到购买按钮。如果视觉设计没有引导用户可能第一眼看到的是促销广告反而忽略了商品本身。传达信息层级是指通过视觉手段区分信息的重要程度。标题和正文的字体大小、颜色深浅、间距大小都在告诉用户哪些信息更重要。如果所有信息看起来都一样重要用户就不知道从哪里看起。建立情感连接是指视觉风格传递出的情绪和调性。同样是工具类产品有的看起来专业严谨有的看起来轻松活泼。这种调性要和目标用户的心理预期匹配。面向企业用户的产品用太活泼的配色用户会觉得不靠谱面向年轻用户的产品用太沉闷的配色用户会觉得无趣。7.2 设计规范的价值表现层最容易被忽视的产出物是设计规范。设计规范不是限制设计师的创造力而是保证产品在不同页面、不同状态下的一致性。没有设计规范的产品做几个版本之后就会出现各种不一致按钮圆角不一样、颜色深浅不一样、间距大小不一样。用户可能说不出来哪里不对但会觉得“不精致”。设计规范至少应该包含色彩系统主色、辅助色、语义色、字体系统字号、字重、行高、间距系统基础单位、常用组合、组件库按钮、输入框、卡片等。这些规范要同步给开发和测试确保实现和设计一致。常见问题设计规范做多细我的经验是核心组件和常用页面要细边缘场景可以粗。比如按钮的各种状态默认、悬停、点击、禁用、加载要定义清楚但某个很少出现的弹窗可以灵活处理。规范是为了提高效率不是为了增加流程。7.3 表现层的验收标准表现层做完之后怎么验收我通常从三个维度检查一致性、可读性、适配性。一致性是指同一类元素在不同页面是否表现一致。比如所有的主按钮是不是同一个颜色、同一个圆角、同一个点击反馈。可读性是指文字是否清晰易读包括字号是否够大、对比度是否足够、行高是否舒适。适配性是指在不同屏幕尺寸、不同设备上是否都能正常显示。这三个维度里适配性最容易被忽略。设计师在电脑上看效果很好到了手机上发现文字太小、按钮太挤。我建议在表现层阶段就用真机测试不要等到开发完成才发现问题。8. 五层模型在实际项目中的排查应用8.1 用五层模型定位问题五层模型最大的实用价值是排查问题。当用户反馈“体验不好”的时候你可以从下往上逐层检查定位到具体是哪一层出了问题。我整理了一个排查表这是我在实际项目中反复用的用户反馈可能的问题层级排查方向“不知道这个产品能干嘛”战略层价值主张是否清晰“功能太多太乱”范围层功能优先级是否明确“找不到想要的东西”结构层信息架构是否合理“不知道怎么操作”框架层导航和引导是否清晰“看起来不舒服”表现层视觉规范是否统一这个表不能覆盖所有情况但能帮你快速缩小排查范围。比如用户说“找不到想要的东西”你先检查结构层的信息架构而不是急着改界面颜色。8.2 从表现层反推结构层问题有时候表现层的问题其实是结构层问题的症状。比如用户反馈“页面太乱”你去看表现层发现视觉设计确实有问题但改了一版之后用户还是觉得乱。这时候就要往上追可能是结构层的信息分类不合理导致页面上堆了太多不相关的内容。我遇到过一个典型案例一个后台管理系统的用户反馈“操作效率低”。表现层看界面很整洁按钮也很清晰。框架层看导航和布局也没问题。追到结构层才发现核心操作流程需要跳转五个页面每个页面都要重新加载数据。用户效率低的根源是流程设计不合理不是界面问题。后来把五个页面合并成两个效率问题就解决了。这个案例说明一个道理表现层的问题好改结构层的问题难改但结构层的问题影响更大。如果只改表现层可能短期内用户不抱怨了但根本问题还在。8.3 五层模型的迭代应用五层模型不是一次性的而是持续迭代的。产品上线后用户行为数据会告诉你哪一层需要调整。比如数据显示用户在某个页面停留时间很短就离开了可能是框架层的信息层级有问题。如果用户在某一步骤的流失率很高可能是结构层的流程设计有问题。我习惯在每个版本复盘的时候用五层模型过一遍战略层有没有变化范围层有没有新增或砍掉功能结构层有没有调整框架层和表现层有没有优化这样能保证产品迭代是有逻辑的而不是东改一下西改一下。实操心得不要试图一次性把五层都做到完美。资源有限的情况下优先保证战略层和范围层清晰结构层合理框架层和表现层可以快速迭代。战略层和范围层的问题如果拖到后面才发现返工成本极高。9. 常见问题与避坑指南9.1 五层模型用不起来的原因很多人学了五层模型之后觉得“道理都懂但用不起来”。我观察下来主要有三个原因。第一个原因是团队没有共识。产品经理学了五层模型但设计师和开发不认讨论的时候还是各说各的。解决办法是在项目启动会上就把五层模型作为共同语言每个决策都明确是在哪一层做的。第二个原因是时间压力。项目排期紧团队觉得“没时间想那么多”直接跳到画原型。结果原型改了一版又一版反而更浪费时间。我的建议是哪怕只花半天时间把战略层和范围层对齐后面能省下好几天的返工。第三个原因是缺乏验证。五层模型每一层都需要验证但很多团队做完方案就直接开发没有用户测试。我的经验是结构层和框架层至少要做一轮可用性测试表现层至少要做一轮视觉走查。这些验证花不了太多时间但能发现大部分严重问题。9.2 五层模型不是万能药五层模型是一个思考框架不是操作手册。它帮你把复杂问题拆解成可管理的部分但具体怎么拆、怎么解还是要靠你的判断。不同产品、不同阶段、不同团队五层模型的用法都不一样。比如To B产品和To C产品战略层的侧重点完全不同。To B产品更关注决策链和业务流程To C产品更关注用户动机和使用场景。再比如早期产品和成熟产品范围层的策略也不同。早期产品要快速验证核心价值功能要少而精成熟产品要满足不同用户群体的需求功能可以更丰富。我见过一些团队把五层模型当成 checklist每层都填一堆文档结果文档很厚但产品还是不行。问题在于他们把模型当成了目的而不是工具。模型是帮你思考的不是替你思考的。9.3 五层模型和其他框架的关系五层模型和其他产品设计框架并不冲突而是互补的。比如设计思维Design Thinking强调同理心、定义问题、创意发散、原型验证这和五层模型的战略层、范围层、框架层、表现层有对应关系。精益创业Lean Startup强调最小可行产品和快速迭代这和范围层的功能取舍、表现层的快速验证也有交集。我的建议是把五层模型作为底层框架其他方法作为具体工具。比如用设计思维的方法做用户调研用精益创业的方法做功能验证但整体上还是用五层模型来组织思考。这样既有框架的完整性又有方法的灵活性。10. 我个人的一些实操体会做了这么多年产品五层模型对我最大的帮助不是让我知道该做什么而是让我知道不该做什么。每次团队讨论陷入细节争论的时候我就会问一句“这是哪一层的问题”这个问题往往能让讨论回到正确的轨道上。还有一个体会是五层模型里战略层和范围层是最需要反复确认的。因为这两层的变化会直接影响下面三层。我见过太多项目因为战略层目标变了导致范围层功能要砍结构层流程要改框架层和表现层全部重做。如果能在战略层和范围层多花一点时间对齐后面的返工成本会低很多。最后分享一个小技巧每次做新功能或者改版的时候先写一句话描述这个功能在五层模型里分别是什么。比如“战略层提升新用户留存范围层增加新手引导结构层引导流程嵌入核心操作路径框架层用气泡提示和进度条表现层品牌色和插画风格”。这一句话写出来团队对要做什么就清楚了后面执行起来也顺畅得多。这个内容后续还可以这样扩展针对不同产品类型工具类、内容类、电商类、社交类分别整理五层模型的侧重点和常见陷阱或者把五层模型和数据分析结合起来用数据指标来验证每一层的效果。这些方向我在实际项目中都有尝试后面有机会再展开聊。
1. 为什么“用户体验要素”值得反复拆解产品经理圈子里有个挺有意思的现象几乎所有人都听过《用户体验要素》这本书但真正能把里面那套五层模型落到日常需求评审、原型设计和上线复盘里的人其实不多。更多人记住的是那句“用户体验就是产品好不好用”然后继续在需求文档里堆功能点。我自己带过几个从零到一的产品项目也接手过一些“功能齐全但用户就是不买账”的烂摊子踩过的坑让我越来越确信一件事——用户体验不是界面美化也不是交互细节的堆砌它是一套从战略到表现的完整决策链条。你跳过任何一层后面都得用更高的成本补回来。这篇文章我想聊的不是读书笔记而是把“用户体验要素”这套框架拆成能直接上手用的东西。核心关键词就三个用户体验、五层模型、产品设计。我会讲清楚这五层分别解决什么问题、每一层的产出物长什么样、层与层之间怎么衔接以及在实际项目中怎么用这套框架去排查问题。不管你是刚入行的产品助理还是做了几年但总觉得“差点意思”的交互设计师或者是一个需要把控产品方向的创业者这套东西都能帮你把模糊的“体验不好”翻译成具体的、可执行的改进项。先说一个我自己的判断大部分产品的体验问题根源不在执行层而在战略层和范围层没想清楚。表现层的问题最容易被发现也最容易被当成全部问题来治结果就是改了一版又一版UI用户该走还是走。五层模型最大的价值就是逼着你从下往上检查而不是从上往下瞎猜。2. 五层模型到底在解决什么问题2.1 从抽象到具体的决策漏斗《用户体验要素》里把用户体验拆成五个层级战略层、范围层、结构层、框架层、表现层。很多人把它理解成一个瀑布式的开发流程先做完战略再做范围一层层往下推。这个理解不算错但容易让人误以为必须严格按顺序来。实际上它更像一个决策漏斗——越往下的层级越抽象越往上的层级越具体每一层都在回答一个核心问题。战略层回答的是“我们为什么要做这个产品用户想从中得到什么”。范围层回答的是“我们要做哪些功能不做哪些功能”。结构层回答的是“这些功能怎么组织用户怎么在信息之间穿梭”。框架层回答的是“界面上的元素怎么摆放导航怎么设计”。表现层回答的是“最终呈现给用户的视觉和感知是什么样的”。我习惯用一个类比来解释盖房子。战略层是“这房子给谁住、用来干嘛”范围层是“要几个房间、有没有车库”结构层是“房间怎么连通、动线怎么走”框架层是“家具摆在哪、开关装在哪”表现层是“墙面刷什么颜色、地板用什么材质”。你不会在没想清楚给谁住之前就开始挑瓷砖但现实中很多产品就是这么干的。2.2 每一层的核心产出物光知道五层的名字没用得知道每一层该产出什么。我整理了一个对照表这是我在实际项目中反复用的检查清单层级核心问题典型产出物常见失误战略层为什么做、为谁做用户画像、产品目标、成功指标目标模糊用“提升体验”当目标范围层做什么、不做什么功能列表、需求优先级、内容清单功能蔓延什么都想要结构层怎么组织、怎么流转信息架构图、流程图、交互逻辑分类混乱用户找不到东西框架层怎么摆放、怎么引导线框图、导航设计、界面布局信息层级不清重点不突出表现层长什么样、感觉如何视觉稿、设计规范、动效方案风格不统一视觉压过功能这张表我建议你打印出来贴在工位上。每次需求评审或者方案讨论卡壳的时候对照一下大概率能定位到是哪一层没对齐。比如团队在争论按钮放左边还是右边这其实是框架层的问题但如果战略层的目标用户都没定义清楚这个争论就没有判断标准最后只能靠“我觉得”来收场。2.3 为什么不能跳层跳层是产品设计里最常见的隐性成本。我见过一个项目战略层只写了一句“做一个面向年轻人的社交产品”然后直接跳到表现层开始画界面风格很潮、动效很炫上线后留存率惨不忍睹。复盘的时候发现范围层没定义清楚核心功能是什么结构层没想明白用户怎么建立关系框架层没解决冷启动时内容从哪来的问题。表现层做得再好也撑不起一个空壳。跳层的另一个表现是“用表现层的问题掩盖结构层的问题”。比如用户反馈“找不到某个功能”产品团队的第一反应往往是“那我们把入口放大一点、颜色调亮一点”。这可能在短期内有效但如果根本原因是信息架构不合理放大入口只是让用户更快地走进死胡同。正确的做法是回到结构层重新审视分类逻辑和导航路径。注意五层模型不是让你每次做需求都从战略层重新推导一遍。对于成熟产品的迭代战略层和范围层通常是稳定的你只需要在结构层、框架层、表现层里做调整。但如果是新产品或者大版本重构从下往上完整走一遍是值得的。3. 战略层把“用户想要”翻译成“产品目标”3.1 用户需求不是问出来的战略层最核心的两件事定义用户需求定义产品目标。听起来简单做起来最难。因为用户需求往往不是用户直接说出来的。亨利·福特那句“如果我问用户想要什么他们会说想要一匹更快的马”被引用烂了但道理是对的。用户能描述的是他们遇到的问题不是解决方案。我在实际项目中用的是一个“三层追问法”。第一层问“你遇到了什么不方便”第二层问“这个问题在什么场景下发生”第三层问“如果这个问题解决了你的感受会有什么变化”。举个例子用户说“你们的搜索功能不好用”这是第一层。追问下去发现是在商品数量超过一定量之后搜索结果排序不符合预期这是第二层。再追问发现用户真正在意的是“快速找到符合预算且评价好的选项”这是第三层。到了第三层你才知道要优化的不是搜索框的样式而是排序算法和筛选条件的设计。这个方法的要点是不要问用户“你想要什么功能”而是问“你在什么场景下遇到了什么阻碍”。功能是解决方案场景和阻碍才是需求本身。3.2 产品目标要可衡量“提升用户体验”不是产品目标因为它没法衡量。战略层的产品目标必须是具体的、可量化的。我通常会把目标分成三类用户目标、业务目标、技术目标。用户目标关注的是用户行为和感受的变化比如“新用户首次完成核心操作的时间从3分钟降到1分钟以内”。业务目标关注的是商业指标比如“注册转化率提升15%”。技术目标关注的是系统能力比如“页面加载时间控制在2秒以内”。这三类目标之间往往存在张力比如为了提升注册转化率把流程简化可能会牺牲一些用户信息的完整性。战略层的作用就是把这些张力摆到桌面上让团队知道优先级是什么。实操心得战略层的目标不要超过三个。超过三个等于没有重点。我见过一个项目的战略文档写了八个目标结果每个季度都在调整优先级团队疲于奔命。后来砍到两个核心目标反而推进得更快。3.3 用户画像要具体到能吵架用户画像不是画一个卡通人物写上“张三28岁白领”就完事了。好的用户画像应该具体到团队能为了“这个功能张三会不会用”而吵架。我习惯用“场景行为痛点”的结构来描述用户画像。比如“通勤场景下的内容消费者”每天早上8点到9点在地铁上单手操作手机网络信号不稳定主要行为是快速浏览标题和短内容痛点是加载慢、操作复杂、内容太长看不完。这个画像一出来很多设计决策就有了依据——按钮要大、操作要少、内容要短、加载要快。如果团队在争论要不要加一个复杂的手势操作对照这个画像就知道答案了。战略层还有一个容易被忽略的产出物不做什么。明确列出“我们不为哪些用户服务”“我们不解决哪些问题”这比列出要做什么更能统一团队认知。我见过太多产品因为想讨好所有人最后谁都没讨好。4. 范围层功能取舍的决策框架4.1 功能列表不是越长越好范围层的核心任务是决定“做什么”和“不做什么”。大部分团队在这一层的典型问题是功能蔓延——每个需求评审都有人提“顺便把这个也做了吧”结果版本越做越大上线时间一推再推核心功能反而没打磨好。我用的方法是“功能价值矩阵”。横轴是“用户价值”纵轴是“实现成本”把每个候选功能放进四个象限高价值低成本优先做、高价值高成本规划做、低价值低成本有空做、低价值高成本不做。这个矩阵的关键是“用户价值”的评估标准要统一不能凭感觉打分。评估用户价值的时候我会问三个问题这个功能能帮用户完成什么任务不做这个功能用户有没有替代方案这个功能影响的是核心用户还是边缘用户三个问题的答案越具体打分越靠谱。4.2 需求优先级不是拍脑袋优先级排序是范围层最容易引发争论的环节。产品说这个重要技术说那个做不了设计说另一个体验更好。我的经验是把优先级判断拆成可量化的维度让争论有据可依。我常用的维度有四个用户覆盖度影响多少用户、使用频率用户多久用一次、业务影响对核心指标的影响程度、实现复杂度技术成本和依赖关系。每个维度按1到5分打分加权求和。权重根据产品阶段调整——早期产品更看重用户覆盖度和使用频率成熟产品更看重业务影响。这个方法不能保证结果绝对正确但能让讨论从“我觉得”变成“数据说”。而且打分的过程本身就能暴露很多信息比如技术团队在评估复杂度的时候可能会提出更简单的替代方案。4.3 内容清单和功能清单一样重要范围层不只是功能列表还包括内容清单。特别是内容型产品内容的质量、数量、更新频率直接决定了用户体验。我见过一个知识付费产品功能做得很完善但内容更新跟不上用户来了发现没什么可看的很快就流失了。内容清单要明确内容从哪来UGC还是PGC、内容怎么分类、内容怎么更新、内容质量怎么把控。这些问题如果在范围层没想清楚到了结构层和框架层就会变成无解的难题。比如UGC内容如果没有审核机制到了表现层就会出现大量低质量内容影响整体体验。常见问题范围层和结构层的边界在哪里我的判断标准是范围层回答“有什么”结构层回答“怎么组织”。比如“有文章、视频、音频三种内容形式”是范围层“这三种内容怎么分类、怎么关联、怎么推荐”是结构层。5. 结构层让用户不迷路的信息架构5.1 信息架构的三种组织方式结构层的核心是信息架构和交互设计。信息架构解决的是“内容怎么分类”交互设计解决的是“用户怎么操作”。这两件事经常被混在一起讨论但它们的判断标准不同。信息架构的好坏看用户能不能找到东西交互设计的好坏看用户能不能顺畅完成任务。信息架构有三种基本的组织方式层级式、矩阵式、线性式。层级式最常见适合内容有明确从属关系的场景比如电商分类。矩阵式适合内容可以从多个维度访问的场景比如按价格和按品牌都能筛选。线性式适合有固定顺序的场景比如注册流程。选择哪种方式取决于用户的心智模型。用户在想找某个东西的时候脑子里通常已经有一个分类预期。如果你的分类和用户的预期不一致用户就会迷路。我常用的验证方法是“卡片分类法”把内容项写在卡片上让目标用户自己分组看看他们的分类逻辑和你的设计是否一致。5.2 交互流程要画到“异常路径”画流程图的时候大部分人只画正常路径用户打开页面、点击按钮、完成任务。但真正影响体验的往往是异常路径网络断了怎么办、输入错误怎么办、权限不够怎么办、内容为空怎么办。这些异常路径如果在结构层没考虑到到了开发阶段就会变成临时补丁体验很难保证。我习惯在流程图里用不同颜色标注正常路径和异常路径异常路径至少要考虑四种情况加载失败、输入无效、权限不足、内容为空。每种情况都要有明确的用户提示和下一步操作建议。比如内容为空的时候是显示“暂无内容”还是推荐其他内容是引导用户去创建内容还是返回上一页这些决策在结构层就要定下来。5.3 结构层的验证方法结构层的方案怎么验证最常用的方法是树状测试和可用性测试。树状测试是给用户一个任务让他在信息架构树里找到目标内容看能不能找到、需要几步找到。可用性测试是让用户实际操作原型观察他在哪里犹豫、在哪里出错。这两种方法我都在项目里用过说句实在话树状测试更适合验证分类逻辑可用性测试更适合验证交互流程。如果时间有限优先做可用性测试因为用户的实际操作行为比分类偏好更能暴露问题。测试样本不用多5到8个目标用户就能发现大部分严重问题。实操心得做可用性测试的时候不要问用户“你觉得这个设计怎么样”而是给一个具体任务比如“你想买一双跑步鞋预算500以内请找到符合条件的商品”。观察他的操作路径记录他在哪里停顿超过3秒、在哪里点了返回、在哪里皱眉头。这些行为信号比口头反馈可靠得多。6. 框架层界面上的每一像素都有理由6.1 线框图的三个层次框架层的产出物主要是线框图。线框图不是随便画几个框它要解决三个层次的问题信息层级、导航路径、操作入口。信息层级决定用户先看到什么、后看到什么。导航路径决定用户怎么在页面之间跳转。操作入口决定用户在哪里完成核心操作。我画线框图的时候会遵循一个原则一个页面只解决一个核心任务。如果一个页面上有多个同等重要的任务用户就会分心。比如商品详情页的核心任务是“让用户决定买不买”那么加入购物车和立即购买就是核心操作其他如分享、收藏、客服都是辅助操作在视觉权重上要明确区分。线框图阶段不要纠结颜色和字体那是表现层的事。框架层关注的是布局和层级。我见过太多团队在线框图阶段就开始争论按钮颜色结果结构问题被掩盖了。6.2 导航设计的常见陷阱导航设计是框架层最容易出问题的地方。常见的陷阱有三个导航层级过深、导航标签含义模糊、导航状态不清晰。导航层级过深是指用户要点击很多次才能到达目标页面。移动端一般建议不超过三层桌面端可以适当放宽。如果层级确实很深就要考虑用搜索、快捷入口、推荐等方式来缩短路径。导航标签含义模糊是指用户看了不知道点进去是什么。比如“更多”“其他”“相关”这种标签用户无法预判内容。好的标签应该是具体的、用户能理解的比如“相似商品”“购买过的人还看了”。导航状态不清晰是指用户不知道自己当前在哪个位置。面包屑导航、高亮当前菜单项、页面标题都是解决这个问题的常用手段。特别是移动端用户很容易迷失清晰的导航状态能显著降低焦虑感。6.3 框架层的检查清单框架层方案完成后我会用一份检查清单过一遍用户第一眼看到的是不是最重要的信息核心操作是否在拇指可触达的范围内移动端页面之间的跳转逻辑是否一致返回操作是否符合用户预期空状态、加载状态、错误状态是否都有设计信息密度是否适合目标用户的使用场景这份清单看起来简单但能筛掉大部分框架层的低级错误。特别是空状态和错误状态很多团队只设计正常状态用户遇到异常时看到一片空白或者一堆报错代码体验直接崩掉。7. 表现层视觉不只是好看7.1 视觉设计的三个功能表现层是最容易被误解的一层。很多人觉得表现层就是“把界面做好看”但实际上视觉设计承担着三个功能引导注意力、传达信息层级、建立情感连接。引导注意力是指通过颜色、大小、对比度等手段让用户的视线按照你期望的顺序移动。比如电商详情页用户第一眼应该看到商品图片第二眼看到价格和核心卖点第三眼看到购买按钮。如果视觉设计没有引导用户可能第一眼看到的是促销广告反而忽略了商品本身。传达信息层级是指通过视觉手段区分信息的重要程度。标题和正文的字体大小、颜色深浅、间距大小都在告诉用户哪些信息更重要。如果所有信息看起来都一样重要用户就不知道从哪里看起。建立情感连接是指视觉风格传递出的情绪和调性。同样是工具类产品有的看起来专业严谨有的看起来轻松活泼。这种调性要和目标用户的心理预期匹配。面向企业用户的产品用太活泼的配色用户会觉得不靠谱面向年轻用户的产品用太沉闷的配色用户会觉得无趣。7.2 设计规范的价值表现层最容易被忽视的产出物是设计规范。设计规范不是限制设计师的创造力而是保证产品在不同页面、不同状态下的一致性。没有设计规范的产品做几个版本之后就会出现各种不一致按钮圆角不一样、颜色深浅不一样、间距大小不一样。用户可能说不出来哪里不对但会觉得“不精致”。设计规范至少应该包含色彩系统主色、辅助色、语义色、字体系统字号、字重、行高、间距系统基础单位、常用组合、组件库按钮、输入框、卡片等。这些规范要同步给开发和测试确保实现和设计一致。常见问题设计规范做多细我的经验是核心组件和常用页面要细边缘场景可以粗。比如按钮的各种状态默认、悬停、点击、禁用、加载要定义清楚但某个很少出现的弹窗可以灵活处理。规范是为了提高效率不是为了增加流程。7.3 表现层的验收标准表现层做完之后怎么验收我通常从三个维度检查一致性、可读性、适配性。一致性是指同一类元素在不同页面是否表现一致。比如所有的主按钮是不是同一个颜色、同一个圆角、同一个点击反馈。可读性是指文字是否清晰易读包括字号是否够大、对比度是否足够、行高是否舒适。适配性是指在不同屏幕尺寸、不同设备上是否都能正常显示。这三个维度里适配性最容易被忽略。设计师在电脑上看效果很好到了手机上发现文字太小、按钮太挤。我建议在表现层阶段就用真机测试不要等到开发完成才发现问题。8. 五层模型在实际项目中的排查应用8.1 用五层模型定位问题五层模型最大的实用价值是排查问题。当用户反馈“体验不好”的时候你可以从下往上逐层检查定位到具体是哪一层出了问题。我整理了一个排查表这是我在实际项目中反复用的用户反馈可能的问题层级排查方向“不知道这个产品能干嘛”战略层价值主张是否清晰“功能太多太乱”范围层功能优先级是否明确“找不到想要的东西”结构层信息架构是否合理“不知道怎么操作”框架层导航和引导是否清晰“看起来不舒服”表现层视觉规范是否统一这个表不能覆盖所有情况但能帮你快速缩小排查范围。比如用户说“找不到想要的东西”你先检查结构层的信息架构而不是急着改界面颜色。8.2 从表现层反推结构层问题有时候表现层的问题其实是结构层问题的症状。比如用户反馈“页面太乱”你去看表现层发现视觉设计确实有问题但改了一版之后用户还是觉得乱。这时候就要往上追可能是结构层的信息分类不合理导致页面上堆了太多不相关的内容。我遇到过一个典型案例一个后台管理系统的用户反馈“操作效率低”。表现层看界面很整洁按钮也很清晰。框架层看导航和布局也没问题。追到结构层才发现核心操作流程需要跳转五个页面每个页面都要重新加载数据。用户效率低的根源是流程设计不合理不是界面问题。后来把五个页面合并成两个效率问题就解决了。这个案例说明一个道理表现层的问题好改结构层的问题难改但结构层的问题影响更大。如果只改表现层可能短期内用户不抱怨了但根本问题还在。8.3 五层模型的迭代应用五层模型不是一次性的而是持续迭代的。产品上线后用户行为数据会告诉你哪一层需要调整。比如数据显示用户在某个页面停留时间很短就离开了可能是框架层的信息层级有问题。如果用户在某一步骤的流失率很高可能是结构层的流程设计有问题。我习惯在每个版本复盘的时候用五层模型过一遍战略层有没有变化范围层有没有新增或砍掉功能结构层有没有调整框架层和表现层有没有优化这样能保证产品迭代是有逻辑的而不是东改一下西改一下。实操心得不要试图一次性把五层都做到完美。资源有限的情况下优先保证战略层和范围层清晰结构层合理框架层和表现层可以快速迭代。战略层和范围层的问题如果拖到后面才发现返工成本极高。9. 常见问题与避坑指南9.1 五层模型用不起来的原因很多人学了五层模型之后觉得“道理都懂但用不起来”。我观察下来主要有三个原因。第一个原因是团队没有共识。产品经理学了五层模型但设计师和开发不认讨论的时候还是各说各的。解决办法是在项目启动会上就把五层模型作为共同语言每个决策都明确是在哪一层做的。第二个原因是时间压力。项目排期紧团队觉得“没时间想那么多”直接跳到画原型。结果原型改了一版又一版反而更浪费时间。我的建议是哪怕只花半天时间把战略层和范围层对齐后面能省下好几天的返工。第三个原因是缺乏验证。五层模型每一层都需要验证但很多团队做完方案就直接开发没有用户测试。我的经验是结构层和框架层至少要做一轮可用性测试表现层至少要做一轮视觉走查。这些验证花不了太多时间但能发现大部分严重问题。9.2 五层模型不是万能药五层模型是一个思考框架不是操作手册。它帮你把复杂问题拆解成可管理的部分但具体怎么拆、怎么解还是要靠你的判断。不同产品、不同阶段、不同团队五层模型的用法都不一样。比如To B产品和To C产品战略层的侧重点完全不同。To B产品更关注决策链和业务流程To C产品更关注用户动机和使用场景。再比如早期产品和成熟产品范围层的策略也不同。早期产品要快速验证核心价值功能要少而精成熟产品要满足不同用户群体的需求功能可以更丰富。我见过一些团队把五层模型当成 checklist每层都填一堆文档结果文档很厚但产品还是不行。问题在于他们把模型当成了目的而不是工具。模型是帮你思考的不是替你思考的。9.3 五层模型和其他框架的关系五层模型和其他产品设计框架并不冲突而是互补的。比如设计思维Design Thinking强调同理心、定义问题、创意发散、原型验证这和五层模型的战略层、范围层、框架层、表现层有对应关系。精益创业Lean Startup强调最小可行产品和快速迭代这和范围层的功能取舍、表现层的快速验证也有交集。我的建议是把五层模型作为底层框架其他方法作为具体工具。比如用设计思维的方法做用户调研用精益创业的方法做功能验证但整体上还是用五层模型来组织思考。这样既有框架的完整性又有方法的灵活性。10. 我个人的一些实操体会做了这么多年产品五层模型对我最大的帮助不是让我知道该做什么而是让我知道不该做什么。每次团队讨论陷入细节争论的时候我就会问一句“这是哪一层的问题”这个问题往往能让讨论回到正确的轨道上。还有一个体会是五层模型里战略层和范围层是最需要反复确认的。因为这两层的变化会直接影响下面三层。我见过太多项目因为战略层目标变了导致范围层功能要砍结构层流程要改框架层和表现层全部重做。如果能在战略层和范围层多花一点时间对齐后面的返工成本会低很多。最后分享一个小技巧每次做新功能或者改版的时候先写一句话描述这个功能在五层模型里分别是什么。比如“战略层提升新用户留存范围层增加新手引导结构层引导流程嵌入核心操作路径框架层用气泡提示和进度条表现层品牌色和插画风格”。这一句话写出来团队对要做什么就清楚了后面执行起来也顺畅得多。这个内容后续还可以这样扩展针对不同产品类型工具类、内容类、电商类、社交类分别整理五层模型的侧重点和常见陷阱或者把五层模型和数据分析结合起来用数据指标来验证每一层的效果。这些方向我在实际项目中都有尝试后面有机会再展开聊。
