UX、UI、CX 与相近概念的区别
团队最高的成本，不是工具订阅费，而是每个人嘴里说的是同一个词，心里指的是完全不同的东西。
一个常见场景：产品经理说"我们要提升用户体验"，UI 设计师听完打开 Figma 改按钮圆角和间距。UX 设计师说"我先做一轮用户访谈"。服务设计师说"那我先画一张旅程地图"。客服负责人说"我把投诉报表整理一下"。四个人都动起来了，做的东西合不到一起。三个月后复盘，每人都觉得自己做了该做的事，但用户反馈的同一个问题——"预约后不知道下一步怎么办"——没有变好。1
这就是概念混用的代价。各说各话、互相推诿、重复劳动，最后变成组织成本。不是谁做错了什么，是团队没有建立一套共享的判断语言。
概念区分
在进入角色之前，先把七个概念说清楚。不需要背定义，只需要理解每个概念的作用范围。
UX（用户体验） 设计的是用户为了完成目标而经历的一整套互动过程。包括用户操作前的预判、操作中的反馈、操作后的结果和情绪。它不是"这个页面好不好看"，而是"用户能不能走完这段路，走得顺不顺，出错了有没有人管"。
UI（用户界面） 是用户看见和操作的那层界面——按钮、表单、图标、颜色、排版、控件状态。UI 决定用户能否看清楚、读明白、找到下一步。但 UI 不决定"用户为什么来"、"下一步合不合理"、"点错了怎么办"。
CX（客户体验） 范围更大。它不是只看某个产品好不好用，而是看客户从知道这个品牌、比较方案、购买、使用、求助、续费、投诉到离开的整段关系。一个 App 很好用，但客服态度差、退费规则苛刻，客户体验仍然糟糕。
服务设计 关心的是"用户看见的前台"和"用户看不见的后台"怎么串起来。用户在 App 上预约了医生，到了医院发现系统里没有记录——这就是前台和后台断开了。服务设计师的任务就是让这段衔接不靠运气。
产品设计 关心的是做什么、为谁做、做到什么程度、如何与业务目标对齐。它不只看体验，还要看技术可行性和商业模式能不能转起来。
HCI（人机交互） 是 UX 的地基。它研究人如何与计算系统互动——认知负荷、输入方式、交互范式、人机信任。HCI 是学术研究的土壤，UX 则是面向真实产品的施工方式。
用户研究 是 UX 的证据来源。它不等同于"问用户想要什么"，而是用定性和定量方法理解用户的行为、需求、情境和问题。没有研究，设计就是揣测。
导读
让六个人各自回答"我为谁设计"，第一反应可能完全不同：
UI 设计师关注用户的眼睛和手指操作。 UX 设计师关注用户的任务和情绪。 CX 负责人关注客户与公司的长期关系。 服务设计师关注前台触点与后台系统的衔接。 产品经理关注用户价值、业务目标和实现成本的三角取舍。 用户研究员关注让团队不靠猜测做决策。
没有谁比谁高级。它们是分工，不是等级。项目出问题时，往往不是因为某个角色不够努力，而是因为需要 UX 解决的问题被扔给了 UI，需要服务设计解决的问题被当成了界面优化。
方法框架
换个角度：如果不做这件事，项目会出什么问题？
UI 不到位时，用户看不清楚入口、按钮状态不一致、控件不可操作。
UX 不到位时，用户任务走不通、频繁卡住、重要功能没人用、每一步都在担心出错。
CX 不到位时，用户在每个触点都觉得自己在和一家"说法不一致的公司"打交道。
服务设计不到位时，前台承诺的服务后台做不到，用户在 App 上看到的和在现场经历的是两个系统。
产品设计不到位时，团队做了一堆功能没人用，资源全浪费在"我觉得用户需要"的猜测上。
用户研究不到位时，团队每次开会都在"我听说用户想要这个"和"我觉得用户不会这样"之间争论，谁也说服不了谁。
这套反向定义的好处是，团队不用吵"这个岗位的边界在哪里"，直接问"如果这个问题没人处理，谁会受影响"。风险承担者就是天然的职责边界。
顺着这个思路，对比第 1 章的机场比喻：UI 是登机牌是否清楚易读，UX 是旅客能不能从值机顺利走到登机口，CX 是旅客和航空公司的每次接触是否一致，服务设计是值机系统、安检流程、行李系统、登机口调度和延误通知之间有没有串起来。登机牌再漂亮，旅客在三号登机口等了两个小时却没有延误通知——整个体验还是崩了。
实际场景
一个真实问题能把这些概念一次性拉开。企业采购系统的供应商准入申请。采购员要填一堆资料，上传文件，等待审批。
UI 设计师看到的问题是：页面排版乱了，按钮颜色不一致，下拉菜单太长。改完视觉，页面确实好看了。
但用户仍然反复提交失败——因为不知道选哪种供应商类型，不知道上传文件的命名规则，被驳回后只看到"资料不完整"的提示，审批人和采购员看到的状态不一致。
这时才轮到 UX 设计师：用户任务到底是什么？上传前的理解有没有断点？驳回后的反馈够不够？客服让用户问业务部门，业务部门又让用户回去看系统——这不是界面问题，这是服务流程问题，需要服务设计师把 App、客服、审批系统和业务规则串起来。如果团队还想知道"被驳回的用户是第一周最多还是全程平均"，需要用户研究员去挖行为数据。
案例
在线医疗平台"预约后取消率高"。四个人坐在会议室里，说的是一件事，但每个人描述的方式完全不同。
产品经理先说："预约规则有问题。用户选了时段但系统不锁号，到现场发现号源被占了，当然取消。"
UI 设计师跟着说："预约页面的信息层级确实混乱。医生简介太短，费用说明藏在二级页面，用户不确定要不要选这个医生，就关了。"
服务设计师接话："问题不只是页面。短信提醒的内容和现场签到系统对不上。用户收到短信说'请到三楼分诊台'，到了现场说'你这个预约不在我们这个院区'。用户不取消才怪。"
客户成功经理最后开口，语气已经带着疲惫："客服接到的投诉里最多的是'取消后不知道退不退款'和'取消了但系统还显示已预约'。用户不是不想预约，是不敢再约了。"
四个人说的都对。但没有一个人说全。取消率高不是一个单一问题，它是预约规则、界面信息、前后台服务一致性和事后反馈四个问题的集合。如果团队只让一个人去改，他一定会漏掉另外三块。
从概念到衡量
区分概念不只为了理清话语，还为了选对衡量方式。
问题落在界面层时，看界面一致性、可访问性通过率、控件状态完整性和视觉层级。一个按钮颜色不一致——不是战略问题，是设计系统和 UI 规范问题。
问题落在用户体验层时，看任务成功率、错误率、完成时间、首次成功率和 SUS（系统可用性量表）。 用户能不能完成转账、能不能提交报销、能不能找到订单状态——这些更靠近 UX。
问题落在客户关系层时，看 NPS（推荐意愿）、CSAT（满意度）、CES（费力程度）、投诉率、留存和复购。但这些离具体界面远，归因也更复杂。
问题落在服务交付层时，看一次解决率、跨部门转交流畅度、等待时间和工单重复率。
问题落在产品决策层时，看激活率、功能采用率和业务目标达成。
需要研究判断的问题，不看"做了几次访谈"，看研究问题是否清楚、样本是否匹配、结论是否有证据支撑。
指标像不同焦距的镜头。NPS 下降时，你要继续看投诉内容、任务测试和客服工单，才知道是预约页、费用规则、短信提醒还是现场签到处出了问题。
话说回来，概念清楚不是为了让组织架构更完整，而是为了让问题能被对应的角色接住。UI、UX、CX、服务设计、产品设计和用户研究之所以要分清，不是因为它们天生应该被切碎，而是因为每个层面的问题需要不同的视角、证据和解决方式。团队协作的关键不是"这归谁管"，而是"这个问题需要哪些视角"。
ISO 9241-210 对人本设计活动和概念分工的说明值得反复对照。
注释 1 ISO 9241-110:2020、NN/g 方法资料。不同概念对应不同衡量方式——UI 看可访问性和一致性，UX 看任务成功率。CX 看 NPS/CES，服务设计看一次解决率。 🔗 https://www.iso.org/standard/75258.html