Tab选项卡适合把同一对象或同一工作区域的内容分成几组，让用户一次查看其中一组。设计时先确认分组是否互相清楚，再决定标签名称、激活样式和切换规则；筛选条件、滚动位置、未保存内容和加载失败也要一起考虑。仅画出一条高亮下划线，还没有完成标签页设计。
本文以“春季上新”的项目详情为例，组织“概览、任务、文件、活动”四个标签。可以在墨刀设计中把各标签内容并排放到画布，检查它们是不是同一层级，再调整桌面与手机上的呈现。
先判断你需要的是标签页、筛选，还是导航
W3C的Tabs模式把标签页描述为一组内容面板，每次展示其中一个，激活标签与其面板对应。关键是内容关系，而不只是几个文字并排的外观。
| 用户要做什么 | 更合适的组织方式 | 项目示例 |
|---|---|---|
| 查看同一项目的不同信息 | 标签页，切换相邻内容面板 | 概览、任务、文件、活动 |
| 缩小同一批数据的范围 | 筛选条件 | 任务中只看未完成，或只看分配给我的项 |
| 改变同一批数据的展示方式 | 视图切换或分段控件 | 同一任务列表切成列表视图或看板视图 |
| 前往产品的另一主要区域 | 全局导航 | 从项目进入消息或账户设置 |
同一个“全部、进行中、已完成”条带，视觉上可以像Tab，但如果它只是过滤同一张任务表，设计说明应明确它改变的是筛选范围。这样，“负责人=我”是否继续生效、数量如何计算、返回后保留什么，才有一致的解释。
要让用户同时比较“本月”和“上月”两组数据，也未必适合做两个标签：来回切换会增加记忆负担，可能并排比较更直观。按顺序填写“基本资料—确认信息—完成”的流程，则更接近步骤，不应随便改成可以自由跳过的Tab。应用主要区域的安排可另看APP导航设计。
先把四组内容分清，再写四个短标签
“春季上新”是页面始终不变的项目名称。四个Tab管理的是这个项目里的不同内容，顶部项目标题、项目状态和返回入口保持稳定，切换后只有相应内容区变化。
| 标签 | 包含什么 | 不放什么 | 常用动作 |
|---|---|---|---|
| 概览 | 项目说明、负责人、时间安排与关键进度摘要 | 完整任务表、所有附件 | 修改项目说明 |
| 任务 | 待完成工作、负责人和状态 | 仅记录发生时间的操作历史 | 新建任务、筛选任务 |
| 文件 | 项目需要共享的图片和文档 | 任务名称或历史通知正文 | 上传、查找、下载文件 |
| 活动 | 成员做过什么、何时发生的时间线 | 需要用户接手完成的待办列表 | 查看变更经过 |
这里的“活动”指项目动态记录，不是会议日历。若目标用户容易理解错，可以改成“动态”或“操作记录”，再用实际找信息任务验证。不要用“综合”“管理”“更多”一类含义过宽的名字替代尚未想清的分组。
标签之间可以有摘要和跳转。例如概览展示三条近期任务，点击“查看全部任务”进入任务标签；完整任务仍由任务区管理。把同一份完整内容分别塞进多个标签，会让用户不知道哪处才是可靠入口。
每组都要有存在理由。如果“文件”目前只有一份固定说明，放在概览里可能更直接；若文件已经需要搜索、类型筛选和上传操作，独立标签才更有价值。标签数量取决于内容规模、名称长度和比较需求，没有一个适用于所有页面的固定数字。
切换时保留什么，要按状态归属决定
先设定一条具体路径：用户在任务标签选择“仅看未完成”，滚动到“核对商品信息”；随后到文件标签筛选“图片”，查看“主视觉.jpg”；再返回任务。合理的结果是继续看到原来的未完成任务范围和位置，而不是把文件筛选“图片”带进任务区，或重新回到所有任务顶部。
| 信息或状态 | 本例的归属 | 切换后的处理 |
|---|---|---|
| 项目编号、项目名称 | 详情页共享上下文 | 四个标签始终指向同一项目 |
| 仅看未完成、任务滚动位置 | 任务标签自己的浏览状态 | 去文件再回来时保留 |
| 文件类型“图片”、文件滚动位置 | 文件标签自己的浏览状态 | 去任务再回来时保留 |
| 新选中的项目 | 新的详情对象 | 按新项目初始化，不能带入旧项目的编辑草稿 |
| 未保存的项目说明 | 概览中的编辑草稿 | 按明确草稿规则处理，不能静默丢失 |
如果所有标签确实共用一个“时间范围”，应把筛选放在共享位置，并说明它影响哪些内容。不要把看起来位于任务表上方的筛选，悄悄同时作用于文件和活动。保留浏览状态也不等于永久缓存：刷新页面、重新登录或跨设备后是否仍保留，需要另行约定。
有编辑和加载时，标签切换不能只剩一段动画
本例允许在概览编辑项目说明。为了让用户临时查看文件，设计约定在当前项目详情内切换标签时保留未保存草稿，返回概览能继续编辑；界面仍显示“有未保存修改”。保存成功之前，这份文字不能被标为已经更新的项目说明。
离开当前项目时，则需要处理未保存内容：提供继续编辑、放弃修改，或产品确实支持的保存草稿方式。若业务必须要求切换标签前确认，也可以采用离开确认，但要在同类编辑区一致使用。重要的是清楚决定保留范围，不能在设计稿里看似保留、实现时每次切换都把表单重置。
文件标签首次打开需要加载数据时，保持标签栏和项目标题可见，只在文件内容区显示等待反馈。明确激活的是“文件”，不要仍显示“任务”选中却在下面加载文件。文件加载失败时，保留在文件区说明失败并提供重试，别用“暂无文件”的空状态代替错误。
切回已经出现过的内容，可以按产品规则保留旧数据并标明正在刷新，也可以重新加载。用户正在阅读时，不应因后台刷新突然切换标签、清空筛选或跳回顶部。新数据使原来的任务消失时，再解释结果变化，并让用户继续浏览相邻内容。
还要考虑直接打开指定标签，例如同事分享了项目的文件入口。打开后应同时看到“春季上新”和“文件”当前态；刷新、浏览器返回的行为由团队约定。设计师可以标明可分享的目标和预期落点，具体地址与历史记录交给研发实现。
手机上放不下时，不要先缩小文字
先检查标签是不是冗长、内容分组是否可以简化。确实需要保留的标签可以横向滚动，或在合适场景采用竖向排列、独立导航入口；选择哪种方式要看用户是否需要经常在相邻内容间切换。
- 横向滚动要让人看见还有内容。可以露出下一项的一部分或提供可理解的滚动提示。激活的标签要保持可见，不能让用户滚到另一端后找不到当前位置。
- 标签顺序保持稳定。不要因为某项刚被点击就自动挪到最前面，也不要因为暂时没有文件就删除标签、让其他项横向跳动。
- 名称增长时重新看布局。“活动”改为“项目活动记录”之后，检查能否保持清楚。截断到每一项只剩相同的前两个字，会让标签失去区分作用。
- 谨慎采用多行折返。两行标签都靠近同一个内容面板时，选中位置和分组关系可能不清楚。若需要折返，必须让当前项与面板的关系可辨，而不是仅让浏览器自动换行。
文件区改成手机单列，不代表顶部Tab也要重命名或重排。内容布局和导航位置可以分别适配，让用户在两个设备上仍能认出同一组信息。
选中与键盘焦点，可能落在不同标签上
桌面页面不能只考虑鼠标。根据W3C的Tabs模式，键盘用Tab进入标签组时通常落到当前激活标签；在横向标签组里，用左右方向键移动，下一次Tab再离开标签组进入后续内容。标签组内部不应简单设计成每按一次Tab才移动到下一项。
激活方式可以按内容加载情况选择。内容已经准备好、切换没有明显等待时，可以让焦点移动同时激活标签；如果每次切换都要等待加载，更适合先移动焦点，再按Enter或空格确认。本例采用后者：当前选中“任务”保持下划线，焦点移到“文件”时显示另一种清楚的外框，确认后才展示文件内容。
选中样式说明“正在看哪个面板”，焦点样式说明“下一次键盘操作作用在哪里”。二者可以同时存在，不能共用一个无法分辨的浅底色。更完整的跨页面与弹窗落点可以参考键盘导航与焦点管理。
用一次往返操作检验整套Tab
在画布上准备四个内容面板和当前态组件，并补上文件加载失败、概览未保存两种画面。需要体验切换时，可用墨刀原型把页面或对应状态连接起来。不要让每个Tab只连到同一张换了标题的空白页；任务区要有任务，文件区要有文件，参与者才能判断分组是否有用。
可以请同事完成这个任务：“找到还没完成的商品准备工作，查看项目主视觉，再回来继续处理那条任务。”观察他是否猜错标签，返回后是否重新筛选，是否知道当前项目没有改变。然后在概览修改一句说明，切到文件再回来，检查草稿规则是否与页面反馈一致。
交付时把各标签的内容范围、默认落点、独立筛选、未保存处理和加载结果放到对应画面旁。原型能帮助讨论这些预期；实际网页的键盘路径、内容隐藏、选中状态和辅助技术反馈，仍需在实现版本中验证。设计完成的标志是用户能找到内容并接着做事，而不只是四个标签都能点亮。
