设计挑战
如何让用户独立、准确地完成复杂申请，并始终知道自己正在回答什么、为什么回答，以及下一步会发生什么？
用户不是不愿意填写，而是无法获得可控感。
当政策术语、材料不确定、网络中断和错误提示同时出现时，申请流程会把本应被服务的人推向退出。
01 — 场景
压力中的普通手机用户
用户可能在公共场所、旧设备或不稳定网络下申请；有人需要家人、社工或社区志愿者协助。
02 — 机会
把政策逻辑翻译成生活语言
不要求用户先理解分类。先问“和谁住在一起”，再逐人确认收入，最后由系统生成可检查的摘要。
“请说明申请人及共同居住人员过去四周所有可计算收入。”一个看似简单、却同时要求记忆、判断术语和理解范围的问题
传统表单
申请人收入类型 · 请选择
共同居住人员姓名 / 收入 / 频率
请说明所有可计算收入
长说明、多个输入框、术语不熟悉；用户需要同时记住“谁、什么、多久、怎么算”。
PlainPath
先建立事实，再完成分类现在和你一起住的人有谁？
让复杂流程变成一串可恢复的小决定。
章节不是为了制造进度压力，而是让用户知道已完成什么、还要处理什么，以及离开后可以从哪里回来。
申请全流程 UX User Flow
主流程恢复路径
- 进入与辅助设置语言、字号与朗读
- 资格预检判断是否值得继续不确定 → 人工确认 → 继续填写
- 分章填写单问题引导，自动保存中途离开 → 恢复到原章节
- 准备材料上传与清晰度检查材料缺失 → 替代证明或稍后补件
- 核对答案发现矛盾 → 返回具体章节修改
- 确认并提交获得申请编号与下一步说明
每个分支都留有继续申请的入口；暂停与修正后，回到对应章节。
A
单问题引导
解释“为什么需要”，允许“不确定”，避免一次出现多个决策。
B
可撤回的协助
按章节授权、设定有效期、默认隐藏敏感答案，申请人掌握最终提交。
C
状态先于错误
弱网时答案仍保存；上传失败只影响材料，不让用户失去已经完成的内容。
一个问题，一次判断，一条清楚的下一步。
点击手机原型中的选项，查看选择反馈、保存状态、材料缺失和矛盾修正的不同状态。
高保真交互状态
把“可计算收入”拆成用户真的能回答的问题。
关键不是把表单做得更短，而是降低每一步需要同时记住的内容，并在用户犹豫时给出恰到好处的解释。
- 默认朗读标签、示例、错误与隐私解释。
- 保留用户原始输入，同时自动格式化日期、金额与电话。
- 错误信息说明发生了什么，以及如何修复。
需要有人陪你填写？
PlainPath● 已自动保存
关于你的情况第 2 / 6 题
居住情况
现在和你一起住的人有谁？
这能帮助我们只询问与你情况有关的收入和材料。
收入情况
过去四周，你有收到哪些钱？
先从你记得的开始。没有也可以选择“没有收到”。
材料中心
你有最近四周的收入证明吗？
可以拍照上传，也可以稍后补交。
已保存：居住情况
你选择了“另一位成年人”
提交前核对
有一处需要你确认
你之前选择了“自己一个人”，但后来添加了另一位成年人。
请确认哪一个答案正确。
把不可见的负担，变成可以设计的对象。
PlainPath 的价值不只在于界面更“友好”，而在于减少用户需要同时记忆、判断和承担的事情。
同时记住的信息从一个问题拆成一个事实，再进入下一个事实。
陌生政策术语用生活语言提问，由系统在后台完成分类。
不可恢复的错误保留原始输入，错误直达具体章节与修复入口。
对后续的不确定每个状态都说明保存、处理阶段与下一步。
↓记忆负担
?术语门槛
↩修正成本
→下一步清晰
设计判断视觉元素只承担导航和解释功能；不为严肃的公共服务流程添加装饰性噪音。
先验证理解，再验证完成。
这是概念项目的轻量验证计划，不代表真实研究结果，也不对应某个地区的政策或法规。
招募 5–7 名参与者
尽量包含非母语者或较低数字熟练度用户。
完成四个关键任务
资格预检、收入问题、材料缺失、提交核对。
要求复述问题含义
观察用户是否理解“政府想知道什么”，不只记录点击成功。
邀请 2–3 名社工复核
检查信息是否足以支持后续人工审核。
理解
资格问题复述正确率
待验证
完成
独立完成率
待验证
修正
提交前主动纠错
待验证
信心
知道接下来会发生什么
待验证
研究问题
“为什么需要这项信息”应默认显示还是按需展开？用户如何判断材料是否符合要求？哪些信息不应默认向协助者开放？章节式进度、剩余时间和百分比，哪一种最能建立可控感？
设计不是替用户做决定，而是让决定变得可回答。
PlainPath 将复杂性留在系统内部，把用户看到的内容控制在当下真正需要的一步。
少一点术语
先问生活事实，再将答案映射到审核所需的政策字段。
多一点解释
用渐进披露回答“为什么”，不在首屏堆满说明。
始终能回来
自动保存、可恢复、可撤回，让暂停不等于失败。