表单原型设计要同时画清三件事：用户需要填什么，什么时候看到提示，提交后去哪里。以企业成员邀请表单为例，先确定姓名、工作邮箱、所属部门和角色，再补空值、格式错误、重复邀请与提交失败状态。你可以用墨刀AI生成表单原型搭建初稿，再用组件和交互完善细节。
表单不是把输入框排整齐就结束。用户能否理解字段、修正错误并保留已填内容，往往比视觉装饰更影响完成体验。下面围绕同一个邀请表单说明设计方法。
先删掉不必要的字段，再安排输入顺序
邀请企业成员时，工作邮箱用于接收邀请，角色决定加入后的权限，所属部门用于组织管理。姓名如果允许成员加入后自行完善，就未必需要在邀请时强制填写。不要因为模板有手机、地址和生日字段，就全部保留。
| 字段 | 本例的填写规则 | 需要显示的说明 |
|---|---|---|
| 工作邮箱 | 必填，用于接收邀请 | 填写可接收企业邀请的邮箱 |
| 所属部门 | 必选，从现有部门中选择 | 无部门时如何申请或联系管理员 |
| 角色 | 本例默认普通成员 | 普通成员与管理员的权限差异 |
| 姓名 | 选填，可在加入后补充 | 明确标注选填，不用猜测 |
这是一组教学规则，并非所有企业产品都应采用的默认设置。字段是否必填、谁可以邀请管理员、外部邮箱能否加入，需要由当前业务确认。先把这些规则写在原型说明中，再开始布局。
标签一直可见，比只放占位文字更清楚
不要只在空输入框里写“请输入工作邮箱”，因为用户开始输入后，这段文字就可能消失。字段上方或左侧应保留稳定的“工作邮箱”标签，示例格式和用途放在辅助说明里。必填、选填也应采用统一表达，不只依赖颜色或星号让人猜。
W3C表单教程强调标签、说明、分组和反馈对于表单可用性的重要性。原型阶段可以先把这些内容画出来，并在交付时注明标签与控件需要正确关联；画面上有文字，不代表最终代码已经具备相应的无障碍语义。
桌面可以分组，手机尽量顺着往下填
本例可以分为“成员信息”和“加入设置”两组，让邮箱与姓名在前，部门与角色在后。短表单采用单列通常更容易扫描；如果桌面端确实需要双列，应检查阅读和键盘操作顺序，避免用户不知道下一项在哪里。
移动端不要简单缩小桌面表单。部门选择器、长邮箱和错误说明都需要完整显示，提交按钮也不能遮住最后一个字段。页面较长时，可保留清晰的分组标题，但不要为了显得完整给四个字段拆出多个步骤。
错误提示要说清哪里错、怎么改
用户刚输入邮箱第一个字符时，不必立即出现一片红色。可在离开字段或尝试提交后检查格式，再按产品场景决定后续反馈时机。提示“邮箱格式不完整，请补充邮箱域名”，比“输入有误”更能帮助用户修正。
对于重复邀请，应区分“已是成员”和“邀请待接受”。前者可引导查看成员资料，后者可提供重新发送的操作，但是否允许重发以及频率限制应由业务确认。不要把两种情况都当成邮箱格式错误。
别只画红边，也要保留可读的文字
错误状态应包含文字说明，并放在对应字段附近；提交后有多个错误时，可让用户看到概览并找到具体位置。不能只靠红色区分错误与正常。更完整的反馈原则可参考W3C表单通知说明。
提交按钮之后，还要设计四种结果
- 正在提交：明确显示处理中，避免用户不确定是否点到。
- 提交成功：告诉用户邀请发往哪个邮箱，并给出返回成员列表的入口。
- 提交失败：说明可以重试，保留已填写的信息。
- 重复操作：明确不会因为连续点击就产生多条有效邀请。
最后一项不仅是按钮禁用的问题。原型可以表达界面行为，但真实系统仍需由服务端处理权限、数据校验和重复请求。前端校验不能替代服务端校验，原型中可点击也不代表接口已经接通。
复用模板时，优先看状态，不只看样式
可以从表单原型素材或登录页原型素材寻找布局参考，实际使用权限以素材页为准。复制后应替换字段、默认值和错误文案，而不是只改Logo。
若模板只包含默认状态，可先复制关键页面，分别画出错误、加载和成功状态，再建立交互。复杂字段依赖如“选择外部成员后增加有效期”，应明确哪些字段出现、已有数据是否保留。
用AI起稿，再按一份邀请任务走完
设计企业成员邀请表单，包含工作邮箱、所属部门、角色和选填姓名。邮箱与部门必填，角色默认普通成员；管理员角色需显示权限说明。补充邮箱格式错误、已是成员、邀请待接受、提交中、成功和失败状态。移动端单列布局，错误时保留输入内容。不要接真实邮件发送服务。
生成后让同事用长邮箱、空部门和重复成员分别试一次。每种情况都应有明确结果。如果还需要整理验收记录，可参考测试用例怎么写；要继续搭建点击与状态变化，再看交互原型设计。在墨刀AI创建表单初稿后，把错误恢复和提交结果一起做好，表单才真正便于评审。
