写问题前先定义任务
明确谁填写表单、当时掌握什么、下一位处理者必须作出什么决策，以及哪些证据能证明结果。没有下游用途的字段只会增加填写负担，并不能改善流程。
- 用一句话说明提交者的任务。
- 明确下一负责人及其要作出的决策。
- 只保留支持路由、行动、证据或报表的字段。
- 区分系统已知信息与填写者必须输入的信息。
表单设计指南
清晰易用的业务表单设计指南
设计清晰的业务表单，使用目的明确的字段、条件区块、有效校验、无障碍错误提示、移动端适配布局，以及下一负责人可直接采取行动的数据。
构建表单及其业务流程
将设计转化为可运行的 Jodoo 表单、工作流、记录视图和 Dashboard
Jodoo 让经过培训的业务管理员在一个可配置应用中构建表单、条件规则、计算、角色权限、提交记录视图、审批工作流和 Dashboard。
打开 Jodoo 表单构建器设计顺序
从用户任务和下一项决策开始
用户能准确完成表单，下一负责人无需补齐缺失上下文即可行动，才算表单成功。
按用户可以回答的顺序对字段分组
先从熟悉的上下文开始，把相关问题放在一起，并将依赖前面选择的细节延后显示。简短且含义明确的区块，比堆满字段的长页面更容易浏览。
- 从用户熟悉的身份、申请、站点、资产或事项上下文开始。
- 把日期、金额、单位和证据放在其所解释的问题附近。
- 仅适用于部分情况的问题应使用条件分区。
- 让填写者先检查结果，再显示确认与提交操作。
为实际执行工作的人编写标签和帮助文本
使用目标用户熟悉的词语。标签应说明要输入什么；只有在能防止常见错误时，帮助文本才需解释边界、示例、格式或原因。
- 使用“要求交付日期”等明确标签，不要只写“日期”。
- 在数值或编码字段旁标明单位和可接受格式。
- 避免使用提交者无需了解的政策、实施和系统术语。
- 定稿布局前检查翻译后标签的长度。
通过验证帮助填写者纠正记录
验证应阻止不可用的提交，并说明如何修正。不要把每个字段都设为必填，也不要只重复字段标签而不给出指导。
- 只要求填写当前阶段所需的数据。
- 在必要处验证范围、格式、日期、合计值和跨字段关系。
- 把错误提示放在字段旁，并保留用户填写的其他答案。
- 将不确定或异常的值送审，不要强行制造虚假的精确性。
设计完成与退回状态
提交后体验仍应继续。确认已收到的内容，在适当时显示负责人或下一步预期，并让填写者清楚理解退回修改要求，同时不暴露内部数据。
- 编写有用的确认消息和参考编号。
- 保留提交的证据和决策历史。
- 记录被退回时，准确说明必须修改的内容。
- 让更正与原记录保持关联，而不是创建重复记录。
用真实的移动端数据和异常进行测试
空白的桌面预览看不出长标签、翻译、校验、照片、文件、签名、计算和条件分支带来的问题。请在用户实际使用的设备上测试完整表单。
- 涉及现场工作时，应使用手机尺寸视口和真实设备测试。
- 填写所有长字段、附加证据、触发校验并打开条件区块。
- 提交一条正常记录，并退回一条不完整记录。
- 让下一负责人无需口头解释即可根据提交数据采取行动。
表单设计检查清单
发布前逐层检查
在真实表单上使用检查清单，并加入实际数值、角色、设备和一个退回案例。
层级需要回答的问题需要检查的佐证常见失败情况
任务提交者要完成什么任务？一句话任务和明确受众表单照搬内部数据库，而不是围绕用户任务设计
决策下一位负责人要做什么决定或行动？明确负责人、路径、截止日期和结果字段已采集，却没有明确负责的下一步行动
字段每个字段是否都支持行动、证据或报表？从现场到决策的路径必填或重复问题过多
布局用户能否在移动端快速浏览并完成表单？用较长真实内容做手机端测试区块过长、过早换行、提交操作被隐藏
逻辑无关问题是否已隐藏，必填信息是否清晰可见？正常路径与条件路径可避免的错误发生后才提示必填字段
验证用户能否理解并修正错误？无效范围、格式、日期和缺失证据测试笼统的错误提示或丢失的答案
退回路径复核人能否准确指出需要更正的内容？退回原因、责任字段和保留的历史再次提交会生成重复记录
报表指标能否下钻到背后的源工作记录？从 Dashboard 下钻到记录图表只显示数量，没有负责人或行动
实际测试
通过四轮简短检查改进一份表单
从任务和数据设计推进到移动端填写与下游行动。
只有真实用户能够完成表单、下一角色无需重新拼凑上下文就能继续处理时，表单才算真正可用。
删除没有实际用途的字段
将每个字段映射到路由、行动、证据或报表，并删除其余字段。
- 明确受众。
- 明确决策。
- 标记系统已知值。
重写结构和标签
按自然顺序整理剩余问题，并替换内部术语。
- 使用简短分区。
- 补充单位和示例。
- 检查翻译后的长度。
测试移动端、逻辑和错误处理
在手机尺寸视图中使用真实数值、文件、照片、计算和条件分支测试。
- 触发每一种错误。
- 让提交按钮保持可见。
- 测试最长路径。
测试提交与退回
让下一负责人复核记录、退回一个问题，并完成更正后的案例。
- 保留历史。
- 确认角色权限。
- 打开仪表板下钻。
模板
明确设计规则后再比较不同表单
申请、巡检、登记和现场报告需要不同的术语与证据，但都可用以任务为先的设计方法避免多余问题和无法使用的记录。
最适合开始使用的模板将本指南应用到真实请求表单
打开采购请求表单，在桌面端和移动端完成填写，退回一条不完整记录，并在修改字段前检查提交值、工作流、负责人队列和 Dashboard。
常见问题
表单设计常见问题
好的表单设计是什么样的？
良好的表单设计帮助特定受众准确完成明确任务，只采集下一负责人能使用的数据，清楚解释错误，适配实际设备，并让回复与行动和报表保持关联。
一份表单应该有多少个字段？
没有适用于所有表单的固定数量。保留当前任务和决策所需字段，仅部分情况需要的信息应放在条件分区或后续工作流步骤中。
每个字段都应该必填吗？
不需要。只有当前阶段缺少该字段就无法路由、处理、验证或汇报记录时，才将其设为必填。过多必填字段会增加虚假或低质量答案。
表单在移动端应如何工作？
使用清晰分区、便于点击的控件、简洁标签、合适输入类型、尽量少的键盘输入、就近说明、明显的证据控件、可见错误提示和清晰提交操作，并在真实手机尺寸视图中测试实际数据。
表单提交后应该发生什么？
确认接收、分配记录、路由复核或审批、显示缺失或逾期工作、保留意见和决策、创建有人负责的跟进，并让 Dashboard 可从每个信号下钻到源记录。