UI Context and Scope

UI上下文与范围

Users need to know three things at all times:

Where am I? — current location in the product hierarchy
What context am I in? — which section, record, or workspace is active
What will my actions affect? — scope of changes before committing them

When these are unclear, users make mistakes, feel lost, and lose trust in the product.

用户需要时刻清楚三件事：

我在哪里？ —— 在产品层级中的当前位置
我处于什么上下文？ —— 哪个分区、记录或工作区处于激活状态
我的操作会影响什么？ —— 提交更改前的影响范围

当这些信息不明确时，用户会犯错、感到迷茫，并对产品失去信任。

Communicating Hierarchy with Visual Structure

用视觉结构传达层级关系

Lines and Dividers

线条与分隔符

Horizontal rules and borders signal the boundary between sections. Use them to separate content areas that belong to different contexts — not just for decoration.

A line between a header and content says "the content below belongs to this header"
A sidebar border says "this is a different region with a different purpose"
Avoid overusing dividers — proximity and whitespace should do most of the work; dividers reinforce where space alone is insufficient

水平线和边框标志着不同分区之间的界限。用它们来分隔属于不同上下文的内容区域——而不只是装饰。

标题与内容之间的线条表示“下方内容属于此标题”
侧边栏边框表示“这是一个用途不同的独立区域”
避免过度使用分隔符——邻近关系和留白应承担主要作用；只有当留白不足以区分时，再用分隔符强化

Colour Regions and Background Fills

色块与背景填充

Background colour is one of the strongest signals for "you are now in a different area."

Use a distinct background shade for sidebars, panels, or contextual drawers
Active or selected regions benefit from a subtle fill to confirm "this is the current context"
When a user's changes are scoped to a specific section, that section should be visually bounded — border, fill, or both — so the scope is self-evident before the user commits

背景色是“你现在进入了一个不同区域”的最强烈信号之一。

为侧边栏、面板或上下文抽屉使用独特的背景色调
激活或选中的区域可添加细微填充，以此确认“这是当前上下文”
当用户的更改仅针对特定分区时，该分区应通过边框、填充或两者结合进行视觉界定，确保用户提交更改前就能清晰知晓影响范围

Section Labels and Context Headers

分区标签与上下文标题

Every major region should be able to answer "what am I?" without the user having to read surrounding content.

Name sections with the user's vocabulary, not the system's
Show the active entity: "Editing: Invoice #2041" or "Settings for: Workspace" — not just "Settings"
In forms that affect a specific record, show the record name prominently in the form header

每个主要区域都应能让用户无需阅读周边内容就能回答“这是什么？”

用用户的词汇而非系统术语来命名分区
显示当前激活的实体：“编辑中：发票#2041”或“设置：工作区”——而不只是“设置”
在针对特定记录的表单中，将记录名称醒目地显示在表单标题处

Navigating Depth

深度导航

Breadcrumbs

面包屑

Use breadcrumbs when the product has three or more levels of hierarchy, or when users can arrive at a page from multiple paths.

Home > Projects > Website Redesign > Tasks > #142 Fix header

Each breadcrumb item should be a clickable link back to that level
The current page is the last item — not a link, just text
On mobile, collapse to show only the immediate parent:
```
← Website Redesign
```
Breadcrumbs do not replace primary navigation — they complement it

当产品拥有三层及以上层级，或用户可通过多种路径到达某一页面时，使用面包屑。

Home > Projects > Website Redesign > Tasks > #142 Fix header

每个面包屑项都应是可点击的链接，能返回对应层级
当前页面是最后一项——仅显示文本，不设链接
在移动端，可折叠为仅显示直接父级：
```
← Website Redesign
```
面包屑不能替代主导航——而是对其补充

Search and Filter as Navigation

搜索与筛选作为导航方式

In products with large or dynamic content trees, search reduces the cognitive cost of navigating depth.

Global search for finding any entity across the product
Contextual filters for narrowing within the current scope
Search results should show enough context to distinguish similar items (e.g. project name alongside task name)

在内容树庞大或动态变化的产品中，搜索能降低深度导航的认知成本。

全局搜索：用于查找产品内的任意实体
上下文筛选：用于在当前范围内缩小查找范围
搜索结果应显示足够上下文以区分相似项（例如，任务名称旁显示项目名称）

Scope Communication Before Action

操作前的范围传达

When a change, setting, or action affects a specific scope, that scope must be communicated before the user commits — not discovered afterward.

Labels: "This setting applies to: this workspace only" / "All users will see this change"
Visual bounding: Highlight or outline the affected region when the user is about to edit it
Confirmation copy: Destructive or wide-scope actions should state the scope in the confirmation dialog ("Delete this project and all 47 tasks inside it?")

当一项更改、设置或操作仅影响特定范围时，必须在用户提交前传达该范围——而非事后才发现。

标签说明：“此设置仅适用于：当前工作区” / “所有用户都会看到此更改”
**视觉界定：**当用户即将编辑某区域时，高亮或勾勒出受影响的区域
**确认文案：**具有破坏性或影响范围广的操作，应在确认对话框中说明影响范围（“确定要删除此项目及其中的47项任务吗？”）

Acting on Behalf of Someone Else

代他人操作场景

Whenever the user is viewing or changing data as another user, customer, or account — impersonation, admin "view as", support acting on a customer's behalf — the interface must make that unmistakably obvious the entire time, not just at the moment they enter the mode.

Persistent, unmissable indicator: a coloured banner or bar that stays on screen the whole session ("You are acting as Acme Corp — changes affect their account"), not a toast that disappears.
Whose view is this: name the account/customer being acted upon, and make it visually distinct from the operator's own normal context so the two can never be confused.
An obvious exit: a clear "Return to your account / Stop acting as…" control, always visible.

The risk being designed against is an operator making a change believing they're in their own context when they're really in a customer's — scope confusion here causes real damage.

无论何时用户以其他用户、客户或账户的身份查看或修改数据——例如模拟操作、管理员“以他人视角查看”、客服代客户操作——界面必须全程清晰显示这一状态，而不只是进入该模式时提示一次。

持久且醒目的提示：使用彩色横幅或栏位，在整个会话期间保持显示（“你正在以Acme Corp的身份操作——更改将影响其账户”），而非会消失的提示框。
**明确视角归属：**标注出当前操作的账户/客户名称，并使其与操作员自身的常规上下文在视觉上区分开，避免两者混淆。
**清晰的退出方式：**始终显示明确的“返回你的账户 / 停止代操作”控件。

这种设计旨在避免操作员误以为是在自己的上下文中操作，实则是在客户的上下文中——此类范围混淆会造成实际损失。

Authentication Is a Trust Context

认证环节是信任上下文

The login / sign-up screen is where the user hands over a password — an inherently scary moment, and the point where they most need to feel they're in the right, safe place. Design it as a trust surface, not an afterthought:

It must feel unmistakably like the brand. A generic or off-brand login page reads as suspicious ("is this really them, or a phishing page?"). Carry the full brand identity — logo, colours, type, tone — into the auth screens.
The URL must live in the customer's own ecosystem. Host auth on the customer's domain or a clear subdomain —
```
app.customer.com
```
,
```
customer.com/login
```
— not a random third-party URL. Keep the path shallow and legible (at most
```
domain/path/path
```
, only meaningful query params). Users read the address bar to judge safety; an opaque redirect chain reads as phishing.

登录/注册页面是用户提交密码的场景——这本质上是一个令人不安的时刻，也是用户最需要确认自己处于正确、安全环境的节点。应将其设计为信任界面，而非事后补充的模块：

**必须具有鲜明的品牌辨识度。**通用或偏离品牌风格的登录页面会让用户产生怀疑（“这真的是官方页面，还是钓鱼网站？”）。将完整的品牌标识——logo、色彩、字体、语气——融入认证页面。
**URL必须属于客户自有生态。**将认证页面托管在客户自有域名或清晰的子域名下——例如
```
app.customer.com
```
、
```
customer.com/login
```
——而非随机的第三方URL。保持路径简洁易读（最多为
```
domain/path/path
```
，仅保留有意义的查询参数）。用户会通过地址栏判断安全性；模糊的重定向链路会被视为钓鱼行为。

Distinguish Internal Tools from External Products

区分内部工具与外部产品

Internal / back-office software should carry a deliberate visual "quirk" — a distinct accent colour, an env badge, a marked header — that makes it impossible to mistake for the customer-facing app. This prevents an operator from confusing an internal admin surface with the external product (or a staging environment with production). The cue should be persistent and immediately legible, not hidden in a settings page.

内部/后台办公软件应带有刻意的视觉“标识”——独特的强调色、环境徽章、标记化标题——使其绝不可能被误认为是面向客户的应用。这能防止操作员将内部管理界面与外部产品混淆（或将 staging 环境与生产环境混淆）。该标识应持久显示且一目了然，而非隐藏在设置页面中。

Review Checklist

审核清单

Can the user always identify which section or record they are currently editing?
Are colour regions or borders used consistently to separate distinct contexts?
Does navigation deeper than 2 levels use breadcrumbs or a clear back path?
Do action confirmation dialogs state the scope of what will be affected?
When acting on behalf of another account, is there a persistent, unmissable indicator naming who, plus an always-visible exit?
Do internal/back-office tools carry a persistent visual cue that distinguishes them from the customer-facing app (and staging from production)?
Do auth screens feel fully on-brand, and does the login URL sit in the customer's own domain/subdomain with a shallow, legible path?
Are section titles written in user vocabulary, naming the active entity where relevant?
Is global search available when the content structure is too large to browse?

用户是否总能明确自己当前正在编辑哪个分区或记录？
是否一致使用色块或边框来分隔不同的上下文？
层级超过2级的导航是否使用了面包屑或清晰的返回路径？
操作确认对话框是否说明了影响范围？
代其他账户操作时，是否有持久且醒目的提示标注操作对象，同时始终显示退出控件？
内部/后台工具是否带有持久的视觉标识，以区分于面向客户的应用（以及staging与生产环境）？
认证页面是否完全符合品牌风格，且登录URL位于客户自有域名/子域名下，路径简洁易读？
分区标题是否使用用户词汇，并在相关情况下标注激活的实体？
当内容结构过于庞大无法浏览时，是否提供全局搜索？

ui-context-and-scope

Original

Translation