B端产品设计|B端产品设计 - 踩过的雷区 B端产品设计-踩过的雷区

在B端产品设计里，如果有类似的功能，沿用已有功能的业务流程和UI界面进行设计，可以让用户在迭代更新的版本中更容易上手。
但这样也容易才中一个雷区：生搬硬套，不符合现实生产规律。
（以下用一些更贴近生活的案例来描述我遇到的这个雷区）

比方说，有三种用户角色：
1. 用户角色：班主任（以下简称A）
2. 用户角色：学生（以下简称B）
3. 用户角色：校长（以下简称C）
已有需求：班主任A需要监督学生B的学习效率。（从A的视觉设计这个功能，即现在需要进行系统的教师端原型设计）
已有功能是：
1. A发现B学习效率差，A填写一份B学习效率不佳的证明材料，要求B在这份材料里面写检讨书（“材料+检讨书”以下简称w）。
2. B写完了邀请A来评判这份w及不及格。
3. 如果及格，这个事件便结束；如果不及格，B需要重新再写检讨书，再来邀请A重新评判。

【B端产品设计|B端产品设计 - 踩过的雷区】于是，便设计了如下原型界面：

文章图片
已有功能界面截图界面解释：（这部分文字有点多，但希望可以把情况描述清楚）

#A发起# A发现B学习效率不佳，点击“新增证明材料”按钮，进入填写证明材料。
- A随后在“待写检讨的w”里面可查看自己发起的w，但是没有填写检讨书的模块。
#B填写# B在系统的学生端页面的“待写检讨的w”窗口里面可以查看需要写检讨的w；
- 然后B在他的客户端里的w填写检讨书内容，写完数据同步到A的教师端；
- 随后B可以在“已写待通过的w”的窗口查看自己写完的检讨书，但没有“通过”按钮。
#A选择通过与否# A在教师端的“已写待通过的w”中查看到B写的检讨，评判后决定通过不通过。
- 如果通过，A、B双方都可以在各自的客户端的“通过已结束”的窗口看到已通过的w；
- 如果不通过，继续要求B进行二次重写w的检讨部分。

在更新迭代过程中，产生了一个新的需求，跟已有需求类似。

类似需求：A、B、C三方都要求不可迟到。迟到了需要进行检讨。
类似功能：
1. 三方都可以检查迟到情况。发现其中一方迟到，填写一份证明材料，要求对方在这份材料里写检讨（“材料+检讨书”以下简称v）。
2. 需检讨方写完了，邀请发起人来评判这份v及不及格。
3. 如果及格，这个事件便结束；如果不及格，需检讨方要重新再写检讨，其后再邀请发起人二次评判。

于是，为了节约用户适应新功能的时间成本，沿用已有功能的界面，设计出如下原型图：

文章图片
类似功能界面截图但是，在进入开发之后，发现了以下的问题：
A发起的v和A接收的v都显示在第一个窗口“待写检讨的v”里面。
如果v的数量比较多，那么在用户A看来会比较乱，而且开发要做多次判断，数据表多增加flag。
类似功能比原有功能的角色增加了，不同权限应该对不同的数据模块进行处理操作，在这样的背景下，沿用原有的业务流程看起来就会有点乱。
于是讨论之后决定，找到另一种更容易理解和开发的方案，如下图，

文章图片
更改过后的原型图分为两个大类：一是“待我处理”，二是“我发起的”。

“待我处理”的里面是装“需要我去通过的”，以及“需要我去写检讨”的v；
“我发起的”里面装的是“我发起”的v，其中包括的状态有：“对方还没有写检讨的v”、“对方写了检讨但我还没通过的v”、“对方写了检讨但我要求对方重写的v”、“对方写了检讨我通过的v”，这些都是同属于“我发起”这一大类的。

这个失误的解决方案不难，改页面也就改几个字。令人有挫败感的是把业务流程背后的逻辑都改了。虽然这两个方案都是可行，但是后一种方案更优。
为什么会出现这样的失误呢？在我看来主要原因是在于，不熟悉业务场景，思考不够全面。任何一款产品都是需要一套无懈可击的业务逻辑层支撑起来的，且B端产品对业务逻辑的思考要求就更高。
因此，产品小白更要积极主动去了解产品功能，从不同的用户角色去体验这个功能能否真正满足用户们的需求。