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 不只是让用户填写信息，而是将任务类型、时间、地点、预算、 技能需求和紧急程度转化为匹配信号。
表单不是收集信息，而是帮助系统判断谁最可能回应。
Why Matched：让 helper 明白“为什么是我”
Helper 不回应的原因不一定是不愿意帮助，而是任务边界不清、匹配理由不清、 回应成本过高。我在 Matched Request 中加入 Why matched、任务范围和轻量回应动作。
把正式承诺前置的压力，拆成一次低成本的第一回应。
Live Activity：把等待焦虑变成可理解的系统状态
Requester 发布请求后，最大的焦虑不是等待本身，而是不知道系统是否在工作。 Live Activity 把 Sent、Matching、Notifying 和 Strong matches 等状态可视化。
状态设计不是装饰，而是在不确定场景里给用户控制感。
Compare & Confirm：把模糊聊天转成结构化承诺
Compare Helpers 按速度、距离、经验、信任信号和价格组织信息， 减少用户在聊天记录里来回比较的成本。Confirm Helper Card 再次明确时间、地点、 任务范围、费用和安全提示。
Decision support + clear commitment.
06 / Testing & Iteration
核心流程更容易完成和理解
我进行了两轮原型可用性测试。
平均发布用时 4:35 → 2:52
正确理解人数 4/8 → 7/8
的理解人数 3/6 → 6/6
07 / Responsive & System
Mobile-first，再同步关键 Web 页面
我使用 Figma 输出 80+ 个高保真 frames，覆盖 mobile app 的 requester / helper 核心流程、 关键状态页与 responsive web 关键页面适配，并整理关键组件与核心流程标注规范。
08 / Reflection
双边平台的关键，是降低第一次回应的信任成本
双边平台不是把两类用户放在一起就会自然互动。真正关键的是降低第一次回应的心理成本和信任成本， 让双方都能理解下一步行动的意义和边界。
Kapabala 证明了我在交互设计中的核心能力：从旧产品诊断、用户行为理解、 双边平台机制和原型测试出发，把模糊问题转化为可验证、可交付的核心体验闭环。