昨天审核设计稿的时候，发现投诉详情页的处理轨迹存在问题。这个界面的场景和流程是这样的：客户在小程序发起投诉，售后人员沟通并记录在后台，后台再返回数据至小程序，让客户看到投诉结果。
你可以代入客户角色来理解一下：你收到了商品，使用后没有达到你预期的效果，现在要投诉。公司派了售后跟你联系，先跟你沟通退 30%的钱，你不太满意这个结果；于是进行第二次沟通，说给你退 50%的钱，你觉得可以，完结了这一次的投诉流程。
这个过程，肯定只有一个人跟你联系，不管是不是同一名售后客服。不会存在 A 跟你说退 30%，B 跟你说退 50%，让你选一个方案的情况。因此，在你同意售后方案之前，你也不知道下一步是什么，都是沟通后才会得出结果。
基于这个场景下，你看看下面这个界面，场景和界面是不匹配的：
界面做出来和场景不匹配，可能是在某个环节发生了误解。于是我跟设计沟通，看看她是怎么理解原型做出来。下面是她的理解：
她认为这是一件事的三个固定步骤。第一个步骤已经处理完了，第二个步骤正在处理，第三个步骤待处理。
回想一下刚才说的用户场景：“在你同意售后方案之前，你也不知道下一步是什么，都是沟通后才会得出结果”。又怎么会存在固定的三个步骤呢？又怎么会知道下一步待处理的是什么呢？她问我，我们的分歧是不是左边的状态跟右边的文案顺序反了，产品经理是不是需要改文案。
我察觉到设计师可能还是没理解用户场景，导致我们不在一个维度讨论。她也没有把小程序和后台的操作对应起来，没考虑到后台进行了什么操作才会产生这样的前端页面。于是我把小程序对应起后台，结合场景带她走一遍流程，让她知道产品原型为什么会这么体现：
在售后客服处理投诉的时候，会存在今天跟客户沟通，但客户不满意方案的情况。这种情况下，客服会选择「处理中」这个状态，下一次再接着跟进沟通。
产品经理将后台的「处理中」和「已处理」的数据，全部反馈回小程序。要注意，会有多条「处理中」的数据。即可能会出现以下的轨迹：
如果你是用户，看到下面这个界面会不会懵掉：我的投诉到底多少个人在处理？为什么又有已处理，又有处理中，又有待处理？现在到底是处理完了没有？
产品经理在规划小程序和后台的原型时，是从 B 端考虑数据回显到小程序，但是没有从 C 端用户的角度去考虑——他们在这个页面需要获得什么讯息。
客户发起投诉，最关注的就是处理结果和处理进度。整个事件的结果，应该有且仅有一个状态，即「待处理、处理中、已处理」三者之一。我们只需要让客户看到一个状态。至于处理的轨迹，只需要按照时间倒序排列即可。
跟产品经理沟通后，她表示我们这样改是对的，同时建议我们可以不用图标来表示进度的状态，因为每个状态都是售后在后台实际操作之后生成的数据，不存在等待下一步。下面是正确的界面：
做完需求后，我们跳出彼此的角色去复盘。在设计层面，设计师应该立足场景，结合小程序与后台，将数据一一对应起来，做之前先思考这么体现是不是正确的；在产品层面，产品经理应该分清小程序与后台的两个不同用户群体在界面中应该获得什么信息。张圣焕教授说过：脉络和洞察在先，设计在后。产品设计是为人而生，为解决问题而生的。思维与分析很重要，排版和视觉只是结果。
整个过程，我们从设计层面出发，看到设计表达与场景的不匹配，沿着思路比对原型，从原型中理解产品经理的思路，再结合场景调整做法，与产品经理商量哪种方式更合适，最终解决了这个问题，这是一次有效的产品设计沟通。
本文中原型与界面已脱敏，已经过产品经理与设计师的同意，将本次沟通过程发表成文章。
欢迎关注作者微信公众号：「牙线y2x」
