后台系统设计

用户调研

调研过程中问题举例

1. 过去是怎么处理这项业务的？
2. 哪一个环节给你带来困扰或者说需要花费你大量的时间去完成？
3. 最希望实现或改进的功能是什么？
4. 谁可以操作这项业务？（权限控制）
5. 操作的范围又是哪些？
6. 是否需要对用户的操作行为进行记录？

设计要素

1. 角色、
2. 角色的权限（包括功能权限和数据权限）、
3. 业务流程、
4. 所需字段、
5. 操作日志等。

善用表格、图文并茂

1. 后台中的功能结构、角色权限的分配等结构性内容采用表格的形式；
2. 数据流向、业务流程用流程图、泳道图等描述清楚；

3. 功能用原型图呈现，原型图中的信息进行归类，不能因为是后台，无需考虑太好的用户体验而忽视了页面的清晰整洁度。

   
   
   

   image.png

描述方法

一般后台功能可分为列表数据、功能操作（增删改查等）两大块。可以从以下方式进行描述：

（1）列表数据

字段：字段名称、字段类型、字段描述、数据来源、字段规则等；列表：呈现字段、排序规则、分页规则、状态等。

（2）功能操作

方法一：事件流程法

比较复杂的后台功能在同一个功能点中可能包含多个事件，所以复杂后台功能可按照：基本事件流程、子事件流程与特别需求来描述。

image.png

方法二：条件描述法

这个方法适用于查询功能，直接对需要查询的条件、规则进行描述。

image.png

方法三：输入输出法

输入处理输出大部分是由开发来考虑的，但产品经理如果能站在开发的角度，明确输入、处理、输出的内容，那会省去很多开发的理解成本。

image.png

image.png

方法四：简要测试用例

测试用例可直接用来表述简单、常见的功能，直击功能的目的。前提是这类功能一定是比较常见的，不需要过多的深入描述，开发也能懂。

image.png

一些小TIPS：

需不需要描述很细节的东西？这个问题要取决于整个开发团队的默契度，以及在开发之前是否已经形成了标准的规范，如果是，那么产品经理可以适当减少一些细节描述，简要概括，将重点放在业务的流程和逻辑上。大部分情况下，前台需求决定后台需求，后台产品经理设计前一定要与前台产品经理进行深入沟通，不管是对目前有的功能还是未来的前台需求规划，后台产品经理都要了解，提前做好规划，眼光放长远，思考功能的可持续性。有些团队的后台文档可能会由若干个产品经理共同完成，建议对每个模块的作者做好标注，方便开发找到负责人沟通。同时，做好各大模块的标题和大纲，供开发查找。一份需求文档一定会修改好几个版本，一般采用R（Requirement）0、R2.0……来表示版本号。