B端常见误区：[ 筛选 ] 混淆 [ 详情 ]

某个系统中，存在员工与客户两种实体，它们在界面上表现为两个不相关的列表。

当员工与客户产生关系，比如某个员工关联多个客户，每个客户只能对应一个员工，此时形成两个相关的列表。

员工列表统计每个员工的客户数量，可以进行区间筛选；客户列表增加对应员工，并且可通过单选某个员工对客户进行筛选。

某位设计师灵感闪现，将员工列表中的客户数量直接链接到客户列表中对应的筛选结果，称之为原始方案。例如，在员工列表中点击 客服C 的客户数量4，此时进入客户列表，并且对应员工的筛选自动选中 客服C。

并且，原始方案看起来非常具备优势：复用了客户列表的筛选，无须新增界面；直接下拉切换查看其他员工的相关客户，方便直观。

然而，原始方案忽略了三个问题。

问题一：站在任务角度，单选员工的冗余

如图，员工列表完成了单选员工的任务，客户列表中的对应员工的筛选，完成了相同的任务。当然，很多设计师觉得这样也没所谓~~试想，员工是一个不断自增的ID，难道不应该设计为搜索？

问题二：站在记录集角度，无效的数据列

在员工列表中，如果从 客服C 的客户数量进入，此时对应员工必然是 客服C ，变成了毫无意义的存在。

问题三：扩展性较低，容易引起认知混乱

如果系统中增加渠道，每个员工可以关联多个渠道，每个渠道可以有多个员工负责，每个客户也可以关联多个渠道，客户的对应员工依然保持唯一。

按照原始设计方案，将员工列表中的渠道数量直接链接到渠道列表中对应的筛选结果。站在用户的角度，或许会觉得很奇怪：员工列表显示 客服C 的客户数量是4，但是进入渠道列表之后，客服C 对应的两条渠道的客户数量分别是3和2，是不是很让人凌乱？（实际上是某个客户对应了两个渠道）

综上所述，原始方案并非优雅设计，看起来提供了方便，但已经给产品迭代埋下了雷：当实体增加，关系复杂，就开始混乱了。

稍微改变一下思路，新增全新的界面，专门为了承载每个实例的某种关联记录，好像扩展性就增加了很多。至少避免了重复设计单选员工任务，员工列表搜索员工，某个员工的客户列表搜索Ta的客户，一个界面一个任务。

因为专注单一关系，所以在增加渠道之后，从员工列表查看 客服C 的渠道，依然要避免显示渠道的客户数量，避免产生混乱。

推荐按照“列表-详情”设计优雅方案，员工列表点击姓名进入员工详情，罗列 客服C 的全部关系；员工列表上关于 客服C 的各种数量统计，链接到详情的各个锚点（一种关系一个锚点）；以此类推，客户列表对应客户详情，渠道列表对应渠道详情。

显然，遵循“一个界面一个用户任务”的基本原理，还可以输出更多设计方案。

原始方案的设计思路，把 [ 筛选 ] 和 [ 详情 ] 两件事混淆在一起，陷入了误区，继续深挖：

原因一：

依赖主观场景，无脑追求方便

原因二：按照设计APP的方法理解网页

设计师没有意识到用户可以自主打开多个窗口，同时访问任意列表和任意详情。