对于常规的系统软件，成规模体系后用户通常会有一些查看子账号操作记录以及限制各子账号功能权限的诉求。作为比较常规的功能，里面的细节和坑还是不少的，今天我们就来详细展开讲一讲。
概念基础篇在设计功能之前，我们先来看看这两个功能的基本概念。
操作日志：业务角度的诉求，我们一般是理解为用户的操作记录以及操作变更的数据。站在研发的角度上日志则是各种服务运行的消息，分类上更是会根据服务类型进行区分登录、系统日志、订单等等。
明白这两者的区别后，我们在接收需求的时候就会更加明白实际场景的诉求。对于用户来说他们的诉求一般都是查看子账号的操作使用记录以及操作的数据。作为团队内部，通常会需要监管整个产品的使用链路，查看转化率等数据时，其实就是需要我们的研发同学做好各个节点的日志。
对于后者来说，其实我们的产品也要熟悉数据层面的链路，对于线上问题可以通过排查相应的日志找出问题。
功能权限：功能权限其实会更容易理解，常规来说只需要区分数据和功能层面即可。数据很好理解，分为可见或者不可见；功能则主要是是否具有操作的权限，但具体的产品设计方案上有很多方式，我们在下面细讲。
产品设计篇操作日志：
操作日志的产品设计上个人认为主要有两个点需要特别考虑。第一是使用者的视角，是希望基于页面模块还是功能维度去查看记录。第二就是操作日志展现的呈现形式，如何一眼让用户看到最想看的内容。
针对第一点，站在业务角度来说，如果你的系统本身模块之间的功能结合程度不高，且功能较为零碎，建议从页面模块维度来区分日志类型。
但如果的你的系统本身，所有功能有一个核心领域，周围的功能与之关联度高，且页面之间对于功能管理上来说较为灵活（比如商品和标签，能在商品模块编辑标签，也能在标签模块编辑后关联商品），建议从功能维度去划分日志类型。
举一个很直观的例子。电商客服平台。有很明显的中心领域，例如商品这个角色。同时还会有很多其他的功能，那么我会建议你在划分日志的时候，从功能维度去思考（商品信息模块、权限模块等等）。
第二点就是呈现样式上，除去基本的操作账号、时间，如何设计操作内容是最关键的。因此我们需要明确操作过程中几个比较重要的点，分别是操作维度（页面维度还是功能维度）、被操作对象、操作类型（上传、新增、删除等）、操作数据。
同时，这个里面需要注意的就是操作类型，存在一些上传表格、导出表格类型的操作，看是否需要在记录中展示表格链接，但这个链接一般都会有一个有效期，还是看业务本身是否需要。对于操作数据，如果需要前后比对的，可以展现操作前数据。
但一般为了界面简洁以及操作记录只是为了追溯，不是为了复原，所以大多数情况可以不需要操作前的数据，
最后还有一点很重要，就是记录只记录成功的数据，功能操作后，数据没有生效的记录一般不需要记录。
功能权限：
功能权限在设计上一般会引入角色的概念，方便去批量设置权限。利用账号关联角色，再用角色关联权限的方式设计。
功能权限一般会设计页面权限、操作权限以及数据权限。页面主要会包含菜单、栏目、按钮等元素，主要控制其是否可见。操作权限则主要是对功能是否可进行操作的权限。数据权限本身其实也是页面的一种元素，把它单独领出来主要是为了概念的区分。
在用这种方式设计产品的时候，最重要的工作就是拆分页面元素。
（图片来源于网络）
例如上述这张图，针对功能以及列表中的数据我们是可以根据业务需求事先拆分好的。然后可针对其设置权限。
对于大多数管理系统来说，其实权限功能做到什么程度取决于你的客户需求，上诉这种是比较全面的做法。如果你的需求比较简单，在考虑成本的情况下，通常会设计成只针对操作功能做权限管控。
如果没有对操作功能做是否可见，在设计上最好是调用接口的时候给予用户提示‘您没有当前模块的操作权限’
这样设计的好处就是多页面都使用同一接口的时候，不用在每个页面的前段去做限制，如果后续产品迭代，整体的前段限制可能连你自己都会忽略，所以尽量在调用接口的时候去判断。
操作日志和功能权限还是属于比较常规的系统功能，在设计层面其实也没必要完全按照上述方式来，只是和大家分享一些我的经验，希望能给你带来启发。
我是红尘，我们下期见！（都市摆渡人）
