表单，作为我们日常工作重要的项目内容，我们每周都会对其进行设计。而在我前几年的工作当中，接触到的更多是 简单零星的字段、朴实无华的组件。这对于在座“高级设计师”来说，做起来会比较简单。
而现在大多数 B 端产品，我们接触到的都是二三十个字段，并且每一个字段都会包含有大量的逻辑信息，针对这种情况，我们作为设计师应该如何应对？今天我们就来说说 复杂表单 的设计思路。
由于复杂表单本身比较难理解，我们会通过一个最近做的政府类的项目来带领大家进行分析，讲讲设计优化前后的点。
项目背景：
这次的项目为一个政企项目，主要是为某一线城市政府部分提供一个人群监控系统的设计优化，系统是为政府部门的重点人群，进行采集、核对、巡防，以达到管理的作用。整个流程当中会包含有 社工采集、巡防任务分发、社工巡防、区县审核，通过前期的资料收集，发现问题最多的便是社工采集流程。
痛点：
这次迭代主要的问题源自系统的采集端，走访、现场观察了社工的采集状况，大致可以整理为以下问题：
首先，在设计过程当中，我们依旧会做对应的基础设计，不过由于不是咱们这次讨论的重点，就不展开详细描述。而对于这个页面大家可以先思考，如果由你来进行接手，会如何进行优化。
信息预览
在上方的表单当中，我们会发现由于表单过长，导致用户会出现上下反复滚动的行为。在对这个行为进行挖掘时，明确原因是用户信息过多需要 反复确认，因此需要上下滚动，进而影响其填写效率。
对于确认的场景，我首先考虑到在页面右上方增加一个预览按钮，点击后会有预览页面。
但预览也需要反复点击跳转页面，本身并不是一个好的选择，为此我们考虑在原有的页面布局上进行优化。
在页面宽度上，很多同学会觉得越宽越好，比如一个页面，会尽可能压榨其宽度，产出这样的一些页面。
实际上，我们的宽度，也会有一定的限制，才能够让用户更为聚焦，比如常见的文档产品，他们在宽度的设定上，都会默认在 700-900 之间，这样才能够保证用户聚焦于整个文档当中，如果过长，你会发现我们不太愿意认真的去阅读里面的内容。
因此大多数情况下，我们的表单列数以两列为主，最多不要超过三列。而在布局上，并不是说我们其他空间的位置就不能去排布信息，而是不能去展示核心内容，因此，我们可以考虑将次要内容放在核心内容模块两侧。
同时在设计上，页面长度的增加会导致我们无法对页面整体的内容有完整的了解，因为不同的组件都会占据页面的整体高度，当页面内容超过一屏时，我们在确认信息的时候，就只能通过上下滚动页面的方式进行确认，导致效率低。针对上述的所有情况下，我们会考虑采用左右结构的版式，将右侧区域作为一个独立的预览模块。在左侧填写表单时，右侧预览区域将有一个实时预览，从而对输入的内容进行快速判断和确认。
通过点击预览区域的字段也可以快速定位到左侧该字段位置，从而帮助我们在不同信息之间的来回跳转。
其次右侧预览也能够起到锚点定位的作用，能够帮助我们在不同信息之间来回跳转。
弊端：
当然，任何方案都会有两面性。使用左右布局的方式，也就意味着我们在屏幕的最小宽度上需要由之前方案的 1280px，变为现在方案的 1360px。这也就意味着对于屏幕尺寸的兼容会更少。但目前系统使用 1280px 的情况并不多，我们可以稍加牺牲。同时作为方案的兜底，考虑让开发实现当页面尺寸小于 1360px 时，目前是提醒用户通过浏览器自带的缩放功能解决，后续会采用响应式布局，将右侧内容移至底部进行展示。
在我们最后方案评审前，我们再进行走查会发现：“很多用户并不会在意右侧的所有信息”。
为此，我们对最终方案的交互又一次进行调整，将之前的提交操作移至右侧，并将右侧的展示信息进行优化。这样的页面信息布局，让用户在提交表单之前，能够对表单内容快速的确认。也保证了用户会利用到调整后的页面，同时也一定程度上降低了用户对负反馈的接收，使其更准确的进行填写。（当然这是在下方的方案做完过后的决定，具体原因下方也会讲到）
