Overview
From 低互动校园服务平台 to 可信校园互助启动系统
Kapabala 是一个面向海外大学生的校园互助平台。旧版产品以“服务浏览”为核心， 但真正影响互动发生的不是服务数量，而是 requester 能否发出清楚需求， helper 能否放心做出第一回应。
我将 redesign 的重点从“扩大用户范围”重新定义为“启动可信连接”：通过 request、 matching、response、compare 和 confirm，把一次校园互助从模糊聊天转化为可理解、 可回应、可确认的闭环。
01 / Challenge
旧版内容有用户，但没有形成高频互动
旧版 Kapabala 更像一个校园服务 marketplace：helper 发布服务，requester 浏览后私聊。 这个模式能展示供给，却没有很好地支持“临时求助”这种更强情境、更高不确定性的行为。
旧版. Browse Service
可以看到服务， 但需求表达弱
02 / Problem Reframing
团队以为问题是“用户范围太窄”
如果只把问题理解为“用户不够多”，设计容易滑向增加入口、分类或推广。 我先把问题拆成 market、product understanding、two-sided interaction、trust 和 metrics， 重新定位真正阻碍互动发生的断点。
目标用户是否足够大
用户是否理解产品能帮什么
双方是否能自然互动
双方是否有依据做决定
哪些节点需要被观察
帮助 requester 更快获得可信第一回应，同时降低 helper 的回应心理成本。
03 / Research & Synthesis
找到 requester 和 helper 的真实断点
我结合定向问卷、半结构化访谈 / 反馈整理，以及从 UX audit、开放题、访谈、 竞品和 journey map 中拆解出的观察点，聚合出三类关键洞察。
不是不会发布，而是发布后不知道系统有没有在工作。
等待焦虑来自状态不可见，而不只是等待时长。
不是不愿意帮，而是不知道为什么匹配自己。
回应前需要任务边界、距离、时间和承诺压力被解释清楚。
双方缺少结构化依据，很多承诺被挤压进聊天里。
信任判断需要在关键决策点出现，而不是全靠聊天补齐。
04 / Strategy
从服务浏览转向连接闭环
旧版核心结构是“浏览服务 → 私聊”，但校园互助真正需要的是“表达需求 → 获得匹配 → 收到回应 → 比较选择 → 确认承诺”。因此我把机制从 marketplace 改为 connection system。
看到服务，但需求表达弱。
可以私聊，但回应理由弱。
聊天继续，但承诺边界模糊。
Use activity
Compare helpers
Confirm helper
05 / Product Improvements
4 个关键支点，启动一次可信校园互助
我没有把 redesign 做成功能堆叠，而是围绕 request、match、response、compare、 confirm 这条核心路径，处理双方最容易停下来的节点。
New Request：把表单变成 matching signals 采集器
新版 New Request 不只是让用户填写信息，而是将任务类型、时间、地点、预算、 技能需求和紧急程度转化为匹配信号。
表单不是收集信息，而是帮助系统判断谁最可能回应。
06 / Testing & Iteration
核心流程更容易完成和理解
我进行了两轮原型可用性测试：Round 1 为低保真混合用户测试 n=8； Round 2 为高保真测试，requester n=8，helper n=6。 这些数字证明的是原型阶段的理解和任务完成改善，不包装成上线后业务增长。
07 / Responsive & System
Mobile-first，再同步关键 Web 页面
我使用 Figma 输出 80+ 个高保真 frames，覆盖 mobile app 的 requester / helper 核心流程、 关键状态页与 responsive web 关键页面适配，并整理关键组件与核心流程标注规范。
08 / Reflection
双边平台的关键，是降低第一次回应的信任成本
双边平台不是把两类用户放在一起就会自然互动。真正关键的是降低第一次回应的心理成本和信任成本， 让双方都能理解下一步行动的意义和边界。
Kapabala 证明了我在交互设计中的核心能力：从旧产品诊断、用户行为理解、 双边平台机制和原型测试出发，把模糊问题转化为可验证、可交付的核心体验闭环。