最近在设计后台业务系统，从需求分析到原型设计，重走了一遍从0-1的过程，整理了一套设计流程，其中有思考也有总结。
后台业务系统设计流程如下：
- 客户-角色划分；
- 需求-功能规划；
- 业务流程梳理；
- 信息架构搭建；
- 交互自查；
- 界面原型设计。
1.客户-角色划分
后台业务系统与一般2C前端产品有所不同，2C的前端产品目标客户只有一类角色，即通过使用产品完成某一特定需求的客户。后台业务系统往往涉及较为复杂的业务流程，在业务流程的不同环节还涉及到不同角色之间的交互行为。
所以在做后台业务系统设计之前，首先要明确系统的客户角色，即有几类客户使用你的产品。
2.需求-功能规划
2.1 需求
对于后台业务系统而言，不同的业务场景下会有不同的业务需求，所以获取需求最直接也是最有效的方式就是通过客户访谈。
根据客户角色的划分，根据不同角色客户，对每一类角色客户进行访谈，访谈的几个维度：
- 客户当前的工作的内容是什么，业务流程是什么？
- 客户通过系统实现什么样的目标，如果当前有系统，那么当前系统的问题是什么？
- 客户期望的工作状态是什么，期望实现什么样的工作目标？
其实在客户访谈中或者在需求分析时，经常会被提一种要求就是：我希望加一个XX功能，我认为流程应该是XX的。
无论是业务部门也好，客户也好，都会向产品经理提这样的难题。每当遇到这种情况，就需要坚定自己的立场。
客户提的要求是从单个客户的视角提出的需求，这个需求是个体类需求还是群体类需求？客户提的是高频需求还是低频需求？等等这些问题都是需要从产品的视角，从整个流程的视角去分析，而不是单纯的默默接受客户的要求。
2.2 功能
通过客户访谈等各种方式获取了需求后，就需要对需求进行拆解分析，并形成不同的功能规划。
上面提到了，在获取需求阶段，可能会从客户那里获得很多“伪需求”或者说是“非最优解决方案”。那么在需求分析阶段，就需要去辨别，哪些需求是真的要去帮助客户实现的？哪些需求是个别客户的需求，在当前资源配置阶段不宜去满足的？
在需求分析时，也有几个维度可以用来分析需求要不要满足：
- 需求是个体的还是群体的？如果需求仅仅是为了满足某一个人的需要，那么可以考虑延后或者不做，当然，如果是大领导另当别论。
- 需求是刚需还是锦上添花？如果需求不被满足，会不会影响正常业务流程的运转？如果会影响那么就是刚需；如果需求仅仅是为了系统更高效更便捷，可以根据当前资源配置、时间等因素考虑通过版本迭代的方式进行规划。
当你分析需求的过程中如果无法决断，那么就回归到业务本质，回归的客户本身，将自己置身于客户角色当中去思考，相信你就可以得到正确的答案。
3.业务流程梳理
3.1 核心业务流程
核心业务流程指完整的业务流程，其中涉及了多角色之间的交互行为，通过对不同角色客户访谈以及对业务的了解，借助于泳道图（跨角色流程图）梳理核心业务流程，明确不同环节节点不同角色客户的操作及需要完成的任务。
3.2 客户流
客户流针对某一个角色而言，该角色通过系统所完成既定任务的业务流程，梳理不同角色的业务流程，为下面的信息架构搭建提供决策。客户流的梳理方式可以是传统的流程图，也可以使用页面流程图的形式，展现更为清晰。
4.信息架构搭建
信息架构，简单来说就是对产品功能的分门别类，比较常用的方法是卡片分组，将所有的功能写在卡片上，然后由客户将卡片进行分组，再由产品经理根据客户分组结果进行一定调整，最终形成信息架构。
另外一种方式就是基于客户流进行信息架构搭建，在梳理客户流的过程中，可以根据业务流程节点梳理出所有客户可能用到的功能，然后根据功能点之间的逻辑关系，确定功能之间的分门别类。
5.交互自查
后台业务系统的特点是业务逻辑复杂，涉及不同客户角色之间交互行为，所以在进行设计的过程中难免会遇到想不到处理不到位的情况出现。
关于交互自查的细节，网上有很多更为详尽的资料，这里仅列出较为重要的两个维度：
流程：在梳理业务流程时，无论是核心业务流程还是客户角色流程，需要注重异常流程的处理，尽可能想到所有的异常流程，当客户操作出现问题时，系统可以给予相应的反馈。
状态：组件、按钮，涉及到客户交互以及不同角色之间交互时，都会出现状态的改变，在进行功能及界面设计时，需要明确可能得所有状态，然后明确不同状态之间的切换逻辑。
6.界面原型
经过上面客户角色划分、需求-功能规划、业务流程梳理、信息架构搭建以及交互自查，基本上对产品的原型已经有了一个大致的想法，接下来就是通过原型工具把想法转换成可以落地的原型。
原型的目标是把规划的功能、流程展现出来，方便与研发团队沟通，可以将产品落地，将需求转化为可以给客户使用的产品。
