既定改造方案
基于上一篇分析出的种种问题，我们将库房人员的系统操作划分为两大类。
第一类为货物驱动的操作，这类操作主要随着货物而前进，人员不看或者看软件的次数比较少，更多是对货物的状态进行系统上的确认和进行下一步的业务数据准备。
第二类为任务驱动的操作，这类在库房目前特指质控的相关工作（这边的领域会有其它的定义），更多是为了处理各种紧急情况、异常情况和纯系统操作，我们将上面的各种情况抽象为一个个的任务，让质控人员来处理一个又一个的任务。
货物驱动模式
在货物驱动的工作场景中，定义人员进行尽量少的系统操作，条件允许的情况下使用PDA代替电脑进行简单的操作，条件不允许或者必须使用电脑进行的操作，设计遵循以下几个原则
- 菜单和角色绑定，不再进行单独的权限设置
- 菜单不再按照功能模块进行拆分，而按照操作单元进行拆分，尽量减少菜单数量
- 所有货物操作由一个扫描框起（灵感来源于搜索引擎），系统自动识别所需操作
- 强引导模式，将操作动线限定在比较固定的范围内
- 减少列表的使用或原则上禁止使用列表
- 将视觉焦点定义出来，并将重点区域进行极夸张的放大
- 严格控制界面元素，将元素维持在尽量少的数量内
- 非重点区域，进行视觉上的略化
- 所有操作界面必须支持全键盘操作，尽量不使用鼠标
上面不是所有的设计原则，仅包含特别重要的部分。
任务驱动模式
在任务驱动的工作场景中，约定了几个要点
- 任务找人而不是人找任务
- 为用户提供充分的决策辅助
- 一个界面处理所有任务，无需切换
在这个前提下，我们选用了给客服提供的一套工作平台，界面设计上类似于Slack。
我们将所有任务虚拟成消息放在左边的channel（slack位置）的位置，中间用来推送不同任务的处理界面，把各种内外部系统整合后放在最右边栏根据不同的任务场景推送给用户，用作决策支持。
当然在里面还做了很多小的工具，比如地址、电话的自动识别的，订单的自动连接啊，多异常合并，不同质控或者质控和外部人员的信息互通，目的都是为了加速质控人员的处理效率，降低错误。
上图为Slack图
基于上面的两个设计，我们就志得意满的开始打造我们的新版WMS系统了，但是到此还没完，中间出了一些变数，下篇我们再继续讲。