后台业务系统设计流程的6个步骤

6 评论 26990 浏览 167 收藏 8 分钟

最近在设计后台业务系统,从需求分析到原型设计,重走了一遍从0-1的过程,整理了一套设计流程,其中有思考也有总结。

后台业务系统设计流程

  1. 用户-角色划分;
  2. 需求-功能规划;
  3. 业务流程梳理;
  4. 信息架构搭建;
  5. 交互自查;
  6. 界面原型设计。

1. 用户-角色划分

后台业务系统与一般2C前端产品有所不同,2C的前端产品目标用户只有一类角色,即通过使用产品完成某一特定需求的用户。后台业务系统往往涉及较为复杂的业务流程,在业务流程的不同环节还涉及到不同角色之间的交互行为。

所以在做后台业务系统设计之前,首先要明确系统的用户角色,即有几类用户使用你的产品。

2. 需求-功能规划

2.1 需求

对于后台业务系统而言,不同的业务场景下会有不同的业务需求,所以获取需求最直接也是最有效的方式就是通过用户访谈。

根据用户角色的划分,根据不同角色用户,对每一类角色用户进行访谈,访谈的几个维度:

  • 用户当前的工作的内容是什么,业务流程是什么?
  • 用户通过系统实现什么样的目标,如果当前有系统,那么当前系统的问题是什么?
  • 用户期望的工作状态是什么,期望实现什么样的工作目标?

其实在用户访谈中或者在需求分析时,经常会被提一种要求就是:我希望加一个XX功能,我认为流程应该是XX的。

无论是业务部门也好,用户也好,都会向产品经理提这样的难题。每当遇到这种情况,就需要坚定自己的立场。

用户提的要求是从单个用户的视角提出的需求,这个需求是个体类需求还是群体类需求?用户提的是高频需求还是低频需求?等等这些问题都是需要从产品的视角,从整个流程的视角去分析,而不是单纯的默默接受用户的要求。

2.2 功能

通过用户访谈等各种方式获取了需求后,就需要对需求进行拆解分析,并形成不同的功能规划。

上面提到了,在获取需求阶段,可能会从用户那里获得很多“伪需求”或者说是“非最优解决方案”。那么在需求分析阶段,就需要去辨别,哪些需求是真的要去帮助用户实现的?哪些需求是个别用户的需求,在当前资源配置阶段不宜去满足的?

在需求分析时,也有几个维度可以用来分析需求要不要满足:

  • 需求是个体的还是群体的?如果需求仅仅是为了满足某一个人的需要,那么可以考虑延后或者不做,当然,如果是大领导另当别论。
  • 需求是刚需还是锦上添花?如果需求不被满足,会不会影响正常业务流程的运转?如果会影响那么就是刚需;如果需求仅仅是为了系统更高效更便捷,可以根据当前资源配置、时间等因素考虑通过版本迭代的方式进行规划。

当你分析需求的过程中如果无法决断,那么就回归到业务本质,回归的用户本身,将自己置身于用户角色当中去思考,相信你就可以得到正确的答案。

3. 业务流程梳理

3.1 核心业务流程

核心业务流程指完整的业务流程,其中涉及了多角色之间的交互行为,通过对不同角色用户访谈以及对业务的了解,借助于泳道图(跨角色流程图)梳理核心业务流程,明确不同环节节点不同角色用户的操作及需要完成的任务。

3.2 用户流

用户流针对某一个角色而言,该角色通过系统所完成既定任务的业务流程,梳理不同角色的业务流程,为下面的信息架构搭建提供决策。用户流的梳理方式可以是传统的流程图,也可以使用页面流程图的形式,展现更为清晰。

4. 信息架构搭建

信息架构,简单来说就是对产品功能的分门别类,比较常用的方法是卡片分组,将所有的功能写在卡片上,然后由用户将卡片进行分组,再由产品经理根据用户分组结果进行一定调整,最终形成信息架构。

另外一种方式就是基于用户流进行信息架构搭建,在梳理用户流的过程中,可以根据业务流程节点梳理出所有用户可能用到的功能,然后根据功能点之间的逻辑关系,确定功能之间的分门别类。

5. 交互自查

后台业务系统的特点是业务逻辑复杂,涉及不同用户角色之间交互行为,所以在进行设计的过程中难免会遇到想不到处理不到位的情况出现。

关于交互自查的细节,网上有很多更为详尽的资料,这里仅列出较为重要的两个维度:

  • 流程:在梳理业务流程时,无论是核心业务流程还是用户角色流程,需要注重异常流程的处理,尽可能想到所有的异常流程,当用户操作出现问题时,系统可以给予相应的反馈。
  • 状态:组件、按钮,涉及到用户交互以及不同角色之间交互时,都会出现状态的改变,在进行功能及界面设计时,需要明确可能得所有状态,然后明确不同状态之间的切换逻辑。

6. 界面原型

经过上面用户角色划分、需求-功能规划、业务流程梳理、信息架构搭建以及交互自查,基本上对产品的原型已经有了一个大致的想法,接下来就是通过原型工具把想法转换成可以落地的原型。

原型的目标是把规划的功能、流程展现出来,方便与研发团队沟通,可以将产品落地,将需求转化为可以给用户使用的产品。

#专栏作家#

记小忆,人人都是产品经理专栏作者,野蛮生长的产品经理,擅长从0-1搭建产品经理知识体系。公众号:PM龙门阵。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我觉得把,做业务系统的关键是梳理清楚业务场景,首先抓核心场景,与需求方协作输出业务流程图,流程图里自然包括了业务角色、业务活动、业务实体、业务规则,然后再补充对各种分支场景的考虑,产品再提取需求,整合为功能架构

    来自广东 回复
  2. 信息架构、功能架构是不是写反了?

    回复
  3. 恰好我就是做业务系统的

    来自北京 回复
  4. 言简意赅,都是干货,收藏了

    来自北京 回复
  5. 虽然没有深挖,不过总结的挺好的

    回复
  6. 概括得挺好,可是没细节,涉及具体问题还是要细化分析的

    回复