案例 | 作为产品经理,我是这样设计业务系统的

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

蓦然回首,从事产品经理差不多一年光景,期间曾作为产品负责人完成了两个业务平台的整体规划工作。因此总结两个项目的经验,希望能起到抛砖的作用。

chanp

业务系统的本质需求是满足前台维护或工作需要,因此,严谨的业务流程实现和较少的操作步骤,是业务系统应该具备的基本特点。

完整的业务系统,应该涵盖如下内容:

QQ截图20160707222647

由于业务系统本身是为满足用户的工作需要,因此用户管理、权限分配、工作流毫无疑问占据核心地位。

与前端产品不同,业务系统往往基于复杂的数据流和业务逻辑,这就要求产品经理提供详细完整的业务流程图和PRD。接下来作者就一些常见模块设计做简要说明,有纰漏之处还请各位大牛批评指正。

1.用户管理

平台的设计最终是为了服务于用户。

 1.1用户登录名

业务系统不同于社交APP和论坛,用户名往往是严肃准确的。而由于用户同名的几率太大,使用姓名作为登录名显然是不太合适的,常见的业务系统或后台登录名如下:

姓名(拼音)+编号:如zhangsan,zhangsan1;

  • 优点:用户名命名规则简单,完全避免了同名问题;
  • 缺点:命名需自动生成或由管理员负责,行政领导使用时可能不合适;

身份证号:

  • 优点:完全杜绝重复,用户名较严肃;
  • 缺点:若用户年龄群体较大,记忆和输入身份证号不利于提高用体验;

手机号码:

  • 优点:便于记忆;
  • 缺点:手机号更换较麻烦,不适用于较严肃的业务系统;

工号/单位内个人编号:

  • 优点:严肃、避免重复;
  • 缺点:记忆不便、适用范围较窄(不适用于无工号的单位);

除此之外,其余能够标记用户唯一性的方式均可使用,但应严谨、严肃,不宜出现个性化因素,如昵称等。

 1.2用户来源

常见的业务系统用户往往来源于管理员主动添加。在用户较多且不便导入或其他使用者特殊需求情况下,可能存在用户自行注册的情况。

  • 由管理员添加:较常见。管理员添加用户并为用户关联权限信息,此时用户即可正常使用系统;
  • 用户自行注册:用户注册可能存在冒名顶替现象,需身份验证环节。验证审核与授权工作在交互上可同时完成。

 1.3用户安全

业务系统涉及到使用者业务流程、重要数据等,因此对安全要求较高,除常见的密码、验证码等方式之外,有可能借助其他加密方式,如UKEY、数字证书等。

2.权限管理

权限管理决定了哪些用户可以使用什么功能,完成什么操作,对什么数据进行操作,是业务系统中的重中之重。

 2.1功能权限

功能权限决定了用户能看到多少菜单,能访问哪个页面,能操作哪些按钮。业务系统的权限往往能够精确到页面中甚至弹窗中的按钮,而普通的内容后台则往往不需要多此一举。

常见的功能权限的控制主要有以下几类:

  2.1.1角色控制

角色是功能权限的集合。之所以放在第一个,是因为该方法是在业务系统中最常见的、操作简便的功能权限控制方式。

实际应用中,引入角色概念,建立某个角色,并关联若干功能点。此时将角色关联到用户下,即可赋予该用户不同角色权限的并集。

角色是功能的集合

角色权限控制适用于使用者权限具有典型性、普遍性的状况,可以避免重复对具体功能权限进行重复操作,能极大提高管理员效率。因此,在部门、岗位划分明确的状况下一般使用该方式。

  2.1.2岗位控制

岗位控制的前提是存在明确组织结构管理,并通过相应的岗位与员工一一对应。岗位本质上与角色一样是功能权限的集合。

通常情况下,岗位管理属于人事管理范畴而非系统管理,因此通过岗位关联权限的做法,在系统内存在人事模块时,会混淆人事管理和系统管理的概念。

  2.1.3直接关联

对于单位内人员较少,人员分工较不明确的单位,也存在将人员直接关联功能权限的设计。该做法仅仅适用于较小范围内、不同人员权限差异较大的情况下使用。

  2.1.4跨单位功能权限

跨单位功能权限多用于存在较多分公司、事业部、分支机构、下属单位等情况的大型业务平台。不同单位的功能权限有所区别。

这就要求存在一个超越所有单位的超级管理员,对不同单位授权以作为单位的最大权限。各单位管理员基于单位权限对单位内用户进行权限分配。

常见的跨单位功能权限处理方式如下:

  • 引入单位角色概念:首先由超级管理员建立单位角色,将单位关联角色。此时,单位基于单位角色作为单位的最大权限,对用户进行详细的权限划分;
  • 使用单位类型区别单位的功能权限:与单位角色在授权方式上并无本质区别,但单位类型可能作为单位查询的统计口径之一,未必能够完全兼顾权限,灵活度较差;
  • 将单位直接关联功能权限:简单粗暴,灵活性较强,适用于单位较少的情况。

 2.2数据权限

数据权限决定了不同用户在同一页面上能够看到的数据的不同,能看哪些数据,不能看哪些数。在部门或不同单位职权划分明确、或者不同性质单位使用同一系统时,数据权限的区分至关重要。

数据权限与功能权限共同组成系统的权限控制,是业务系统不可或缺的一部分。

  2.2.1单位数据权限

同功能权限一样,数据权限首先要定义单位的最大数据权限:

通过单位类型限制:适用于存在多种类型单位的大型平台使用。不同类型的单位需要使用到的数据不同,因此使用单位类型进行限制是较合理的方式;

通过权限级别限制:适用于存在多级别单位的平台,通常与单位类型控制混合使用。例如县级行政单位使用本县所有数据,市级行政单位则使用本是区域内(市直单位、县区)的所有数据;

  2.2.2用户数据权限

单位数据权限确定之后,就要为不同用户分配权限,不同级别、不同部门、不同岗位的用户需要使用的数据往往是不同的。而对用户限制数据,通常与权限控制类似:

部门/岗位/角色控制:不同部门、岗位、角色分工不同,数据权限自然不同。例:业务部门1与业务部门2的数据权限均为由本部门人员产生的数据;

通过功能权限控制:该方式对数据权限的控制粗糙但简单。有页面功能权限的用户默认为看到该页面展现的所有数据(能否操作数据由按钮的功能权限控制)。适合分工较明确的场景下使用。

3.工作流管理

工作流是业务系统的灵魂所在,是实际业务流程在系统中的反映。根据实际业务中的不同需要,工作流存在自定义工作流和固定工作流两种状况。

而无论是自定义还是固定工作流,理清业务流程,绘制业务流程图是非常重要的,而在业务流程图中,泳道图是最为常用的。

QQ截图20160708142301

 3.1自定义工作流

满足同一业务需求:常见的诸如请假、财务等OA流程等。此时自定义工作流主要定义发起人(发起角色)、工作流节点、工作流节点条件等内容。该情形主要适用于同一单位内部存在较多上下级流程的需求,拥有相应权限的用户可对不同流程节点的参与人员/角色进行定义;

自定义工作流适合不同使用单位下,相同业务流程有差异的情况,如系统中存在单位A和单位B,单位A的请假审核流程为员工—部门经理—总监—人事,而单位B的审核流程为员工—部门经理—人事;

自定义工作流的各个节点视情况可精确到岗位、角色、用户等;

 3.2固定工作流

固定工作流并非一成不变,其本质是通过控制功能权限和数据权限来控制工作流中的节点。该方式适用于平台内业务流程较稳定、较统一的情况。为详细阐述,下面举例说明:

例:假设系统中存在业务A,A业务流程如下:县级子公司——市级子公司——省级总公司部门A——省级供公司部门B。假定该业务流程非常稳定,则可将工作流固定,由不同区域的子公司甲和子公司乙发起的业务均使用该流程。

4.数据处理

数据处理是为管理人员提供决策支持、单位对外展示的重要依据。

 4.1数据可视化

数据可视化能够明确表达数据间变量和属性的关系,是数据分析中不可或缺的方式。应选用合适的统计图对有重要作用的数据进行分析(统计图在web中有很多可以直接拿来用的插件,可以减少前端的工作量,如E-Charts、Highcharts等)。

111

4 .2数据勾稽(逻辑)关系

数据勾稽关系常见于报表系统、财务系统等,适用于表达表格间不同行、列或多表格间的关系。

勾稽关系由需求决定,目标明确而单一。表达勾稽关系要求PM在PRD中明确表现出来,一般使用对表格中不同的行、列赋名,以公式的形式表示。

例:(以某功能PRD为例)

3

5.系统首页

业务系统的首页设计应遵循实用、简洁的原则。

常见的首页组成元素通常包括快捷方式、数据分析、待办事项、通知公告等,部分有个性化需求的首页往往可以对首页元素进行自定义。

自定义首页元素可分为后台自定义和用户自定义。为便于自定义元素的排版,自定义的各个元素大小应保持一致。

6.消息发送

业务系统中消息发送作为用户与用户、单位与单位之间交流的重要方式。

消息发送主要考虑到发送主体、接受范围、可见范围、附件上传、已读未读标记、消息记录等要素。

7.操作记录

操作记录用来记录用户的操作轨迹,即对用户的登录退出、数据变更、数据访问、操作内容(必要记录如财务等可详细到从A变更为B)、操作人、操作时间等。

记录用户的操作轨迹是出现问题后追责的重要依据,是业务系统和后台系统的标配。

8.交互案例

上面谈了一系列业务系统的简单设计逻辑,但最终还是要落实到原型上。该模块主要体现的是用户体验层级中的框架层。一些复杂业务流程的交互和页面布局往往比较复杂。笔者总结项目经验,对部分典型交互做简单解释。

 8.1审核流程状态

层级审核流程中,为用户标记出完整流程并指示用户当前所在流程的状态,能在很大程度上提高用户体验;

 8.2存在多层级数据

如按照行政区域进行划分的数据等,使用树的形式展现是较为清晰的模式,而若数据存在审核操作,则在树中以颜色的形式标示出审核状态,使数据状态一目了然。

 8.3复杂数据录入

复杂数据录入时用户往往因繁杂的录入框而手忙脚乱,因此,复杂数据录入时有必要为用户分门别类,以清爽、有序的方式展示给用户:

  • 按类别将输入内容分门别类;
  • 分步骤有序填写;
  • 复杂表格内容在表格中直接填写;

 8.4硬件控制

硬件控制主要侧重于工控方面,清晰的控制按钮与状态反馈非常重要:

使用按钮操作硬件,尤其是硬件个数较多时,需要给用户清晰展示出按钮的作用;

5555

用户通过网页或APP内的按钮控制某硬件设备,往往会存在“我是否成功操作”的疑问,因此需要在用户操作之后及时给予反馈。

33333

 8.5数据展示

数据展示合理使用图表,对于提高数据直观性,明确表达数据之间的变量的关系具有重要作用。而对于既需要分析数据变量,又需要展示数据详情的需求,则可以使用图表+列表的形式展现。

QQ截图20160708150524

9.总结

业务系统为满足业务需要而产生,产品目标明确单一。但分析深藏在业务需求表面的潜在核心需求同样非常重要。使用户操作形成完整的闭环,以较少的、符合用户习惯的操作实现业务需求,并有效控制开发成本的设计,就是合理的设计。

 

作者:张骞(微信号zhangqian9208),开创集团产品经理。一年产品工作经验。

本文由 @张骞 原创发布于人人都是产品经理。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 11

登录后参与评论
  1. 前辈,您好~~~
    看了文章学到了不少业务系统设计的经验,但是有一个疑问,针对不同权限的用户,界面怎么设计?比如同一块内容或者按钮,有的可见,有的不可见,那界面设计的时候需要进行区分设计?这样会不会造成界面整体设计杂乱,页面布局难度也会很大?
    谢谢您的解答!

    回复
    1. 回复

      一般情况下都是使用同一个页面,导航栏比较简单,没有该功能的就隐藏掉,页面中的按钮,可以按照优先级排列,比如新增修改删除放在最前面,一般都会有这些,审核往后放,这样最小程度影响页面布局。首页的话可以用相同大小的DIV,没有的隐藏掉不会影响整体布局。如果是区别较大的页面,比如某些群体的特殊需求,可以单开首页,但是这种情况非常少见

  2. 不错的东西。再来些prd看看,和原型看看就更棒啦😄

    回复
  3. 已经被坑了,来好好学习一下

    回复
  4. en

    回复
  5. 实用、有共鸣,顶

    回复
  6. 跨单位权限实际可通过功能和数据权限结合实现

    回复
    1. 回复

      对,条条大路通罗马。使用单位类型或者单位角色其实是把单位统计和权限结合了

  7. :razz:

    回复
  8. 好文章~~~最近重点转入业务平台,也遇到类似问题,感谢分享

    回复
    1. 回复

      共同学习!

加载中