1、前端设计和后端设计的区别
对于产品经理来说，平时的设计工作最主要是以下几种：
APP设计
WEB设计
微信端设计
后台设计
也可以分为：前端设计和后端设计。
其中前端设计包括：APP设计，WEB设计，微信端设计。其特点是面向群体一般比较繁杂，从功能上一般是展示数据，收集数据——传送到后端（用户操作数据，用户行为轨迹数据等等）。一般业务性和交互设计体验两者属于同等重要的地步——如果你的软件满足了用户的需求，但是丑得像陀翔，用户不买账；但是如果美得不可方物，但是没有切中用户的需求，用户也只能忍痛舍弃。
而后端设计更加注重数据流转（数据来源，数据流向，以及在这个过程中对数据的处理）以及业务逻辑。对于用户体验方面倒是注重得比较少。所以可以看到，一般的后台系统视觉风格比较严谨，注重分类清晰。
2、后台系统的本质
权限管理
工作流
记录流
操作流
本质为谁可以对什么进行怎样的操作，需要产生什么记录，即who—where—how—what。
工作流
工作流解决的主要问题：为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档，信息或者任务。
举个例子：审批流程设计
审批设计首要就是弄清楚流程。流程涉及多少个人/部门？每一个人/部门都有哪些数据权限和操作权限？其审批流程如下：（不同的办公审批流程是不一样的）
流程：
开始 → 创建请假审核 → 部门经理审核 → 行政经理审核 → 结束
记录流
工作流主要包括操作轨迹和数据查询。其中，操作轨迹是用户对后台的数据进行操作所产生的记录，需要达到一步一记录的程度。
将初始状态，变更状态，操作内容，操作人，操作时间罗列清楚，一般来说不同业务差异性不大，是后台的标配模块。
其中，数据查询是指能够在后台中针对不同维度的数据进行查询，了解，分析，并且获取其价值。
一般来说，尽量使用默认控件去进行设计，以及不同模块之间，能够使用较为统一的交互方式——开发会比较有效率。
操作流
工作流主要包括：系统内部操作前后端互动。
（1）系统内部操作
一般是系统基础数据配置和XX管理等等。XX管理一般功能比较丰富（新增内容，删除内容，修改内容，查询内容，导出内容等等）而系统基础数据配置相对来说比较简单。一般只有基础数据的选择配置，并不涉及到数据的增删查操作。
系统基础数据配置一般是配置系统的一些基础数据，比如说：积分，上传设置等等。
（2）前后端互动
比如说，我们最常看到的微信公众号的文章的录入系统，此部分有很多的参数提供给使用者选择，如何选择这些参数是设计这类后台的难点。
权限管理
好的权限系统一般需要思考以下几点：
谁是否对某资源具有实施某个动作（运动，计算）的权限；
通过用户，角色，资源（权限）三方面来进行权限的分配；
赋予用户某个角色，角色能访问及操作不同范围的资源（权限）。
本质来讲就是：通过建立角色系统，将用户和资源进行分离，保证权限分配的实施。
3、后台系统的常见分类
后台系统按照开放度分类一般分为：开放式后台系统和非开放式后台系统。
第一种（开放式后台系统）常见的有：微信公众平台等等；第二种是一般不会在界面上提供注册功能，后台系统用户的添加一般是拥有相关权限的管理员添加配置。
那么，如何设计权限呢？
针对不同的后台，对角色的设计也是不同的。
业务流后台，按照业务类型进行角色设计。
数据统计后台，按照用户类型来进行角色设计。
CRM，按用户的职位等级进行划分。进行一级划分后，往往还需要对角色进行细分。之后通过级别的划分来控制可访问及操作的数据。
在进行角色细化时，有三点需要注意：
同类型的角色，上下级角色的权限关联是怎样的？
上级角色能否对下级角色的业务进行操作？
删除的操作是否需要上级的审核。
在实际开发过程中，权限的分配往往是在整个后台开发完毕之后才去实现的。
最近在做的项目涉及到一个业务流后台的权限管理系统，不仅涉及到纵向的分级，还涉及到了横向的分级。举这个例子来讲解一下权限系统的流程。
1）进行角色的分级，包括 全国级经理 → 大区级经理 → 区级业务人员。
2）确定各区级包含的地域，以组织管理的方式附能到账号信息中。全国级经理账号具有所有区级组织，各大区只具有所属大区组织。
3）当业务进入平台后，根据2）确定的区级关系分类
4）进行任务工作流程的拆解 拆解后流程 业务需求进入 → 按照组织关系分类 → 分类后业务需求进入总需求列表 → 根据账号组织关系显示需求列表 → 1）大区级经理分配给区级业务员2）全国级经理可不按照组织关系分配给大区级经理
5）通过1）-4）的拆解 可以得到，我们对业务需求的管理需要 2个菜单显示，1）未分配的需求列表菜单，全国级经理账号显示所有需求，大区级经理站好显示所属大区需求，区级业务人员没有此菜单。2）分配给我的需求列表，所有账号都具有此菜单，显示分配给自己的需求列表。
