教你从0到1做后台系统设计
从硬币的角度去看待后台系统，培养自己的设计思维。
正面看后台：1.减轻运营压力；2.注重数据流转；3.侧重功能实现。
反面看后台：1.设计风格单一；2.业务逻辑复杂；3.缺少系统说明。
侧面看后台：1.数据准确有效；2.操作流程简单；3.系统简单好用。
了解后台系统
后台就是给用户分配一个有某些权限（菜单级）的角色，对特定数据（数据级）进行增删改查导（功能级）的管理系统。
了解后台必须熟悉前端业务，前端偏向用户（功能操作）查看信息，提交信息，而后台侧重管理员（数据处理）创建信息、处理信息的地方，而信息传递的中间件就是服务器。
后台系统本质
后台系统侧重于工作流、权限管理和操作流。本质是谁可以对什么进行怎样的操作，需要产生什么记录，即who—where—how—what。
后台系统特点
1.系统目标明确：辅助用户自主完成任务，减轻运营压力。
2.用户需求明确：需求一般来至企业内部的领导、团队或业务部门。
3.注重运转效率：以功能实现为目的，注重提高系统各个环节的运转效率。
4.注重系统业务:以业务导向为目的，注重整个系统业务流程和相关模块的逻辑清晰。
梳理后台业务
需求驱动产品
需求是业务驱动或技术驱动的核心。需求驱动设计就是根据相关部门提出的需求，进行产品架构与功能设计。对产品而言，是改变自己的设计策略。
常见梳理方式
产品功能规划
产品规划直白点就是我们在哪（分析现状），怎么能去（找资源），我们要去哪（确定目标）。一般会输出产品路线图，项目计划，需求矩阵，版本迭代计划。
产品结构设计
产品结构设计是针对产品功能的结构设计，在项目立项或产品设计的过程中，更多是基于功能构建产品的整体架构。一般会设计功能结构图、信息结构图、结构图，主要是梳理产品框架，产品功能、页面流程。
洞见后台需求
以需求的“真实、刚需、高频”中心，洞见用户需求与用户行为间的情感链接。
用例图梳理后台业务
用例图从用户的角度描述系统的功能要求，使用者作用于系统边界的方法以及系统的反应。在设计用例的时候，一般是从操作的Uc级描述系统功能，并指各功能的操作者，本质还是扩展功能的增删改查导。案例分析：以某共享街电后台管理的商户和业务员为例。
流程图梳理后台业务
流程图是梳理业务的最好方法。在产品从想法过渡到模型的阶段，流程图以动作来推动业务前进。流程图描述的是完整的业务流程，可以梳理功能模块、业务流程、使用路径。常见的有业务流程图、任务流程图、页面流程图等。案例分析：以某融资租赁公司的消费贷为例。
状态图梳理后台业务
状态图是对类图的补充，仅需为那些有多个状态的、行为随外界环境而改变的类画状态图。根本就是阐明在其生命周期的时间和状态图是用于此目的的一个对象将满足某些条件、执行某些活动、等待某些事件。案例分析：以某共享充电商品结算为例。
时序图梳理后台业务
时序图是一种强调时间顺序的交互图，它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。时序图具备了时间顺序的概念，提供了控制流随着时间推移的清晰的可视化轨迹，从而可以清晰地表示出对象在其生存期的某一个时刻的动态行为。案例分析：以某借款人的标的逾期还款为例。
分析业务场景
以业务闭环为中心，分析用户画像，深度挖掘用户使用场景，去验证真实需求。
用户故事地图
以用户思维为中心，站在用户的视角去看产品，分析用户行为和动机总结。
用户体验地图
后台系统设计
常见后台系统
了解后台设计
后台设计流程一般是定架构（布局）→画页面（原型）→加交互→写逻辑（软件需求），直白点就是对功能或数据的增删改查导（踩过的坑）。
后台设计更多是考验产品的设计逻辑思维。做后台设计先要快速了解公司业务，其次是需求的频次和重要性决定你的产品规划，最后是要求对数据的准确性，处理的时效性。
在敏捷开发中，为了方便系统维护和版本迭代，在设计过程中要懂得管理菜单类目，制定数据字段，梳理业务流程，拟定业务规则，规范设计标准，复用设计页面。此外，也要考虑一致性原则，可视化原则，可用性原则，可扩展性原则。对于可有可无的功能模块都砍掉，从0到1一般都是功能简单能用，而系统好用会通过不断的迭代去优化。
了解点线面
点线面是一切判断基准的最基础要素，所有的元素概括起来不外乎点、线、面三种，三种元素的相互结合与相互转换之间就构成了产品设计。
点线面是后台设计中常用的构成元素，它构建了整个产品的架构，使其更加具体化。点线面设计就是把交互事件作为节点，用例作为一条线，再根据点与线的关系构成页面，显现出从点到线，从线到面的设计闭环。
点线面法则有四个重要组成部分：用户、场景、需求、功能。在后台设计过程中最关键的就是如何将用户，场景，需求转化成功能。作为产品经理，我们在后台设计时，更侧重关注点、线、面三位一体的运用，即从点、线、面到面、线、点的闭环。
确定后台布局
无论从0到1做后台，还是系统重构，后台设计是产品经理必备的基本能力，既能逐步锻炼个人的逻辑思维，也能快速了解公司的业务流程。后台设计流程一般是定架构（布局）→画页面（原型）→加交互→写逻辑（软件需求）。
后台设计的标准布局为栅栏设计，一般将后台结构分为导航区域、功能区域、内容区域。比如导航区域的Logo、菜单栏；比如功能区域的账户、消息、安全设置；比如内容区域的列表，录入，详情。
常见的原型设计方式有手绘原型、灰模原型、交互原型。产品经理一般是画低保真的手绘原型或灰模原型，而高保真的交互原型更多是让UI去实现，但我们要在软件需求中说明所有页面的展示，每个功能的状态。
字段设计
字段是后台相关数据的载体，常见的字段类型有：业务型字段、系统型字段、管理型字段、规则型字段。字段设计是后台设计中最基础的部分，比如构建列表字段、设计类图、设计表结构。
手绘原型草图
手绘原型有助于带动思维。在项目立项阶段的头脑风暴和概念测试，手绘原型在初期验证想法时非常高效，也方便讨论和重构，同时也适合敏捷开发时快速出原型，因此手绘是最简单、快速的表现产品轮廓的方式。
灰模原型设计
灰模原型仅仅是将产品需求以线框结构的方式展示出来，让产品需求更加规整的直观展现，所有的元素，除了组件自带的颜色，只用灰黑白。相比交互原型，灰模原型只是缺少交互效果。
后台设计案列
业务规则设计
业务规则描述了业务过程中重要的且值得记录的对象、关系和活动。其中包括业务操作中的流程、规范与策略。业务规则保证了业务能满足其目标和义务。
后台权限管理
了解权限管理
权限管理是公司内部根据系统设置的安全策略。权限管理常见的场景是角色访问控制，用户只能访问自己被授权的内容或数据。直白说就是通过建立角色系统，将用户和资源进行分离，保证权限分配的实施。最常见的权限设计模型是RBAC模型。
RBAC模型
RBAC即基于角色的权限访问控制（Role-Based Access Control）在RBAC中，权限与角色相关联，用户通过成为对应角色的成员而得到这些角色的权限。直白说就是“Who对What(Which)进行How的操作。它支持最小权限原则，责任分离原则和数据抽象原则，从而简化了权限的管理。
权限设计
好的权限系统一般是从用户、角色、权限三方面来考虑。以某共享出行系统为案例：我们要为某业务员和商户创建一个管理账户，并分配对应的角色，且在系统拥有不同的访问权限和操作权限。
账户管理案列
账号管理是管理员最常用到的功能，相应字段一般是常用字段和特定字段。常用字段比如用户的名字，手机号，id，注册信息等，特定字段是公司业务需求，比如部分，角色，登录时间，登录次数，访问IP，访问设备等。
角色管理案列
角色管理是用来管理公司内部用户的角色信息。一个复杂的后台会被分割成很多角色，把具有共同特征的某一类人群的身份归纳，从而为不同的用户赋予对应的角色权限。
权限管理案列
后台是多用户角色，而每个角色的权限也不同。做权限管理要梳理业务逻辑，产品经理可以借助UML建模的用例图将角色按Uc级权限梳理清楚，也可根据部门需求列一份权限清单，并做好CheckList。
-END-
