三个步骤教你如何做好后台产品设计.pdf

三个步骤教你如何做好后台产品设计 编者按 ：这篇文章主要探讨了后台产品的设计方法与思路 ，以点餐为例详细说明 了如何做好业务逻辑梳理、产品梳理以及原型设计。 这段时间 ，让我对后台产品有了初步的了解。所以想尝试自己总结一下 对后台产品设计和开发的一些知识。后台产品也有不同的分类 ，我要介绍的 是工作流方面的产品。 以下的内容 ，有很多都参考了前辈的意见。有不对的地方也希望大家多 多指点。 首先要清楚的是 ，后台产品和前端产品存在很大的差异性。后台产品更 加注重的是业务逻辑的清晰和功能的实现 ，而前端产品对视觉设计和交互设 计有更高的要求。 下面开始 ，介绍自己总结的后台产品的设计方法与思路（就像前面所言 ， 更多还有其他前辈的知识，先在此道谢）。 业务逻辑梳理 需求调研与分析完成后 ，就是自己对内容的消化和吸收。首先要做的事 情是自己先清晰地理解一个产品。只有自己理解了 ，才能更好地推进产品进 行开发。 先梳理清楚线下的业务流程。将线下的业务流程梳理清楚以后 ，然后才 是对产品的思考。这里要介绍几种帮助自己更好地梳理业务流程的工具。 状态图 ，流程图 ，泳道图。三种图 ，所起到的作用是不一样的。下面我 详细说明。 a状态图 状态图的作用是让人清楚业务的实现需要经历的状态序列 ，以及引起状 态转移的事件 ，和因状态转移而伴随的动作。状态图的驱动是基于状态的转 换。下面我以点餐为例子。 业务的开始和结束用圆角矩形表示。业务的状态以矩形表示。每一个矩 形都表示一个状态。菱形表示业务分支。每一个矩形之间都伴随着一个动作。 状态图能清楚地让我们看到完成的点餐流程中，会在哪些地方进行停 留，并知道转向下一个状态时会伴随着怎样的动作。另外，在 “菜品加工 中” 下方特意设立了一个 “食材准备中” 作为子状态，因为业务流程中 可能会出现某些特殊的情况（如某些菜品需要准备食材）而停留在某个状态 ， 这时需要先去完成其它操作（准备食材） 后再回到该状态（菜品加工中） 继续之后的业务流程。 也许会有人觉得 ，这样做将简单的事情复杂化了。如果对于简单的业务 逻辑 ，确实有点多此一举 ，但如果一个业务流程中存在很多个 （7 个 +？） 状态的时候，我相信状态图能让你在进行业务梳理时保持比较清醒的头脑。 b流程图 流程图 ，相信大多数人对此并不陌生。但是 ，我看见很多人绘制的流程 图并不是十分规范。不规范的流程图 ，自己理解起来可能没有什么问题，但 是别人可能就会产生误解。 流程图 ，我将它分为分为三步走。1.流程图。2.泳道图。3.分阶段的泳道 图。下面一个一个介绍。 业务流程图描述的是完整的业务流程 ，以业务处理过程为中心 ，一般没 有数据的概念。流程图以动作来推动业务前进。下面还是以点餐作为例子。 同样业务的开始和结束用圆角矩形表示，而每一个动作则以矩形表示， 菱形表示可能会出现的分支。可以清晰的看到流程图没有任何状态标识。状 态图与流程图表达的不同效果一眼便知。 流程图更加关注的是业务实现具体需要进行哪些操作。每一个动作的构 成形式基本都是 “动词 + 名词” 或者 “动词” 的形 ，这样才能更加明 晰以动作为驱动的流程图。 c泳道图 泳道图 ，又称为跨职能流程图。也是我所说的流程图的第二步。作为流 程图的进阶 ，泳道图加入了泳道表示不同角色 （或岗位、部门等）。让人在 了解业务流程时，也清楚由谁执行该动作。同样以点餐为例子。 可以看到，每一个动作都放在相应的泳道下，对应了执行此动作的人。 这样对于业务流程中不同角色的职责也会更为明确的认识。 d流程图终极版 可以看到 ，在最左边加了一个侧栏 ，将不同的动作划分进了不同的阶段。 个人觉得这是弥补了之前没有状态说明的不足。让人在了解详细业务流程的 同时，也对状态有了大概的认识。 也 许很多人，觉得花这么多时间画图会浪费很多时间。我觉得仁者见 仁智者见智了。对于我个人而言 ，每天捣弄这些图 ，会很快加深我对产品的 理解。特别是在业务比 较复杂，而且之前有完全没有接触过相关方面知识 的时候 ，仅靠大脑很难有清楚的思维 ，但是图形化后却能很好地理解。在业 务整理上多花点时间整理，我觉得是很 有必要的。 产品梳理 a梳理好线下的业务逻辑以后，要将它抽离搬到线上。这个过程