每月初我们公司的运营都要进行对账，这个对账就是拿着我们后台的收款数据和支付宝、微信、百度小程序等各方的数据对比，最终的结果就是要所有的第三方实际收款数据都能够对上我们的后台实际收款数据。
但最近有个问题，出于内部测试需要，测试人员常常会在上线时，针对一些有付费的项目，实际支付金额测试付款流程是否通畅。这样就导致内部系统收款的金额上有部分是来自于公司测试人员的费用。而我们的实际收款金额是与渠道合作分成结算的，意味着，公司所收到的款项是需要按比例支付给渠道的，比如，本月到账100元，渠道分成比例为50%，那么需要支付给渠道50元，自己实际收款为50元。内部测试的金额如果不额外处理，毫无疑问，相当于给渠道做嫁衣。
当然，这个问题并不是现在才有，之前就发现有这些问题，所以独立了一个测试账号，凡是用测试账号测试的，价格固定（很低），然后，金额不体现在后台与渠道分成上。可以说解决一部分问题了。但是对于用户反应产品有bug、但是用测试账号测支付又无效的情况，我们就涉及到需要用非测试账号测试问题的情况了。因此，为避免旧问题发生，老板提出，测试完之后，删除测试订单。尽管删除订单的权限只有几个人有，大家也都声称自己订单都有记录，但之后算账的时候，总后台和实际所得总是有那么些出入。此时，我们的运营就提出了他们的一个对账需求——需要一个能够记录用户删除订单和改订单状态的功能，类似操作日志，这样就不会存在删除了的单据，但是在给他们的单据中却漏了的。
以上皆是实务背景，说这么说，就是希望能够了解清楚实务背景再谈其它的。此处，运营就一句话提出了需求，但是如何把需求落地实行，却是我们需要认真思考的。
（1）需求分析
运营需要一个能够记录用户删除订单和改订单状态的功能”，类似操作日志，那么实际上这个用户操作日志需要包含的功能点有哪些？针对的模块是那部分？都是我们先要分析的。
既然是为了对账，那么这个功能操作实际上只要针对订单，而不用像是全局的操作日志，用户的每一个动作都要记录。因此规划的时候只要针对订单做这个功能即可，类似订单操作日志。而且主要内容围绕用户删除的订单、修改订单支付状态进行。除此之外，他们可能还会关注到的点有哪些呢？
我们不凡这样分析：
首先运营对账最关注肯定是金额，但是金额和哪些有关？订单号、支付方式、操作类型（比如删除订单后台显示的金额会变少，但实际的第三方真正收款还是有这笔钱）
根据以上，我们提炼出一些信息如下：
金额：所删除或修改状态的订单金额
订单号：有了订单号，才可以与第三方收款的订单号做对比
支付方式：常见的有支付宝、微信、苹果内闪付
操作类型：包含删除动作、修改状态等动作
除此之外，运营是每个月对账，那所查看的内容，有个隐藏的需求，能够根据时间选择查看自己需要对账月份的数据就可以了。另外，有所谓删除权限的用户，就那么几个，是否需要给一个删除订单的用户信息用于筛选，能够统计某个人对订单的操作，这时候就需要用户账号和用户真实姓名（此处是因为我们后台系统的用户账号与用户真实姓名是多对一的关系，加上查询时往往用的是真实姓名，所以此处加上这2个信息），因此得出所需要的信息汇总如下：
金额：所删除或修改状态的订单金额
订单号：有了订单号，才可以与第三方收款的订单号做对比
支付方式：常见的有支付宝、微信、苹果内闪付
操作类型：包含删除动作、修改状态等动作
对账的时间选择：每月月初对账上月的金额，因此对账时间往往是XXXX年XX月格式即可
后台账号：用户所登录后台的账号
真实姓名：与后台账号有所绑定的真实姓名
（2）关键信息排布
通过用户分析，一些基本需要的信息点已经出现了，但是要怎么把运营需要的功能实现呢？哪些信息最为主要呢？
常见的用户操作日志如下：
可以根据此，订下我们需要显示内容的优先层次级
表头的筛选项：
根据先前提出的明细点，我们做原型图时，要根据用户的使用习惯做规划，那么哪些是需要独立做筛选项的呢？
毫无疑问，对账的时间选择、支付方式、操作类型、订单号、后台账号、真实姓名都是用户常常会操作使用的。
那么查询出来后，显示信息虽然我们也有在第一点需求分析中得出一些比较关键的，但是具体要显示哪些，彼此之间的哪个排在前面、哪个在后面，也是需要我们用点小心思的。以下是我们订单操作日志，有些地方有特意修改成别的信息，但本质不变。
此处之所以把操作时间放在后面，是因为我们有控制点开当前页面的时候，默认显示当前月份的详细信息。
另外，此处要提醒注意的点还有以下几个：
a、订单号、真实姓名、后台账号这些都是自定义搜索，如果3个并列且同时搜索，会导致内容出不来，因此要给它合理处理，比如设置成如上的筛选
b、操作类型中除了删除订单，其他修改支付状态也应该细项考虑，比如、是已支付改未支付、还是未支付改成已支付、或是已支付给成已退款之类的，都要考虑清楚、同时对应的支付方式，是否除了常见的微信、支付宝支付，既然要考虑改状态的退款操作，是否此处，需要多一个筛选项为未支付。
我所接触来自运营的需求常常只有一句话，但是背后真正需要的点常常需要自己对实务场景有较为充分的了解，并且能够通过这些实务场景的分析，提炼出这些用户的实际需求点，再进行交互上的排版优化。主要提醒自己的就是，需求往往看起来不难，但是想要做好，一定要多思考，哪怕想好了各功能点取值，样式，其内在的彼此之间的逻辑也要深入试下是否可以走通。
