体验治理与体验成熟度模型
很多组织的体验质量，靠的是几个人的责任心。
1. 导读
某个资深设计师会主动检查空状态，某个产品经理会在上线前多走一遍流程，某个前端工程师会坚持组件一致性，某个研究员会提醒团队不要忽略新用户。只要这些人在，产品还能维持基本质量；一旦他们离职、转岗、被别的项目占用，体验问题就开始反复出现。1
这就是为什么需要体验治理。
体验治理不是给设计加更多审批，也不是让每个按钮都等委员会批准。它要解决的问题是：体验质量如何不依赖个别人的记忆、热情和加班。比如费用说明能不能晚到支付最后一步才出现？删除客户数据前要不要二次确认？设计系统组件谁能改？可访问性问题上线前谁有权拦下？AI 给出高风险建议时，谁负责透明度和人工接管？
体验管理处理日常运营问题，体验治理负责权责、标准和流程。好的治理不是把所有动作管死，而是让团队在高压时也知道谁该做什么。
体验成熟度模型不是给组织贴"先进"或"落后"的标签，而是帮团队判断下一步该补哪块短板：是没人做研究，还是研究进不了路线图？是组件库没人维护，还是高风险流程没有评审？是领导支持停在口号里，还是指标只会制造压力？
体验治理和成熟度让你理解为什么很多体验问题不是设计稿本身的问题，而是组织机制的问题；也帮助你判断一家企业是否具备可持续的体验能力，而不是只在单个项目中做出好作品。
2. 核心问题
核心问题是：如何让体验质量不依赖个别人的努力？
这句话直指组织中的一个常见现象：体验质量在不同团队之间波动很大。同一个公司，A 产品有清晰的信息架构、稳定组件、可访问性检查和用户测试；B 产品却每次都重新画按钮、错误提示随意写、上线后才发现用户不会操作。管理者以为这是"设计师水平不同"，但更深层原因往往是治理机制不同。
体验治理要解决三类问题。
第一类是质量问题。怎样保证关键流程、组件、文案、状态、可访问性、错误恢复和风险提示达到最低质量？如果没有最低标准，体验会随着项目压力和个人判断上下浮动。
第二类是效率问题。多个团队重复做同样组件、重复写同样规则、重复争论同样交互，会消耗大量时间。治理通过设计系统、评审机制、贡献流程和知识库减少重复劳动。
第三类是一致性问题。用户不会关心企业内部有多少团队，他们只会感受到同一个产品或品牌是否连贯。一个页面叫"成员"，另一个页面叫"用户"，一个流程支持撤销，另一个流程不支持，用户会觉得系统像拼起来的。2
治理还要回答权责问题。谁负责体验原则？谁维护设计系统？谁决定例外情况？谁检查高风险流程？谁能要求项目补做用户验证？没有权责，体验质量会变成"大家都觉得重要，但没人真正负责"。
3. 关键概念与定义
体验治理，是组织为了保障体验质量、效率、一致性和风险控制而建立的权责、流程、标准、评审、资产和能力建设机制。
体验治理的重点不是控制每个细节，而是让关键体验决策有规则可依。它可以包括体验原则、设计系统、内容规范、可访问性规范、研究准入、设计评审、RACI、指标机制、贡献流程、例外处理、成熟度评估和能力建设路线图。
体验治理不是给设计加更多审批，也不是试图管控每个设计细节。它的本质，是把那些反复引发返工和争议的关键决策点，提前用规则固定下来，让团队在高压下仍然知道该做什么、不该省略什么。
RACI 用 Responsible、Accountable、Consulted、Informed 区分执行者、最终负责者、被咨询者和被告知者。它适合处理跨部门体验问题。比如支付流程要新增"服务费说明"，产品负责提出方案，设计负责把费用影响写进用户决策点，法务确认表述边界，研发实现前端和接口，客服、运营、财务需要知道上线后如何解释。
体验标准是组织对体验质量的最低要求和可复用规则。它不只是颜色、字体和间距，也包括表单出错时怎么解释、数据表格如何处理空值和异常值、高风险操作如何确认和撤回、服务承诺如何前后一致，以及 AI 何时必须说明不确定性。3
设计评审机制是组织在关键节点检查体验质量的流程。它可以包括方案评审、可用性评审、可访问性评审、内容评审、设计系统评审和上线前风险评审。好的评审机制关注用户任务和风险，而不是个人审美。
体验成熟度是组织希望和有能力持续交付用户中心体验的程度。NN/g 的 UX 成熟度模型将组织成熟度分为六个阶段，并从战略、文化、流程和结果等因素观察组织能力。 成熟度模型的价值不是排名，而是诊断。
能力建设路线图是从成熟度评估出发，为组织制定的下一步能力提升计划。比如先建立研究流程，还是先建立设计系统；先补可访问性能力，还是先建立评审机制；先做管理层共识，还是先补一线团队方法。
体验治理不等于设计系统。设计系统是治理的重要工具，但不是治理本身。一个公司有组件库，不代表有治理。如果组件无人维护，贡献流程不清，例外情况没人判断，项目团队仍然各自修改组件，那么设计系统只是资产，不是治理机制。
4. 概念边界与相近概念区别 体验治理不等于审批流程。治理常被误解为“多一层审批”。真正的治理应该减少重复争论，而不是制造等待。比如明确按钮命名、表单错误、空状态、可访问性、数据表格、确认弹窗等规则，可以让项目更快推进；只有高风险、跨品牌、跨系统、强合规的事项才需要更严格评审。 体验成熟度不等于组织好坏。成熟度模型是诊断工具，不是道德评价。低成熟度组织不一定不重视用户，可能只是缺少人员、预算、流程或领导支持；高成熟度组织也可能因为业务压力、组织重组或指标偏差而退步。NN/g 也提醒，组织成熟度涉及流程、设计、研究、领导支持和长期性等多个方面。4
体验治理也不等于设计部门管理。体验质量受产品、研发、运营、客服、销售、法务、数据、安全和品牌共同影响。设计部门可以牵头，但不能独自完成治理。比如 AI 产品要提示"这只是建议，不是最终结论"，文案只是表面；背后还要看模型能做什么、数据从哪里来、哪些场景必须人工确认、政策和合规如何要求、产品负责人愿意承担什么责任。
5. 方法、流程或框架
建立体验治理，可以从五件事开始。
第一，定义治理对象。不要一开始就治理一切。先识别最容易反复出错的地方：新客户上手是不是每条业务线都不一样，权限角色是不是各叫各的名字，错误提示是不是只写"提交失败"。再看支付费用是不是总在最后才露出，AI 建议是不是没有说明依据和人工确认路径。
第二，建立体验原则和标准。原则负责方向，标准负责执行。比如"高风险操作必须可理解、可确认、可恢复"是原则；"删除数据前必须说明影响范围、提供二次确认、说明恢复方式或不可恢复后果"就是标准。原则太抽象会无法执行，标准太碎又会变成文档负担。两者要配合。
第三，设计权责机制。治理最容易失败在"谁说了算"。RACI 可以帮助明确责任。设计系统组件由谁维护？业务线能否自行改组件？内容术语谁审批？可访问性不达标能否上线？AI 高风险场景谁评估？没有权责，标准会在项目压力下被绕过。
第四，设置评审和例外机制。评审不应覆盖所有细节，而应按风险分层。低风险页面可以自查；关键旅程需要设计评审；高风险流程需要产品、设计、研发、法务、数据或安全共同评审；设计系统例外需要说明理由、影响范围和后续处理。治理的成熟之处，不在于没有例外，而在于例外也有规则。5
第五，持续评估成熟度。成熟度评估要看多个维度：战略支持、领导参与、用户研究流程、设计流程、设计系统、可访问性、指标、跨部门协作、人才能力、知识管理、文化和工具。评估结果不应只生成分数，而要形成能力建设路线图。
ISO 9241-210 把人本设计活动放在交互系统生命周期中理解，强调使用情境、用户需求、设计方案和评价之间的循环。 对治理来说，用户中心不应只是项目方法，而应进入组织流程和质量机制。
6. 实际工作场景
一个常见场景是多团队产品体验不一致。比如一家 SaaS 公司有 CRM、报表、权限、设置、移动端、开放平台多个团队。每个团队都觉得自己有特殊场景，于是按钮样式、筛选器、空状态、错误提示、权限文案都不一样。用户在 CRM 中学会了一个操作方式，到了报表模块又要重新学习。治理不是要求所有页面长得一模一样，而是建立共享模式：相同任务用相同规则，特殊场景说明特殊原因。
另一个场景是设计系统失效。公司已经有组件库，但业务团队觉得组件"不够灵活"，前端觉得接入麻烦，设计师觉得组件不适配新场景，最后大家又开始复制旧页面。治理要处理的不是"有没有组件"，而是谁能提交新变体、多久评审一次、旧组件如何废弃、例外能不能回收、采用情况和质量问题谁看。
第三个场景是高风险流程缺少统一评审。比如删除数据、转账、签署合同、开通权限、提交医疗信息、AI 自动生成建议。普通流程只要好用就行，高风险流程还要清楚、可解释、可恢复、可审计。没有治理时，这些流程可能由各项目自己判断；有治理时，组织会建立风险分级和评审机制。6
第四个场景是可访问性总在最后被发现。很多团队在上线前才检查对比度、键盘可达、屏幕阅读器语义，结果发现弹窗无法聚焦、错误提示读不出来、表格在键盘路径里绕远路。治理的做法是让组件先带着可访问性要求出生，并把检查前移到设计评审和开发验收，而不是临上线才补一张清单。
AI 产品让治理更重要。ISO/IEC 42001 提供了 AI 管理体系的标准语境，可用于理解组织层面如何管理 AI 系统风险。 对 UX 来说，AI 产品中的透明度、错误恢复、人工接管、用户控制和高风险场景不能只靠设计师临时判断，而要进入组织治理机制。
7. 案例
U.S. Web Design System 是体验治理在公共部门的代表性案例。USWDS 为美国联邦政府网站提供设计系统、组件、模板和可访问性相关资料。 这类公共部门资料提醒我们：治理不是把页面管得更僵，而是让不同团队在一致性、可访问性和复用上有共同底座。
8. 数据、指标或衡量方式
体验治理的指标主要分为四类：质量、效率、一致性和能力。
质量指标可以贴着真实事故看：严重可用性问题有没有复发，可访问性检查是否通过，错误率是否下降，高风险流程是否被评审，上线后是否又出现体验缺陷。比如一个支付流程每次上线后都引发"为什么多收了服务费"的咨询，治理指标就不应只数开过几次评审会，而要看费用说明是否已经进入支付标准、组件模板和上线检查。
效率指标包括设计返工率、组件复用率、组件采用率、设计系统贡献周期、评审等待时间、从问题发现到修复的周期。效率指标要小心解释。评审等待时间越短不一定越好，如果关键风险没看见，短只是快；组件采用率高也不一定代表体验好，如果组件本身不适配场景，采用越高问题越普遍。7
一致性指标包括核心组件使用一致性、术语一致性、内容模式覆盖率、跨产品导航一致性、品牌和可访问性规范覆盖率。对于多产品公司，一致性不是为了整齐，而是为了降低用户学习成本。
能力指标包括 UX 成熟度评估结果、研究覆盖率、设计系统维护能力、可访问性能力、跨部门协作成熟度、评审机制覆盖率、设计人员与产品团队配比、UX 培训覆盖率、洞察复用率。NN/g 成熟度模型中的战略、文化、流程和结果等因素，可以作为能力诊断的参考。
治理指标不能只拿来考核。它们更适合用来发现能力缺口。比如设计系统采用率低，表面看是团队不守规范；继续追下去，可能是表格组件缺少批量操作，文档没有异常状态示例，贡献流程要等两周，或某类企业后台场景根本没有覆盖。成熟治理会问"为什么不用"，而不是只问"谁没用"。
9. 常见误区
第一个误区，是把治理等同于管控。治理不是为了让设计团队失去判断，而是让关键问题有共同规则。好的治理减少争论，差的治理制造等待。
第二个误区，是有设计系统就以为完成治理。组件库只是开始。没有贡献流程、版本管理、使用反馈、例外机制和采用指标，设计系统很容易变成过期资产。
第三个误区，是成熟度评估只看分数。成熟度模型的价值在于诊断能力缺口。如果只追求"升到第几级"，团队可能会包装流程，而不是改善真实能力。
第四个误区，是所有项目用同一套评审。低风险项目被过度评审会拖慢速度，高风险项目被轻量处理会放大风险。治理必须分层。
第五个误区，是只治理设计团队。体验质量受产品策略、技术实现、服务流程、内容、运营和客服影响。设计团队可以牵头，但不能独自承担全部体验治理。
第六个误区，是把标准写得过细。过细的标准会让团队失去判断，也会快速过时。标准应覆盖高频、高风险、高复用问题，低频特殊场景留给例外机制。
10. 小结
体验治理的核心，是让体验质量不再依赖个别人的努力。它通过原则、标准、权责、评审、设计系统、例外机制和成熟度评估，让组织更稳定地交付体验质量。
治理不是更多审批，而是更清楚的规则。没有治理，团队会反复争论同样问题；过度治理，团队会陷入等待和形式主义。成熟治理要在质量、效率、一致性和风险之间找到平衡。
体验成熟度模型可以帮助组织诊断能力状态，但它不是绩效排名，也不能直接证明商业成效。它最有价值的用途，是把"我们体验能力不足"转化为"下一步先补什么能力"。
设计系统是体验治理最常见、最重要的工具之一，但它只有在治理机制支持下，才会从组件库变成组织级体验资产。
11. 延伸阅读
NN/g 的 The 6 Levels of UX Maturity 适合理解组织 UX 成熟度阶段、影响因素和评估方法。阅读时应把它当作诊断框架，而不是组织排名工具。
ISO 9241-210 可作为人本设计进入组织流程和生命周期管理的基础标准。正式写作时需核对原文授权表述。
U.S. Web Design System 展示了可访问性、一致性和跨机构复用如何进入设计系统的治理结构，是体验治理在公共部门的代表性案例。
ISO/IEC 42001 适合 AI 产品相关组织了解 AI 管理体系语境。它不是 UX 方法，但可提示 AI 产品体验治理需要组织层面风险管理。
注释 1 NN/g, The 6 Levels of UX Maturity。🔗 https://www.nngroup.com/articles/ux-maturity-model/
2 ISO 9241-210。🔗 https://www.iso.org/standard/77520.html
3 GitLab, Measuring the value of our design system。🔗 https://handbook.gitlab.com/handbook/product/ux/how-we-work/measuring-the-value-of-our-design-system/
4 ISO/IEC 42001:2023 Artificial intelligence management system。不是 UX 方法，不提供具体产品合规建议。 🔗 https://www.iso.org/standard/81230.html
5 GOV.UK Design System。🔗 https://design-system.service.gov.uk/
6 U.S. Web Design System。🔗 https://designsystem.digital.gov/
7 GitLab UX Scorecards。🔗 https://handbook.gitlab.com/handbook/product/ux/ux-scorecards/