返回博客

按钮做完了，运营却翻了 18 页——列表操作功能的 UX 盲区

在某后台管理系统做了一次「按状态显示操作按钮」的需求：给员工列表加一列状态展示 + 一个条件按钮，条件 v-if="row.oauth_done && !row.contact_way_qr_code"，只对满足条件的行才显示「生成」按钮。

代码走完测试，自测也通过了。结果验收时运营第一句话就是：

"你的筛选列表没有给我加状态筛选，我现在没办法去找到哪些用户。"

现象

功能逻辑上完全正确：状态展示、按钮条件、接口联动，一行不漏。但运营实际操作时发现——表格总共有 174 条数据，而真正需要操作的只有 3 条。没有筛选器，她只能一页一页翻（每页 10 行），翻完 18 页才能把这 3 个目标全找出来。

如果操作失败要重试，再翻 18 页。

根因

这个功能被拆成了两个互相独立的工程任务：

  • 「加状态展示列」
  • 「加条件操作按钮」

两个任务都交付了，却漏掉了第三块：目标定位。

UX 拼图：

| 模块 | 状态 | |------|------| | 状态展示 | 完成 | | 操作按钮（条件显示）| 完成 | | 筛选器（找到目标行） | 缺失 |

少了第三块，前两块等于给了一把钥匙，但房子藏在迷宫里——操作成本不是「点一下按钮」，而是「翻 N 页找到目标行，再点一下按钮」。

反直觉的地方在于：K 越小，找目标的成本占比越高。3 条数据分散在 174 行里，恰好是最难找的场景。很多人的第一反应是「数据量小，不用加筛选」——这个直觉完全反了。

坑：K/N 越小，筛选越不能省

当总数据 N 很大、需要操作的子集 K 很小（K/N < 5%）时，筛选器不是「锦上添花」而是「功能完整性前置条件」。没有筛选，操作按钮对运营来说就是摆设——她得先翻完整张表才能点到按钮。

常见错误心智：「只有 3 条数据，加筛选小题大做」——实际上正是因为只有 3 条，肉眼扫描成本才最高（3/174 = 1.7%，几乎不可见）。

正解

接到「对 X 状态的记录做 Y 操作」类需求，开始写代码前先回答 4 个问题：

  1. 总记录数 N 和目标子集 K 各是多少？K/N < 5% 则筛选器是必须项
  2. 现有筛选区能否复用已有字段？没有才新增
  3. 新筛选项是否需要后端新增 query 参数？前后端契约确认好
  4. 默认排序是否能让目标集中到前几页？（即便能，也只是减轻，不能替代筛选）

前端：在筛选区追加一个 el-select：

<el-select v-model="filterQrStatus" placeholder="状态筛选" clearable @change="onFilterChange">
  <el-option label="已生成" value="generated" />
  <el-option label="未生成" value="pending" />
</el-select>

后端（PHP 示例，用 whereRaw 精确匹配 NULL 和空字符串两种情形）：

if ($qrStatus === 'generated') {
    $q->whereRaw("(`target_col` IS NOT NULL AND `target_col` != '')");
}
if ($qrStatus === 'pending') {
    $q->whereRaw("(`target_col` IS NULL OR `target_col` = '')");
}

如果后端用闭包复用同一个 $buildWhere 给 count 和 select 两个查询，加一次分支即可自动同步。如果是 dual-query 分别写的，两处都要加，不能漏。

正解：先问「运营怎么找到目标行」，再写按钮逻辑

每次写「按条件显示操作按钮」之前，先回答一个问题：在分页列表里，运营如何在不翻页的情况下找到所有需要操作的行？如果答不上来，就先加筛选器，再写按钮。

一句话外卖

按钮做完不等于功能做完——「状态展示」+「操作按钮」+「目标定位筛选」缺一块都是半成品，而 K/N 越小、缺筛选的代价越大。