企业官网建设流程全解析

1. 从“能用”到“爱用”：用户体验为什么成了产品生死线

做产品的人大概都经历过这样的场景：功能列表拉出来几十项，技术指标全部达标，测试用例通过率百分之百，上线之后数据却纹丝不动。用户来了，看了一眼，走了。你问他们为什么不用，他们说“说不上来，就是感觉不太对”。这个“说不上来”的东西，就是用户体验。

我做了十多年产品，踩过最大的坑就是早期把用户体验等同于“界面好看”。那时候觉得只要视觉过得去、按钮能点、流程能跑通，产品就没问题。后来才发现，用户体验是一个从战略层到表现层的完整系统，任何一个环节的断裂都会让用户流失。最典型的例子是注册流程——技术团队觉得“填五个字段怎么了”，但用户在第3个字段就放弃了，因为他不理解为什么要填、填了会怎样、能不能跳过。这不是界面问题，是信息架构和用户心理的问题。

《用户体验要素》这本书之所以被奉为经典，是因为它把“用户体验”从一个模糊的感觉词拆解成了五个可操作、可验证的层级：战略层、范围层、结构层、框架层、表现层。这五层不是并列关系，而是自下而上的依赖关系——战略层没想清楚，范围层就会失控；结构层混乱，框架层怎么画都别扭；表现层再精致，也救不了底层的逻辑缺陷。

这篇文章适合三类人看：第一类是刚入行的产品经理和交互设计师，需要一套系统框架来指导日常工作；第二类是有技术背景但缺乏产品思维的开发者，想理解为什么“功能没问题”但用户不买账；第三类是创业者或业务负责人，需要在资源有限的情况下判断哪些体验投入是必须的、哪些可以延后。我会把五层模型拆开揉碎，每一层都配上实际项目中的判断标准、常见误区和可落地的操作步骤，不堆理论，只讲能用的东西。

2. 战略层：用户需求和产品目标的对齐才是地基

2.1 用户需求不是“用户说的”，而是“用户真正想完成的”

战略层要回答两个核心问题：我们要通过这个产品得到什么（产品目标），用户要通过这个产品得到什么（用户需求）。听起来简单，但实际操作中，大部分团队在这两个问题上都是模糊的。

我见过一个做内部工具的项目，产品目标是“提升审批效率”，用户需求写的是“快速提交审批单”。上线后使用率极低，调研发现：用户真正的需求不是“快速提交”，而是“提交后能知道什么时候批下来、被谁卡住了”。原来的审批系统提交完就石沉大海，用户要反复打电话问进度。所以真正的用户需求是过程透明，而不是提交速度。这就是战略层没对齐的典型后果——你优化了一个用户根本不在意的指标。

怎么挖出真正的用户需求？我的经验是三个动作：

• 观察行为而不是听回答：用户说“我想要一个搜索功能”，背后可能是“我找不到想要的东西”。搜索是解决方案，找不到才是问题。如果你直接做搜索，可能发现用户根本不知道搜什么关键词。
• 追问“然后呢”至少三层：用户说“审批太慢”，问“然后呢”——“我不知道找谁催”——“然后呢”——“我只能打电话问”——“然后呢”——“打电话经常占线，很烦”。到这一层，你才知道要解决的是“催办路径可视化”，而不是“审批速度”。
• 区分“痛点”和“痒点”：痛点是不解决会死，痒点是解决了更好。战略层优先解决痛点，痒点放在范围层之后考虑。

2.2 产品目标要具体到可验证，否则就是口号

“提升用户体验”不是产品目标，是愿望。“将新用户首次完成核心操作的时间从5分钟降到2分钟以内”才是产品目标。战略层的产品目标必须满足三个条件：可量化、有期限、有责任人。

我习惯用一个简单的模板来写产品目标：

在[时间范围]内，让[目标用户]在[场景]下，将[核心指标]从[当前值]提升/降低到[目标值]。

比如：“在Q3结束前，让新注册用户在首次登录场景下，将完成个人资料填写率从40%提升到70%。”这个目标清晰到可以直接倒推需要做什么功能、改什么流程、投入多少资源。

战略层还有一个容易被忽略的点：竞品分析不是抄功能，而是理解竞品的战略选择。竞品做了某个功能，不代表你也要做。你要问的是：他们为什么在这个阶段做这个？他们的用户需求和我们一样吗？他们的产品目标是什么？如果答案不同，功能就不该照搬。

2.3 战略层的输出物：一份让全团队能背出来的文档

战略层做完，必须产出一份用户体验战略文档，内容不超过一页纸，包含：目标用户画像（不是人口统计学描述，而是行为特征）、核心用户需求（按优先级排序）、产品目标（量化）、关键成功指标。这份文档要能让团队里每个人用一句话说清楚“我们在为谁解决什么问题”。

我经历过最惨痛的教训是：战略文档写完就锁进文件夹，设计和开发各做各的。后来我们改成战略文档上墙，每天站会花30秒对齐“今天做的事和战略目标的关系”。这个动作看起来形式主义，但实际效果很明显——当设计师知道“这个页面的目标是降低跳出率”而不是“老板觉得不好看”，他们的决策质量会完全不同。

3. 范围层：功能边界划不清楚，后面全是返工

3.1 功能规格说明：把“要做什么”变成“做到什么程度”

范围层的核心任务是把战略层的需求翻译成具体的功能和内容需求。这里最大的坑是：功能列表写了一堆，但没有定义每个功能的验收标准。结果开发做完了，产品说“这不是我要的”，开发说“你当初没说清楚”。

功能规格说明必须包含三个要素：功能描述、验收标准、优先级。我举个实际例子：

验收标准要具体到可测试。比如“错误提示明确”就不合格，应该是“错误提示文案为‘验证码错误，请重新输入’，且输入框下方显示，颜色为红色”。这样开发和测试都没有歧义。

3.2 优先级排序：不是所有功能都值得做

范围层最难的决策是砍功能。我的经验是用价值-成本矩阵来排序：

• 高价值低成本：立即做，这是快速赢。
• 高价值高成本：规划做，拆解成多个迭代逐步交付。
• 低价值低成本：有空再做，或者直接不做。
• 低价值高成本：坚决不做，这是资源黑洞。

但“价值”怎么判断？我通常问三个问题：这个功能能直接推动战略目标吗？不做会阻塞核心流程吗？用户会因为这个功能而选择我们而不是竞品吗？三个问题有一个是“是”，就值得做；全是“否”，就砍掉。

还有一个实操技巧：把功能按“必须有、应该有、可以有、这次不会有”四类归档。这个分类法来自敏捷开发实践，好处是团队对“这次不做什么”有明确共识，避免开发过程中不断加需求。

3.3 内容需求：被严重低估的范围层要素

大部分团队做范围层只关注功能，忽略了内容需求。内容包括文案、图片、视频、数据展示等。内容需求没定义清楚，后期会出现“文案风格不统一”“图片尺寸不对”“数据字段缺失”等问题。

内容需求要定义：内容类型、内容来源、内容更新频率、内容质量标准。比如一个电商产品，商品详情页的内容需求包括：商品标题（来源：商家填写，标准：不超过30字，不含特殊符号）、商品图片（来源：商家上传，标准：白底，最小800x800）、用户评价（来源：用户生成，标准：审核后展示，含敏感词过滤）。

我踩过的坑是：内容需求没定义，设计师按自己的理解做了占位图，开发按占位图写了固定尺寸，结果真实内容接入时全部错位。返工成本极高。所以范围层阶段，内容需求必须和功能需求同等对待。

4. 结构层：信息架构和交互设计决定了用户能不能“找到路”

4.1 信息架构：用户的心智模型比你的分类逻辑更重要

结构层要解决的是信息如何组织、页面如何连接、用户如何移动。信息架构的核心原则是：匹配用户的心智模型，而不是系统的实现逻辑。

举个例子：一个后台管理系统，按技术模块分类是“用户管理、订单管理、商品管理、数据统计”。但用户的实际任务是“我要处理今天的退款申请”，这个任务涉及订单模块和用户模块。如果按技术模块分类，用户要跨两个菜单才能完成一个任务。更好的做法是按任务场景分类：“退款处理”作为一个入口，里面聚合了订单信息和用户信息。

怎么做信息架构？我的步骤是：

1. 卡片分类法：把功能点写在卡片上，让真实用户分组并命名。不要给任何提示，观察他们怎么归类。
2. 树状测试：把初步架构做成树状图，给用户一个任务（如“找到修改收货地址的地方”），看他们能否在预期路径上找到。
3. 迭代优化：根据测试结果调整分类和命名，重复测试直到任务完成率达标。

信息架构的命名也很关键。用用户的语言，不用内部术语。比如“SKU管理”用户看不懂，改成“商品规格”；“流量池”改成“推广渠道”。命名要具体、可预测、无歧义。

4.2 交互设计：流程要顺，反馈要快，错误要可恢复

交互设计关注的是用户完成任务的流程和系统反馈。好的交互设计有三个标准：流程最短、反馈及时、错误可恢复。

流程最短不是指步骤最少，而是认知负担最小。比如注册流程，五个字段分两步填，比五个字段一页填体验更好，因为用户一次只需要处理少量信息。但也不能拆得太碎，否则用户会觉得“怎么还没完”。我的经验是：每步不超过3个决策点，总步骤不超过5步。

反馈及时是指用户的每个操作都要有响应。点击按钮要有按压态，提交表单要有加载态，操作成功要有成功提示，失败要有失败原因。最忌讳的是“点了没反应”，用户会重复点击，导致重复提交。

错误可恢复是指用户犯错后能轻松回到正轨。比如删除操作要有二次确认或撤销功能；表单填写错误要保留已填内容，只提示错误字段；网络中断后重新连接要能恢复之前的操作状态。

4.3 结构层的验证：用任务完成率和错误率说话

结构层做完不能靠感觉判断好坏，要用数据验证。核心指标有两个：任务完成率和任务完成时间。任务完成率低于80%说明架构有问题；完成时间超过预期2倍说明流程太复杂。

我通常做** moderated 可用性测试**：找5-8个目标用户，给他们3-5个核心任务，观察他们操作，记录完成情况、耗时、错误点、求助次数。不需要复杂的设备，一个会议室、一台电脑、一个记录员就够了。关键是让用户说出来——“我现在想找XX，我觉得应该在XX菜单，但没找到，所以我点了XX”。

测试结果要分类整理：架构问题（找不到入口）、命名问题（看到了但不知道是干什么的）、流程问题（找到了但操作太复杂）、反馈问题（操作了但不知道是否成功）。每类问题对应不同的修改策略。

5. 框架层：界面布局和导航设计的细节决定成败

5.1 界面设计：视觉层级引导用户注意力

框架层是在结构层确定的基础上，做具体的界面布局、导航设计和信息展示。界面设计的核心是视觉层级——让用户第一眼看到最重要的信息，第二眼看到次要信息，第三眼看到辅助信息。

视觉层级通过大小、颜色、对比度、留白、位置来实现。最重要的元素放在左上角或视觉中心，用更大的字号、更深的颜色、更多的留白来突出。次要元素弱化处理。辅助元素最小化，但不等于隐藏。

我见过很多界面把“删除”按钮做得和“保存”按钮一样大、一样显眼，结果用户误删。正确的做法是：主操作突出，次操作弱化，危险操作隐藏或二次确认。比如“保存”用实心主色按钮，“取消”用文字链接，“删除”放在更多菜单里。

还有一个常见问题是信息过载。一个页面塞了太多内容，用户不知道看哪里。我的原则是：一个页面只解决一个核心任务。如果内容太多，就拆成多个页面或分步展示。留白不是浪费空间，是给用户的眼睛休息的地方。

5.2 导航设计：让用户永远知道“我在哪、我能去哪、怎么回去”

导航设计要回答三个问题：我在哪（当前位置）、我能去哪（可选路径）、怎么回去（返回路径）。这三个问题任何一个不清晰，用户就会迷失。

常见的导航模式有：顶部导航、侧边导航、底部导航、面包屑、标签页。选择哪种取决于产品结构和用户场景。移动端常用底部导航（3-5个主入口），后台系统常用侧边导航（层级多），内容型产品常用顶部导航+面包屑。

导航设计的一个关键细节是当前状态的标识。用户必须能一眼看出自己在哪个页面、哪个菜单被选中。通常用颜色、下划线、加粗来标识。我见过一个后台系统，所有菜单项长得一模一样，用户点进去才知道是哪个模块，这是典型的导航设计失败。

5.3 信息展示：用用户能理解的方式呈现数据

信息展示包括文字、图片、图表、列表、卡片等形式。选择哪种形式取决于信息的类型和用户的任务。

• 文字：适合精确信息，如金额、日期、名称。
• 图片：适合展示外观、场景、情绪。
• 图表：适合展示趋势、对比、占比。
• 列表：适合展示同类多项信息，便于比较。
• 卡片：适合展示异构信息，每项内容结构不同。

信息展示的一个常见错误是用图表展示不需要图表的数据。比如“今日订单量：100”，一个数字就够了，不需要画一个只有一根柱子的柱状图。另一个错误是图表类型选错：用饼图展示趋势（应该用折线图），用折线图展示占比（应该用饼图）。

还有数据精度的问题。用户不需要知道“转化率是3.1415926%”，说“3.1%”就够了。精度过高反而增加认知负担。但也不能过度简化，比如“约3%”在需要精确对比的场景下就不够用。

6. 表现层：感知设计是用户体验的最后一公里

6.1 视觉设计：一致性比好看更重要

表现层是用户直接感知的层面：颜色、字体、图标、间距、动效。表现层的核心原则是一致性——同一个产品里，相同类型的元素应该长得一样，相同含义的颜色应该一致，相同层级的文字应该字号一致。

一致性通过设计规范来保证。设计规范要定义：色彩系统（主色、辅助色、语义色）、字体系统（字号、字重、行高）、间距系统（4px或8px的倍数）、图标风格（线性或填充、圆角或直角）、组件库（按钮、输入框、弹窗等）。

我见过很多产品，每个页面单独看都挺好看，但放在一起就像拼凑的。问题就出在没有设计规范，或者有规范但没执行。设计规范不是限制创造力，而是把创造力用在刀刃上——基础元素保持一致，创新留给核心体验点。

6.2 动效设计：有意义的动效提升体验，无意义的动效干扰用户

动效在表现层里是双刃剑。好的动效解释空间关系（如页面切换方向）、提供反馈（如按钮点击涟漪）、引导注意力（如新消息提示）。坏的动效延迟用户操作（如过长的加载动画）、分散注意力（如无意义的背景动画）、引发不适（如过快或过慢的过渡）。

我的原则是：动效时长控制在200-500毫秒。低于200毫秒用户感知不到，高于500毫秒用户觉得卡。缓动曲线用ease-in-out或ease-out，避免线性运动（显得机械）。动效要可跳过，尊重用户的“减少动态效果”系统设置。

6.3 表现层的验收：用设计走查和用户感知测试

表现层做完，要做设计走查：对照设计规范，检查每个页面的颜色、字体、间距、图标是否一致。走查要具体到像素级，比如“这个按钮的圆角是4px，规范是6px”“这个标题的字号是18px，规范是16px”。

还要做用户感知测试：给用户看设计稿或原型，问他们“你觉得这个产品是什么感觉”“你最注意到什么”“有没有觉得哪里不舒服”。用户的感知是主观的，但主观感受往往能发现客观问题。比如用户说“感觉有点乱”，可能意味着视觉层级不清晰；用户说“感觉有点冷”，可能意味着色彩太单调。

表现层的迭代是无止境的，但要在正确的时间停止。我的经验是：当设计走查通过、用户感知测试没有严重负面反馈、核心指标达到预期时，就可以进入下一轮功能迭代。追求完美设计而延迟上线，是产品失败的重要原因之一。

7. 五层模型的实战串联：一个完整案例的拆解

7.1 案例背景：一个内部知识库产品的体验改造

某团队做了一个内部知识库，功能齐全：文档上传、分类、搜索、评论、权限管理。但使用率一直很低，员工宁愿在聊天记录里翻找信息，也不用知识库。团队找到我，希望“优化一下界面”。

我先问了一个问题：你们做这个知识库的战略目标是什么？团队回答：“让信息沉淀下来，减少重复提问。”我再问：用户的核心需求是什么？团队回答：“快速找到需要的信息。”这两个答案看起来匹配，但实际有偏差——战略目标是“沉淀”，用户需求是“查找”。沉淀是管理视角，查找是使用视角。如果只关注沉淀，就会做很多上传、分类、审核功能；如果关注查找，就要做搜索、推荐、关联。

7.2 逐层诊断：问题出在结构层和框架层

我让团队把知识库的首页截图给我看。首页是一个分类目录，按部门分：技术部、产品部、市场部、人事部。每个部门下面有子分类。用户要找“如何申请年假”，需要：点击人事部→点击假期管理→找到年假申请文档。三步，看起来不多，但问题是：用户不知道“年假申请”属于人事部还是行政部。如果分类不符合用户心智，每一步都是猜谜。

这就是结构层的信息架构问题：按部门分类是组织逻辑，不是用户逻辑。用户找信息时想的是“我要办什么事”，而不是“这事归哪个部门管”。正确的做法是按任务场景分类：入职、请假、报销、采购、IT支持等。

框架层的问题是搜索入口太弱。搜索框放在页面右上角，很小，而且只支持标题搜索，不支持全文搜索。用户搜“年假”找不到“休假申请流程”，因为标题里没有“年假”两个字。正确的做法是：搜索框放在显眼位置，支持全文搜索，搜索结果按相关度排序，并高亮关键词。

7.3 改造方案：从战略层重新对齐

改造从战略层开始。重新定义产品目标：将员工查找信息的平均时间从5分钟降到1分钟以内。用户需求：用自然语言描述问题，快速获得准确答案。

范围层：砍掉复杂的分类管理功能，聚焦搜索和推荐。增加“热门问题”和“最近更新”模块。内容需求：文档标题必须包含用户可能搜索的关键词，文档内容必须结构化（问题描述、解决步骤、注意事项）。

结构层：信息架构从“部门分类”改为“任务分类+标签体系”。每个文档可以打多个标签，用户可以通过标签组合筛选。搜索支持自然语言，比如“怎么请年假”能匹配到“休假申请流程”。

框架层：首页顶部是搜索框，下面是热门问题列表，再下面是最近更新。导航简化成“首页、分类、我的”三个入口。文档详情页增加“相关问题”推荐。

表现层：统一色彩和字体，搜索框用主色边框突出，热门问题用卡片展示，每个卡片包含问题标题和简短答案预览。

7.4 改造结果与经验总结

改造上线后，知识库的日活跃用户从15%提升到60%，平均查找时间从4分30秒降到50秒。最关键的变化是：员工开始主动往知识库上传文档了，因为他们发现“传上去真的有人看、有人用”。

这个案例给我的经验是：用户体验问题往往不是界面问题，而是战略和结构问题。如果只改界面，把搜索框放大、颜色调亮，可能有一点效果，但不会解决根本问题。五层模型的价值就在于强迫你从下往上检查，找到真正的瓶颈层。

还有一个实操心得：不要试图一次性改造所有层。先诊断哪一层问题最大，集中资源解决那一层，快速上线验证，再迭代下一层。五层模型是诊断工具，不是施工顺序。有时候战略层没问题，结构层也没问题，只是表现层太丑，那就只改表现层。关键是知道自己在改哪一层、为什么改。

8. 常见误区与避坑指南：我踩过的那些坑

8.1 误区一：把用户体验等同于UI设计

这是最普遍的误区。很多团队招了一个UI设计师，就认为“用户体验有人负责了”。但UI设计只是表现层的一部分，用户体验涵盖战略、范围、结构、框架、表现五层。一个UI设计师再厉害，也解决不了战略层用户需求不明确的问题。

我的建议是：产品经理负责战略层和范围层，交互设计师负责结构层和框架层，UI设计师负责表现层。小团队可以一人多角，但思维模式要切换——做战略层时想“为谁解决什么问题”，做表现层时想“颜色字体间距是否一致”。

8.2 误区二：用户说的就是用户想要的

用户说“我想要一个导出Excel的功能”，可能实际需求是“我想把数据分享给同事”。导出Excel只是他想到的解决方案，分享才是目的。如果你只做导出，用户还要自己发邮件，体验并没有本质提升。如果你做“生成分享链接”，用户直接发链接就行，体验更好。

区分“解决方案”和“需求”是产品经理的核心能力。用户提的永远是解决方案，你要挖的是背后的需求。方法就是前面说的：追问“然后呢”，观察行为，区分痛点和痒点。

8.3 误区三：功能越多用户越满意

功能多不等于体验好。每增加一个功能，就增加一份认知负担、一份维护成本、一份出错概率。用户面对一个功能繁多的产品，第一反应往往是“太复杂了，不想学”。

我的原则是：能用默认值解决的，不要让用户选择；能自动完成的，不要让用户操作；能一步完成的，不要拆成两步。比如注册时能自动获取手机号，就不要让用户手动输入；能根据IP自动选择地区，就不要让用户下拉选择。

8.4 误区四：上线就算完事，不做数据跟踪

用户体验不是一次性的工作，是持续迭代的过程。上线只是开始，之后要跟踪数据、收集反馈、持续优化。核心指标包括：任务完成率、任务完成时间、错误率、用户满意度、净推荐值。

我习惯在产品里埋点跟踪关键路径的转化率。比如注册流程，每个步骤的进入率、完成率、放弃率都要记录。如果某一步放弃率突然升高，说明那里有问题，需要立即排查。数据不会说谎，但数据需要解读——放弃率高可能是流程复杂，也可能是文案不清，还可能是技术故障，要结合用户反馈和可用性测试来定位原因。

8.5 误区五：忽略无障碍和包容性设计

无障碍设计不是“为少数人做的”，而是“为所有人做的”。色盲用户、老年用户、临时受伤的用户（比如一只手受伤）、在嘈杂环境中的用户，都是无障碍设计的受益者。具体做法包括：颜色对比度达标、支持键盘操作、提供文字替代、避免仅靠颜色传达信息。

我见过一个产品用红绿区分“成功”和“失败”，色盲用户完全无法分辨。改成“成功”用绿色+对勾图标，“失败”用红色+叉号图标，问题就解决了。这个改动成本极低，但体验提升很大。

9. 给不同角色的实操建议

9.1 产品经理：从战略层往下推，不要从表现层往上猜

产品经理最容易犯的错误是“看到竞品有个好设计，直接抄过来”。但竞品的设计是基于他们的战略层和结构层，你的战略层和结构层不同，抄过来可能水土不服。

正确的做法是：先明确战略层，再推导范围层，再设计结构层，最后交给设计师做框架层和表现层。每一步都要有依据，不能拍脑袋。战略层的依据是用户研究和业务目标，范围层的依据是战略层和资源约束，结构层的依据是用户心智模型和任务流程。

9.2 设计师：理解业务目标，不要只关注美观

设计师最容易犯的错误是“追求视觉完美，忽略业务目标”。一个页面设计得很漂亮，但用户找不到核心操作按钮，这个设计就是失败的。

设计师要主动了解战略层和范围层：这个页面要解决什么问题？用户的核心任务是什么？成功指标是什么？然后用设计手段服务于业务目标。比如核心操作按钮用主色、大尺寸、显眼位置，次要操作弱化处理。美观是手段，不是目的。

9.3 开发者：理解用户体验，不要只关注功能实现

开发者最容易犯的错误是“功能实现了就行，体验是设计师的事”。但很多体验问题恰恰是技术实现导致的：加载太慢、点击没反馈、错误提示不明确、数据不一致。

开发者要理解性能就是体验。一个页面加载超过3秒，用户就会流失。一个操作没有即时反馈，用户就会重复点击。一个错误提示不明确，用户就会困惑。这些都需要开发者在实现时考虑，而不是等设计师提出来。

9.4 创业者：资源有限时，优先保证战略层和结构层

创业者资源有限，不可能五层都做到完美。我的建议是：战略层和结构层必须做对，框架层和表现层可以先用成熟方案。

战略层做对，保证方向不偏；结构层做对，保证用户能找到路。框架层可以用现成的组件库（如Ant Design、Material Design），表现层可以用模板。等产品验证了核心价值，再投入资源优化框架层和表现层。

最忌讳的是：战略层没想清楚，就花大量资源做漂亮界面。结果上线后发现用户根本不需要这个产品，所有设计投入都白费。

10. 五层模型的边界与延伸

五层模型是一个分析框架，不是施工图纸。它帮你诊断问题出在哪一层，但不告诉你具体怎么改。具体怎么改，需要结合具体业务、用户、资源来判断。

五层模型也不是线性流程。实际工作中，五层是交织的。你可能在画界面（表现层）时发现信息架构（结构层）有问题，需要回头调整。这很正常。关键是知道自己在哪一层、为什么调整。

五层模型还可以延伸到服务设计。用户体验不只是数字产品的体验，还包括线下服务、客服、物流等。比如电商的用户体验包括：浏览商品（数字产品）、下单支付（数字产品）、收货（物流服务）、售后（客服服务）。每一环都影响整体体验。五层模型可以扩展成服务蓝图，把前台体验和后台支撑流程对应起来。

最后分享一个我常用的体验检查清单，每次评审产品时过一遍：

• 战略层：用户需求明确吗？产品目标可量化吗？
• 范围层：功能优先级清晰吗？内容需求定义了吗？
• 结构层：信息架构符合用户心智吗？核心任务流程顺畅吗？
• 框架层：视觉层级清晰吗？导航明确吗？信息展示合理吗？
• 表现层：设计一致吗？动效有意义吗？无障碍考虑了吗？

这个清单不能保证产品成功，但能帮你避免明显的体验陷阱。产品成功最终取决于是否真正解决了用户的问题，体验只是让解决方案更容易被接受、更愿意被使用。