您正在使用IE低版浏览器，为了您的雷锋网账号安全和更好的产品体验，强烈建议使用更快更安全的浏览器
发私信给人人都是产品经理
导语：本文适合入门级的移动端产品经理，在思考、设计、制作客户端及后台原型时可做参考。
同步到新浪微博
中国最大、最活跃、最具人气产品经理学习、交流、分享平台。
当月热门文章
为了您的账户安全，请
您的邮箱还未验证,完成可获20积分哟！
您的账号已经绑定，现在您可以以方便用邮箱登录分享优秀作品，可以成为
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
喜欢: 0 & 回复:
Powered by您的位置：
三个步骤教你如何做好后台产品设计
作者：点融黑帮（DianrongMa
　　编者按：本文经授权转载自微信公众号点融黑帮(DianrongMafia)，作者方东东。这篇文章主要探讨了后台产品的设计方法与思路，以点餐为例详细说明了如何做好业务逻辑梳理、产品梳理以及原型设计。
　　导语：
　　这段时间，让我对后台产品有了初步的了解。所以想尝试自己总结一下对后台产品设计和开发的一些知识。后台产品也有不同的分类，我要介绍的是工作流方面的产品。
　　以下的内容，有很多都参考了前辈的意见。有不对的地方也希望大家多多指点。
　　首先要清楚的是，后台产品和前端产品存在很大的差异性。后台产品更加注重的是业务逻辑的清晰和功能的实现，而前端产品对视觉设计和交互设计有更高的要求。
　　下面开始，介绍自己总结的后台产品的设计方法与思路(就像前面所言，更多还有其他前辈的知识，先在此道谢)。
　　业务逻辑梳理
　　需求调研与分析完成后，就是自己对内容的消化和吸收。首先要做的事情是自己先清晰地理解一个产品。只有自己理解了，才能更好地推进产品进行开发。
　　先梳理清楚线下的业务流程。将线下的业务流程梳理清楚以后，然后才是对产品的思考。这里要介绍几种帮助自己更好地梳理业务流程的工具。
　　状态图，流程图，泳道图。三种图，所起到的作用是不一样的。下面我详细说明。
　　a.状态图
　　状态图的作用是让人清楚业务的实现需要经历的状态序列，以及引起状态转移的事件，和因状态转移而伴随的动作。状态图的驱动是基于状态的转换。下面我以点餐为例子。
　　业务的开始和结束用圆角矩形表示。业务的状态以矩形表示。每一个矩形都表示一个状态。菱形表示业务分支。每一个矩形之间都伴随着一个动作。
　　状态图能清楚地让我们看到完成的点餐流程中，会在哪些地方进行停留，并知道转向下一个状态时会伴随着怎样的动作。另外，在 “菜品加工中” 下方特意设立了一个
“食材准备中” 作为子状态，因为业务流程中可能会出现某些特殊的情况(如某些菜品需要准备食材)而停留在某个状态，这时需要先去完成其它操作(准备食材)
后再回到该状态(菜品加工中)继续之后的业务流程。
　　也许会有人觉得，这样做将简单的事情复杂化了。如果对于简单的业务逻辑，确实有点多此一举，但如果一个业务流程中存在很多个(7 个
+?)状态的时候，我相信状态图能让你在进行业务梳理时保持比较清醒的头脑。
　　b.流程图
　　流程图，相信大多数人对此并不陌生。但是，我看见很多人绘制的流程图并不是十分规范。不规范的流程图，自己理解起来可能没有什么问题，但是别人可能就会产生误解。
　　流程图，我将它分为分为三步走。1.流程图。2.泳道图。3.分阶段的泳道图。下面一个一个介绍。
　　业务流程图描述的是完整的业务流程，以业务处理过程为中心，一般没有数据的概念。流程图以动作来推动业务前进。下面还是以点餐作为例子。
　　同样业务的开始和结束用圆角矩形表示，而每一个动作则以矩形表示，菱形表示可能会出现的分支。可以清晰的看到流程图没有任何状态标识。状态图与流程图表达的不同效果一眼便知。
　　流程图更加关注的是业务实现具体需要进行哪些操作。每一个动作的构成形式基本都是 “动词 + 名词” 或者 “动词”
的形，这样才能更加明晰以动作为驱动的流程图。
　　c.泳道图
　　泳道图，又称为跨职能流程图。也是我所说的流程图的第二步。作为流程图的进阶，泳道图加入了泳道表示不同角色(或岗位、部门等)。让人在了解业务流程时，也清楚由谁执行该动作。同样以点餐为例子。
　　可以看到，每一个动作都放在相应的泳道下，对应了执行此动作的人。这样对于业务流程中不同角色的职责也会更为明确的认识。
　　d.流程图终极版
　　可以看到，在最左边加了一个侧栏，将不同的动作划分进了不同的阶段。个人觉得这是弥补了之前没有状态说明的不足。让人在了解详细业务流程的同时，也对状态有了大概的认识。
　　也许很多人，觉得花这么多时间画图会浪费很多时间。我觉得仁者见仁智者见智了。对于我个人而言，每天捣弄这些图，会很快加深我对产品的理解。特别是在业务比
较复杂，而且之前有完全没有接触过相关方面知识的时候，仅靠大脑很难有清楚的思维，但是图形化后却能很好地理解。在业务整理上多花点时间整理，我觉得是很有必要的。
　　产品梳理
　　a.梳理好线下的业务逻辑以后，要将它抽离搬到线上。这个过程，可能会删除掉某些线下的环节。
　　同样以点餐为例。
　　可以看到，这个过程当中，厨师和勤杂工在线上不需要有操作。所以状态图和流程图看起来简洁了很多。
　　b.产品功能点。
　　依据产出的流程图，基本上可以大致确定产品的功能点。
　　先理出单独的功能(功能)
　　然后加入角色(功能 + 角色)
　　准备工作做好以后，可以开始搭建产品的架构图了。
　　页面关系
　　页面 + 功能
　　页面内架构
　　后面的架构就不写了。
　　先搭页面，再确定页面内的功能，最后细化页面内的信息。在原型出来以前，可以拿产品架构图先和别人进行一下交流。产品架构图相较于原型图，与数据库的设计思想比较一致。而原型视图化后，对于数据库设计却反而变得抽象了。另外，产品架构图修改较快捷，返工成本相对较小。
　　需要说明的是，产品架构图更多是需要个人的整理。
　　原型设计
　　产品梳理好以后，就要开始搭建原型了。
　　a.先确定通用模块：页头、页尾、一级导航、二级导航
　　根据产品的不同，选择合适的布局。
　　b.将产品架构图的内容填充到页面内，并加入文字说明操作
　　c.细节添加
　　导航： 一(二、三)级导航;菜单...
　　常用模块交互方式
　　弹窗：对话框...
　　色彩：页面基调;字体颜色...
　　反馈：提示;警告;正确;错误...
　　细节内容可以在页面旁边的进行注释。但尽量要单独出一份详细的 PRD。
　　产品设计的阶段，就暂时结束了。
　　之后就是与开发沟通，推动产品一步一步往前走了。这个过程中，可能会有许多需求变更和返工。要有充足的耐心慢慢解决问题。
　　产品设计也许结束了，但是产品的开发才刚刚开始。
　　路漫漫其修远兮，吾将上下而求索。
(转载请保留)
置顶推荐热门话题大家都在看
互联网的一些事，已超50万小伙伴关注！综合（58）
如何设计后台管理系统原型，我理解的是，针对互联网产品范畴的后台管理系统。即维护用户、管理社区、跟踪分析用户行为并进行数据统计分析等。我当初搭建后台产品的时候也遇到过很多疑问，正好借着这个回答来个梳理和总结。
这里不讨论涉及供应链系统的后台产品，如电商、团购等，美团O2O供应链系统架构设计解析 里面涉及复杂的交易流程优化。
为什么说设计后台产品很难？看看这个问题的回答。
难参照竞品。用户只要大量地使用过别的产品，便会建立起相应的心智模型。然而后台对于很多人而言却非常陌生，毫无心智模型可言，也难以做竞品调研。——郑坚义
也就是说面向大众用户的前台产品，大家培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。而且，做后台产品需要非常懂业务，考验产品经理的核心竞争力——业务知识储备、结构化思维和系统性抽象能力。推荐看：为什么说好的产品经理一将难求？ – 蒸汽机的回答
开始后台产品设计之前，先找找相类似的产品，虽然我们无法去观照其他产品的后台都是长什么样的，但是现在有不少提供标准化数据分析的SaaS服务公司，如友盟、诸葛IO。但是为什么我们很难直接采用这些公司的产品来管理和维护运营？软件运营（SaaS）模式的核心是标准化架构+定制化需求，比如体系已经成熟的ERP、CRM、OA等管理系统涉及审批流程、财务审计等更容易标准化生产。而互联网产品的业务各式各样，变化不断，还会随时出现一种全新的业务模式，所以后台产品做到标准化有一定难度。
我们先看看，类似的数据分析平台。
百度统计——最大的中文网站分析平台
诸葛IO——精细化数据分析工具
友盟_专业的移动开发者服务平台
TalkingData-移动.数据.价值
莲子数据首页-lotuseed-专业的移动数据分析服务平台
腾讯云分析
面对公司的社区型产品和运营人员提出的需求，发现以上平台都难以满足后台管理运营。但是拆解分析里面的业务逻辑能帮助你理解后台产品的模块结构。
后台产品的功能里最容易标准化的就是用户分析，新增用户、留存率、活跃度等，所以我在设计后台产品的运营数据上很大程度上参考了这些数据分析的结构和模式。而市面上的数据分析工具，最大的问题在于，我所知道的工具里还没有任何一款可以整合统计不同渠道的数据，也就是说PC、H5、iOS、Android分别进行统计，假如统计今天多少用户进行了“点赞”的操作，这个用户行为跟踪是无法进行全渠道分析，那么分析就被割裂开来，难以形成系统。并且大部分是针对移动应用，网站分析这一块只有百度做得相对详细点。后台产品是根据业务情况定制化需求的，游戏应用、O2O、电商、垂直社区、社交产品都会有形成巨大差异的后台产品模型。
针对我负责的垂直社区来进行下一步分析，结合前台产品的整体功能，我确定了后台产品的模型架构分为三大模块：运营数据分析、社区管理、交易中心。运营数据分析是用来监测用户和内容的变化趋势；社区管理是运营人员对用户和内容进行日常的维护和管理；交易中心是用来记录交易明细和收支变化趋势的（社区有打赏和红包功能）。
运营数据分析包括用户分析、内容分析和事件分析，其中有用户类别和渠道两个维度。就是说每个分析里面可以针对不同的维度，比如除去内部运营人员后今天产生多少点赞数，比如在iOS上今天产生多少点赞数。以下是我考虑功能结构的思路（下面图片涉及核心业务数据将会模糊处理）：
用户分析→用户追踪→新增趋势+活跃度+留存率+用户特征
内容分析→用户生产内容追踪→新增趋势+类别情况
事件与转化→用户行为追踪→事件趋势+事件交互+事件转化
社区管理主要包括用户管理、内容维护、事件设置。社区管理在一定程度上影响运营数据的变化。比如，给用户添加标签生成用户画像。
用户管理→用户特征+用户分类→用户分析
内容维护→用户生产内容管理→分类管理+内容监控
事件设置→用户行为管理
交易中心包括总资产概况、交易明细、交易分析，结构比较简单，用来管理社区的财务和监控财务数据，与电商平台复杂的财务系统相去甚远。
以上仅仅是提供一种后台产品模型架构的思路，后台产品主要由前台产品模型和业务模式决定，不同种类的互联网产品的后台可能千差万别，勿直接套用。
说了那么多，是想说明后台产品的设计非常有挑战性，虽然由于多种原因不像前台产品那样是香饽饽，但绝对是个很好的锻炼机会。产品人除了把控流程逻辑和功能细节外，产品模型架构能力来自于业务知识储备、结构化思维和系统性抽象能力，因为你的思考维度需要跳出单线程的逻辑或单一功能的交互，要进化成梳理多线程之间的复杂逻辑或多个功能之间的交互。
好了，最后贴个干货出来，记录这一次挑战。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：222369次
积分：4027
积分：4027
排名：第6223名
原创：97篇
转载：587篇
(40)(1)(22)(2)(1)(5)(6)(21)(8)(8)(17)(12)(9)(2)(1)(4)(29)(44)(10)(9)(12)(3)(93)(3)(34)(8)(8)(36)(39)(17)(10)(6)(16)(16)(57)(36)(1)(8)(25)(1)(4)(5)(2)