近半年的工作中经常接触到后台页面的设计,企业后台数据的展示通常都是由大量的表格以及表单组成的,初接手时设计上存在很多困惑的地方。因为这类型的页面和平面的排版不同,没有印刷排版的经验可以追溯,也不像普通移动端用户界面,在网上有很多设计作品和文章可以参考,很多的设计只能通过我自身的感觉和尝试决定。再加上平台自身没有成熟的设计规范可供参考,所以最初在设计上不免缺乏一些底气。接手一段时间后,开始研究一些大厂如element、ant
design的设计规范,仿照着做了一份设计规范,但终究是依葫芦画瓢,知其然不知其所以然。

前端和后端设计的区别

一般产品经理的平时的工作有:前端(APP设计,web设计,微信端设计),后端(后台设计)。

前端设计重视用户需求讲究痛点,最求用户体验;后端设计是重视需求,讲究信息展示的清晰合理,操作流程符合逻辑。

后台管理系统的用户是根据业务所辐射的范围而划分的不同类别,这些类别的分类标准是根据用户角色管理来设定的。较用户型产品来讲,该类产品用户类型固定、需求明确、用研精确。

近来对这个问题关注许久,查阅了网上许多资料,也抽空整理了一下网页端的设计规范,在此综合起来对企业后台的数据表格页面作一个简单的阶段性总结。

后台系统类型

后台设计分为开放性后台系统(微信公众号后台)和非开放性系统。

图片 1

非开放系系统

对于使用后台管理系统的用户,有以下几大特征:

表格的类型

表格是一种对数据进行组织整理的手段。大体上可分为四类,入口型表格、设置型表格、纯记录型表格以及被动生成型表格。这四类表格对应提供的功能以及用户行为是有所区分的。在我所负责的签到和工作汇报的管理后台页面中只包含两类表格:设置型表格与纯记录型表格。

后台系统的本质

权限管理,工作流,记录流,操作流(增删改查)。也就是什么人对什么进行什么操作,产生什么记录(who-where-how-what)。

1.普遍对业务逻辑有清晰地认识。后台管理系统的用户主要为了通过系统更加便捷有效地完成业务内容,将业务内容信息化,将业务逻辑明显化也成为了该类用户对系统的需求点。如何将复杂的业务逻辑和庞大的数据体量进行一体化的展示,即可以保证系统所输出信息的完整性又能对业务数据进行即时性反馈,则成为了后台管理系统产品经理与开发人员工作内容的重中之重。

设置型表格

用户使用设置型表格主要进行的操作是快速扫视,搜索到需要进行增、删、改、查的内容。签到后台中用到的设置型表格有(管理员对签到规则以及人员规则进行查看和编辑)、签到管理员设置(管理员对签到管理员及其权限进行设置)。

权限管理

权限管理指的是对整个后台管理系统进行权限管理,主要针对的是员工,避免操作错误和信息泄露。

权限管理一般包含用户(账号),角色,权限(RBAC模型)。三者关系如下:

图片 2

用户,角色,权限关系

管理员先将权限授予给角色,然后将角色授予给用户。

角色根据实际情况有纵向的和横向的。不同的角色有不同的权限。

图片 3

角色关系

同时权限一般分为页面权限,操作权限,数据权限。页面权限指的是角色能够访问的页面;操作权限指的是角色能够操作的数据;同理数据权限指的是用户能够查看的数据,比如小组A成员智能查看和修改A组数据,不能查看修改B组数据。

图片 4

权限授予

在进行角色细分的时候,需要注意:

同部门的,上下级角色的关联是怎么样的?(组织机构和权限机构是分开的,父子角色可以保证父角色包含子角色—具体设计?)(设置一个管理的角色?)

对外用户是实现权限分离还是使用不同的后台设计?

为角色设置互斥关系,互斥关系的角色不能授权给同一个人。

是否在账号注册成功时授予默认角色?

2.具有一定的专业知识。对于电商、互金、商业广告产品等商业性质较强的产品来讲,其中都含有一些所属行业内的业务知识或者商业变现的技术基础存在,而后台管理系统的用户基本都需要掌握这些内容,那么系统则需要整合、过滤、筛选信息,将系统内的关键词等信息精炼化。

纯记录型表格

纯记录型表格在大多数情况下只是作为一个数据的存放地而存在的。签到后台中用到的纯记录表格有签到记录表(员工及负责人查看或导出自己的签到记录)、各类明细报表(管理员及负责人查看或导出员工的签到明细)。

工作流

为了实现某个业务目标,利用计算机在多个用户之间按照某种规则自动传递文档,任务或者信息。

图片 5

正常工作流(未包含异常状态)

3.注重系统效率。后台管理系统用户的最终目标是为了提高产品收益,所以使用系统的高效性也是十分重要的需求之一。

在设计时应该注意什么

根据不同角色用户对表格的使用行为中可以看出,在这两类表格设计上最重要的就是易读性和效率。即要在保证阅读舒适性的同时突出重要信息以便于查找。

1.用户的逻辑是什么,而不是业务逻辑是什么

企业后台页面经常会出现的一个问题就是数据展示的逻辑是按照业务逻辑来展示,而非用户的角度来展示的。当你质疑这一点时,产品经理还会言之凿凿地说“业务逻辑就是这样的”,让人啼笑皆非。

例如签到记录表,对用户来说最重要的是「签到状态」这个信息,但是业务上的逻辑是先展示你的各种签到明细,最后才展示签到状态。因此按照业务逻辑来设计的话就会将无用信息固定在了左侧,用户最关心的信息反而排列在最后一列,大大降低了使用效率。

2.告诉用户「你从哪里来」「你要到哪里去」

用户在使用设置型表格和纯记录型表格时的主要目的都是检视页面、找到自己要操作的项。因此在页面设计时要清晰地告诉用户你现在在看什么,以及你关心的数据在哪里。

例如签到记录表,由于表格自身属性原因,数据量大是无法避免的,用户在查看表格时比较吃力,容易不知道自己现在看的是哪里,因此给这一行提供一个悬浮的状态显示。对于用户关心的异常信息,可以通过标红等方式去展示,让用户在扫视过程中就能快速找到目标。

3.对不必要展示的信息进行隐藏或删除

基于简约至上的原则来对页面中的每一项进行检查,看是否有可以进行隐藏或删除的信息,减少用户的选择以及页面中的噪音。

例如顶部的标签,可以由系统判断员工所属的签到组的签到规则来自动生成,而不是无差别地将所有的选项都放置在顶部,降低了用户使用时的效率;另外也可以将用户不常用的「异常」类选项折叠起来;再比如说作为员工个人使用签到记录表时,自己是谁以及在哪个部门是再清楚不过的,因此固定在左侧的「部门」和「人名」这一列占用了很大一部分位置,完全没有必要展示的。

4.不同场景下采用不同的处理方式

在和易读性相平衡的前提下可以在不同的场景中使用不同的行高。纯记录型的表格可以紧凑一些,因为大多数数据不需要进行处理;数据量少、需要处理的数据类型多时可以留白多一些,这样操作起来比较不容易出错。

5.规范很重要

不以规矩,不成方圆。企业后台系统的设计在一定程度上是最容易被标准化和量化的设计,建立一份完整的设计规范,封装进组件库,前端建立代码库,这样以后能省去很多繁琐的标注,并且在工作交接的情况下能够起到很大的作用。

现在我在设计中面临的许多问题大都是因为没有一份标准化的设计规范造成的。因为在我接手项目之初没有花一些时间进行规范的梳理,现在我要花数倍于此的时间去填这个坑,呜呼哀哉。

记录流

后台系统一般有一个操作日记,用于记录用户的操作轨迹。因为后台数据对于企业比较有价值,所以一般会进行保护。

记录流主要有操作轨迹和数据查询。

操作轨迹,就是用户对后台数据进行操作所产生的轨迹,一步一记录。一般记录的是初始状态,变更状态,操作内容,操作时间,操作人。

数据查询,在对工作流中产生的数据进行整理,然后形成功能模块。会根据具体的业务需求来进行设计,来对不同的维度的数据进行查询,了解,分析,形成价值。

图片 6

设计流程

4.对系统输出的数据有实时性和准确性等要求。后台管理系统用户对系统的输出有更高的要求,降低用户的时间成本,与其他用户型产品对用户留存有很高要求有着明显区别。

操作流

操作流包含,系统内部操作和前后端互动。

系统内部操作,包含系统基础数据配置和xx管理。xx管理的功能一般包含:增删改查。一般只有基础数据(积分,上传记录)的选择配置,并不涉及到数据的增删查操作。

前后端互动,就比如,微信公众号的文章的录入系统。

根据对这四大特征的分析,可以基本对后台管理系统的使用用户进行准确地定位了。

业务驱动型后台管理系统需求点分析

2.1数据可视化需求

业务驱动型后台管理系统的一大核心商业价值就是对业务的数据进行整理梳理,应用相关样式对数据进行可视化的展示,应用相关技术对业务数据进行规则制定及数据挖掘,以此为特定的商业模式提供可靠而有效的数据支持。而图表类组件是后台管理系统中必不可少的信息呈现方式。动态类图表可直观而实时的反应平台当前的数据状态,而在系统中可能会有很多种类型的数据维度,多重类型的数据同步展示,就对图表类型和展示方式有了进一步的要求。如何明确而清晰地进行数据信息的表达则是该类产品的痛点之一。

2.2系统结构化需求

对于后台管理系统的架构来讲,主要为了方便业务人员操作会采用不同的架构展示形式。不同于用户型产品,同质性用户产品会有相似的模块分类,而这些模块的分类依据更多的是为了用最少的用户操作路径保证最长的用户留存时间。前期的架构搭建之后,就是对其进行功能优化版本迭代等工作,而后台管理系统内容展示形式既统一又千差万别。统一之处是使用场景基本都是PC端,所以在页面设计上主要分为导航栏、多级菜单栏、信息展示区等部分。不同之处是二级菜单页面之后的内容展示,这也是区别不同业务类型后台管理系统的主要板块。那么如何保证系统的多级页面跳转更加一体化、结构化也是系统的需求之一。加强各模块之间的分类界限,提高各个界面的关联性,形成一个层次性、结构化的平台,通过系统的结构化直观地将业务的逻辑内容展示出来,会使用户更容易通过系统的组成部分去更快速的完成业务逻辑性比较强的工作。

2.3操作流程化需求

后台管理系统与用户之间的交互核心就是将业务需求进行流程化实现,各个操作区域之间的耦合度要适度,清晰分类标准,在业务内容嵌套的过程中区分前后操作顺序,明确父子关系,采用树状逻辑进行内容输出设计会更加明确。

2.4界面简洁化需求

后台管理系统普遍都会避免过多样式上的渲染设计,被动型使用使得系统将更多的设计重心倾向于如何传输出更多的信息价值。这也可以从特斯勒复杂性守恒定律的角度上分析,即产品系统的复杂性是守恒的,当用户行为越简单时,对开发人员和设计人员的工作复杂性要求就越高,反之。所以简洁化需求也从另一个方面对技术有了更高的要求。

后台设计注意点

后台设计:展示列表优,编辑弹窗佳,筛选下拉好,组合查询棒。同时注意使用同一控件和互动方式。

未完待续!

定价配置系统业务输出质量要求

后台管理系统所涵盖的类型有很多种,就本人所接触过的金融风控管理系统、电商广告数据平台管理系统、定价配置系统来讲,不管从前台功能设计到后端开发工作,都有比较强的相似点。以下主要通过定价配置系统的部分重要领域,来阐述对于一个业务型管理系统来讲,在输出质量方面都有哪些要求。

定价配置系统简介:通过不同管理员账号识别,开放系统不同的操作内容。主要对销售线上的相关项目进行定价以及配置相关数据模型的操作,并对不同地区的项目进行独立的商务优惠设置,将内部和对外优惠类型与折扣率等信息统一展示在页面内。

输出质量要求:

(1)可以将各类型项目进行分类设置,既可以新建项目,也可对已有项目进行修改,而修改或者新建后的项目内容要保持准确性,尤其是已经更改后的项目,输出的数据一定要保证为最新数据。

(2)相关的模型配置要与当前所在的业务背景适配,对可向模型添加的产品线进行标示性较强的提示,减少业务人员试错数量。

(3)对于部分二维表、图表类内容,保证可导出功能,并且可以对其进行二次操作,方便业务人员后续跟踪核实工作。

(4)对业务变更的响应及时,对于变更的项目可以快速与变更系统对接,在本平台内可以发出风险预警提示信息。

后台管理系统性能可优化点

不同的后台管理系统在相关的业务背景下都有一定的性能要求。举几个例子对其进行分类描述。如电子商务支付管理系统,很多电子支付系统都是以商品交易为核心,大致地支付流程也可以按照交易前、交易中、交易后来进行功能线上的划分。那么在交易前需要提前对商品价值方面的各类数据进行提前的录入,这里可以将实时数据展示进行系统性能优化的入手点,减少人工修改已录入的信息等。其次是在交易中所需要保证的数据保密性、完整性、交互操作等。对于后台管理系统来说,加强信息认证,保护数据安全,防止数据信息泄露是对系统安全性能优化的重中之重。在交易后,完成商品交易,对于后台管理系统来讲,最大的功能点就是对此次交易进行后期跟踪反馈,以及对完成交易的用户信息进行进一步的记录等。

以该类系统为例,阐述的几个功能可优化点较为浅显,但总结起来讲,就是将其进行流程拆分,在每一个节点上都保持其垂直功能的完备,并且在节点加入总流程线之后,既可保证一定的灵活性,又可以维持本节点数据信息不会被其他节点所覆盖。

后台管理系统对业务的反激励策略

一个平台的数据管理系统想必会是很多功能点、业务点效果的集中展示区了,而数据管理系统也是可以发现业务需求点的重要途径。包括定价配置系统,通过对项目的相关信息设置操作,也可梳理出周期内业务变化趋势,并且可将其反馈给业务人员。所以后台管理系统不仅是对业务逻辑的产品化实施系统,更是可以对业务进行反激励的途径之一。只是可能需要更强大的技术做支撑,可同时对数据进行加工处理,并且保证响应速度等。

相关文章