后台设计小结

9 评论 82947 浏览 555 收藏 10 分钟

后台系统,在目前接触来看,主要分几种:管人、管事、管物。管人的,有对内和对外的两种类型,对外的CRM(客服管理系统)、对内的考勤系统;管事的,简而言之,就是人可以做什么事、可以怎样去做事,这种最经典的就是数据统计后台、业务流管理后台;管物的,主要是指电商类型的商城管理后台,用于管理商品的交易

后台系统,在目前接触来看,主要分几种:管人、管事、管物。管人的,有对内和对外的两种类型,对外的CRM(客服管理系统)、对内的考勤系统;管事的,简而言之,就是人可以做什么事、可以怎样去做事,这种最经典的就是数据统计后台、业务流管理后台;管物的,主要是指电商类型的商城管理后台,用于管理商品的交易

但是,从本质上看,后台主要有权限管理、工作流、记录流三大方面。可以归结为一句话,谁可以对什么进行怎样的操作,需要产生什么记录:简称who-where-how-what

权限管理(who-where)

权限管理,是指一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源。通俗解释就是,谁是否对某资源具有实施 某个动作(运动、计算)的权限

权限管理,目前主要是通过用户、角色、资源三方面来进行权限的分配。具体来说,就是赋予用户某个角色,角色能访问及操作不同范围的资源。通过建立角色系统,将用户和资源进行分离,来保证权限分配的实施。

那么,权限可以怎样设计呢?

如果是业务流后台,在设计权限时,可以按业务类型进行角色设计,比如客服、运营、充值员;如果是数据统计后台,可以按用户类型来进行角色设计,如对外用户、内部人员;如果是CRM,则可以按用户的职位等级进行划分。在进行一级划分后,往往还需要对角色进行细分,例如客服,可以细分为 普通客服、客服组长、客服总监,通过级别的划分来控制可访问及操作的数据。

另外,在进行角色的细化时,有两点是需要注意的:

1. 同类型的角色,上下级角色的权限关联是怎样的?上级角色是否能对下级角色的业务进行操作?下架的操作是否需要上级的审核?

2. 对外用户,是采取权限分离,还是采取两个不同的后台去处理?前者的话,实现起来方便一些,就看系统对于安全性的考虑;后者的话,会更加的安全,在数据的处理上也会方便一些

虽然我们将权限管理放在第一位,但是在实际开发过程中,权限的分配往往是在整个后台开发完毕后才去实现的(主要是为了避免权限设置对开发造成影响)。

工作流(how)

工作流(Workflow),指“业务过程的部分或整体在计算机应用环境下的自动化”。是对工作流程及其各操作步骤之间业务规则的抽象、概括描述

工作流主要解决的主要问题是:为了实现某个业务目标,利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

设计工作流时,除了最基本的单个后台工作流的设计,还有多个后台之间进行工作流的设计。OK,先从最基本的单个后台开始聊聊,工作流的设计,其实和2C产品的需求设计很相似:

1. 在了解业务需求后,产出适合的业务流程图(业务流程图此处不展开,稍后另开一章来写)、状态图(部分简单的工作流不需要出这个),通过业务流程图,向开发更好的传递业务需求

2. 搭建工作流的产品架构图,主要是罗列工作流涉及到的功能模块(广度思考),这个时候,就可以将产品架构图和其他人进行碰撞;为什么不使用产品原型图来碰呢?这个以下几点原因:

(1)产品原型产出周期较长,不适合前期的思维碰撞

(2)产品架构图比产品原型返工更容易,能够更快的迭代

(3)可以针对后期加入的需求低成本的进行讨论,使开发设计库表时,更好的考虑拓展性

3. 通过前两步,基本可以把工作流较好的传递给研发那边;紧接着,可以将产品架构图进行细化,细化到什么程度呢?最好是把工作流涉及的点都能够细化在上面,这样,在产出产品原型图的时候,可以更加全面的是思考单个模块与整个后台系统之间的交互

4.在第三点,有提到了产品架构图的细化,接着,就是放大招的时候— 出产品原型图

5.适当的重复上述3、4点,这样,一个较完整的工作流就设计好了

在出了产品原型图,就要开始和研发大大进行更凶残的肉体碰撞了,关于肉体碰撞的细节,在这里就不展开了,但是可以补充一句:做产品得耐操!

上面讲述的都是单个系统内的工作流设计,那么 多个系统协同处理的工作流有什么不同呢?

首先在设计上,基本流程不会有区分。主要是要和系统架构师多多沟通,让一整套系的工作流能够更好的满足业务需求。在进行沟通的时候,最好可以先自己拟定一份假想架构图,这份产出物更多关注的是不同系统之间的数据交互,表明系统间的输出、输入,这样,在定好满足需求的架构上,才能够更好的对工作流进行设计。

其次,还有一点细节是需要关注的,那就是在不同后台的原型图中,要注意描述清楚工作流是否与其他模块有所交互,这样方便自己,也方便他人。

记录流(what)

后台系统进行设计时,往往都会有一个专门的操作日志,记录后台登录用户的操作轨迹,主要是因为后台数据对于企业来说是比较有价值的,所以需要对其进行保护。

总的来说,记录流主要分 操作轨迹、数据查询两种。

操作轨迹,很容易理解,就是用户对后台的数据进行操作所产生的记录,需要达到一步一记录的程度。这种,在进行设计时,就是将初始状态、变更状态、操作内容、操作人、操作时间罗列清楚就OK了,不同业务差异性不大,算是后台的标配模块

数据查询,这个的话,更多是对于工作流中产生的数据进行整理,然后形成的功能模块。这种的话,不会像操作轨迹那样,每一步都会记录下来。而是会根据具体的业务需求来进行设计,以满足用户能够在后台中针对不同纬度的数据进行查询、了解、分析,获取价值。

出了上述的三个基本模块,在进行后台设计的时候,还有一点可以关注一下,尽量使用默认控件去进行设计,以及不同模块之间,能够使用较为统一的交互方式,这样开发起来更有效率。

以上是后台设计Part1,在这方面有心得大大,欢迎加我微信Yoic__,(验证写简书)一起交流讨论下哈~~

#专栏作家#

Yoic,简书@Yoic,人人都是产品经理专栏作家,关注游戏、电商等领域,正在努力成长的产品汪一枚。爱好:星际2和看书

本文原创发布于人人都是产品经理,未经许可,不得转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 在谷歌搜索用户操作日志的产品设计,进入这里了,感谢你的分享。
    我分享一下我的想法,记录用户的操作日志,主要是用户的操作有记录,并且能查得到。然后再去设计哪些操作场景需要记录,记录的具体格式和内容。

    来自广东 回复
  2. 记录流产生的数据查询,这点不是很理解,作者能多写一点吗?

    来自福建 回复
    1. 我理解的 记录流产生的数据查询:对用户操作行为进行记录,由此产生的一些数据,这个需要在进行埋点时根据业务需求考虑的问题,然后加以分析,才能有数据的查询。

      来自广东 回复
  3. 微信加不了呀~

    回复
  4. 😀 太棒的文章,赞

    来自广东 回复
  5. 正在设计后台,头大中,微信怎么加不了呀

    来自上海 回复
  6. 微信加不了

    来自广东 回复
  7. 虽然有些地方还是理解不进去,但是已经提供了一个大的方向,谢谢,心怀感激。

    来自北京 回复
  8. 总结的太棒了!膜拜!! 😀

    来自北京 回复