用户体验五层框架：从战略层到表现层的产品设计实战指南

1. 为什么用户体验值得被当作产品的一等公民做产品的人大概都经历过这样的场景功能列表全部按时交付技术指标漂亮得能拿去汇报上线之后数据却纹丝不动用户进来转一圈就走了。团队复盘的时候各说各话有人怪推广渠道不行有人怪运营活动没跟上很少有人会承认——问题出在体验本身。《用户体验要素》这本书之所以被反复提起不是因为它讲了多少高深的理论而是它把一件很虚的事情拆成了可以讨论、可以分工、可以验收的五个层次。这个价值太大了。因为在实际项目里“体验不好”这四个字几乎等于没说谁都能说谁都不知道该改哪里。而一旦把体验拆成战略层、范围层、结构层、框架层、表现层讨论就落地了是用户目标没对齐还是功能范围失控还是信息架构混乱还是页面布局让人找不到重点还是视觉呈现让人不信任。这篇内容适合三类人看。第一类是刚接手产品工作的新人需要一套能跟开发、设计、运营对话的共同语言。第二类是做了几年功能但总觉得产品“差一口气”的从业者想搞清楚那口气差在哪里。第三类是非产品岗但需要参与产品决策的人比如技术负责人、市场负责人理解体验要素之后提需求会精准很多。我自己的体会是用户体验最容易被误解成“界面好不好看”。界面当然重要但它只是最上面那一层。真正决定一个产品能不能留住人的往往是下面几层看不见的东西。下面我按自己的理解把这套框架重新拆一遍结合这些年踩过的坑讲清楚每一层到底在解决什么问题、怎么落地、容易在哪里翻车。2. 用户体验五层框架的整体设计与选型逻辑2.1 为什么是五层而不是一堆零散原则市面上讲体验的原则很多什么“简洁”“一致”“反馈及时”听起来都对用起来全乱。因为这些原则是平行的没有优先级也没有先后关系。你没法判断“简洁”和“功能完整”冲突的时候该听谁的。五层框架的高明之处在于它是有依赖关系的。下面一层没想清楚上面一层做得再漂亮也是白费。就像盖楼地基没打好外墙贴再贵的石材也撑不住。这个依赖关系是战略层决定范围层用户要什么才决定我们做什么范围层决定结构层做什么功能才决定这些功能怎么组织结构层决定框架层怎么组织才决定界面怎么摆框架层决定表现层怎么摆才决定视觉怎么呈现我见过太多团队是反着来的。先定视觉风格再往里塞功能最后发现用户根本不买账。这种倒着做的项目返工成本极高因为改一层要动全身。2.2 每一层的核心问题与交付物把五层摊开来看每一层其实都在回答一个核心问题并且有明确的交付物。这个对照关系建议直接抄下来贴在工位上层级核心问题关键交付物主要负责人战略层用户要什么我们要什么用户需求文档、产品目标产品负责人范围层我们做什么不做什么功能规格、需求优先级产品经理结构层内容怎么组织流程怎么走信息架构、交互流程交互设计框架层界面元素怎么摆线框图、导航设计交互/视觉表现层看起来、用起来什么感觉视觉稿、设计规范视觉设计这张表的价值在于责任到层。很多扯皮是因为大家在不同层上吵架。设计师在纠结按钮颜色表现层产品在纠结要不要加功能范围层两个人根本不在一个频道上。把层级说清楚吵架都能吵得有效率。2.3 选这套框架的三个实际理由第一个理由是它逼你从下往上想。大部分产品失败不是因为做得不好而是因为做错了东西。从战略层开始强迫你先回答“用户到底要什么”而不是“我能做什么”。这个顺序的调整能省掉大量无效开发。第二个理由是它让体验变得可验收。体验之所以难管是因为它太主观。但拆成五层之后每一层都有相对客观的验收标准。战略层看用户目标是否覆盖范围层看需求是否闭环结构层看任务路径是否最短框架层看关键操作是否在视线焦点表现层看视觉是否传递了正确的情绪。第三个理由是它适配不同规模的项目。小项目可以五层都做但每层很薄大项目可以每层展开成独立的工作流。框架本身不挑项目大小只挑你有没有认真对待每一层。注意五层不是五个阶段不是做完一层再做下一层。它是五个视角需要反复来回看。实际工作中战略层想清楚了做范围层的时候可能发现战略有问题要回去改。这是正常的不是流程出错。3. 战略层与范围层把“做什么”想清楚再动手3.1 战略层用户目标和产品目标必须同时成立战略层要回答两个问题用户想从我们这里得到什么我们想从用户那里得到什么。这两个问题必须同时有答案而且不能互相打架。我见过一个典型的翻车案例。某工具类产品用户目标是“快速完成某个任务”产品目标是“让用户尽可能久地停留在产品里”。这两个目标直接冲突。结果就是产品不断加功能、加引导、加弹窗用户越来越烦最后流失。问题不在执行在战略层就错了。用户目标怎么挖不要问用户“你想要什么功能”要问“你在什么场景下想解决什么问题”。功能是解决方案场景和问题才是需求。我常用的方法是让用户描述最近一次做这件事的完整过程从触发到结束中间卡在哪、绕了哪些路这些卡点和绕路就是机会。产品目标怎么定要具体到可以衡量。不要说“提升用户体验”要说“把新用户完成核心任务的时间从5分钟降到2分钟”。前者是口号后者是目标。目标越具体后面几层的决策越有依据。3.2 范围层功能规格和需求优先级范围层的核心工作是把战略翻译成功能并且决定先做哪些。这里最容易犯的错是“全都要”。需求列表越拉越长每个都说很重要最后做出来一个臃肿的产品。我的做法是给每个需求打两个分用户价值分和实现成本分。用户价值分看它解决了多痛的问题、覆盖了多少用户实现成本分看开发工作量、技术风险、维护成本。两个分一交叉优先级就出来了高价值低成本立刻做高价值高成本规划做拆阶段低价值低成本有空做或者不做低价值高成本坚决不做这个矩阵看起来简单但真正用起来会发现大部分争议需求都落在“低价值高成本”那一格只是提需求的人不愿意承认。这时候需要用数据说话而不是靠嗓门大小。功能规格怎么写要写到开发看完知道怎么做、测试看完知道怎么验。我习惯用“场景-行为-结果”的格式在什么场景下用户做了什么操作系统应该给出什么结果。这个格式能逼你把边界情况想清楚比如网络断了怎么办、数据为空怎么办、权限不够怎么办。实操心得范围层一定要有“不做清单”。明确写下这次不做什么以及为什么不做。这个清单在项目后期会救你的命因为总有人会临时加需求你可以指着清单说“这个我们讨论过这次不做”。3.3 两层之间的衔接需求追溯战略层和范围层之间要有一条清晰的追溯链。每一个功能都能追溯到某个用户目标每一个用户目标都能追溯到某个战略判断。这条链断了就会出现“这个功能是谁要的”“不知道反正就做了”的情况。我习惯用一个简单的表格来维护这条链用户目标对应功能优先级验收标准快速找到所需内容搜索功能高搜索到结果的平均时间3秒不迷路面包屑导航中任意页面可一键回到上级这个表格在评审的时候特别有用因为任何人提新需求都可以问一句“它对应哪个用户目标”。对不上的就要重新审视。4. 结构层与框架层让用户不迷路、不费劲4.1 结构层信息架构和交互流程结构层解决的是“东西怎么放、路怎么走”。信息架构是把内容分类组织交互流程是把任务拆成步骤。这两件事做不好用户就会迷路或者绕路。信息架构的核心原则是符合用户的分类习惯而不是公司的组织架构。我见过太多产品按部门来分栏目用户根本不知道那个部门是干嘛的。正确的做法是做卡片分类让用户自己把内容分组然后按用户的分组来设计导航。交互流程的核心原则是最短路径。用户完成一个任务需要几步每一步是不是必须的能不能合并能不能跳过。我常用的方法是画流程图然后把每个节点问三遍“这一步能不能去掉”。通常能去掉三分之一。这里有个容易忽略的点异常流程和正常流程一样重要。正常流程用户走一遍就记住了异常流程才是体验的分水岭。比如提交表单失败是清空所有内容让用户重填还是保留内容只提示错误项这个细节决定了用户是骂一句继续用还是直接关掉。4.2 框架层界面布局和导航设计框架层是把结构层的东西摆到屏幕上。核心问题是什么放在哪里什么先被看到。界面布局的第一原则是视觉层级匹配任务优先级。用户最常做的操作、最重要的信息应该在最显眼的位置。这个道理谁都懂但实际做的时候经常被“老板觉得这个重要”“设计觉得那样好看”带偏。我的做法是列出页面的三个核心任务然后检查这三个任务的操作入口是不是在首屏、是不是在视线自然落点。如果核心任务需要滚动才能看到或者需要思考才能找到布局就有问题。导航设计的第一原则是让用户知道自己在哪里、能去哪里、怎么回去。这三个问题回答不了用户就没有安全感。导航不是越多越好而是越清晰越好。我见过一个产品顶部导航、侧边导航、底部导航三套并存用户完全不知道该看哪个。后来砍到只剩一套使用率反而上去了。注意框架层不要过早进入视觉细节。线框图阶段就用灰块和占位文字逼自己关注结构和层级而不是颜色和字体。一旦开始调颜色注意力就被带偏了。4.3 两层之间的衔接从流程到界面结构层和框架层的衔接本质上是把抽象的流程映射到具体的界面。一个任务流程可能跨多个页面每个页面承担流程中的一段。映射的时候要保证用户在任何一页都知道自己在流程的哪一步以及下一步该做什么。我常用的检查方法是走查拿一个真实的任务从入口开始一步步走每一步都问“用户现在知道该干嘛吗”。走查的时候不要用设计稿要用可点击的原型因为静态稿看不出流程的连贯性。5. 表现层视觉不是装饰是信息传递5.1 视觉设计的三重任务表现层经常被误解成“让界面好看”。好看当然重要但视觉设计真正要完成三重任务第一重是传递层级。通过大小、颜色、间距告诉用户什么重要、什么次要、什么是一组。用户扫一眼就能抓住重点不需要逐字阅读。第二重是传递情绪。颜色、字体、圆角、阴影这些元素组合起来会传递出专业、活泼、可靠、亲切等不同的情绪。情绪要和产品定位匹配。一个理财产品的视觉如果太活泼用户会不放心一个儿童产品的视觉如果太严肃家长会觉得不好玩。第三重是传递一致性。同一个产品里相同功能的元素应该长得一样相同层级的元素应该有一致的处理方式。一致性建立信任用户不需要重新学习。5.2 视觉规范的建立与维护视觉规范不是设计团队内部的自嗨它是跨团队协作的基础。开发需要知道间距用多少、颜色用哪个值、字号有哪几档。没有规范每个人凭感觉来最后就是一团乱。我建议规范从最小可用开始不要一上来就搞几百页。先定颜色、字号、间距、圆角这几个基础项然后在项目里用起来遇到不够再加。规范是长出来的不是一次写出来的。规范建立之后维护比建立更重要。要有一个人或一个机制来审核新增的视觉元素防止规范被慢慢侵蚀。我见过太多产品规范文档写得很漂亮但实际界面里全是规范外的颜色和字号规范形同虚设。5.3 表现层的验收标准表现层怎么验收不能靠“我觉得好看”。我常用的标准是把界面缩小到50%还能不能看出层级把界面转成灰度还能不能区分主次把界面给一个没用过的人看5秒问他记住了什么这三个测试能过滤掉大部分“好看但没用”的设计。视觉的第一目标是传递信息第二目标才是美感。顺序反了就会做出漂亮但难用的东西。6. 常见问题与排查技巧实录6.1 五层框架落地时的典型翻车场景场景一战略层缺失直接跳到范围层。表现是需求列表很长但说不清为什么做。排查方法是问每个需求的来源如果答案是“竞品有”“老板要”“用户提过”就要警惕。竞品有不一定对老板要不一定准用户提过不一定代表普遍需求。场景二范围层失控功能越加越多。表现是项目延期、质量下降、用户抱怨复杂。排查方法是看需求变更记录如果变更频繁且没有明确的取舍标准就是范围层没管住。解法是回到战略层重新对齐目标然后砍需求。场景三结构层混乱用户找不到东西。表现是客服收到大量“XX功能在哪里”的咨询。排查方法是做任务测试让用户找几个核心功能看成功率。如果成功率低就是信息架构有问题。场景四框架层和表现层脱节。表现是设计稿很漂亮但开发实现出来完全不是那个感觉。排查方法是看设计稿有没有标注清楚间距、字号、颜色值。如果全靠开发目测必然走样。6.2 问题排查速查表现象可能的问题层排查动作解决方向用户进来就走战略层访谈流失用户重新对齐用户目标功能很多但没人用范围层看功能使用率砍掉低价值功能用户找不到功能结构层做任务测试重做信息架构操作步骤太长结构层/框架层走查核心流程合并或删除步骤界面看起来乱框架层/表现层灰度测试、缩小测试重建视觉层级开发实现走样表现层检查设计标注补全规范并审核6.3 几个反直觉的实操技巧技巧一先做最难的流程再做最简单的。大部分团队习惯先做简单功能找感觉但简单功能掩盖不了结构问题。先做最复杂的流程能把结构层和框架层的问题提前暴露出来。技巧二让开发参与结构层讨论。开发对技术边界最清楚他们在结构层就能指出哪些流程实现成本高、哪些有技术风险。等到框架层再拉进来返工成本就大了。技巧三用真实内容做设计不要用占位文字。占位文字的长度和真实内容往往差很多用占位文字做的设计换成真实内容就崩了。尽早用真实内容能提前发现布局问题。技巧四把用户反馈按五层分类。用户说“找不到”可能是结构层说“太乱”可能是框架层说“不好看”可能是表现层。分类之后就知道该找谁改而不是所有人一起瞎忙。实操心得五层框架最大的价值不是让你按部就班而是让你在吵架的时候有个共同的坐标系。当有人说“体验不好”你可以问“哪一层不好”讨论立刻从情绪变成问题。7. 我个人的一些体会这套框架我用了很多年最大的感受是它不能保证你做出成功的产品但能帮你避免做出明显错误的产品。成功的产品有很多偶然因素但失败的产品往往有共同的模式而五层框架能识别出大部分模式。另一个体会是五层里最难的不是上面几层而是战略层。因为战略层要面对的是“我们到底为谁解决什么问题”这种根本性问题而大部分团队不愿意花时间想这个更愿意赶紧动手做功能。但恰恰是战略层的偷懒导致了后面所有的返工。最后分享一个小技巧每次项目复盘的时候不要只复盘“做了什么”要复盘“哪一层想错了”。把错误归到具体的层下次就能在那个层上多花时间。这个习惯坚持几次团队的判断力会明显提升。