移动端表单的难点不在于把输入框缩小，而在于用户往往只看得见半块屏幕：键盘占据下方空间，验证码切换会中断填写，网络失败后可能需要重新提交。如果设计稿只有一张所有字段都填好的页面，很多真正影响任务完成的问题会直到开发后才暴露。
本文以“预约产品演示”为贯穿任务，检查用户从开始输入到收到结果的全过程。桌面表单通用的字段规划可参考表单设计技巧；本文重点处理手机上的键盘、恢复和提交状态，不把按钮营销文案当成表单设计的全部。
1. 先删掉当前任务不需要的问题
预约演示真正需要的可能是姓名、联系方式、意向时间，以及帮助安排演示的需求简述。公司规模、详细地址、所属行业是否都必须在首次提交前收集，需要逐项说明用途。没有明确使用者和使用时点的字段，先移到预约成功之后，而不是默认为必填。
把字段分成完成当前任务必需、能帮助服务但可选、只为后续营销三类。对可选项直接标注“选填”，让用户知道留空不会卡住。GOV.UK的问题页面指南强调先弄清每个问题的必要性。实际项目应把必填说明统一写清，避免一部分字段加星号，另一部分字段又采用完全不同的约定。
短任务通常可以一页完成；涉及多个决策或资料准备的长任务，可以按用户理解的步骤拆分。不能机械地把十个字段变成十页。评估拆分时，要看每一步是否形成一个完整问题、返回后信息是否保留，以及用户是否知道还需准备哪些资料。步骤条应反映真实流程，条件分支变化时也要同步。
2. 标签始终可见，提示只解释容易出错的规则
“请输入邮箱”如果只放在占位文字里，用户开始输入后就失去字段名称。用固定标签说明填写什么，在必要处增加简短提示，例如“用于接收预约确认”。W3C表单标签教程要求控件有可识别、与控件建立关联的标签；设计交付时也要标明这层语义，而不仅是在输入框上方画一段文字。
提示说明格式，错误说明哪里不符合规则，两者不要互相覆盖。预约时间可以在选择前说明时区；附件上传可以先说明文件类型和大小限制。不要等用户完成选择后才告诉他规则。电话号码则需要考虑服务覆盖地区，不能把所有号码都限定为某一种长度再宣称支持国际用户。
手机上的单列排列通常更容易建立“标签—输入框—反馈”的阅读顺序。只有自然成组且长度明确的字段才考虑同排，并测试长标签、文本放大和较窄屏幕。姓名和电子邮箱不应因为看上去能并排就被压成两个难以核对的短输入框。
3. 选择适合输入任务的键盘，但保留真实校验
邮箱、电话、数字代码和自由文本需要不同的输入体验。MDN对inputmode的说明指出，它是给虚拟键盘的输入模式提示，不会自动施加校验规则。因此“弹出数字键盘”不等于后台已经拒绝非法值，设计文档应分别写键盘提示与允许的数据格式。
验证码、邮编这类“看起来全是数字”的信息并不一定是数值运算对象；要确认是否允许前导零。金额还涉及小数分隔符与币种，不能只写“数字输入”。邮箱字段需要允许常见符号和粘贴，不应擅自把大小写、空格处理规则隐藏在界面之外。与研发一起确定前后端归一化规则，再写出错误提示。
在原型中放入软键盘占位区域，检查当前字段、错误提示和主要操作是否仍可见。若采用底部固定按钮，键盘打开后不能压住输入框，也不能让按钮突然跳到无关联的位置。向下滚动后应仍能识别当前填写的问题，关闭键盘也不应把页面带回顶部。
还要测试系统自动填充、粘贴和密码管理器等真实输入路径。用户从邮箱应用切回表单后，已填写内容应该尽可能保留。涉及敏感信息时，由产品和研发约定保留范围与时长；不要用“方便”作为长期存储所有输入的理由。
4. 让错误可以被找到，也可以被修正
错误提示最少回答三个问题：哪一项有问题、为什么无法继续、怎样改正。“输入错误”没有提供恢复路径；“请输入包含@的邮箱地址”则说明了修正方向。字段级错误放在对应控件附近，不能只把边框变红。多个错误分散在长页面时，还要提供清晰的定位入口。
GOV.UK错误摘要组件采用顶部摘要和字段旁错误配合，摘要链接能够带用户到相应输入位置。移动表单可以借鉴这条关系：提交失败后先知道哪些地方要改，再直接进入字段。摘要和字段旁的措辞应一致，不要一个说“联系方式无效”，另一个却说“缺少邮箱”。
校验时机也要考虑用户是否已经完成输入。用户刚键入邮箱第一个字母就显示红色错误，会把正常输入过程当成失败；涉及跨字段关系、账户状态或服务可用性的校验则需要明确的等待反馈。无论采用失焦还是提交校验，都应允许用户顺畅修改，不在纠错过程中反复抢走输入焦点。包含条件字段的长表单，可结合B端表单的字段分组与联动规则逐项检查。
错误不应该清空其它正确数据。例如邮箱格式不符，姓名和已选时间仍应保留；网络超时，也不能自动断言预约没有创建。后者需要让研发确认服务端状态并提供可安全重试的方案。设计稿应把“字段不符合规则”和“系统未能确认结果”画成不同的状态。
5. 按钮说清下一步，提交过程避免二次操作
预约最后一步可以使用“提交预约”，中间步骤使用“下一步”，修改阶段使用“保存修改”。不要每一步都写“确定”，让用户无法预判点击后是否已经完成。按钮附近展示用户确实需要理解的信息，例如预约提交后还需要等待确认，而不是用无关的承诺挤占填写空间。
点击提交后应给出正在处理的反馈，同时处理重复点击。前端临时禁用按钮只能减少重复操作，不能替代后端去重或幂等控制。验收时快速连点、切换网络并返回页面，确认最终只产生一条预约记录；如果无法保证，记录为发布前要解决的业务风险。
成功状态要明确告诉用户已完成什么、接下来会发生什么以及如何查看记录。例如显示预约编号、提交的意向时间和“等待工作人员确认”，而不是只有一个绿色勾。若系统只接受了申请，就不要写成“预约已确认”。空状态与错误状态的区分可结合页面状态设计方法一起建立。
6. 把预约表单交付成状态清单
在Pixso中建一组相同宽度的画板，分别放初始、正在输入、格式错误、提交中、成功和结果未确认六个状态。复用输入框组件，同时让标签、提示、错误和禁用状态都有明确变体。评审时按任务走一遍，而不是逐张询问颜色是否喜欢。
给研发的说明可以写成具体用例：“姓名已填，邮箱缺少@，点击提交；姓名保留，邮箱旁显示修正提示，用户能定位邮箱；补全后再次提交，只创建一条预约；成功页展示已提交时间。”这一条就同时覆盖了错误定位、数据保留和重复提交，比“优化用户体验”更容易验证。
如果业务后台包含复杂的条件字段、批量输入或多人审批，不应全部挤进移动预约表单。可以将移动端收敛为当前用户最常完成的任务，把后台信息组织问题交给B端表单设计单独解决，避免一个页面承担彼此冲突的目标。
7. 在真机上完成最后一轮检查
- 逐字段输入时，标签、提示与当前输入值是否同时可见？
- 键盘打开、收起和切换输入法后，页面是否仍能正常滚动？
- 自动填充与手动粘贴能否完成任务，前导零是否被保留？
- 只用键盘或辅助技术能否识别字段、错误与提交结果？
- 返回上一步、切换应用和短暂断网后，输入是否按约定保留？
- 连续点击提交会不会产生重复记录，结果未确认时是否有安全恢复路径？
完成率可以帮助观察整体变化，字段错误率、放弃位置和重复提交次数则能定位具体问题。比较前后版本时，应尽量保持入口、用户群和任务条件一致。先把“能顺利填完、知道是否成功”做好，再讨论转化率提升，才能让优化结果与设计改动建立可信的联系。
