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