鉴于之前有负责过几次ToB的后台工作，最近的一个项目正巧也是一个客服工单系统的项目，所以本次的复盘想针对后台管理管理系统做一点分享。一共包含如下几个点：

1、在对接需求时，你需要注意哪些方面。

2、在设计后台管理系统时，我们需要具备的最基本的设计思考框架应是什么？

3、如何将业务进行解构后再重新将其纳入你的设计中。

4、上线后，我们如何对其进行体验提升。

本期我要和大家分享的是，我们应该如何与需求方进行一次（可能不止一次）的友好交流（微笑式撕逼）---对接需求时，你需要注意哪些方面～😊

 我的工作背景是这样的，我接到这个后台需求的时候，其实已经有一个交互设计师和产品沟通过一次了，所以相当于我是半路上车的人。我这里是和这位交互设计师进行的需求沟通--结果可想而知，职业通病：处于对需求的理解，我的小伙伴已经有了初步的框架，所以在第一期的需求中，沟通出现了大量的反复讨论。所以在第二期的时候，我提出了我要自己去和产品面对面的需求。第二期的需求还没有进行评审。所以我开始了我的参与需求的道路。

在需求的介入过程中，我是这样做的。

一、与需求方至少有一次的深入交流、需求立项尽量在场。

1、及时提问与质疑

大家都知道电的传播是有损耗的；同样，信息的穿搭也是具备损耗属性的，所以我希望我自己能有一次真正和需求方面对面的机会；因此我在需求评审会之前找到了需求方，和他们进行了一次交流。抛去无效的交流外，我的整个核心语言框架是这样的，希望可以和大家进行分享：

这样聊下来，你就会知道目前的产品正处于什么样的阶段，需要对这个产品做哪些改造；当然这其中肯定存在一定数量的个人观点，所以在会上，我会提出自己的疑问。

比如之前会上有个比较令我困惑的点就是，系统本身已经存在了一个新建的入口，且是非常易于操作的，但是需求还是希望在其他不同功能模块中也要有这样的功能入口，重点是每一个都要，这其实对设计与技术来说没有什么难度，但是在整个系统的逻辑中，这样做是不合适的，因为我们还是要分权限角色，且有的功能模块只是一个数据浏览的页面，没有操作区域，只是因为一个添加操作，就破坏整个系统的一个业务逻辑，是不合适的。所以我在会上就问了一下这个问题。

2、模拟场景

在需求立项会上，当产品与需求方在阐述自己的需求的时候，我自己也会在心里根据需求的描述模拟一份草稿，这样的好处是不容易开小差以及去筛选需求，你也可以对整个产品的框架有一定的了解。当遇到逻辑颗粒的时候，你要及时提出自己的疑问，你可以用疑问的句式来重复需求方的话，目的是让需求方再一次复盘自己的需求是否合理。

3、敲定排期以及本时间段内

因为后台管理系统具有业务复杂的属性，所以在交互设计的工作中，也存在着大量的工作量，出了各个模块之间的业务配合以外，你还有注意页面本身的交互逻辑。

所以一定要将系统功能的优先级给排出来，你可以找产品一起做这件事情，先将功能框架排好，再将功能分到所属的对应关系中，先让优先级高的功能投入开发，次级的功能紧随其后。

二、在设计后台管理系统时，我们需要具备的最基本的设计思考框架应是什么？

在思考之前我们可以先想想在设计B端产品的时候，要考虑与C端的不同：1、交互设计师并非被动的接受某个单点需求，也没有既定的模式去执行。

2、要以全局的思维去设计，去规划更好的方案。

这之后，我们要从需求的角度来统筹考虑，思考各个模块的关系，是否存在相互支撑，相互限制的原则。只有这样，我们在后期的交互稿件中，才不会顾此失彼，在评审的时候无法回答各方的质疑。

每个功能中有不同的模块，一个功能组可能不需要多个模块的支持，所以，在设计的过程中要全盘考虑功能与功能之间的配合关系。

3、交互文档的布局。

交互文档在输出的阶段中最好以系统的框架为搭建原则，这样的话，有助于在渐渐累加的交互结构中，可以清晰的区别和厘清功能与功能之间的关系，也方便其他人员在后期的使用中，可以清晰的理解的你的交互方案，减少多余的沟通成本。

4、后期的宣讲。

宣讲的过程中，首先要将本次项目的背景交代清楚，目标是什么，解决的问题是什么，以积极的态度去面对各方的质疑，因为你要明白的是，大家的目的是为了产品更好的体验，所以千万不能有负面情绪，这也是评审过程中非常重要的一个环节。其他关于项目本身的问题，那就是你对需求的理解，以及你和产品经理沟通的深入程度来，就像我第一部分写的那样。

好了，这一次的分享就现到此为止，有想交流的可以互相交流。

下一次分享的2个主题是：

3、如何将业务进行解构后再重新将其纳入你的设计中。

4、上线后，我们如何对其进行体验提升。