课堂作业：软件的UX - 快速分析并提议改进

UX 分析诊断：PQ问答

切入点一：认知阻力 (Cognitive Friction)

• 1. 问题是什么？

  • 角色：听众
  • 进入小程序后，听众参与活动的主要方式之一是“请输入6位数字活动码”。在典型的大学阶梯教室场景中，听众（学生）需要：在远处的大屏幕上看清这串数字然后在手机上准确输入。这个过程需要用户在视觉、记忆和操作之间进行多次切换，中断了“看到即加入”的流畅体验，增加了不必要的认知负担。
    

• 2. 为何是问题？

  • 这违背了“降低认知负荷”和“奥卡姆剃刀”原则。一个优秀的设计应该让用户用最少的精力完成核心任务。相较于“扫码”这一肌肉记忆级别的操作，输入六位数字增加了出错的可能性和心理上的“费力感”。虽然提供了扫码选项，但将数字输入框置于这么显眼的位置，实际上引导了用户使用一个更高阻力的路径。

• 3. 团队为何犯错？

  • 我们猜测团队的设计初衷是提供一个“万能的备用方案”。他们可能考虑到在某些极端情况下（如投影模糊、座位太远），二维码无法扫描，此时数字码就成了唯一的入口。这是一个技术上“图省事”且合理的冗余设计。但问题在于——他们在界面上给予了这个“备用方案”与“首选方案”（扫码）几乎同等的视觉权重，而没有根据用户使用频率和便捷性进行主次区分。

• 4. 如何改进？

  • 我们选择重新设计这个入口界面：
    1. 强化首选路径：将“扫描二维码”按钮作为整个页面的视觉中心，做得更大、更突出。甚至可以考虑首次进入时，默认请求相机权限并直接开启扫码界面，提供最直接的体验。
    2. 弱化备用方案：将“输入活动码”的选项改为一个不起眼的文字链接，放置在扫码按钮下方，文案可以是“扫码遇到问题？尝试手动输入活动码”。

---

切入点二："Paper-Cuts" (微小的挫败感)

• 1. 问题是什么？

  • 角色：听众
  • 在活动结束后，分数相同的用户会“随机排名”。对于一个同样答对所有题目，获得满分但排名却在第5位的学生来说，这会带来一种强烈的不公平感和挫败感。用户获得高分但没有得到公平的回报，排名机制的武断性削弱了排行榜的激励作用。
    

• 2. 为何是问题？

  • 这违背了“公平与透明” 的原则。游戏化设计的核心是激励，而激励的基石是公平。一个随机的排名系统会让用户觉得自己的努力被随机性所抵消，从而产生“玩弄感”，这是一个典型的 "Paper-cut"。这种微小但尖锐的挫败感会逐渐侵蚀用户对产品的信任和参与热情。

• 3. 团队为何犯错？

  • 这很可能是技术上“图省事”的典型案例。在数据库查询中，实现“按分数降序，然后随机排序” (ORDER BY score DESC, RAND()) 是一条非常简单直接的SQL语句。要实现一个更公平的次级排序标准（如答题用时），则需要额外记录每个用户的提交时间戳，并在查询时增加一个排序字段 (ORDER BY score DESC, submission_time ASC)。团队可能在早期版本中为了快速实现功能，选择了最简单的技术方案，而忽略了它对用户心理的微妙影响。

• 4. 如何改进？

  • 我们团队可能会将排名规则优化为多维度排序：
    1. 引入次级排序标准：将排名规则明确修改为“分数优先，同分情况下以答题用时更短者为先”。这不仅公平，还能鼓励学生在保证正确率的同时提高效率。
    2. 明确规则告知：在排行榜页面的显著位置，用一行小字说明排名规则：“同分时，用时短者排名靠前”。透明的规则能消除用户的疑虑，让他们感觉系统是公正的。
    3. 技术实现：要求后端在用户提交答案时，必须记录服务器时间戳，并以此作为排序依据。

---

切入点三：同理心 (Empathy)

• 1. 问题是什么？

  • 角色：演讲者
  • 从截图和功能描述来看，“活动管理”页面似乎是一个扁平的列表。对于一个需要教授多门课程、跨越多个学期的大学教师来说，这意味着他所有的互动活动（例如“第一章课后测验”、“期中复习题”、“2023秋季班-微积分-随堂测试”）都会混杂在这个列表中。当活动数量增多时，管理、查找和复用特定活动将变得非常困难和低效。
    

• 2. 为何是问题？

  • 这反映了设计上缺乏同理心，没有真正站在高频、重度用户（教师）的真实工作流角度去思考。教师的心理模型是围绕“课程”和“学期”来组织教学材料的，而不是一个无限滚动的“活动流”。这种设计无法满足用户进行信息归档和高效复用的深层需求，使得产品“越用越乱”，难以成为教师长期依赖的教学工具。

• 3. 团队为何犯错？

  • 这可能是团队陷入了“MVP（最小可行产品）思维陷阱”和“知识的诅咒”。在产品初期，核心目标是“让老师能创建一个活动”，因此一个简单的列表就足够了。他们可能没有预见到（或暂时搁置了）一个老师管理十几个活动时的混乱场景。此外，开发者自己可能不是教师，无法深刻理解教学工作的组织性和周期性，他们从“功能实现”角度出发，设计了一个“活动列表”，而不是从“用户场景”出发，设计一个“教学管理系统”。（尽管有一个“课程管理”的Tab，但从界面看来，它和“活动管理”的联动未被充分设计）。

• 4. 如何改进？

  • 我们团队会将“组织性”作为演讲者端的核心体验进行优化：
    1. 强化“课程”概念：将“课程管理”提升为核心功能。引导演讲者首先创建“课程”。
    2. 活动与课程强关联：创建任何新活动时，必须让演讲者选择该活动隶属于哪一门“课程”。
    3. 分层级的浏览视图：“活动管理”页面的默认视图应改为按课程分组，或者提供按课程筛选的功能。用户可以轻松地查看某一门特定课程下的所有活动。
    4. 增加复用功能：在活动旁边增加“复制”或“复用至其他课程”的按钮，让老师可以方便地将去年的期末测验复用到今年的新班级中，极大地提升效率。

---

总体评价与NPS分数

完全基于上述的 UX 分析，我们给出的 NPS 分数是：7 分。

这是一个典型的“被动者”分数。它完成了核心功能，没有致命缺陷，但体验上的种种“纸上划痕”和不够体贴的设计，让它离一个能让人“惊喜”并“主动推荐”的“推广者”产品还有距离。

11.在你的软件项目中，你们要吸取什么教训？
郑权（项目经理）：需提前明确工时记录标准，避免数据延迟影响进度统计；实时跟踪任务剩余工时变化，及时调整燃尽图预期。
陈鉴祥（全栈开发 & Scrum Master）：微服务接口设计需提前与前后端对齐，减少联调返工；技术方案需充分预估高并发场景风险。
何绍斌（后端开发）：开发前需细化功能复杂度，避免任务剩余工时大幅增加；接口返回格式需严格遵循约定，减少适配成本。
张廷智（前端开发）：需提前调研小程序版本兼容性，预留适配时间；功能开发前需预判技术难点（如图片上传），避免临时优化。