公务系统设计(二)-执法终端

项目背景

在互联网及大数据技术推广之前，交警执法的工作开展起来比较麻烦。传统的执法都是纸质开单，事后统计，数据更新不及时，各辖区数据对接不统一；接到报警后需要先问清楚警情再赶到现场处理，其过程非常耗时；进行工作汇报的时候需要另外拍摄图片难以简单讲清楚。

因此我们需要一个专门针对交警使用的，可以提高执法效率，减少数据录错率，同时操作方便，后续利于增加完善功能的工具。基于这些需要，移动执法平台应运而生。

项目内容

移动执法平台与后台几乎是同期进行设计开发，二者功能互相关联。可以这么理解，移动执法平台是执法后台的轻便版本，它保留了后台的主要功能操作，又具有一线交警执法时的必要项目。携带安装了这款软件的硬件设备，即使只有一名交警在现场执法，效率也能大大提高。

由于需求紧急，功能众多，前期需要对所有需要进行筛选整理。尽快上线的1.0版本必须要包含主要常用的执法功能。

每次小版本迭代更新都进行功能优化，使操作更简单更符合交警执法的流程。

在设计开发过程中，由于人员较少，时间紧急，设计与开发是同时进行的。

设计思路

根据产品给出的导图简单分析需求，哪种操作会频繁出现，页面之间的关联如何等。

移动执法平台因其使用人群工作的特殊性，表单输入数据录入特别多。既然有数据录入，那么录入后数据如何展示，统计的图表以哪种方式展示统计数据，是否能查看详细数据，详细到何种程度，如何操作，这些都需要考虑。

设计过程

1.原型绘制

原型绘制两种。第一步，简单的线框原型，确定大致布局，页面之间的跳转交互，这里与产品过审。确定没有大问题后，在此基础上细化，进入第二步，完成高保真原型。高保真原型完成后再次与产品过审，并抄送给领导。领导那边认为跟平常执法的操作不冲突，没有问题后，即可抄送给开发进入下一阶段。

2.构建设计规范、组件库

构建规范包括但不限于：标签：类别标签，状态标签；按钮：表单按钮，列表按钮，筛选框按钮；输入框：表单输入框，搜索输入框；toast提示：loading提示，文字提示；字体字号及应用场景等。

之前实习的时候被开发小哥科普了一下，有点复杂当时没听懂只记住了显示屏的1个点对应4个像素。因此，在进行设计的时候都是尽量使用4的倍数值，或者至少是偶数值，避免出现像素偏移。

这里使用了720*1280尺寸的画板进行设计。

配色。这里顾虑到行业特性以及使用人群特征，使用了蓝色作为主色。字体颜色使用了比较深的灰蓝色。一些提醒、表示状态的颜色保持与主色灰度或明度一致。

字体及字号。这里沿用了Android原生的字体。字号控制在了五个，相同内容、功能的文字信息使用同种字号，同时使用颜色区分是否可点击。

诸如圆角、标签、toast、按钮，列出不同的类型的使用场景并加以说明。在需求文档里可更详细地进行描述，比如toast两种类型分别出现的位置，以什么方式出现，停留时长等。

3.整理设计稿

差不多可以进行测试的时候，对全部的设计稿再进行一次整理。

在开发的过程中（不确定是不是都会遇到这种情况），领导、产品突然对某个已完成的页面提出修改，功能的修改、元素的修改、操作布局的修改都有可能。我个人在修改页面的时候会复制一个画板，然后在新复制的画板上进行修改调整。或者，他们也许还会突然要求增加一些页面，但是没有说明是属于哪一个模块内的，手头上正在进行别的页面设计的时候，可能随手就在旁边新建一个画板补充了。当这种突然提出的修改要求多了，设计稿原件就会出现很多不需要的画板，功能位置不知道属于哪里的画板。

对全部的设计稿重新进行一次整理，清理掉重复的这版本里没使用的页面，将中途补充的页面归纳到对应的模块里。重新整理一遍设计稿也相当于重新梳理了一遍功能及流程，对迭代更新如何优化能提供能多想法的。

总结

因为团队人员非常少，项目时间紧迫，前期设计的时候还是细心点考虑多一些使用时可能出现的情况及应对方案比较好。已经开发到一半发现有问题要返工的时候，可能会打起来呢（bushi）。

开发互联网产品的想法并不完全适合公务应用。公务系统有自己特有的一套习惯、流程方式，盲目硬是套用普遍互联网应用的方式可能会让使用这个应用的人更加不知道该怎么用，会让他们觉得这个产品反而让办公办事更加复杂化。

不管是什么产品，都还是自己也先了解使用人群，从他们的一方出发来考虑，如何让他们使用起来更方便。