frontend-logic-design

name: frontend-logic-design description: "Use when 1flowbase frontend/UI structure feels illogical, unintuitive, inconsistent, hard to navigate, or has unclear information hierarchy, entry points, drill-down paths, or same-object behavior."

前端逻辑化设计（Frontend Logic Design）

Overview

当前端界面让用户感到"不对劲"时，问题往往不在视觉层，而在信息架构层——信息的分类、层级、下钻路径和交互行为不符合用户的心智模型。

本 Skill 提供一套系统性的诊断和修正流程，基于三大核心理论：

• MECE 原则（互斥且穷尽）— 保证信息分类不重不漏
• 渐进式披露（Progressive Disclosure）— 保证信息按深度递进展示
• 施耐德曼法则（Shneiderman's Mantra）— 概览优先，缩放筛选，按需详情

触发场景

当用户提出以下类型的问题时，必须使用本 Skill：

• "这个页面感觉没有逻辑"
• "为什么有的能点有的不能点"
• "交互不一致"
• "不知道该去哪里找信息"
• "这个功能放在这里合理吗"
• "信息层级混乱"
• "导航结构不清晰"
• "用户会困惑"
• 任何涉及信息架构、导航设计、页面层级的设计讨论

The Iron Law

不要在 UI 容器维度做 MECE，要在信息深度维度做 MECE。
容器（侧栏/页面/弹窗/对话）是实现手段，不是分类维度。

诊断流程

Phase 1：识别问题类型

首先判断问题属于哪一类（可多选）：

Phase 2：信息深度审计

用四层信息深度模型审计当前页面的每一个元素：

L0 概览（Overview）
  用户问题："什么情况？"
  容器：卡片 / 列表摘要 / 统计数字
  规则：直接可见，无需交互
  允许的操作：一键确定性操作（审批、标记已读等）

L1 聚焦（Focus）
  用户问题："这条具体是什么？"
  容器：侧栏抽屉（Drawer）/ 展开面板
  规则：点击任意条目触发
  关键：同一页面内，所有可点击条目的行为必须一致

L2 管理（Manage）
  用户问题："让我找/改某个东西"
  容器：独立页面（Full Page）
  规则：通过"查看全部"入口进入
  特征：全量数据 + 搜索 + 筛选 + 批量操作 + CRUD

L3 执行（Execute）
  用户问题："帮我做这件事"
  容器：对话页面 / 向导流程 / 专用操作页
  规则：通过明确的行动按钮触发
  特征：需要多步骤或AI介入的复杂操作

审计方法：列出页面上的每一个交互元素，标注它属于哪个深度层。如果发现：

• 同层元素行为不一致 → 深度不一致问题
• 某层完全缺失 → 入口缺失问题
• 元素放错层 → 层级错位问题

Phase 3：MECE 检查

对页面的信息分类进行 MECE 检验：

互斥性检查（ME）

对于页面上的每一个数据项：
  它只属于一个分类/一个卡片/一个Tab吗？
  如果同一数据出现在多处：
    - 是否因为呈现角度不同？（允许：D01待办 和 D10今日 可以有重叠）
    - 还是因为分类维度混乱？（不允许：同一操作在两个地方都能做）

穷尽性检查（CE）

列出用户对该模块的所有可能意图：
  - 能否在当前设计中找到每个意图的入口？
  - 是否存在"用户想做某事但不知道去哪"的情况？
  - 是否存在只能通过URL直接访问的"孤岛页面"？

Phase 4：一致性矩阵

构建交互一致性矩阵，确保同类元素行为统一：

| 组件/卡片 | 条目可点击?(L1) | 查看全部?(L2) | AI执行?(L3) | L0内操作 |
|----------|---------------|-------------|------------|---------|
| 卡片A    | ?             | ?           | ?          | ?       |
| 卡片B    | ?             | ?           | ?          | ?       |
| ...      |               |             |            |         |

规则：

• 所有列表型组件的"条目可点击"列必须全部为 ✅（或全部为 ❌）
• 同列的交互触发方式必须一致（比如都是弹出侧栏，不能有的弹侧栏有的跳页面）

Phase 5：生成修正方案

基于诊断结果，生成修正方案。方案必须遵循：

1. 统一下钻规则：定义清晰的 L0→L1→L2→L3 路径，所有同类组件遵循
2. 入口暗示原则：每个被隐藏的深层功能，在上层必须有可见的入口暗示其存在
3. 容器选择决策树：

需要保持当前上下文？
  ├─ 是 → 用户需要对比/参考背景数据？
  │    ├─ 是 → Drawer（侧栏抽屉）
  │    └─ 否 → Modal（弹窗）— 仅用于简单确认
  └─ 否 → 操作复杂度？
       ├─ 高（多步骤/全量数据/批量操作）→ Page（独立页面）
       └─ 低（单步操作）→ 就地完成（inline）

输出格式

诊断完成后，输出以下结构化报告：

## 信息架构诊断报告

### 问题清单
| # | 问题类型 | 位置 | 描述 | 严重度 |
|---|---------|------|------|--------|

### 一致性矩阵（当前状态）
| 组件 | L0 | L1 | L2 | L3 |

### 修正方案
| # | 改动 | 深度层 | 涉及文件 | 说明 |

### 一致性矩阵（修正后）
| 组件 | L0 | L1 | L2 | L3 |

理论参考

详见 references/ 目录下的理论文档：

• mece-in-frontend.md — MECE 原则在前端设计中的应用
• progressive-disclosure.md — 渐进式披露的设计模式和反模式
• container-decision-tree.md — Modal vs Drawer vs Page 决策树

示例提示词

用户可能这样描述问题，你应该立即启动诊断流程：

"我们看板上有的卡片能点进去看详情，有的不能，感觉逻辑不一致"
→ 诊断方向：深度不一致（Phase 1 → Phase 4 一致性矩阵）

"这个功能放在看板上有意义吗？用户根本不会在这里添加任务"
→ 诊断方向：层级错位（Phase 2 信息深度审计）

"用户说找不到某个功能，但那个页面明明存在"
→ 诊断方向：入口缺失（Phase 3 穷尽性检查）

"我们有侧栏、有独立页面、有弹窗，感觉分类很乱"
→ 诊断方向：在容器维度做了 MECE（Iron Law 违反）

"帮我审查这个新模块的信息架构是否合理"
→ 完整走一遍 Phase 1-5

Anti-Patterns

1. 在容器维度做 MECE

❌ 错误：侧栏放详情、页面放管理、对话放执行 → "三者互斥"
✅ 正确：L0概览 → L1聚焦 → L2管理 → L3执行 → 信息深度互斥，容器只是实现手段

2. 每个组件自己决定交互行为

❌ 错误：卡片A点击弹侧栏，卡片B点击跳页面，卡片C不可点击
✅ 正确：所有列表型卡片的条目点击行为一致（统一弹侧栏或统一跳页面）

3. 概览层塞入重操作

❌ 错误：在看板卡片里放"快速添加任务"输入框
✅ 正确：概览层只展示信息 + 一键确定性操作，创建操作放到 L2 或 L3

4. 隐藏功能无入口暗示

❌ 错误：存在 /tasks 页面但看板上没有任何链接指向它
✅ 正确：每个列表型卡片底部有"查看全部 →"链接

5. 深层信息越级展示

❌ 错误：在概览卡片里展示任务的完整描述、所有评论、历史记录
✅ 正确：概览只展示标题+状态+一句话摘要，详情在 L1 侧栏中展示