交互设计
导读
交互设计最容易被误解成"把界面画出来"。
页面当然重要，按钮、输入框、列表、弹窗、导航也都重要。但交互设计要追问的是动作背后的来回关系：用户发起了什么，系统怎样回应，用户凭什么判断下一步，任务中断后还能不能接着走。
用户点击之后，系统是否有反馈？输入错误后，用户是否知道错在哪里？任务中断后，用户能不能回来？删除、支付、提交、授权这些高风险动作之前，系统是否让用户确认后果？用户没有权限时，系统是只说"无权访问"，还是告诉他该找谁、如何申请？网络失败、数据加载、重复提交、批量操作、审批退回、支付异常，这些状态有没有被设计？
这些问题就是交互设计的核心。
如果说信息架构决定用户从哪个入口进入任务，交互设计决定他进来之后每一步是否被接住。自助值机是一个典型的交互流程：证件识别失败时，系统要告诉旅客换证件还是找柜台；座位被占用时，要给出可选座位；行李额超了，要说明补差价还是去人工柜台；登机牌打印失败，也要留下补救路径。
核心问题
想清楚这几个问题。
交互设计到底设计什么？它设计的是行为、流程、状态、反馈和控制关系，而不只是界面排版。
用户流、任务流和系统流有什么区别？用户流关注用户如何完成目标，任务流关注任务步骤和决策，系统流关注系统状态和后台处理。
反馈为什么重要？用户每做一步，都需要知道系统是否收到、正在处理、已经成功、失败原因是什么、下一步能做什么。
错误如何被预防和恢复？用户难免会输错、选错、重复提交或遇到系统失败，交互设计要做的是在关键风险点提前提醒，并在出错后给出可继续行动的路径。
状态为什么经常被漏掉？空状态、加载中、成功、失败、禁用、权限不足、部分完成、过期、冲突、离线，都是产品真实体验的一部分。
复杂流程如何设计？审批、支付、配置、批量操作、权限管理、企业后台任务，都需要同时处理步骤、角色、规则、风险和异常。
交互设计如何衡量价值？它通常通过任务成功率、错误率、完成时间、首次成功率、客服咨询、投诉、返工和风险事件来观察。
关键概念与定义
交互设计
交互设计，Interaction Design，是设计用户与系统之间行为、流程、状态和反馈的工作。
它回答的问题包括：用户从哪里开始，下一步是什么，系统如何回应，用户能做哪些选择，什么时候需要确认，失败后如何恢复，任务完成后如何收尾。
比如"提交报销单"不是一个按钮问题。用户要选择费用类型、上传发票、填写金额、确认审批人、提交、等待结果、处理退回、查看到账。交互设计要处理整条任务链，而不是只设计"提交"按钮。
用户流
用户流，User Flow，是用户为了完成目标在产品中经过的路径。
用户流强调用户视角。以购买一件商品为例，用户可能先比较两个商品页，再把其中一个加入购物车，填写地址时临时修改配送方式，看到优惠券不可用后返回商品页凑单，最后支付并查看订单状态。这条路径不一定笔直，但它才是用户真实完成购买时走过的路。
用户流不一定等同于系统流程。用户可能在系统外查资料、问同事、联系客服、等待短信，这些也会影响体验。
任务流
任务流是完成某个任务所需的步骤、决策和输入。
它比用户流更关注任务本身。例如"配置权限"的任务流可能包括选择成员、选择角色、确认数据范围、预览权限、提交审批、通知成员。任务流能帮助团队发现哪些步骤必须存在，哪些可以合并，哪些需要默认值或模板。
系统流
系统流是系统在后台如何处理状态、数据、权限、接口和异常。
用户点击"支付"，系统可能要创建订单、锁定库存、调用支付渠道、等待回调、处理失败、释放库存、更新状态、发送通知。用户不需要知道所有系统细节，但系统流如果没有被设计清楚，用户体验就会断裂。
状态
状态是系统或对象在某一时刻的情况。
常见状态包括默认、悬停、聚焦、禁用、加载中、成功、失败、空、已保存、未保存、过期、冲突、无权限、部分完成。复杂产品里，一个对象可能有业务状态，比如待审批、已退回、已支付、已取消、已归档。
很多交互问题不是正常状态没设计好，而是边界状态没设计。
反馈
反馈是系统对用户行为的回应。
Donald Norman 关于反馈、可供性、概念模型和错误设计的讨论，常被用于解释为什么系统需要让用户理解可做什么、做了什么、发生了什么。 用户点击按钮后，如果没有反馈，他会怀疑自己是否点到；提交表单后，如果只显示"系统异常"，他不知道该重试、等待还是联系客服。
错误预防与错误恢复
错误预防是减少用户犯错的机会，错误恢复是帮助用户在出错后回到正确路径。
错误预防包括清晰标签、合理默认值、输入约束、即时校验、风险提示、确认机制。错误恢复包括撤销、修改、重试、保存草稿、清晰错误原因、恢复上一步、转人工或联系客服。
好的交互设计同时考虑这两件事。
概念边界与相近概念区别
交互设计与界面设计
界面设计关注页面结构、组件、视觉层级和呈现方式。交互设计关注用户和系统之间的行为关系。
一个支付页面可以视觉清楚，但如果失败后只停在一句"系统异常"，用户会立刻担心三件事：钱扣了没有，订单还在不在，刚才用掉的优惠还算不算。反过来，一个低保真线框也可以表达很好的交互逻辑，只是还没有进入最终界面呈现。
界面是交互的载体，但不是交互的全部。
交互设计与原型设计
原型是表达和验证交互的工具，不是交互设计本身。
团队可以用纸面草图、流程图、低保真线框、高保真点击原型甚至真实代码来表达交互。关键不是原型多精致，而是它是否表达了任务、状态、反馈、异常和风险。
如果一个高保真原型只有顺利路径，没有错误、空状态、权限不足和加载失败，它仍然不是完整交互方案。
用户流与系统流程
用户流从用户目标出发，系统流程从系统处理出发。
以退款为例，用户流是发现问题、查看规则、申请退款、等待审核、寄回商品、查看物流、收到退款。系统流程可能是创建退款单、冻结款项、商家审核、物流回传、财务打款、订单状态更新。
两者都重要。只看用户流，可能忽略系统约束；只看系统流，可能忽略用户焦虑和等待成本。
状态设计不是边角料
很多团队先设计"理想状态"，上线前才补空状态、错误状态和加载状态。结果真实产品里最常出现的恰恰是这些状态。
新用户没有数据，所以会看到空状态；网络不好，所以会看到加载和失败；复杂权限下，用户会看到禁用和无权限；多人协作时，会出现冲突和版本变化。
状态不是边角料，而是真实体验。
错误提示不止是文案
错误提示确实需要好文案，但交互设计要处理的不只是说什么。
错误发生在哪里？能否提前预防？提示是否贴近出错字段？用户能不能立即修改？是否保留已填内容？是否说明后果？是否提供下一步？是否需要人工介入？
如果用户申请发票时已经填完公司名称、税号、地址、电话和邮箱，提交后页面只在顶部闪出一句"资料未通过校验"，他会从头扫一遍字段，猜是税号位数、邮箱格式，还是抬头类型选错。这时问题不只是文案不友好，而是系统没有把错误定位、修改路径和已填内容保护好。
微交互不是装饰动画
微交互可以包括按钮反馈、开关状态、拖拽反馈、保存提示、进度变化、输入校验等。它的价值不是让产品"更炫"，而是让用户理解系统状态。
动画如果帮助用户理解变化，就有价值；如果只是增加等待或分散注意，就会成为负担。
方法、流程或框架
从关键任务开始
交互设计要从关键任务开始，而不是从页面开始。
先明确用户要完成什么任务，再拆解步骤、输入、决策、系统反馈、异常和结束状态。比如"创建项目"这个任务，可以拆成选择模板、命名项目、邀请成员、设置权限、确认创建、进入项目。每一步都要问：用户需要什么信息？系统需要什么输入？可能出现什么错误？下一步如何提示？
如果从页面开始，团队容易把注意力放在布局和组件；从任务开始，团队会更自然地关注行为和状态。
区分用户流、任务流和系统流
复杂任务最好同时画三类流。
用户流回答：用户如何从目标出发完成一件事。任务流回答：这件事需要哪些步骤、决策和输入。系统流回答：系统如何处理数据、权限、状态和异常。
以企业后台"批量导入员工"为例。用户流包括进入成员管理、选择导入、上传文件、预览错误、修改或重新上传、确认导入、通知员工。任务流包括准备文件、字段匹配、校验、冲突处理、提交。系统流包括文件解析、字段校验、重复账号检查、权限写入、日志记录、消息发送。
三类流放在一起，团队才能发现真实风险：用户以为导入成功，系统其实部分失败；用户不知道哪些员工失败，系统没有保留错误明细；用户重新上传，系统造成重复账号。
设计状态表
以"审批单"为例，它至少可能有草稿、待提交、待审批、已退回、已通过、已拒绝、已撤回、已过期。不同状态下按钮、提示、权限和下一步都不同。如果没有状态表，界面很容易出现逻辑漏洞。
状态表就是把这些状态列清楚：触发条件是什么，用户看到什么，可以做什么，系统如何恢复。
设计反馈机制
反馈要匹配任务风险。
低风险动作可以用轻量反馈，比如切换筛选、收藏、展开列表。中风险动作需要明确反馈，比如保存成功、修改已生效。高风险动作需要确认和结果说明，比如支付、删除、授权、提交审批。
反馈还要考虑时间。如果系统处理很快，用户只需要看到结果；如果处理需要等待，用户需要看到进度、预计时间或可离开提示；如果处理失败，用户需要知道原因和下一步。
NN/g 的可用性启发式中，"系统状态可见性""用户控制与自由""错误预防""帮助用户识别、诊断和恢复错误"等原则，都直接支撑交互设计中的反馈和恢复。4
设计错误预防
错误预防比错误提示更重要。
表单可以通过输入格式、示例、默认值、分组、即时校验和合理控件减少错误。支付可以通过费用提前展示、确认页和风险提示减少误解。权限配置可以通过模板、预览和风险标记减少误配。
错误预防不是层层设卡。它更像在高风险路口提前亮灯：用户批量删除客户数据前看见影响范围，给外包同事授权前能预览可访问内容，提交报销前能发现发票号码格式不对。 如果做反了会怎样
"错误预防"经常被误解成"加更多校验"，但大多数致命交互错误来自视觉混淆，不是来自用户粗心。某系统把"删除项目"按钮做成了和"保存"一样的蓝色、一样的大小、放在同一个操作区域。管理员在一次批处理中把三个项目删掉了。系统没有报错——功能正常，只是用户点错了。这不是用户的错，是设计的错。
相比之下，"删除项目"用红色描边按钮、放在页面底部、加上弹窗二次确认——不是因为红色好看，是因为管理员看到红色时大脑会自动放慢速度。这是利用了认知习惯。好的交互不是让用户"自己小心一点"，是在用户来不及小心的时候替他挡一挡。
设计错误恢复
用户一定会出错，系统也一定会失败。
支付失败后，用户最怕的不是"失败"两个字，而是不知道钱扣没扣、订单还在不在、优惠是否失效、还能不能换一种支付方式。恢复路径要先回答这些问题，再把用户带到下一步。表单提交失败也一样，系统应该把用户带回具体字段，保留已填内容，并说明如何修正。
深度案例：审批系统退回操作的结构化改造
某企业审批系统的"退回"操作在过去两年里导致了17次数据事故。流程看起来没问题：审批人点"退回"，系统弹窗问"确认退回吗"，审批人点"确认"，流程回到申请人。
事故出在审批人在退回时写的"退回原因"——"不符合规定""材料不完整""再核实一下"。申请人看不懂，以为只是格式问题，改了一处又提交了。审批人再次退回。一来一回三次，审批人最后手动打电话解释，工单挂在系统里没人跟进。
改版后做了三件事。退回原因从自由输入改成结构化选项——"发票信息有误""费用类型不匹配""缺少审批附件""超出预算限额"——每个选项附带一句说明告诉申请人"你需要改什么"。提交退回时，系统在确认弹窗里展示了"退回后将回到申请人手中，你有48小时可以撤回这次退回"。最关键的改动："退出"按钮旁边加了"保存并稍后处理"——审批人可以先标记、明天再退，不用在疲劳时做一个会出错的决策。上线半年，退回相关的工单和事故降到零。
处理复杂权限和异常流程
复杂产品里，权限和异常往往比正常流程更影响体验。
用户没有权限时，不应只看到"无权访问"。他需要知道这是因为角色限制、数据范围限制、审批未通过，还是账户状态问题。更进一步，他需要知道能不能申请权限、找谁申请、申请后多久生效。
异常流程也要被设计。真实产品里，订单可能超时，审批可能退回，库存可能刚好卖完，两个人可能同时编辑同一条记录，文件可能上传到一半断网，批量导入可能只成功了其中 93 条。把这些情况留到开发或上线后临时处理，交互就会在用户最需要解释的时候断开。
用评审和测试验证交互
交互设计可以先用启发式评估、走查和 UX Scorecard 发现问题，再用可用性测试、行为数据和错误日志验证。GitLab 公开的 UX Scorecards 机制就是一个持续发现体验问题的企业实践案例。1
评审适合快速发现明显问题，测试适合观察用户是否真的能完成任务，数据适合上线后监测规模和趋势。三者结合，交互设计才不只是设计师自己的判断。
实际工作场景
场景 1：表单提交
表单是最常见的交互场景，也是最容易暴露细节问题的地方。
假设用户要在线申请发票。字段命名是否清楚？必填项是否提前说明？抬头类型选错后会怎样？税号格式能否即时校验？提交失败是否保留内容？错误提示是否定位到字段？提交成功后用户是否知道发票何时开具、从哪里下载？
表单设计不是把字段排整齐，而是帮助用户正确、安心、可恢复地提交信息。
场景 2：支付流程
支付流程对反馈和错误恢复要求很高。
用户在支付时最关心几件事：总价是否清楚，优惠是否生效，钱有没有扣，订单有没有生成，失败后能否重试，重复支付会不会发生。任何含糊反馈都会制造焦虑。
因此支付流程需要提前展示费用，明确支付状态，处理渠道失败，保留订单，说明重试方式，并在必要时提供人工帮助。交互设计在这里直接影响信任和转化路径，但具体商业结果仍受价格、库存、物流、活动和流量影响。
场景 3：审批流
审批流的难点是角色多、状态多、责任多。
申请人关心材料是否提交成功、现在到谁、什么时候有结果。审批人关心是否能快速判断风险、退回理由如何写、批量处理是否安全。管理员关心规则、权限、超时和审计。
如果只设计一个"提交"和"审批"按钮，流程很快会在退回、补充材料、超时、撤回、转交、代理审批和权限变化时崩掉。审批流必须从状态和异常开始认真设计。
场景 4：批量操作
批量操作看起来是效率功能，实际上是高风险交互。
批量删除、批量导入、批量授权、批量发送通知，都可能把一个小错误放大成系统性事故。交互方案至少要让用户确认选中了哪些对象，预览将发生什么，看到高风险提醒，知道是否还能撤销；如果只成功一部分，还要说明失败对象、失败原因和重试办法。
如果系统只告诉用户"操作成功"，但实际上 100 条里有 7 条失败，用户会在后续工作中才发现问题。更好的设计要说明成功多少、失败多少、失败原因、能否导出错误明细、如何重试。
场景 5：移动端与桌面端差异
同一个任务，在移动端和桌面端的交互重点不同。
移动端屏幕小、输入成本高、使用环境更分散，适合短任务、清晰反馈和分步推进。桌面端空间更大，适合复杂表格、多窗口比较、批量操作和长时间任务。
如果把桌面后台原样搬到手机上，用户会被密集表格和复杂筛选压垮。如果把移动端的分步简化照搬到桌面，专业用户又可能觉得效率太低。交互设计要根据设备、任务和使用情境调整。
案例
案例 1：GitLab UX Scorecards2
GitLab UX Scorecards 的案例说明它关注复杂产品中持续发现和改进体验问题。GitLab 公开其 UX Scorecard 机制，用于评估体验、发现可用性问题并推动改进。3
这个案例对交互设计的启发是：复杂产品的交互问题不能只靠上线前一次评审发现。随着功能增加、角色增多、权限复杂、流程变长，团队需要持续走查任务、记录问题、评估严重度，并把发现转化为优先级。
需要说明的是，UX Scorecards 是一种持续评估机制，不等同于用户行为数据。它帮助团队发现和记录问题，而不是替代可用性测试或数据分析。
案例 2：NN/g 可用性启发式5
NN/g 的 10 条可用性启发式不是公司案例，但它们是交互设计评审中常用的可核查方法来源。系统状态可见性、用户控制与自由、一致性、错误预防、识别而非回忆、帮助用户恢复错误等原则，都能直接指导交互评审。
这里使用它，是为了说明交互设计不是纯审美判断。团队可以用一组原则系统检查流程、反馈、状态和错误恢复。
数据、指标或衡量方式
交互设计可以用任务和错误来衡量。
最直接的指标是任务成功率。用户是否能完成注册、支付、配置、审批、批量导入？如果任务本身定义不清，任务成功率也没有意义。
第二类指标是错误率。用户是否填错字段、选错权限、重复提交、误删数据、支付失败后重复尝试？错误率适合表单、审批、配置、支付和后台操作，但前提是团队定义了什么算错误。
第三类指标是任务完成时间和首次成功率。它们适合观察效率和易学性。比如新管理员第一次配置权限需要多久，是否第一次就能成功完成。
第四类指标是客服联系率、错误日志、投诉率和撤销率。它们能帮助团队看到上线后的交互问题是否扩散到运营和服务成本。
第五类指标是主观任务难度，比如 SEQ。用户完成一个任务后觉得困难，可能说明流程虽然能完成，但理解成本高。
这些指标必须结合场景解释。完成时间越短不一定越好，高风险操作太快可能说明用户没看清后果。错误率下降也不一定完全来自交互改进，可能是用户熟练了、规则变了、样本变了。交互指标要和任务、版本、用户群、业务规则一起看。
常见误区
交互设计就是画线框图——线框图可以表达交互，但交互设计还包括流程、状态、反馈、权限和异常。每个关键任务都同时输出用户流、状态表和异常场景。
只设计正常路径——正常路径最容易画，也最不够真实。为错误、失败、无权限、空状态、加载、过期、冲突和部分成功设计处理方式。
反馈越多越好——反馈要匹配风险和用户需要。低风险动作过度弹窗，会打断任务；高风险动作反馈不足，会制造焦虑。按动作风险分层设计反馈。
错误提示只是文案问题——错误提示背后是错误定位、输入保留、修改路径和恢复机制。先设计错误恢复逻辑，再写错误文案。
禁用按钮可以防止错误——禁用按钮如果没有解释，用户不知道为什么不能点。对禁用状态提供原因和可行动提示，尤其在复杂表单和权限场景中。
移动端和桌面端只是尺寸不同——设备差异会影响输入方式、注意力、任务时长和信息密度。按设备和任务重新评估流程，而不是简单缩放页面。
上线后没人投诉就说明交互没问题——用户不投诉，可能是放弃了、绕路了、问同事了，或者找不到反馈渠道。结合任务数据、错误日志、客服工单和可用性测试判断。
小结
交互设计是设计用户和系统之间的行为关系。
它关注用户如何开始、如何推进、如何理解状态、如何控制风险、如何从错误中恢复。好的交互设计会认真处理流程、反馈、状态、权限、异常和失败，让批量导入、支付确认、权限配置这类麻烦事少在上线后爆出来。
关键是从任务出发，同时梳理用户流、任务流和系统流，并为关键状态和异常情况建立清单。判断交互设计是否完整，要看团队是否真的降低了任务风险，而不是只交付顺利路径的界面稿。
交互设计的价值常常藏在麻烦没有发生的时候：用户没有重复提交，管理员没有配错权限，财务没有因为一批失败导入返工，客服没有反复解释支付状态。它不总是最显眼的设计部分，却经常决定产品是否真正好用。
延伸阅读
延伸阅读：NN/g 的 10 Usability Heuristics，建立交互评审中的系统状态、控制、错误预防和恢复原则框架。
注释
1 Don Norman, The Design of Everyday Things。反馈、概念模型和错误设计是交互理解的重要基础。 🔗 https://www.nngroup.com/books/the-design-of-everyday-things/
2 NN/g, 10 Usability Heuristics for User Interface Design。系统状态、用户控制、错误预防和错误恢复可作为交互评审原则。 🔗 https://www.nngroup.com/articles/ten-usability-heuristics/
3 GitLab UX Scorecards。复杂产品可用 UX Scorecards 持续发现体验问题。 🔗 https://handbook.gitlab.com/handbook/product/ux/ux-scorecards/
4 Baymard Cart & Checkout Usability Research。结账流程交互摩擦会影响关键业务路径。 🔗 https://baymard.com/research
5 ISO/IEC 25010, Systems and software Quality Requirements and Evaluation。软件产品质量模型可补充可用性等质量维度。 🔗 https://www.iso.org/standard/78176.html