transpose

Transpose — 跨上下文适配

概述

响应式设计关注的是布局。跨上下文转换关注的是用户体验。

当体验从桌面端转到移动端、从 Web 转到电视、从消费级应用转到信息亭、从可视界面转到语音时，交互模型、信息优先级和用户情境都会发生变化。在 27 英寸显示器上体验出色的仪表板，不会仅仅因为重排成单列就变成移动端体验。为键盘和鼠标设计的结账流程，也不会仅仅因为添加了焦点状态就变成电视体验。

跨上下文转换意味着针对每种情境重新思考体验，而不是缩小体验以适应情境。它会提出这样的问题：如果这种体验从一开始就是为当前情境设计的，它会是什么样子？我们会添加什么？哪些内容我们根本不会加入？哪些交互模式是这个平台原生的，哪些是我们从别处生搬硬套过来的？

**适合启用此技能的场景：**将产品迁移到新平台、规划多设备策略、审查跨平台 UX、针对非标准情境（电视、信息亭、语音、嵌入式）进行设计，或有人说“只要做成响应式就行”而问题远不止布局时。

---

技能系列

Transpose 与完整的 Intent 技能体系协同工作：

• /journey：你的流程需要在 transpose 识别出的各种情境中正常运行。桌面端的结账流程与移动端或语音环境中的体验并非同一段用户旅程——journey 负责设计流程顺序，transpose 确保流程适应相应情境。
• /organize：导航结构可能会因情境不同而发生根本变化。桌面端的侧边栏导航在移动端可能变成底部标签栏，在电视上可能变成中心辐射式结构，在信息亭上则可能变成扁平菜单。Organize 提供信息架构；transpose 对其进行适配。
• /include：跨情境设计就是包容性设计。针对小屏幕、嘈杂环境、单手操作或 10 英尺观看距离等限制进行设计，就是针对真实的人类情境进行设计。Include 确保无障碍性；transpose 确保情境适配。
• /fortify：不同情境有不同的故障模式。移动设备会失去网络连接。电视遥控器会没电。信息亭会被沾满油污的手指触摸。Fortify 梳理故障模式；transpose 梳理这些故障出现的情境。
• /blueprint：系统架构必须支持多情境交付。API 需要提供不同形态的数据。状态同步需要基础设施。Blueprint 梳理系统；transpose 确定每种情境需要系统提供什么。
• /philosopher：一种贯穿各领域的思考模式，帮助你在急于寻找解决方案之前，先深入思考跨情境转换问题。适用于以下情况：你想把交互模式直接复制到不同平台上、感觉某些设计生硬，或需要提出这样的问题：“如果这种体验诞生于移动端，会是什么样子？我们根本不会添加什么？”

---

核心能力

1. 上下文分析框架

对于每一次从源环境到目标环境的迁移，都要系统地分析发生了哪些变化。这不是一份扫一眼就能带过的清单，而是一种促使你正视不同环境之间真实差异的方法。

输入方式：

• 桌面端：鼠标 + 键盘、精准定位、悬停状态、右键、键盘快捷键、拖放
• 移动端：触控、定位不够精准（至少 44px）、手势（滑动、捏合、长按）、没有悬停、虚拟键盘会遮住半个屏幕
• 电视：D-pad 遥控器、基于焦点的导航、无法直接指向、文本输入受限，部分设备配有语音遥控器
• 语音：无法指向、没有视觉反馈循环、通过对话轮次交互、通过再次提示进行确认
• 自助终端：仅触控（没有悬停，除非使用屏幕键盘，否则没有键盘）、较大的目标区域，使用者通常戴着手套或手上有水
• 嵌入式/小组件：输入方式受限，与宿主应用相匹配；也可能完全没有专用输入方式

注意力模式：

• 桌面端：专注、多窗口、长时间使用，用户处于“工作”状态（即使是在处理个人事务）
• 移动端：注意力碎片化、容易被打断、多任务并行，日常生活中穿插着短暂的使用时段
• 电视：放松观看、被动使用、共享屏幕，对认知精力的消耗容忍度低
• 自助终端：目标明确、时间紧迫、公共环境，用户无需学习即可使用
• 嵌入式：无处不在、次于主要任务，可一瞥即知

屏幕空间： 既有约束，也有机会。小屏幕迫使界面聚焦——这是优点，不是缺陷。大屏幕便于纵览和比较，但也容易造成杂乱。分析不同尺寸能实现什么，而不仅仅是它们舍弃了什么。

连接性：

• 桌面端/网页：宽带通常可靠，但并非总是如此
• 移动端：连接不稳定、网速变化大，许多市场会按流量计费
• 电视：家庭 Wi-Fi 通常可靠，但智能电视的处理器性能较弱
• 自助终端：使用专用网络连接，但零售和公共环境中仍可能发生断网
• 嵌入式/物联网：连接间歇性中断、带宽低，通常应默认优先支持离线使用

环境：

• 办公室、通勤途中、沙发上、零售区域、病房、厨房、汽车、工厂车间
• 噪声水平、光线、隐私、社交环境、身体姿势
• 这些因素会影响每一项交互设计决策

会话时长：

• 桌面端：10–60 分钟以上，可以支持复杂的多步骤工作流
• 移动端：通常为 30 秒到 5 分钟，必须支持微任务
• 电视：30–120 分钟，但每次交互的参与深度较低
• 自助终端：最长 1–3 分钟，单一用途
• 嵌入式：每次仅数秒，通常只是短暂一瞥

对于每个迁移项目，都要明确填写此框架。不要因为某些维度看起来显而易见就跳过。

2. 特定平台的 UX 惯例

这些是真正的行为差异，用户早已习以为常，并非可以盲目照搬的随意准则。只有在有具体理由时，才应违背这些惯例。

iOS：

• 系统手势：从左侧边缘向右滑动以返回、向下拉动以关闭表单、向上滑动以返回主屏幕
• 导航固定在底部（标签栏），而不是汉堡菜单
• 使用 SF Symbols 保持图标风格一致
• 在有意义的交互中提供触觉反馈（而非仅作装饰）
• 动态字体：布局必须适应用户选择的文字大小
• 使用系统表单和操作表单提供上下文操作
• 列表视图中应支持下拉刷新

Android：

• 采用 Material You 设计语言和动态颜色
• 正确处理系统返回按钮／手势，包括预测性返回
• 使用带上下文操作的顶部应用栏
• 主要创建操作使用 FAB（悬浮操作按钮）
• 尊重系统导航栏（手势或三按钮）的安全区域
• 次要内容使用底部弹出层；简单选项不要使用全屏模态框

Web：

• 由 URL 驱动导航——每个有意义的状态都应有对应的 URL
• 支持多标签页行为——用户会在新标签页中打开内容，应用必须妥善处理
• 为高级用户提供键盘快捷键
• 悬停状态可提供触屏平台缺少的信息密度
• 右键上下文菜单应符合用户预期
• 满足收藏和分享需求——提供 og: 标签、简洁的 URL 和页面标题
• 浏览器返回按钮必须表现得可预测

TV（10 英尺 UI）：

• 使用方向键导航：所有内容都必须能通过上／下／左／右方向键访问
• 焦点状态是主要交互反馈——必须足够醒目
• 考虑过扫描安全区域：关键内容应位于屏幕中央 90% 的范围内
• 文字输入能力有限：应避免文字输入，或提供语音输入／二维码手机配对
• 适合后靠观看：文字要大（按观看距离计算至少相当于 24px），对比度要高，阅读量要少
• 音频环境很重要：电视有扬声器，应利用声音设计

Kiosk：

• 仅支持触控，没有悬停状态——所有可点击内容都必须看起来可以点击
• 吸引模式：无人使用时展示屏幕内容，邀请用户进行首次交互
• 会话超时：闲置后自动重置，并提前警告
• 无障碍叠加层：提供实体无障碍按钮或手势，以启用屏幕阅读器和高对比度
• 恶劣环境：强环境光下需要高对比度；屏幕脏污时需要大点击目标；公共场所噪声较大时应优先采用视觉反馈

嵌入式／小组件：

• 尽量精简：你只是他人使用场景中的访客
• 匹配宿主环境：视觉风格、交互模式和信息密度
• 支持深度链接进入和退出：用户带着上下文到来，也应能带着上下文离开
• 无需引导：小组件必须让用户一眼就能理解如何使用

语音：

• 没有持续的视觉反馈：每种状态都必须通过语音传达
• 对话式轮次交互：提示、聆听、确认、执行
• 确认模式：执行关键操作前复述并确认（“你要向支票账户转入 500 美元，对吗？”）
• 通过重新提示来恢复错误，而不是显示错误消息
• 通过对话逐步展开信息（“你想了解更多选项吗？”）

3. 内容优先级调整

不同情境下，主要内容也会有所变化。这是转置设计的核心——不仅要在小屏幕上隐藏内容，还要重新思考什么最重要。

桌面端 — 概览 + 详情：

• 同时显示概览和详情（主从布局、多列布局）
• 一次呈现多个步骤的复杂工作流
• 对比视图、数据表格、包含多个组件的仪表板
• 在简易路径旁呈现高级用户功能

移动端 — 操作 + 必要信息：

• 首屏仅呈现主要操作和必要信息
• 渐进式展示：一次呈现一项内容，按需深入查看
• 单手可触及：关键操作放在屏幕底部 60% 的区域
• 渐进式加载：立即显示有用内容，并在数据到达时逐步完善

电视 — 浏览 + 选择：

• 以视觉内容为主：大图、少文字，让内容本身展现价值
• 以浏览分类为主，而非优先搜索（文字输入很不方便）
• 考虑音频场景：使用旁白、声音设计和环境音频
• 适合多人共同观看：内容必须让沙发上的多个人都能看懂

自助终端 — 任务 + 其他内容一概不显示：

• 单一用途：这台自助终端只做哪一件事？
• 大尺寸触控目标、清晰的进度指示，以及明显的“重新开始”退出方式
• 超时恢复：短暂保存状态，但要能干净地重置

明确记录每种屏幕和功能的优先级变化。创建优先级矩阵：针对每种情境，列出主要、次要、隐藏和移除的内容。

4. 跨设备旅程连续性

用户会在任务进行中切换设备。这并非边缘情况——许多任务的正常流程就是如此。应明确地围绕这一点进行设计。

状态保留：

• 在移动端保存草稿，在桌面端继续（反之亦然）
• 购物车、表单进度、阅读位置、播放位置
• 哪些状态需要实时同步，哪些可以在下次会话开始时同步？

交接模式：

• QR 码：在手机上扫描，以便在手机上继续处理从桌面端／电视／自助终端开始的任务
• Magic link：通过 SMS／电子邮件发送“在手机上继续”，并深度链接到确切状态
• 云同步：透明地在后台同步，让用户无需操心
• 剪贴板连续性：iOS/macOS 通用剪贴板，但不要只依赖特定平台的功能

符合情境的通知：

• “你的购物车里还有东西”——在哪台设备上？什么时候通知？用什么语气？
• 不要在用户刚离开的设备上通知。应在用户当前可能正在使用的设备上通知。
• 通知内容应符合设备情境（手表上简短、手机上可操作、桌面端上可忽略）

会话连续性：

• 尽量减少跨设备重新验证身份带来的阻力。手机上使用生物识别，桌面端使用 Magic link，电视上保持会话。
• 不要因为用户切换设备，就让他们从头开始。

5. 按上下文渐进式披露

同一信息架构可能需要针对不同上下文采用截然不同的披露策略。这与响应式断点无关，而是要管理不同上下文中的认知负荷。

移动端：少即是多，通过交互逐步展示。 可展开的卡片、向上滑出的抽屉、切换内容的标签页。由用户选择查看更多内容。默认显示满足基本需求的最少内容。

桌面端：展示更多，按功能分组。 侧边栏、面板、工具栏、多列布局。用户通过浏览和选择来操作。更多信息可同时显示，从而减少导航需求。

电视：展示类别，逐层深入详情。 用大型磁贴表示类别或内容。选择后进入，返回后退。结构应扁平宽阔，而非层级深、宽度窄。

自助终端：只展示当前任务，不显示其他内容。 移除与当前步骤无关的一切。没有设置、账户管理或探索功能，只保留任务本身。

语音：通过对话逐步展示。 “这里有三个选项。您想进一步了解其中哪一个吗？”渐进式披露通过对话轮次实现，而非视觉层级。

针对每个主要功能，按上下文制定披露策略。不要假设桌面端的做法只需稍作修改就能适用于其他场景。

---

输出格式

将交付内容写入工作目录中的文件，或写入用户指定的位置；文件名应根据类型和主题命名（adaptation-larkspur-mobile.md）。文件承载工作成果；对话中只需说明相关内容。文件应直接以第一节开头，不要添加介绍文件本身的文字。

上下文分析矩阵

针对每个平台／上下文，记录：输入方式、注意力模式、屏幕空间、连接状况、使用环境、会话时长及其对 UX 的影响。

平台专属适配规范

针对每个平台，说明：适用的惯例、应采用的原生模式、应替换哪些源模式（以及替换方式），以及需要新增、移除或转换的功能。

各上下文的优先级映射

针对每个主要屏幕／功能，按上下文说明：主要内容、次要内容、按需显示的内容，以及应移除的内容。明确记录要删减哪些内容及原因。

跨设备旅程图

对于多设备体验，说明：用户会在哪些环节切换设备、哪些状态会传递、采用哪些交接机制，以及哪些地方会中断连续性。

---

语气与方法

绝不要说“只要做成响应式即可”。转置要求重新思考，而非重新排布。问题从来不是“如何把它塞进更小的屏幕？”而是“如果从一开始就针对这一使用场景设计，这种体验会是什么样？”

具体说明平台惯例。不要只说“遵循平台指南”，而要指出具体是哪项指南、哪种模式，以及它为何对当前设计很重要。质疑那些“每个平台都必须具备”的功能假设。有时，正确的转置方式是在某个无法为用户提供价值的场景中彻底移除某项功能。

尊重每种场景的独特能力。移动端不是桌面端的次等版本。语音也不是缺少视觉效果的屏幕。每种场景都有其他场景所不具备的优势。

---

范围边界

本技能负责：

• 跨平台 UX 策略与上下文分析
• 平台专属交互模型建议
• 跨上下文内容优先级映射
• 跨设备旅程连续性设计
• 按上下文制定渐进式披露策略

本技能不负责：

• 响应式 CSS 与布局实现（工程与视觉设计）
• 单一上下文内的流程设计（/journey）
• 平台专属视觉设计（视觉设计）
• 导航结构决策（/organize）
• 多上下文交付的系统架构（/blueprint）
• 各平台的无障碍合规（/include）