[🛠] Operations Automation #5: 把失败的原型变成UI审计标准
✨ GPT-5.6 Sol 的总结
记录我如何不再逐页修补充斥大块留白的卡片和失效的table，而是把搜索、filter、多行行结构、当前view下载与编辑风险分类写成共用UI审计标准。
大卡片和宽松留白毁掉了页面
我当时正在重新设计一套供50岁以上职员与管理员使用的休假管理页面。要求是大字号、大操作区域和充足留白。但原型用最简单、也最糟糕的方式理解了这些要求。
本来一行就能放下的数值，被拆成项目名 → 大数字 → 补充说明三行，再塞进巨大的card。三张card吃掉了整个首屏，用户真正需要立即处理的工作反而被推到下面。申请页面把calendar、摘要和输入分别堆成巨大的白色方框；记录table里关键值是空的，只剩状态badge。甚至还出现了横向scroll。
以前，我在真实mobile设备上修复被挤坏的table与filter时，以为消除overflow和异常换行就能改善页面。这次原型暴露了更根本的问题：不破版的页面和真正能用的页面完全不是一回事。
UI审计标准比页面更早失效
更严重的问题是，这样的页面居然通过了单独的审计流程。
审计会检查route能否打开、文字是否被截断、control能否点击、颜色与间距有没有严重错位，却没有强制回答以下问题。
- 用户能否在首屏找到现在需要处理的工作
- 同一判断所需的值是否集中在一个视野内
- 空白是在解释信息关系，还是仅仅填满component尺寸
- table的搜索、filter、排序、总数与结果是否连成一个流程
- 当前查询结果能否原样下载并再次使用
- 可修改的值与不得覆盖的历史记录是否区分清楚
审计项里没有的问题，即使Agent看见了也可能照样判定通过。因此，我没有继续逐页缩小padding，而是先修改共用审计标准，让这种失败无法再次通过。
Collection把搜索、结果与下载合为一体
我研究得最多的参考页面，是另一款休假管理app的申请管理table。其官方帮助也把Web管理员mode下的日期查询、申请filter、批准与拒绝作为同一项工作来说明。1 参考画面里最醒目的不是功能数量，而是功能之间的距离。
期间和申请类型就在结果正上方。搜索框与各列对应，总申请数与download也处于同一视野。某项申请的日期、变更前后与工时差等需要一起阅读的值，并没有不断增加列，而是放在同一个cell内分多行呈现。状态与可执行action也延续在同一行。
我没有只把这种结构复制到某一个休假页面，而是将其推广为collection的共用contract。
- table、grid、高密度list与calendar的list view，都把search/filter block放在结果正上方。
- 期间与scope、搜索、快速filter、详细filter、适用条件、总数/当前数量、重置、download处于同一视野。
- 用于同一判断的值按
主要信息 → 辅助信息 → 条件警告放进多行cell。 - 行高由内容决定。不能因为使用多行，就制造固定高度的mini card。
- download导出符合当前条件的全部结果，而不是当前page里可见的几行。
- export保留当前scope、期间、搜索、filter、排序、基准时间与用户可见的业务列。
- 个人信息与审计资料也不应彻底取消download，而要应用相同的权限、masking与audit。
只检查“有download按钮”仍然会再次失败。还必须核对导出文件与实际页面的数量、代表性行、已应用filter、排序和masking是否一致。
编辑方式按数据风险划分
直接在table里改值很方便。但如果所有cell都做成Excel，批准记录、台账和法律证据也会变成可随意覆盖的普通输入框。
因此，我先区分变更性质，再决定编辑control。
| 变更性质 | 默认interaction |
|---|---|
| 可撤销的单一低风险值 | 带可见编辑affordance的inline edit |
| 多行安全重复修改 | 明确的editable-grid mode |
| 需要同时查看上下文的多个field | 保留list位置的side panel |
| 简短、独立的输入或确认 | 单一目的的modal |
| 高风险、生效日、权限、version、append-only变更 | 独立的preview-and-apply或correction workflow |
double-click、Enter与F2只作为熟练用户的加速方式，不能把编辑入口只藏在这些操作里。grid需要keyboard移动、变更cell提示、validation、undo、全部取消、stale冲突、应用前preview与应用后readback。批准、拒绝和append-only台账事件不属于cell edit对象。
分离共用审计规则与产品contract
如果把从参考页面学到的内容全部写成Leave Operations专用规则，下一个project还会犯同样的错误。反过来，如果连休假审批阶段、促进文档、台账修正等业务规则也放进共用Skill，共用标准就会变成某个产品的设计书。
所以我划开了边界。
共用规则与UI审计Skill收纳以下失败类型。
- 把短scalar做成巨大的独立card
- 机械地把label、值、分母拆成三行
- 搜索与filter远离结果
- collection没有总数、重置与当前view download
- table把相关值铺成过多列，或把多行内容固定为统一高度
- export的权限或当前view条件与页面不一致
- 编辑只隐藏在hover或double-click中
- 通过普通cell或popup覆盖高风险、versioned、append-only数据
Leave Operations文档则另外说明这些原则应应用到哪个page的哪个view。审批箱、职员、促进、台账、考勤冲突、短信结果与业务手机等table分别设定搜索、filter、排序、download contract，并区分职员、所属等需要重复修改的区域，以及审批、台账等不得直接修改的区域。
页面还没有修好
这次工作并没有让实际产品UI变好。我修改了共用规则、UI专用审计Skill与各产品页面contract，并连同原始hash保存了参考图片。Leave Operations的desktop页面还没有按照这些contract实现，也没有让50岁以上职员与管理员从正常入口亲自完成工作的验证。
即便如此，下一个原型至少不应因为同样的原因再次通过。大字号与足够大的操作区域仍然要保留，但不能成为让页面臃肿的借口。目标不是低信息密度，而是高信息密度与低认知负担。
留下评论