订单的概念
订单这个概念想必大家都不陌生，但是需要注意的是，不一定是付款购买的才算是订单。企业中大多数的业务流都是以订单的形式来承载的，而这篇文章将会用几个模块来解释一下订单设计流程中的重要组成部分。
文中描述的设计流程和阶段产出物都是按照最详细的步骤来实施，在现实工作过程中如果因为时间限制没办法完全满足的话，也可以在输出文档过程中不时回顾一下。但是在经验不足的情况下，还是建议尽量把前期准备工作做好。
一、设计之前
无论是toC还是toB，在任何功能开始之前，调研和了解都不可或缺。
1. 明确对象
在开始设计订单之前，首先要明确订单的涉及对象。
以设计常见的电商订单为例，涉及的最基础外部对象有消费者、卖家、物流服务商，企业内部有运营、客服、仓库等多个部门，根据各个平台的不同情况还会涉及财务、风控等等。
明确对象的好处和必要性体现在，后续进行设计时可以保证：
- 减少遗漏订单节点的发生
- 保证能迅速找到节点的负责人
- 确保对各个环节的把控
2. 了解业务流程
在你明确了对象之后，就可以开始与业务部门进行沟通，了解他们对于这个业务的定位和需求。
这里的业务部门可以是互联网的运营、市场，也可以是企业内部的相关业务人员。
有人的地方就有江湖，在梳理业务流程的过程中，各个业务部门之间不可避免会有各种冲突和意见。作为对整体流程负责的产品经理，需要把控好业务与系统流程的结合点，不能让业务的需求无限膨胀，但是也不能忽略这些专业人士的需求，否则会发现最终做出来的东西根本没办法用。
3. 阶段产出物——业务对象分析图、业务流程图
在完成了初步的沟通之后，需要一张业务对象分析图、多张业务流程图承载你们的沟通过程和结果。同时这些流程图也可以作为记录，避免后续的扯皮。
（1）业务对象分析图
有利于后续接触项目的成员可以迅速掌握项目情况，也可以帮助你拆分相应的业务流程图，减少遗留的情况出现。对业务对象分析图的要求有：
- 包含所有业务对象及对应的关键动作；
- 标记三流——订单流（信息流）、资金流、物流，如果没有资金流物流的话可以忽略不计。
（2）业务流程图
可以帮助你进行后续的系统设计工作，一张合格的业务流程图需要做到以下几点：
- 业务闭环——业务需要完成闭环，就需要考虑到上游和下游的业务衔接，不要出现突然出现的信息或环节；
- 把控好颗粒度，不出现过多的判断——业务流程图的主要作用是展现业务，一般不需要出现大量的系统判断，影响阅读性；
- 确保阅读顺序——常见的是从左至右，从上至下，考虑到阅读性，尽量保持在一个方向滚动，减少又要左右滚又要上下滚的情况。
二、系统设计
在于业务同事完成了沟通，对业务流程有了一致的共识之后，就可以开始进行系统设计了。
首先，我们需要对订单流程进行下一步的细化。
1. 订单流设计
在这个阶段，还不能直接动手画原型写文档，因为业务流程≠系统流程。
所以，为了避免后续画原型时出现遗漏或者冲突而影响文档的交付时间，需要对订单状态进行设计。
展现订单流程的关键元素就是订单状态，为了让真正的使用对象可以迅速明确订单所处的流程，我们需要把操作和状态进行结合。
这个时候就要对订单状态进行规划，原型永远是最后才做的。
（1）确认合理并且必要的状态
1）一个订单可以有多个状态
还是以电商订单为例，因为在实际业务过程中可能会存在多个分支，只用一个订单状态显然不合适。所以设计人员一般会为订单规划多个订单状态，例如一个总的订单状态、发货状态、付款状态、退款状态等等。
2）状态映射表
如果订单状态非常的多，外部用户看起来难免会头晕眼花，这个时候就需要设计一个状态映射表，用符合外部使用者心智模型的设计方式来巧妙地显示状态
（2）考虑触发状态变更的动作
从状态A到状态B，是通过什么动作来触发的，自动还是手动，这些都要提前思考清楚
（3）考虑状态变更触发的动作
订单状态变更时，是否会触发其他环节？
（4）考虑逆向流程
订单是否可以取消？什么时候可以取消？谁能发起取消？取消之后怎么处理？（涉及物流和资金流时尤其需要慎重考虑）
（5）考虑上下游
如果你目前所设计的订单流程中还有上游流程和下游流程，或者涉及多个系统的交互，那么就要考虑清楚与上下游、其他系统的信息交互问题。
2. 阶段产出物——状态机图、系统流程图、状态映射表
（1）状态机图
用于展示订单状态的变化流程，主要便于项目人员快速了解订单在系统中的流向和关键操作
（2）系统流程图
展示业务对象及其在系统中的操作，以及系统中自动执行的判断和处理，主要便于项目人员快速了解订单的详细逻辑
（3）状态映射表（非必要）
展示订单状态在多个端口的映射关系。
小结
可以看到，在现阶段工作的重点在于将业务与系统结合，同时主要输出物也是便于后续开发工作的进行，这些产出物都是需求文档中重要的部分。越是复杂的系统，越需要这些资料进行辅助了解，不能指望后面加入的项目人员能根据你的文字来了解复杂的业务。
一、订单信息设计
在完成了流程和状态的设计之后，需要进一步确认订单包含的所有信息
1. 确认订单编码生成规则、标识
订单编码有一个最常见的也是最简单的组成方式，标识+时间戳+随机编号，如果是企业内部的订单或者预计订单量不会非常庞大的话，完全可以使用这套规则来生成订单，这样内部人员在看到订单编码的时候就能迅速分辨出订单类型和订单日期。
- 标识：可以为纯数字，可以为英文组合
- 时间戳：一般为YYMMDDHHMM格式，
- 随机编号：一组随机数字，根据上面时间戳的末位和订单预计生成量来决定使用多长的随机编号
如果是外部订单，为了不容易被发现规则，以上3个元素的位置可以任意组合。
现在主流平台的外部订单大多都已经不使用以上组成方式，一来是因为这种编码方式太过直白，容易暴露例如订单量等公司内部信息，二来是因为当要在短时间内生成大批量订单的时候，为了确保订单编码不重复，就要重复比对历史订单。随机码越长时，对服务器造成的压力也就越大。
2. 订单编码的重要原则
（1）唯一不重复
无论生成规则如何设计，最重要的就是一点，保证订单编码的唯一性。
（2）安全
订单编号不能暴露出公司的信息
（3）控制长度
订单号的主要作用是查询，在某些需要输入或者用户念出来的情况下，订单号长度并不是越长越好。
（4）尽量保持纯数字
纯数字的检索在数据库订单查询时效率要高于文本型（字母加数字）
以淘宝订单为例，84034576013582XXXX，
总共18位，前14位为序号，15-16位买家ID的倒数1-2位，17-18位买家ID的倒数3-4位
3. 确认字段及字段规则
订单的字段往往包括几大模块
- 基本信息：包括订单编号、用户名称、提交时间等等
- 商品信息：包括商品名称、数量等等
- 支付信息：包括总金额、支付金额、优惠金额等等
在开始设计各个端口的线框图原型之前，最好将所有字段用表格或者脑图罗列出来，避免后续设计过程中遗漏了重要的字段。
二、订单操作设计
1. 基础操作-增删改查
对订单的操作本质上跟对数据库的操作一样，常见的基础操作无非就是增删改查、提交、取消这几个。
在设计操作时，最重要的有几点：
- 操作的条件——需要满足什么样的条件下才能进行当前操作？订单处于什么状态？相关的其他数据处于什么状态？
- 操作的影响——这一步操作完成之后，订单会发生什么样的变化？会影响到哪些功能和数据？
- 操作的结果——操作的时候会得到什么结果？会遇到什么样的异常状态？需要怎么处理？这是设计时常常会遗漏的部分，最好把所有可以预想到的结果梳理出来，避免后面开发的时候发现问题。
- 操作的可撤销性——操作是否可逆？如果不可逆是否考虑增加二次确认让用户充分了解操作的后果？
2. 操作权限
订单具备业务承载作用，是安全性要求很高的数据。虽然在实现层面不需要对订单模块单独开发一套权限功能，但是一定要明确不同权限用户对订单的操作。
三、订单列表设计
对订单的内容完成了设计之后，就要开始进行列表的设计。
1. 列表字段
同样是订单列表，移动端和PC端的表现形式相差很远，但是在把订单字段全部列出来的情况下，第一步需要做的就是把重要且必须的信息抽出来组合成表单。
在这里说几个常见的移动端和PC端设计上的区别
（1）内容展示量
相比起PC端，移动端每一屏能展示的内容更少。在常见的电商平台移动端里，就算是大屏手机一屏幕最多也就展示2-3个订单，所以在展示字段和确认布局的时候就要更加严格，不能什么字段都往上塞。
（2）操作侧重点
移动端的特性决定了订单列表的更多作用是查看最近的订单和快速操作，PC端则是在这个基础上承载了更多，例如对历史订单的查找和管理功能。
淘宝的PC端有多个筛选条件、排序等功能，而移动端则是只能按照订单时间顺序排列，顶端也只有一个输入框对商品标题或订单号进行搜索。
2. 列表操作
对列表的操作可以分为几类：查询、筛选、排序。
以下为各类操作需要注意的点
- 查询——要区分开精准搜索、模糊搜索，对文本类一般为模糊搜索，而对订单编码类的则是精准搜索；
- 筛选——注意选项是否可多选，是否有全选的选项（等于空选项）；无论是查询还是筛选，操作所指向的字段最好能与列表中的字段对应得上。例如对订单金额进行了筛选，可是订单列表中却没有出现订单金额的字段，用户会对搜索结果感到困惑，不知道对列表的操作是否已经生效了。
- 排序——常见的排序是对时间字段进行正序或倒序排列，如果需要对文本类型的字段进行排序，最好是先了解数据库的排序规则；
小结
常见的订单设计从梳理流程开始，到订单字段、列表的设计就算是结束了。但是还有很多更加复杂的功能尚未提及，在实际系统构建过程中需要注意灵活运用，灵活设计。