业务订单的设计流程详解（2）

　　本文主要说明订单功能在产品设计中常见的信息架构与设计思路，希望帮助未接触过订单模块的产品经理对于设计流程有大致的了解。
　　一、订单信息设计
　　在完成了流程和状态的设计之后，需要进一步确认订单包含的所有信息
　　1。确认订单编码生成规则、标识
　　订单编码有一个最常见的也是最简单的组成方式，标识时间戳随机编号，如果是企业内部的订单或者预计订单量不会非常庞大的话，完全可以使用这套规则来生成订单，这样内部人员在看到订单编码的时候就能迅速分辨出订单类型和订单日期。
　　标识：可以为纯数字，可以为英文组合
　　时间戳：一般为YYMMDDHHMM格式，
　　随机编号：一组随机数字，根据上面时间戳的末位和订单预计生成量来决定使用多长的随机编号
　　如果是外部订单，为了不容易被发现规则，以上3个元素的位置可以任意组合。
　　现在主流平台的外部订单大多都已经不使用以上组成方式，一来是因为这种编码方式太过直白，容易暴露例如订单量等公司内部信息，二来是因为当要在短时间内生成大批量订单的时候，为了确保订单编码不重复，就要重复比对历史订单。随机码越长时，对服务器造成的压力也就越大。
　　2。订单编码的重要原则
　　（1）唯一不重复
　　无论生成规则如何设计，最重要的就是一点，保证订单编码的唯一性。
　　（2）安全
　　订单编号不能暴露出公司的信息
　　（3）控制长度
　　订单号的主要作用是查询，在某些需要输入或者用户念出来的情况下，订单号长度并不是越长越好。
　　（4）尽量保持纯数字
　　纯数字的检索在数据库订单查询时效率要高于文本型（字母加数字）
　　以淘宝订单为例，84034576013582XXXX，
　　总共18位，前14位为序号，1516位买家ID的倒数12位，1718位买家ID的倒数34位
　　3。确认字段及字段规则
　　订单的字段往往包括几大模块
　　基本信息：包括订单编号、用户名称、提交时间等等
　　商品信息：包括商品名称、数量等等
　　支付信息：包括总金额、支付金额、优惠金额等等
　　在开始设计各个端口的线框图原型之前，最好将所有字段用表格或者脑图罗列出来，避免后续设计过程中遗漏了重要的字段。
　　二、订单操作设计
　　1。基础操作增删改查
　　对订单的操作本质上跟对数据库的操作一样，常见的基础操作无非就是增删改查、提交、取消这几个。
　　在设计操作时，最重要的有几点：
　　操作的条件需要满足什么样的条件下才能进行当前操作？订单处于什么状态？相关的其他数据处于什么状态？
　　操作的影响这一步操作完成之后，订单会发生什么样的变化？会影响到哪些功能和数据？
　　操作的结果操作的时候会得到什么结果？会遇到什么样的异常状态？需要怎么处理？这是设计时常常会遗漏的部分，最好把所有可以预想到的结果梳理出来，避免后面开发的时候发现问题。
　　操作的可撤销性操作是否可逆？如果不可逆是否考虑增加二次确认让用户充分了解操作的后果？
　　2。操作权限
　　订单具备业务承载作用，是安全性要求很高的数据。虽然在实现层面不需要对订单模块单独开发一套权限功能，但是一定要明确不同权限用户对订单的操作。
　　三、订单列表设计
　　对订单的内容完成了设计之后，就要开始进行列表的设计。
　　1。列表字段
　　同样是订单列表，移动端和PC端的表现形式相差很远，但是在把订单字段全部列出来的情况下，第一步需要做的就是把重要且必须的信息抽出来组合成表单。
　　在这里说几个常见的移动端和PC端设计上的区别
　　（1）内容展示量
　　相比起PC端，移动端每一屏能展示的内容更少。在常见的电商平台移动端里，就算是大屏手机一屏幕最多也就展示23个订单，所以在展示字段和确认布局的时候就要更加严格，不能什么字段都往上塞。
　　（2）操作侧重点
　　移动端的特性决定了订单列表的更多作用是查看最近的订单和快速操作，PC端则是在这个基础上承载了更多，例如对历史订单的查找和管理功能。
　　淘宝的PC端有多个筛选条件、排序等功能，而移动端则是只能按照订单时间顺序排列，顶端也只有一个输入框对商品标题或订单号进行搜索。
　　2。列表操作
　　对列表的操作可以分为几类：查询、筛选、排序。
　　以下为各类操作需要注意的点
　　查询要区分开精准搜索、模糊搜索，对文本类一般为模糊搜索，而对订单编码类的则是精准搜索；
　　筛选注意选项是否可多选，是否有全选的选项（等于空选项）；无论是查询还是筛选，操作所指向的字段最好能与列表中的字段对应得上。例如对订单金额进行了筛选，可是订单列表中却没有出现订单金额的字段，用户会对搜索结果感到困惑，不知道对列表的操作是否已经生效了。
　　排序常见的排序是对时间字段进行正序或倒序排列，如果需要对文本类型的字段进行排序，最好是先了解数据库的排序规则；
　　小结
　　常见的订单设计从梳理流程开始，到订单字段、列表的设计就算是结束了。但是还有很多更加复杂的功能尚未提及，在实际系统构建过程中需要注意灵活运用，灵活设计。
　　相关阅读
　　业务订单的设计流程详解（1）