UI Context and Scope
这是一个关于界面上下文与作用域（UI Context and Scope）的设计原则内容页，核心目标是让用户在任何时刻都能明确三件事：我在哪里（当前在产品层级中的位置）、我处于什么上下文（哪个区块、记录或工作区处于激活状态）、我的操作会影响什么（提交前了解改动范围）。若这些信息不清晰，用户容易出错、迷失，并失去对产品的信任。
用视觉结构传达层级
分隔线与边框用于标示区块边界，例如标题与内容之间的线表示内容属于该标题，侧边栏边框表示这是用途不同的区域。应避免过度使用分隔线，优先依靠间距与留白，分隔线只用于空间不足以表达边界的情况。背景色是“你现在进入了不同区域”的最强信号之一，可为侧边栏、面板或抽屉使用不同的背景色；激活或选中的区域可用轻微填充确认当前上下文；当改动被限定在某个区块时，该区块应通过边框、填充或两者同时进行视觉限定，让作用域在提交前一目了然。
区块标签与上下文标题
每个主要区域都应能独立回答“我是什么”，无需用户阅读周边内容。应使用用户的词汇而非系统的词汇命名区块；显示当前实体，例如“Editing: Invoice #2041”或“Settings for: Workspace”，而不是只写“Settings”；在影响特定记录的表单中，应在表单标题中突出显示记录名称。
导航深度
当产品有三级或以上层级，或用户可从多条路径到达某页时，应使用面包屑。示例：Home > Projects > Website Redesign > Tasks > #142 Fix header。每个面包屑项都应是返回该层级的可点击链接，当前页是最后一项，不是链接，只是文本。移动端可折叠为只显示直接父级，例如“← Website Redesign”。面包屑不替代主导航，而是补充主导航。
在内容树庞大或动态的产品中，搜索可降低导航深度的认知成本：提供全局搜索以查找产品内任意实体，提供上下文筛选以在当前作用域内缩小范围；搜索结果应显示足够上下文以区分相似项，例如同时显示项目名称与任务名称。
操作前的作用域沟通
当某项改动、设置或操作影响特定作用域时，必须在用户提交前说明该作用域，而不是事后才发现。方式包括：标签，例如“此设置仅适用于：当前工作区”“所有用户都会看到此更改”；视觉限定，在用户即将编辑时高亮或描边受影响区域；确认文案，破坏性或大范围操作应在确认对话框中说明范围，例如“删除此项目及其中的全部 47 个任务？”。
隐藏的作用域需要可见指示
当某项设置决定整个应用显示哪些数据（租户、站点、环境）时，控件可能位于设置对话框中，但状态不应隐藏。应在界面框架中放置常驻的只读指示器。很少更改是控件的问题，从来不是状态的问题。没有指示器，每个屏幕在错误的数据集下看起来都正确。切换作用域会丢弃前一个作用域派生的一切：搜索、暂存行、选择。
代他人操作
当用户以其他用户、客户或账户的身份查看或更改数据时（模拟登录、管理员“以……身份查看”、支持人员代客户操作），界面必须在整个过程中清晰可见，而不仅仅在进入模式时提示。要求包括：常驻且不可忽视的指示器，例如整个会话期间停留在屏幕上的彩色横幅或条，提示“你正在以 Acme Corp 身份操作——更改会影响他们的账户”，而不是会消失的 toast；说明这是谁的视图，指出被操作账户/客户，并使其在视觉上区别于操作者自己的正常上下文，避免混淆；提供明显的退出入口，例如始终可见的“返回你的账户 / 停止以……身份操作”。要防范的风险是操作者以为自己在自己的上下文中，实际却在客户上下文中操作，这种作用域混淆会造成真实损害。
认证是信任上下文
登录/注册页是用户交出密码的地方，本身是令人紧张的环节，也是他们最需要感到身处正确、安全之地的时刻。应将其设计为信任界面，而非事后补充：必须让人确信是品牌本身，通用或偏离品牌的登录页会显得可疑（“这真的是他们，还是钓鱼页面？”），应将完整品牌识别（标志、颜色、字体、语气）带入认证屏幕；URL 必须位于客户自己的生态中，将认证托管在客户域名或清晰子域名下，例如 app.customer.com、customer.com/login，而不是随机的第三方 URL，路径应保持浅而清晰（最多 domain/path/path，仅使用有意义的查询参数），用户会通过地址栏判断安全性，不透明的重定向链会让人认为是钓鱼；登出状态不挂载任何外壳，应在根节点渲染登录视图，其后不渲染任何内容，用模糊层或不可关闭的模态框遮盖外壳属于掩蔽，而掩蔽只是 CSS，在开发者工具中移除一个类，匿名访客即可看到导航、客户名称和功能开关，应在测试中断言登出状态下不存在任何外壳元素；数据离开上下文时，当某功能将人员或客户数据发送到外部模型，应在请求前将每个可识别字符串替换为稳定假名，并在客户端将响应映射回来，假名应在各行之间保持一致以保留关系，名称一旦离开，任何供应商承诺都无法挽回。
区分内部工具与外部产品
内部/后台软件应带有刻意设计的视觉“怪癖”——独特的强调色、环境徽章、标记过的页眉——使其不可能被误认为面向客户的应用。这可以防止操作者将内部管理界面与外部产品混淆（或将预发环境与生产环境混淆）。该提示应是常驻且立即可读的，不能藏在设置页中。
哪个应用、谁的数据、什么权限
当一次登录可打开多个工具时，“我在哪里”会有两个答案需要用户同时知道，且都应放在常驻外壳中，而非页面上（[[app-shell]]）。哪个应用：当工具共享外壳和品牌后，它们也开始变得相似，这是好结果，但也带来新故障：在错误的工具中操作。应用的自身名称应始终在壳中同一位置可见。谁的数据：在多租户或多客户工具中，当前租户应永久命名，并在任何破坏性操作的确认中重复。应将其命名为标签，不要编码为颜色或主题，后者会破坏品牌并让对比度不可预测。颜色应保留给环境提示，因为混淆生产与预发有真实成本。什么权限：内部用户受益于看到自己操作所用的角色，这能解释为何某操作缺失，并使权限过高的会话对持有者可见。应在壳中显示角色，对于角色阻止的操作，优先使用带原因的禁用而非静默隐藏（[[nielsen-usability-heuristics]]）。面向客户的产品不应以这种方式暴露角色；在那里，缺席是更干净的答案。
检查清单
用户是否始终能识别自己当前正在编辑哪个区块或记录？ 颜色区域或边框是否一致地用于分隔不同上下文？ 超过两级的导航是否使用面包屑或清晰返回路径？ 操作确认对话框是否说明将受影响的范围？ 代其他账户操作时，是否有常驻、不可忽视的指示器说明是谁，并有始终可见的退出入口？ 内部/后台工具是否带有常驻视觉提示，以区别于面向客户的应用（以及预发与生产）？ 当作用域控件隐藏在设置中时，当前作用域是否仍在框架中以只读方式显示？ 登出状态是否只挂载登录视图，没有隐藏在模糊层或模态框后的外壳？ 可识别数据在到达外部模型或服务前是否已假名化？ 认证屏幕是否完全符合品牌，登录 URL 是否位于客户自己的域名/子域名下且路径浅而清晰？ 区块标题是否使用用户词汇，并在相关处命名当前实体？ 内容结构过大而无法浏览时，是否提供全局搜索？ 当多个工具共享一次登录和一种外观时，当前应用是否被持久命名？ 当前租户是否以标签命名，而非编码为颜色或主题？ 在内部工具中，用户角色是否可见——被阻止的操作是否带原因禁用而非静默消失？