oms设计 用讲故事的方式来排版设计网站后台-凯发旗舰

b端产品是c端产品的根基，b端产品更贴近业务，只有深入了解并熟悉业务才能做好b端产品。

今天分享一种叫做oms的设计方法。oms设计是按用户故事设计思路来设计用户的使用场景，通常来讲用户故事，包括时间、人物、地点、事件。通俗讲，管理系统需要做的事情，就是对确定的时间、确定的用户、在确定的场景执行确定的事件，或对他们进行管理。

管理后台类产品，核心就是解决一个问题：“某时间某人使用某物做了某事“。

如图所示：管理后台的核心三要素：人、物、事。

人：权限管理（包括：角色设置、操作权限、数据权限）

人的管理和设计，主要解决这一问题：事件对谁触发？是对所有用户，特定的用户？

能解决这个问题的方式就是权限管理，在讲解权限管理之前，我们首先普及一个概念：

rbac(role-based access control)即基于角色的访问控制，是一种权限设计思想。在 rbac 中，权限与角色相关联，用户通过成为适当角色的成员来获得这些角色的权限。相较传统的访问控制（自主访问、强制访问）来说，rbac 能更好的支持最小权限、责任分离和数据抽象等原则，极大地简化了权限的管理。

角色设置：如管理员、普通操作人员、游客等，是区分不同身份操作管理后台的能力。通常管理员具有最高权限，能获得所有操作，甚至是删除成员；

操作权限：基本包括增、删、改、查四类。角色权限直接影响操作权限，不同角色具备不同的操作权限；

数据权限：一般分为公共库数据和私有数据（特指需要限制的数据，如部分内容不能全局可查看）；

物：事务管理（业务流程图、任务流程流、原型设计图）

业务流程图：是一种描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向的图表。

作用：涉及多角色之间的交互行为，以泳道图方式梳理核心业务流程，明确不同环节节点不同角色用户的操作及需要完成的任务。其作用是——表达清楚业务需求在产品线的各个阶段中在各个功能模块之间的流转。

说明：待需求产生后，首先落地的流程说明。业务流程图不是一层不变的，它随着需求的逐步明确而逐渐调优。业务流程图是整个项目的核心，最后将成为整个项目的标杆文件，物流是产品设计或技术框架都会以此为主要参考，所以梳理清晰业务流程对设计后台管理系统非常重要。

当用户在前端触发某一操作到期望看到的结果之间，会存在很多工作在后台完成，这里所指的后台通常来讲就是管理系统。

以货运行业为例：

业务流程图在产品规划阶段完成，任务流程图在产品设计之前完成，二者存在先后顺序，通常是有了业务流程图之后，再开始着手处理任务流程图。

任务流程图：用户在业务流程中完成了某一项任务，可以通过页面流程图来梳理清晰此阶段主要是围绕着核心业务流程进行拓展，形成直线任务和完善细节。

梳理任务流的思路类似讲一个故事，譬如：我们是如何解决这个问题的？解决问题的流程是什么？

有了任务流程图之后，就可以开始产品体验设计，将任务点一个个拆分为功能模块，然后根据功能模块直接的逻辑顺序，组合成交互设计稿，也就是我们熟知的原型设计。

原型设计图：原型设计阶段，主要工作内容为业务流程图设计、逻辑结构图、功能结构图设计、界面低保真原型设计，确认产品的界面布局、用户用例、交互设计，同时交付需求规格说明书。

事：行为管理（操作路径、行为数据）

当我们明确了不同用户不同权限，不同权限做可操作不同功能之后，就需要进一步回答如下的问题：你要用户干什么？告知用户某个信息后需要用户确认知晓，还是希望用户通过你的信息传递完成一个具体的动作执行？

回答以上问题的过程就是完成行为管理，设计用户操作路径的过程。这一过程中就可以采集到用户的行为数据，通过行为数据我们可以分析用户真实的操作场景，并挖掘到业务流程及任务流程中尚未找到的需求点，从而进一步的完善我们的管理系统。

如图所示：管理后台一般包括三大部分，顶导航、左导航、内容区域。左侧导航，通常结构为1-2级，尽量不超过3级，子层级可通过下拉菜单方式展开。

一个产品的产生到用户使用，类似我们做一道美味佳肴给客户。后厨如同管理后台，是一个产品最核心的业务及流程的承载，呈现给客户的菜品如同前端产品的展示，最终经由后厨的精心制作达到色香味具全。

因此，当我们设计管理后台的时候，业务明晰、逻辑明确是首要任务。管理后台一般相对复杂，很多业务流程都是多线程穿插，而不是单线程的。

设计师设计管理后台时，对功能模块的划分和页面的逻辑设计要求都非常高，一定不可以仅仅是简单的模块叠加。