用途
User Experience 是一个评审视角（lens），用于审查任何面向用户的改动。它可以用在两个时机：在确定某个方案之前，以及在评判一个已经做出来的体验时。它的目的是让工作始终锚定在“用户究竟想完成什么”上，而不是停留在界面细节的调整。
该视角要求以用户的目标为先导，而不是先列出一串表面修补。如果一份评审清单里全是“把这个标签改一下”“把那块挪一挪”这类小修正，通常说明底层的流程从未被真正审视过。正确的顺序是从意图出发，逐步下探到细节。
范围与边界
该视角只覆盖两点：改动是否服务于用户，以及用户走完这条路径是否连贯。
视觉与美学层面的工艺——排版、配色、间距、动效打磨——属于另一个独立关注点，不在本视角的范围内。
三个工作阶段
Understanding（理解）
在塑造方案之前，先确认用户真正需要什么。
- 说清楚用户是谁，以及他们来这里要完成的任务。
- 把用户提出的表面请求与请求背后的目标区分开，并解决那个目标。
- 关于用户需求的判断要有证据支撑（观察到的行为、反复出现的反馈、真实使用情况）。如果一个需求只是被假定而非已知，需要明确标注出来。
Bridging（桥接）
把需求转化为合适的方案，而不是转化为第一个想到的方案。
- 检查方案是否解决了目标，而不仅仅是解决了可见的症状。
- 权衡该改动是否新增了用户必须学习的步骤、界面或概念，以及这份成本是否值得。
- 检查改动新增的提示或通知，是否在重复某个已有界面已经告诉用户的信息；如果是，优先依赖那个已有界面。
- 优先选择替用户减少工作的路径，而不是增加配置或选项的路径。
- 警惕以牺牲用户为代价来解决构建者自身的便利问题。
Flowing（走查流程）
端到端地追踪用户走过的路径。
- 跟随完整旅程：用户如何到达、改动本身、以及之后会发生什么。
- 在软件可以运行时，实际走一遍非顺畅路径：空状态、预置默认值、错误、中断、首次使用与回访使用。任何仅凭源码判断的情况都应被标注出来。
- 确认用户始终知道刚刚发生了什么、接下来该做什么。
- 暴露摩擦点：冗余步骤、死胡同，以及需要用户在脑中记住状态的环节。
适用场景
适用于提交方案前的预判，以及成品体验的评判，尤其适合面向用户的改动评审，帮助团队从用户目标而非表面修补入手。
限制与暂未提供的信息
该资料未提供具体的安装命令、支持的平台、调用方式或与具体工具链的集成方式，这些内容暂未提供。