校园支付体验优化

项目概览

校园支付是一个非常典型的高频、低容错场景。学生排队时间短，窗口人流密集，收银员忙碌，网络条件不稳定，设备却必须快速完成识别、扣费和反馈。

这个项目的起点非常紧急：公司合作的 KA 客户批量采购人像识别设备，用于校园就餐支付。但上线第一天，就出现未扣费、多扣费、扣错人等问题，校方投诉严重，现场设备被停用。客户要求我们尽快给出优化方案，否则可能取消后续采购。

我在这个项目中临危受命，负责支付设备的交互优化。

背景：这个项目的关键是让读者理解现场环境对支付体验的影响。

设计判断：先用总览图说明支付链路和风险点，再进入现场观察和设计优化。

影响：帮助读者快速理解校园支付不是普通 UI 优化，而是现场高风险支付体验设计。

背景

在此之前，我们处理过工地、园区等识别场景，但校园食堂完全不同。

中午放学后，大量学生在短时间内涌入食堂，一个窗口、一台设备，需要连续处理几十位学生的支付。学生排队距离近，容易打闹和移动；收银阿姨也一直处于高强度工作状态，很难逐一解释设备反馈。

这意味着，校园支付场景里的问题不是单一设备问题，而是由人流、排队、识别范围、支付反馈、网络条件和现场协作共同造成的。

我的角色

• 交互设计师；
• 负责支付设备优化方案；
• 前往学校现场观察；
• 重新梳理角色、体验地图、用户流程和异常状态；
• 输出界面与交互优化建议；
• 制作演示原型用于客户确认。

现场观察

为了找到问题原因，我前往学校进行了为期一天的实地观察。

观察中发现，校园食堂支付场景有几个明显特征：

• 中午高峰期学生集中涌入；
• 一个窗口短时间内需要处理大量支付；
• 学生排队拥挤，容易多人同时进入识别画面；
• 学生活泼好动，可能在设备前移动或打闹；
• 收银员注意力主要在打菜和窗口服务上；
• 现场网络条件不稳定；
• 一旦反馈不及时，学生会以为设备没有反应，从而重复识别或重复操作。

现场观察

现场观察：校园食堂窗口在高峰期需要短时间处理大量学生支付。

背景：现场观察图片用于说明问题发生的真实环境。

设计判断：先到现场观察人流、排队、设备和收银员工作状态，再提出优化方案。

影响：让设计判断基于真实场景，而不是只基于客户反馈或内部猜测。

核心问题

现场问题主要集中在以下几类：

1. 人流量过大，学生拥挤，容易干扰识别；
2. 多人同时进入画面，设备可能识别到后方人员；
3. 学生可能走错套餐窗口；
4. 偶发二次消费；
5. 支付时出现余额不足；
6. 反馈不及时；
7. 现场网络条件较差。

这些问题共同导致用户对支付结果产生不确定：到底识别的是不是我？金额对不对？有没有扣款？失败后要不要再刷一次？

体验地图与用户流程

体验地图与用户流程：从学生进入窗口到完成支付、取餐离开的完整过程。

背景：角色、体验地图和用户流程共同说明校园支付的现场链路。

设计判断：将现场问题映射到具体流程节点，找出容易误识别、误扣费和反馈不清的位置。

影响：为后续识别聚焦、信息精简和异常状态设计提供依据。

关键洞察

洞察一：支付体验最重要的是确定性

在支付场景里，用户可以接受稍微多一步确认，但无法接受身份、金额和扣款状态不清楚。

尤其是刷脸支付，用户没有掏手机、刷卡这样的显性动作，如果反馈不明确，很容易产生焦虑。

洞察二：多人同框是校园刷脸支付最大的风险源

校园食堂排队时，学生之间距离很近。设备很容易同时捕捉到多人，甚至识别到后方学生。

如果系统在这种情况下直接进入扣费流程，就会带来扣错人的风险。

洞察三：反馈延迟会诱发重复识别

当设备没有及时告诉用户“正在识别”“已识别”“正在获取支付数据”或“支付成功 / 失败”时，用户会误以为设备没反应，从而再次靠近、再次识别或询问收银员。

洞察四：收银员也是关键用户

很多异常最终都需要收银员判断和处理。界面不只要让学生看懂，也要帮助收银员快速判断当前状态，减少解释成本和现场混乱。

设计挑战

校园支付的难点不是简单提高识别速度，而是在高频、拥挤、弱网、低容错的环境下，让身份、金额、状态和异常处理都变得更确定。

设计决策

决策一：识别聚焦，避免识别后方人员

我们通过识别界面画框约束，让系统引导当前学生进入合适识别区域，减少多人同时进入画面的可能。

同时，算法策略调整为只识别最大人脸，降低后方学生被误识别的概率。

识别聚焦前后方案

通过识别框约束和最大人脸策略，明确当前支付对象，减少后方学生被误识别的风险。

背景：校园食堂排队拥挤，多人同时进入识别画面是扣错人的主要风险。

设计判断：在界面和算法策略上共同收敛识别对象。

影响：降低多人同框造成的误识别和误扣费风险。

决策二：精简界面信息，突出关键支付内容

旧界面中，一些部门、用户类型等信息对当前支付行为帮助有限，却会干扰学生和收银员理解关键内容。

我将界面重点重新聚焦到人名、套餐、金额和支付状态上，不重要的信息转为后台记录或弱化展示。

信息精简前后对比

信息精简前后对比：弱化与支付无关的信息，突出人名、套餐、金额和状态。

背景：辅助信息过多，影响学生和收银员快速判断支付核心内容。

设计判断：删除或弱化低优先级信息，把视觉焦点集中到支付确认信息上。

影响：减少现场误解，提高支付状态判断效率。

视觉优先级调整

进一步调整身份、套餐、金额、余额和支付结果的视觉顺序，让窗口人员和学生先看到当前最重要的信息。

决策三：增加即时反馈，降低等待感

为了避免学生认为设备没有反应，我把反馈过程拆得更清楚：先显示识别结果，再显示平台支付数据，例如余额、套餐和菜品。

这样即使接口还在等待，用户也能知道系统已经识别到自己，减少重复操作。

识别与支付反馈状态

依次展示识别中、识别成功和数据加载状态，并用状态矩阵补充弱网、失败和人工处理规则。

背景：弱网和接口延迟会让学生误以为设备无响应，从而重复识别。

设计判断：将反馈拆成识别结果、支付数据加载、支付成功和失败等状态。

影响：减少重复操作、重复识别和支付结果不确定。

决策四：增加防错与帮助机制

针对余额不足、走错窗口、重复消费等问题，界面需要给出更明确的提示，而不是只显示失败。

这些提示要同时帮助学生和收银员理解：发生了什么，下一步应该怎么做。

防错与帮助

针对走错套餐窗口、余额不足和支付异常，直接说明原因并提供下一步处理方式。

背景：校园支付现场异常会迅速影响排队效率和用户信任。

设计判断：把失败原因和下一步处理方式直接反馈给学生和收银员。

影响：降低异常扩大和现场解释成本。

决策五：支持不同消费模式

原有套餐模式无法覆盖所有校园消费情况。因此在优化方案中，增加菜品模式、查询模式、定制模式和输入金额模式，以适应更多窗口和消费场景。

不同消费模式

不同消费模式：在套餐模式基础上扩展菜品、查询、定制和输入金额模式。

背景：校园食堂不同窗口和收费方式不同，单一套餐模式无法满足所有场景。

设计判断：让设备支持更多消费类型，而不是强迫现场适应固定流程。

影响：提升方案对不同学校和窗口业务的适配能力。

结果

设备升级后获得了客户和学校的肯定，后续客户继续推进采购与推广沟通。

方案获得客户和学校的正向反馈，并支持后续推广沟通。

反思

这个项目让我对支付体验有了更深的认识。

支付设计不是把流程做得越快越好，而是让用户在每一步都知道：识别的是谁、金额是多少、是否正在扣款、是否支付成功、失败后该怎么办。

尤其在校园食堂这种高频、拥挤、低容错场景中，好的设计不是炫技，而是减少误判、减少焦虑、减少争议。

背景

校园刷脸支付是高频、排队、强即时反馈、低容错的支付场景。设备批量上线首日出现未扣费、多扣费和扣错人等投诉，校方暂停使用设备，客户要求快速给出优化方案。

问题

午餐高峰时，多名学生靠近同一设备，窗口工作人员持续忙碌，现场网络也不稳定。如果识别对象、金额、处理中状态和结果反馈不清晰，用户容易担心扣错人、重复扣款或支付没有完成。

我的角色

我作为交互设计师负责支付设备体验优化：到学校观察真实就餐过程，梳理学生和窗口工作人员的任务，分析多人识别、支付反馈和异常路径，制作演示原型并与客户确认。

研究与发现

用 1 天观察学校食堂现场。一个窗口的一台设备需要在短时间内服务 50+ 名学生；学生排队距离近、容易打闹，设备可能同时捕捉多张人脸。窗口工作人员同时处理餐食与支付，无法持续关注复杂界面。

现场与体验证据

现场图片和体验地图呈现支付问题的真实环境：高峰、队列、多人靠近设备，以及学生在每个接触点的担忧。

食堂环境与学生旅程

用真实环境说明为什么实验室里的单人识别路径不够。

关键洞察

设计挑战

支付体验必须同时控制识别风险、资金确认、网络不确定性和窗口效率。设计不能只优化正常成功路径，还要让学生与工作人员知道何时等待、何时重试、何时需要人工处理。

支付流程

1. 进入识别区
2. 人脸识别
3. 身份 / 金额确认
4. 支付确认
5. 支付处理中
6. 成功 / 失败反馈
7. 异常处理

异常状态

• 多人同时入镜
• 识别到错误用户
• 金额未确认
• 网络延迟
• 支付处理中
• 支付失败
• 重复扣款疑虑
• 余额不足
• 设备无响应
• 收银员手动介入

设计决策

信息架构 / 用户流程 / 原型

界面重新排序信息优先级：保留学生和窗口人员共同需要的身份、菜品 / 套餐、金额与结果，弱化部门和用户种类等辅助信息；同时增加套餐、菜品、查询、定制和输入金额等模式。

流程与界面补充

点菜流程和早期设备界面用于说明起点方案中的信息层级、识别对象和支付状态问题。

支付模式与早期界面

通过流程和界面并置，解释为什么需要强化身份、金额与结果确认。

验证

演示原型提交客户确认，随后学校设备完成升级。客户和学校给出积极反馈，但当前没有支付准确率、耗时或投诉变化等量化数据。

结果

这个项目明确了校园刷脸支付场景中的关键风险点，并提出更安全的确认、更清晰的反馈和更可靠的异常处理规则。

反思

支付设备的正常路径只占体验的一部分。真正决定信任的是多人、弱网、等待、失败和人工介入时，系统是否清楚说明正在发生什么。后续最应补的是升级前后的错误类型与任务耗时对比。