针对简单的后台产品，我们通常采用需求驱动设计（Request-driven Design，RDD）。
▎1.需求驱动设计
需求驱动设计，是指我们在设计后台时，根据领导、运营、市场、客服、前端的产品经理等需求方所提的具体需求，直接进行需求设计。这种方式简单快捷，与我们做前端产品在思路和方式上相同。
▎2.设计方法简介
2.1明确目标
后台系统所支持的需求范围、上线进度要求、风险及质量管理等，这一步更多体现在项目管理中。
2.2需求收集
①穷举用户角色
后台的用户是十分明确的，他们一般就是公司内外部的业务操作人员。这也是作为后台产品经理的一个优势，你与用户的距离是十分的靠近，你所有的设计是否有效均可以马上得到检验和反馈。
②需求调研
调研方式-深度访谈：与前端产品不同，后台产品的用户在现实生活中离我们很近，很容易就能接触到，这个时候就不要用问卷调查这种大覆盖面的方式了，一是用户基数没有那么大，二是后台需求基本不需要做数据分析，无需通过这种方式去挖掘用户需求。所以直接与用户交流、访谈是最快有效的方式；
调研对象-关键角色：我们的访谈对象，需要尽可能满足资深、直接使用、有话语权三个条件，因为这种关键人所提出的需求会更加全面、具体且有深度，能够清楚的解释为什么要这个功能，如果没有会出现什么后果，曾经踩过哪些坑。这些被伤害过的人，知道心痛的滋味。
③建立需求池
前面两步的目的都是为了收集需求，接下来我们需要建立需求池对需求进行管理。
2.3结构设计
结构设计即是模块划分，后台设计中的模块划分秉承一个重要原则：一个角色，一个模块，完成一件事情。也就是说一个具体的角色，能够在一个功能模块中完成任务。原因主要是以下两点：
降低用户记忆成本：你绝对不想为了做一件事，要在多个模块跳转、多个页面点击。
便于划分管理权限：做系统产品，权限划分永远是重点，将一个角色要进行的操作单独作为一个模块，方便权限分配。
2.4流程设计
流程设计与原型设计都是基本功，下述将"流程设计"作为一级菜单才介绍，至于原型设计较为基础则不展开介绍了。
▎3.流程设计
3.1流程介绍
①定义
特定的主体，为了完成特定的需求而进行有顺序的一系列操作过程。例如：外卖订餐流程，特定的主体是用户，特定的需求是订外卖。我们在绘制流程图时，只要能够说清楚就可以："谁在哪个环节要做什么"。
②分类
业务流程
根据产品解决用户核心问题的顺序所梳理的完整的闭环流程，包括线上和线下两部分。例如，下图是解决用户订餐问题的整体流程：
理完整的业务流程是产品设计的必要条件，我们要同时重视线上以及线下的流程，保证其完整性。
功能流程
功能流程也可以看做是任务流程，是产品实现某一功能的流程，或者是用户完成某一任务的流程。例如，下图是用户下单流程：
页面流程
在功能流程基础上，用户完成某一项任务所需经过的页面，就组成了页面流程。
操作流程
在页面流程基础上，用户完成某一项任务所需进行的操作顺序，就是操作流程。
③形式
基础性流程图
以图形的形式，显示流程中前后活动的顺序；
跨职能流程图
又称泳道图。显示进程中各个步骤之间的关系以及执行它们的职能单位、系统或功能模块。其实就是在基础性流程图上，将角色独立成为一个个泳道，便于更加直观的查看流程中各环节与角色的关系和流转情况。
④六要素
参与者
在流程设计中，我们要明确参与者。参与者就是谁在这个流程中执行操作：可以是系统，可以是某个设备，更多的指一个角色。比如用户、商家、外卖小哥。
活动（动作）
一个处理动作，具体做了什么事情。比如下单、接单、送餐、评价。
次序
这些事情发生的前后顺序如何，哪个任务是其他任务的前置条件。比如用户不提交订单，就无法生成订单。
输入
每项活动开始取决于什么样的输入物或数据，比如做饭的师傅开始做菜时，需要拿到具体的点菜单。
输出
每项活动结束后，会输出什么样的文档或数据给下一方，比如师傅做好菜后，如何让负责传菜的人知道菜已经做好。
3.2流程设计
①调研现有流程
对于很多的产品，用户痛点是明确的，很早之前就有了各种解决方案。只不过互联网的兴起，提供了一种更快速、更便捷高效的方式。O2O产品就是这样一类借助互联网特性，解决用户已有痛点的产品。
肚子饿了要吃饭，但是很懒不想动，这个就是外卖APP要解决的痛点。当我们从最初开始设计外卖产品流程时，就应该从已有的、 成熟的、经过市场检验的解决方案入手。
当外卖APP还没有兴起的时候，要想能吃到饭又不想出门，人们就有效的方式就是打Call。经过调研，电话订餐的流程如下：
②分析环节痛点，线下流程线上化
线下流程梳理完成后，会发现每个环节都存在或大或小的痛点。这个时候，就应该考虑如何利用互联网打破信息壁垒、便捷快速的特点和技术手段来解决这些痛点，进而在线上解决方案的基础上，设计一条全新的业务流程。例如，初步分析即可发现现有订餐流程存在诸多问题：
③使用泳道图，设计优化流程
