UX 能力模型：你知道自己缺什么吗

小周的七年

你还记得第 1 章里的小周吗？那个刚入行的设计师，客户说"更现代一点"，她花了三周交了三版界面。上线后转化率没有变化。翻看客服工单才发现，三个月来用户投诉集中在一个问题——"转账后不知道到账没有"。

她后来说了一句话："我做的三版界面，没有一版碰过到账反馈。我根本没往那想。"

那时候的小周，处在第一个阶段。

七年后，小周是那家银行的设计负责人。她下面有七个设计师。每个季度的设计评审，她不审批任何一张设计稿。但她会问三个问题：这个问题有没有证据支持、这个用户是不是我们最该优先服务的人、上线后我们看什么指标判断它对不对。这三个问题，她手下的设计师必须在评审前自己回答。回答不了，方案不进入开发。

从小周的第一版界面到现在，中间隔了七年。这七年不是靠"多做项目"填满的——是靠四个关键时刻，每个时刻都在逼她换一种方式思考。

第一个时刻：被数据打脸。 第 1 章那个银行 App 改版上线后，小周第一次认真看客服工单。她在里面泡了两天，整理了三个月的投诉记录。她发现自己的三版设计稿，每一版都改了颜色、间距、图标和布局，但没有一版碰过"转账后有没有到账提示"这个问题。不是客户没告诉过她——客户说了，只是客户说的是"更现代一点"，她听成了"更漂亮一点"。她在复盘会上说了一句话："我在解决一个没有人提给我的问题——怎么让页面更好看。而用户真正的问题，在每一次转账之后的焦虑里。"

这是从初级到中级的第一道坎：不是画图能力，是愿意承认自己一直在解决错误的问题。

第二个时刻：被 CFO 问住。 又过了一年半。小周被派去参加预算评审会，汇报用户研究的年度规划。财务总监只问了一个问题："你去年做的那些研究，有哪个改变了产品的业务指标？"她说了一些数据，但没能连接起来。会议结束后，她找了一个做数据分析的同事，花了两个月把过去一年半的研究项目全部回溯了一遍——哪些研究结论进入了产品决策，哪些留在了报告里，哪些因为研究开始得太晚、方案已经在开发而只能做"事后验证"。结论让她惭愧：三分之二的研究，因为在项目周期中启动太晚，没有真正参与决策。

这是从中级到高级的第二道坎：不是会不会做研究，是能不能让研究在问题定义阶段就参与决策，而不是在方案确定后做验证。

第三个时刻：被竞品教了一课。 第四年，小周负责的 App 改版上线，转化率终于涨了。团队庆祝。三周后，一家竞品上线了几乎相同的功能——只是他们把整个流程缩短了两步。因为竞品的设计团队在评审阶段没有层层汇报，而小周的方案经过了五级审批，每一步都加了一个"保守一点"的妥协。最终上线的版本和她最初方案之间的差距，是五次"这步能不能再简单一点，但也别太冒险"。

这是从高级到负责人的第三道坎：不是设计能力不够，是你的影响力不足以保护方案在组织流程中不被稀释。

第四个时刻：培养出一个不需要她的团队。 第六年，小周升为设计负责人。她开始把过去几年犯过的每一个判断错误，写成了团队的设计原则。不是规则——规则是"按钮用 8px 圆角"。原则是"任何涉及用户资金转移的操作，在确认前必须有三个信号：金额、收款人名称、预计到账时间"。规则会过时，原则可以在不同场景下被团队自己解释和应用。她离开第一周，团队有一个项目上线，设计评审没有等到她回来就自己做了决定。她回来看了，说："这是对的。"

这是负责人的终结标志——你的团队没有你，仍然能做出跟你一样质量的判断。

小周不是一个天才设计师。她的七年就是一条典型的 UX 能力增长弧线。四个阶段之间的差别不是年份，是面对不确定时依赖什么做决定。

你处在什么阶段

UX 能力的层次不是年份决定的，是对不确定性的处理能力决定的。

初级：做对任务。 你面对的问题是"这个页面怎么画"——需求已经明确，你只需要把它变成可用的界面。你的瓶颈是：你画得出来，但说不出为什么这一版比上一版好。你的突破方式不是去学更多工具，是在每次评审前写一句问题陈述。不是"重新设计了登录页体验"，而是"用户在登录页的放弃率是 31%，根因是忘记密码后重置流程无法在手机端完成"。有了这句话，你不再是在画一个好看的登录页，你是在降低 31% 的放弃率。初级阶段的终结标志：你开始为自己的设计找到依据。

中级：做清问题。 你面对的问题是"这个流程怎么走"——需求不明确，你需要把它结构化成可验证的问题。你的瓶颈是：你能找到问题，但说不清优先级。你做了用户研究，发现十二个问题，产品经理让你排序。你凭感觉把最严重的放第一个。产品做了三个迭代，第一个迭代改的那个问题根本不是最影响用户的。你的突破方式是学会用"影响范围 × 严重度 × 证据强度"做排序。影响范围——这个问题影响多少用户、什么使用场景？严重度——是轻微不便、重复劳动、经济损失，还是合规风险？证据强度——来自用户行为数据、多来源交叉验证、还是你个人的推测？三个维度综合打分，优先级自然浮现。中级阶段的终结标志：不是找到最多的问题，是能找到让团队愿意把资源押上去的那一个。

高级：做稳方向。 你面对的问题是"这个问题到底是什么，值不值得做，做了以后怎么知道它是对的"。你的瓶颈是：你说得对，但没有人听。你做了深入的研究，找到了根因，提出了方案。产品经理说"老板要这个功能"，你反驳不了。不是你的研究不对——是你用错了语言。你的突破方式是把用户数据翻译成业务语言。不说"用户的操作路径太复杂"，说"完成一笔报销操作需要 9 步，平均用时 12 分钟，是同行的 3 倍，导致离职员工宁可放弃报销也不做操作——这是我们每年在未报销薪资上损失的金额，保守估算在 X 万到 Y 万之间。"高级阶段的终结标志：你能让没有研究背景的人，在听完你的判断后说"我理解了为什么这个方向是对的"。

负责人：让团队不依赖你。 你面对的问题是"这个团队怎样持续地、可靠地解决这些问题"。你的瓶颈是：团队离开你就不会做判断。你离开一天，设计评审没人能拍板。根因不是你太重要，是你没有留下判断工具。你的突破方式是建立治理机制——不审批每一张设计稿，而是沉淀设计原则。小周的原则是"涉及用户资金转移的操作，确认前必须展示三个信号"。原则比具体判断更持久。你不在的时候，团队拿着原则做决策的质量和你一模一样。负责人阶段的终结标志：你的团队在没有你的情况下，做出了你会做的判断。

六维能力自评：先自评，再读解释

以下六项能力，每一项请你自己打一个分，1-5 分。1 代表"还不太具备"，5 代表"自己能独立交付并指导他人"。

第一维：研究能力。 你能否独立设计一个用户研究方案——确定研究目的、选择方法、招募样本、执行访谈或测试、分析数据并提炼洞察？你的洞察是否让团队改变了原有的假设？

第二维：定义能力。 面对一个模糊问题，你是否能把它结构化——区分用户需求、业务需求、技术约束，写出清晰可验证的问题陈述，识别根因而不是表面症状？

第三维：设计能力。 你是否能用信息架构、交互、界面、内容、原型和视觉方法，把问题陈述转化为可测试的设计方案？你的设计是否考虑了边缘状态、异常流程和错误恢复？

第四维：验证能力。 你是否能判断一个设计方案有没有效——通过可用性测试、专家评审、A/B 实验还是数据分析？你是否会在方案上线后验证预期效果？

第五维：管理与组织能力。 你是否能推动一个项目从研究到上线到复盘的全流程？你是否能在团队目标冲突时找到证据驱动的取舍标准？

第六维：AI 协作与适应能力。 你是否知道 AI 产品的体验设计边界？你是否能设计人机协作流程、AI 输出的反馈机制和信任校准方式？²

打完分了？先别急着看分数高不高。下面告诉你每一个分数意味着什么。

研究能力： - 1→2：能在指导下执行一个已设计好的访谈脚本或测试任务。能按脚本提问，能记录观察。 - 2→3：能独立设计研究方案——匹配方法到研究问题、写访谈提纲或测试脚本、自己招募和访谈、分析数据并写出包含洞察和限制的报告。 - 3→4：能判断什么时候定性比定量重要、什么时候反过来。能识别样本偏差并说明它对结论的影响。能让研究发现改变团队原先的假设。 - 4→5：能设计组织级研究运营机制——让研究洞察跨项目复用、建立用户反馈持续收集渠道、让团队在研究没有启动之前就习惯问"这个假设有没有被验证过"。

定义能力： - 1→2：能从需求文档中识别出关键用户任务。能写出包含用户、情境和阻碍的问题陈述。 - 2→3：能将客户或业务方的一句话需求（"重做首页""加 AI"）翻译为可验证的问题假设。能从多来源证据中寻找模式和冲突。 - 3→4：能在多个候选问题中，用影响范围、严重度、证据强度、业务相关性和实现成本做排序。能区分根因和表面症状。 - 4→5：能在产品战略层面定义问题空间——不只是"这个需求对不对"，而是"今年我们最应该把研究资源押在哪个用户群体上"。组织里的其他人开始带着模糊问题来问你"这个该怎么定义"。

设计能力： - 1→2：能独立完成一个页面或一个流程的信息架构和交互设计。方案在正常路径下可用。 - 2→3：方案覆盖了异常和边界状态——空状态、错误恢复、权限不足、网络断了。设计决策有可说明的依据，不只因为"竞品这么做"。 - 3→4：能从多个方案中选出最优方向，能说清为什么放弃了另外两个。设计方案开始被研发评价为"方案清楚，不需要开发过程中反复确认"。 - 4→5：你的设计方案成为团队其他设计师参考的标准。你不是在设计页面，你是在设计可以被系统化复用的交互模式和内容规则。

验证能力： - 1→2：能执行一次可用性测试——准备任务、观察记录、整理出关键发现。 - 2→3：能根据问题类型选择合适的验证方式——可用性测试、A/B 实验、问卷、数据分析、专家评审。能区分"用户说满意"和"用户确实完成了任务"。 - 3→4：能设计完整的验证计划——预设验证指标和基线、识别混淆变量（同期促销、流量变化、价格调整）、诚实说明归因边界。 - 4→5：能让验证成为团队的默认工作流——需求评审会上同事会习惯性问"上线后我们看什么判断它有效"。

管理与组织能力： - 1→2：能独立管理一个项目的设计交付——从接到需求到评审到交付开发。 - 2→3：能在多个项目之间做取舍，能把模糊的"老板说很重要"翻译为比较框架，让利益相关者在同一张表上看优先级。 - 3→4：能推动跨团队协作——不是靠职位权力，是靠让不同角色的人在同一张证据表上看到各自的约束和共同的目标。 - 4→5：能建立团队级的治理机制——设计原则、评审标准、复盘流程。你的团队在你不在的情况下仍然做出一致质量的判断。

AI 协作与适应能力： - 1→2：能使用 AI 工具辅助日常设计工作——生成方案草稿、分析访谈记录。 - 2→3：能判断 AI 能力边界——知道什么任务适合交给 AI、什么任务必须人类判断。能在 AI 输出面前保持"这需要再确认"的习惯。 - 3→4：能设计人机协作流程——不只是"用一个 AI 工具"，而是设计用户如何理解 AI 的能力边界、何时接手、如何纠错。 - 4→5：能建立 AI 产品的信任校准和伦理审查机制。团队在你的指导下，不会把"AI 说"当成论据的终点。

如果你的研究能力低于 3，你在面对不确定问题时会习惯性地跳过研究直接进入方案。如果你的定义能力低于 3，你可能经常被产品经理或业务方带着跑——你做的方案也许很好，但你解决的问题不一定是正确的。如果你的设计能力低于 3，你的方案可能缺乏说服力——不是不好看，是信息架构不清晰、交互没有考虑边界状态。如果你的验证能力低于 4，你可能做完方案就交付了，不知道它上线后有没有效。

六维自评不是给你打分排名的。它是一个诊断工具——告诉你下一个阶段应该往哪个方向用力。大多数人不需要同时补六个维度。你只需要找到当前的限制因素：是哪一个维度的能力，在持续地阻碍你从当前阶段进入下一个阶段？

跨职能协作：三种关系的真实困境

能力模型的另一个用途是让你理解你在协作关系中缺什么。

和产品经理协作时，定义能力和管理能力最被需要。 产品经理带着需求来找你——你的任务不是直接接住，而是判断：这是一个真实问题还是一个未经验证的方案？有没有证据支持？有没有替代方式？不会定义问题的人，在需求评审会上永远是被动接收方。

举一个真实场景。产品经理周磊在评审会上说："下个版本要加批量导出，两个大客户都要求了，排 P0。"设计师许薇没有立刻答应也没有反对。她问："导出之后，客户在 Excel 里具体做什么？"周磊说他去确认一下。两天后，他带回来的答案是：客户的财务团队每周要从系统里复制数据粘贴到内部报表。六张表——收入、费用、项目成本、人员工时、部门分摊。每周三小时。

许薇说："如果系统可以直接生成这六张报表，每次打开自动汇总呢？不需要导出，不需要复制。"两周后方案交付：不是批量导出，是一键生成周报。客户试用了两周，说"导出功能不用加了"。这个场景在第 7 章出现过。在这里回头看，许薇在这个对话中同时用了两个能力：定义能力——她从"加导出"拆出了"客户需要做报表"这个真实问题；管理能力——她没有直接拒绝 P0 的需求，而是用追问把讨论从"做不做"变成了"为什么做、有没有更好的方式"。

和数据分析师协作时，验证能力和研究能力最被需要。 数据分析师可以给你漏斗，但解读漏斗需要你对用户行为的理解。你说"第二步到第三步的流失最大，因为用户在这里被要求填写一个他们手边没有的信息"——这句话数据说不出来，只有研究能说出来。反过来，研究可以发现用户"不信任费用展示"，但需要数据来帮团队判断这个问题有多大。

和研发工程师协作时，设计能力和定义能力最被需要。 能在交互评审前自己过一遍"空状态、加载中、失败、无权限、过期、冲突、部分完成"的设计师，研发愿意和你合作——因为他不用在开发过程中停下来问你"这个地方如果没数据怎么办"。如果你对技术的边界完全不了解——你不知道这个方案要多大的开发量、你不知道这个交互在技术上有几种实现方式——你很难让研发相信你不是在凭空画图。

从 IC 到 Manager：转型不是升职，是职业切换

"我想转管理"是中国 UX 设计师在五年左右最经常出现的困惑之一。但很多人把 IC 到 Manager 理解成一个线性的"高级之后就管人"，然后发现管理工作和设计工作几乎没有交集。

IC 和 Manager 的本质区别不是职级高低。IC 的价值来自自己的判断质量——你做出的方案是不是对的，你定义的问题是不是准确的。Manager 的价值来自团队的判断质量——你能不能创造一个环境，让团队里每个人持续做出比他们独立工作时更好的判断。

转型信号：你可能适合转管理，如果—— - 你发现自己花在"帮别人想清楚"上的时间，比"自己画清楚"更多。 - 你在评审会上最兴奋的不是你讲自己的方案，是你听完别人的方案后帮他找到他漏掉的假设。 - 你能不依赖职位权力推动协作——研发愿意跟你合作不是因为你是"设计负责人"，是因为你每次都能把模糊问题拆清楚了再带到桌上。 - 你对"培养人"有真实的兴趣——不是享受被人叫"领导"，是享受看到一个人从"我不知道该怎么办"到"我自己判断出来了"的过程。

但如果你不喜欢以下任何一件事，管理可能不适合你： - 你对团队冲突（设计师和产品经理吵起来了、两个设计师在一个方案上意见冲突）的第一反应是"太消耗了"而不是"这需要被结构化的方式解开"。 - 你更享受把一件事亲手做到极致，而不是通过别人的手完成它。 - 你在职级评定、薪酬调整、跨部门资源争取这些事情上感到纯粹的能量消耗——这些是管理工作的日常，不是"偶尔的烦心事"。

不转管理的人如何建立长期竞争力？ IC 不是二等选择。一个十五年经验的 IC 设计师和一个十五年经验的设计管理者，价值体现在不同的地方。IC 长期竞争力的来源是：在某个领域建立了其他人超过你才能替代的判断力。这可能是复杂 B2B 产品的信息架构、可能是金融产品的信任设计、可能是 AI 产品的人机交互模式。关键是"深到不可替代"，而不是"广到什么都碰过"。

AI 时代的技能更新

被 AI 增强的技能：生成备选方案、分析访谈记录。被 AI 缩小差距的技能：视觉执行能力、原型制作。变得更重要的技能：问题定义——AI 可以回答你提的问题，但不能代替你提出正确的问题。证据判断——AI 可以给你数据，但不会判断"这个数据的样本够不够、采集方式有没有偏差"。伦理边界——伦理判断不能外包给 AI，因为承担责任的是你，不是 AI 的输出。

小结

UX 能力模型的实质是一个导航系统——在你发怵的时候告诉你缺的是哪个维度，下一个阶段应该往哪个方向用力。小周的七年从"做界面"走到"让团队不依赖她"，中间的关键转折都不是学了新工具，是换了一种方式思考自己面对的问题。

六维自评不是为了告诉你"你是 3.2 分的设计师"，而是让你在每个项目结束后问自己一句：我的判断有没有依据？我的依据来自哪里？我的哪个维度在限制我进入下一个阶段？下一次我如何更早地发现问题？

初级依赖需求文档，中级依赖方法论，高级依赖证据链和判断力，负责人建立了让团队自己做出高质量判断的系统。

延伸阅读

延伸阅读：NN/g 的 *User Experience Careers* 报告，建立 UX 职业路径层次和能力模型的整体视角。Dreyfus & Dreyfus 的 *Five-Stage Model of Skill Acquisition* 理解从新手到专家背后的认知变化。¹

注释 ¹ NN/g: User Experience Careers。UX 职业路径的层次划分和能力模型定义。 🔗 https://www.nngroup.com/reports/user-experience-careers/

² Dreyfus & Dreyfus: Five-Stage Model of Skill Acquisition。从新手到专家的五阶段技能获取模型，本书简化为四级。 🔗 https://doi.org/10.1016/0004-3702(86)90051-2