toB 应用设计系列 - 用户日志篇

toB 应用设计系列 - 导航

toB 应用设计系列 - 用户日志篇

日志按面向对象分, 分为两种, 一种呈现给用户, 一种是呈现给运维, 本篇主要讨论面向用户的日志

登录登出日志

目的

目的其实我也没搞懂, 只能猜测企业希望看到用户的登录登出日志, 可能是为了更好地掌握员工的上下班的时间

内容

哪个时间(时间) 什么地点, 谁(用户) 用 什么设备(设备) 在 什么客户端(客户端) 登录or登出 了 系统

2019-08-07 15:01:05 深圳市福田区xx路, 小明 用 iphone 手机 在 网页端 登录or登出 了 系统

实现

受制于诸多约束, 有几个很难做到:

• 很难捕获登出的具体时间
• 地点 / 设备无法精确

小结

推荐指数 ★★★☆☆

受制于技术, 完整功能暂无法实现

用户操作日志

目的

• 适当约束用户瞎操作
• 当对某些数据有疑问时, 可找到造成数据有疑问的责任人
• 可掌握用户做了什么操作
• 用户可查询到自己的操作做了哪些动作

内容

分为四个部分:

用户操作日志

哪个时间(时间) 什么地点, 谁(用户) 用 什么设备(设备) 在 什么客户端(客户端) 做了 什么操作

2019-08-07 15:01:05 深圳市福田区xx路, 小明 用 iphone 手机 在 网页端 新增了 订单 a

2019-08-07 15:01:09 深圳市福田区xx路, 小明 用 iphone 手机 在 网页端 修改了 订单 a

2019-08-07 15:01:52 深圳市福田区xx路, 小明 用 iphone 手机 在 网页端 审核了 订单 a

用户操作详细日志

对应用户操作日志的新增和修改, 记录具体新增了哪些数据, 或者具体修改了哪些数据

新增: 假设新增了订单a, 用户填入了 供应商, 备注, 则记录

供应商: G, 备注: 不发货

修改: 假设修改了订单a, 用户将备注改成了 08-02前来得及发货就发货, 来不及就不发货, 则记录

原备注: 不发货, 新备注: 08-02前来得及发货就发货, 来不及就不发货

用户间接操作日志

用户操作带来的间接的操作, 比如审核订单后会生成运单, 然后系统发邮件通知客户已确认订单, 则记录

生成运单y

发邮件通知客户已确认订单

注意:

用户操作日志和用户操作详细日志, 在用户层面是可以直接感知的, 是由用户主动发起的, 比如点击审核按钮, 比如修改订单的某些数据

而用户间接操作日志, 用户无法直接感知, 是由系统实现, 用户可间接感知

用户间接操作详细日志

在如上例子中, 如 生成运单y, 记录运单y 的详细数据

运单y, 单号: xxx, 预计提货时间: 2019-08-08 15:00:00 承运商: 承运商A, 货物: 货物A, 体积: 1m³, 重量: 40kg; 货物: 货物B, 体积: 2m³, 重量: 96kg; …

如上例子中, 发邮件通知客户已确认订单, 记录为

发件人: xxx, 收件人: xxx, 抄送: xxx, 标题: xxx, 正文: xxx, 附件: xxx

注意

不记录查询, 只记录操作

这里一般只记录会变更数据的操作, 对于查询, 是不做记录的, 原因一个是没有必要, 另一个则是若记录查询, 则该记录的数据量会飙升

查询有些记录也是有必要的, 可以做数据分析或者提升用户体验, 比如 搜索, 该部分暂不在本文讨论范围内

实现

1. 地点 / 设备 不能保证精确性
2. 用户操作详细日志虽可以实现, 但数据量大且人性化的表述困难
3. 用户更新数据时, 由于存在并发编辑的问题, 用户本身感知到的修改和最终的修改可能会不一致
4. 用户间接操作详细日志, 数据量庞大且人性化表述更加困难

第三点的说明

由于存在并发编辑的现象, 用户a / b 几乎同一时间进入修改订单的模块, 用户a 将订单预计提货时间由1号改成10号, 用户a 的日志为 旧提货时间: 1号, 新提货时间: 10号; 用户b 将订单预计提货时间由1号(此时用户b 看到的还是1号)改成5号, 用户b 的日志为 旧提货时间: 10号, 新提货时间: 5号, 和用户感知的由1号变更为5号不一致

小结

推荐指数 ★★★★★

进入退出模块日志

目的

• 掌握模块使用频率

内容

哪个时间(时间) 什么地点, 谁(用户) 用 什么设备(设备) 在 什么客户端(客户端) 进入/退出了 哪个模块

2019-08-07 16:04:35 深圳市福田区xx路, 小明 用 iphone 手机 在 微信小程序 进入了 订单模块

实现

• 地点 / 设备 不能保证精确

小结

推荐指数 ★★☆☆☆

流程审批日志

目的

• 查看每个流程的节点

内容

哪个时间(时间), 谁(用户) 审批了 / 驳回了 xxx, 原因: xxx

2019-08-07 16:06:37, 小明 审批了 请假单201908070001
2019-08-07 16:06:37, 小明 驳回了 请假单201908070001, 原因: 理由不成立

实现

无大问题

小结

无

生命周期日志

目的

• 厘清生命周期变化的时间节点, 便于追溯

内容

哪个时间(时间), 什么东西 由 什么状态 演变成 什么状态

2019-08-07 16:08:16, 运单A 由 已发货状态 演变成 已到达目的地状态