移动端原型测试与用户反馈收集，重点不是问用户“喜不喜欢”，而是观察他们能否在手机上完成目标、在哪一步犹豫，以及原型本身是否影响判断。按以下五步执行，即使手头只有可点击的低保真原型，也能获得可用于改进的信息。
第一步：先定要验证的决策
把测试目标写成一个具体问题，例如“用户能否在日历应用中找到并修改已有日程”，而不是笼统地写“测试日历体验”。同时说明本轮测试要支持什么决策：是调整页面结构、补充操作提示，还是确认某个流程是否值得继续开发。
检查原型是否能走完目标路径。若按钮尚未连接、页面跳转不完整，要提前标明限制，避免把原型缺陷误判成产品设计问题。每轮优先验证少量关键目标，通常安排两到四项任务更便于观察；实际数量应按单项任务复杂度和测试时长调整。
第二步：招募符合条件的用户
招募对象应接近真实目标用户，不必只找同事或熟人。先列出与测试有关的条件，例如是否经常使用智能手机、是否用过同类功能、是否属于新用户；条件应服务于本轮问题，不要收集无关的个人信息。
可先安排约五至八名参与者进行一轮探索性测试，再根据发现的问题修改原型并补测。这个范围适合发现常见的可用性障碍，不代表统计意义上的结论；如果用户群差异明显，应分别观察不同群体。预约时告知测试时长、设备要求、是否录屏以及资料用途，并取得同意。
第三步：把任务写成真实情境
任务描述要给出目的，不要提示按钮位置或操作顺序。比如，请参与者在地图应用原型中查看前往某地点的公共交通路线，并比较路线耗时。这样的任务既有明确结果，也不会直接教用户怎么操作。
准备手机或可运行原型的设备，确认屏幕方向、网络依赖、返回方式和原型跳转都符合测试安排。若在桌面上远程演示，参与者实际触屏与观看他人代操作并不相同，记录中应注明测试方式。主持人可使用同一份任务卡和开场说明，减少不同场次之间的引导差异。
第四步：观察操作，少给提示
请参与者边操作边说出正在寻找什么、哪里不确定。主持人保持中立，不要立刻解释图标或指出下一步；若参与者卡住，可先问“你现在会怎么做”，再判断是否需要结束该任务。这样得到的反馈更接近真实使用中的问题。
每项任务记录是否完成、明显停顿、误触或回退、参与者原话，以及主持人提供过的提示。需要录音或录屏时，先说明用途并征得同意；不需要的个人信息不要记录。移动端产品原型测试与用户反馈收集应把“看见的行为”和“对行为的解释”分开写，避免把观察直接变成未经验证的结论。
第五步：整理反馈并确定改进顺序
测试结束后尽快整理笔记，可用表格记录任务、观察到的行为、原话、影响和建议方向。将问题归为导航与信息层级、文案理解、触控操作、系统状态反馈等类别；同一问题在多位参与者身上出现时，合并记录但保留每次出现的证据。
排序时同时看出现频率、对任务的影响和修复成本。阻断关键任务的问题通常应优先处理；低频但可能造成严重误操作的问题也不能只因出现次数少就忽略。把“按钮不明显”改写为具体观察，例如“参与者在页面停留后仍未发现继续入口”，后续团队才能讨论布局、文案或视觉层级等不同原因。
最后形成一页简报：本轮目标、参与者条件、测试方式、主要发现、证据和待验证的改动。每项改动指定负责人或复核方式；原型更新后，用相同任务检查问题是否消失。持续记录这一轮轮结果，移动端产品原型测试与用户反馈收集才会从零散意见变成可追踪的设计依据。
常见问题
一定要用高保真原型吗？
不一定。测试页面结构和任务路径时，低保真原型通常够用；涉及动效、触控反馈或视觉辨识时，再提高交互或视觉保真度。
参与者问“这里应该点哪里”怎么办？
先请对方说说当前的判断，避免马上提示。若确实需要介入，记录提示内容，并把该次表现与未提示的任务区分开。
怎样判断反馈是不是个别意见？
结合出现次数、任务影响和用户原话判断，并检查是否与测试条件有关。单次反馈也可能揭示严重风险，但不应未经复核就当成普遍结论。
测试结束后先改什么？
优先处理阻断关键任务、容易导致错误理解或反复出现的问题；改动后用原任务复测，确认改善没有引入新的障碍。