layers-interaction-flow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/layers-interaction-flow

Assumes
/layers-intro
has been loaded for framework context.

The interaction structure and flow layer defines how a person interacts with the product: the places they navigate, the affordances available, the content presented, and the flow between states. It sits above the conceptual model (which defines what exists) and below the surface (which defines how it looks).

Decisions this layer needs to make:

What are the distinct places this flow moves through?
What can the user do in each place, and where does each action take them?
What content does each place need to show?
What happens on failure paths, empty states, and edge cases?
Is the flow as simple as it can be while still serving the job?

Methods:

Method	When
Breadboarding (Ryan Singer / Shape Up)	Default for most flows. Text-based notation that forces interaction logic to be evaluated before visual design makes changes feel expensive.
User story mapping (Jeff Patton)	Complex product, many user types, planning incrementally. Maps activities → tasks → stories across a timeline.
Task analysis	Redesigning an existing flow. Decompose the current task to find where friction, errors, and workarounds concentrate.
Service blueprinting	Flow spans multiple channels or involves backstage operations (staff, systems, third parties) that affect the user experience.
Critical User Journeys (CUJs)	Deciding which flow to work on. A CUJ is the minimal path to realise core product value — types: high-traffic, high-revenue, or metric-critical.

Default: breadboarding.

Breadboard notation:

Place name
- affordance → destination place
- affordance → destination place
[ content shown in this place ]

Quality signals — what good looks like:

Every affordance has a named destination
Failure paths are breadboarded — not left as afterthoughts
Empty, loading, and post-action states are defined
No broken objects — an object's attributes and actions are available together, not scattered across screens with no cross-linking
No isolated objects — relationships from the conceptual model are visible and navigable in the flow
The flow is minimal: more than 5–6 places for a single job story is a signal to look for what can be collapsed

假设已加载
/layers-intro
以获取框架上下文。

交互结构与流程层定义了用户与产品的交互方式：用户导航的位置、可用的交互元素、展示的内容以及不同状态间的流转。它位于概念模型（定义“存在什么”）之上，表层设计（定义“外观如何”）之下。

该层需要做出的决策：

此流程会经过哪些不同的位置？
用户在每个位置可以执行什么操作，每个操作会将他们带往何处？
每个位置需要展示哪些内容？
失败路径、空状态和边缘情况会发生什么？
在满足任务需求的前提下，流程是否足够简洁？

方法：

方法	适用场景
Breadboarding（Ryan Singer / Shape Up）	适用于大多数流程的默认方法。基于文本的符号表示法，要求在视觉设计导致变更成本升高之前先评估交互逻辑。
User story mapping（Jeff Patton）	适用于复杂产品、多用户类型、增量规划场景。按时间线映射活动→任务→用户故事。
Task analysis	适用于重新设计现有流程的场景。分解当前任务，找出摩擦、错误和临时解决方案集中的环节。
Service blueprinting	适用于流程跨多个渠道，或涉及影响用户体验的后台操作（员工、系统、第三方）的场景。
Critical User Journeys (CUJs)	适用于确定要优化的流程的场景。CUJ是实现核心产品价值的最小路径——类型包括高流量、高收入或指标关键型。

默认方法：Breadboarding。

面包板符号表示法：

Place name
- affordance → destination place
- affordance → destination place
[ content shown in this place ]

质量信号——优秀的标准：

每个交互元素都有明确的目标位置
失败路径已纳入面包板设计，而非事后补充
定义了空状态、加载状态和操作后状态
无“破碎对象”——对象的属性和操作是关联在一起的，而非分散在无交叉链接的多个屏幕中
无“孤立对象”——概念模型中的关系在流程中可见且可导航
流程极简：单个任务故事涉及5-6个以上位置时，需考虑可合并的环节

Guided session

引导式会话

Tell me which user journey you're designing for, or say "guide me" to start a breadboarding session.

Ask: "Where should I capture the work from this session?" (see

/layers-intro

for options)

Check the layer below: "Do you have a conceptual model — defined objects, relationships, and vocabulary — to work from? Or are we designing the flow without a settled model beneath it?" Flows built before the conceptual model is stable often need to be revisited.

Ask: "Which user journey or job story are we designing for?" A breadboard is always for a particular user in a particular situation doing a particular job.

Phase 1 — Frame the flow

Which job story does this flow serve?
Where does the user start? What situation are they in?
What does success look like — what has the user achieved when the flow completes?
New flow, redesign, or extension of an existing flow?

If redesigning: describe the current flow first, even roughly. Existing flows reveal decisions already made — some deliberately, many not.

Phase 2 — Identify the places

"What are the distinct places — screens or states — this flow moves through? Don't think about layout yet. Just name the places."

Ask: are any of these the same place in a different state? Should they be separate places or one place with states? Are there places elsewhere in the product that this flow connects to?

Naming places is itself a design decision. Descriptive, user-meaningful names: "Referral dashboard" not "Page 3."

Phase 3 — Map affordances and connections

For each place, work through what the user can do there and where each action leads. Use the breadboard notation above.

For each affordance: where exactly does this go? What happens if it succeeds? Fails? Is it always available, or only in certain conditions?

Conditions — when affordances are or aren't available — are often where the real design decisions hide.

Phase 4 — Walk through the flow

Narrate as the user: "I'm a user who [job story situation]. I arrive at [starting place]. I see [content]. I want to [motivation]. So I [affordance]..."

Walk the full successful path. Then walk the edges:

Empty states: What does this place look like before any data exists? Often the first thing a new user sees.
Loading / async states: What does the user see while data fetches or an action processes?
Post-action state: After submitting, what happens? Stay here, redirect, inline confirmation? If redirected to a list — does it immediately show the change? If there's lag, could it look like the action didn't work?
Optimistic vs. pessimistic: Show assumed result before server confirms, or wait? State the preference; flag as a named open question if implementation is uncertain.
Failure paths: For each action — validation failure, server error, network disconnection, timeout, concurrent edit. Where does the user go? How do they recover? These are required breadboard steps.
Cancel path: If the user wants to stop halfway, where do they go?
Alternative entry points: Does the flow assume prior state that might not always be true?

Each gap is an unmade design decision. Name it explicitly.

Phase 5 — Challenge the flow

Is there a step users are likely to abandon? Why is it there — is it necessary?
Are there actions users would expect that the flow doesn't offer?
Does the vocabulary in the flow match the conceptual model's ubiquitous language?
Is there a simpler version that serves the same job?

Check for broken objects: For each object from the conceptual model appearing in this flow — are its attributes and actions available together, or split across screens with no cross-linking? If split, either consolidate or add explicit connections between the places where its parts appear.

Check for isolated objects: For each relationship defined in the conceptual model — does the flow make that relationship visible and navigable? If a relationship exists in the model but is invisible in the flow, either surface it or make a deliberate decision that it doesn't need to be navigable from this flow.

Phase 6 — Generate the breadboard

Produce the complete breadboard: all places, all affordances and destinations, content for each place, key conditional states noted.

Generate a flow diagram in left-to-right orientation — flow through time reads left to right. In Mermaid:

graph LR

Note: the diagram is for orientation — the text breadboard is the primary document. The diagram loses content and conditional detail.

告诉我你正在设计哪个用户旅程，或者说“引导我”来启动一个Breadboarding会话。

提问：“我应该在哪里记录本次会话的成果？”（查看

/layers-intro

获取选项）

检查下层基础：“你是否有可依托的概念模型——已定义的对象、关系和术语？还是我们要在底层模型未确定的情况下设计流程？” 在概念模型稳定前构建的流程通常需要重新审视。

提问：“我们正在为哪个用户旅程或任务故事设计？” 面包板始终针对特定场景下执行特定任务的特定用户。

阶段1——框定流程

此流程服务于哪个任务故事？
用户从何处开始？他们处于什么场景？
成功的标准是什么——流程完成时用户达成了什么目标？
是新流程、重新设计流程，还是现有流程的扩展？

如果是重新设计：先大致描述当前流程。现有流程会揭示已做出的决策——有些是刻意的，很多是非刻意的。

阶段2——确定位置

“此流程会经过哪些不同的位置——屏幕或状态？先不要考虑布局，只需为这些位置命名。”

提问：这些位置中是否有处于不同状态的同一位置？应该设为单独位置还是带状态的同一位置？此流程是否连接到产品中的其他位置？

为位置命名本身就是一项设计决策。应使用描述性、对用户有意义的名称：比如“推荐仪表板”而非“页面3”。

阶段3——映射交互元素与连接

针对每个位置，梳理用户可执行的操作以及每个操作的去向。使用上述面包板符号表示法。

针对每个交互元素：它具体指向哪里？成功时会发生什么？失败时呢？它是始终可用，还是仅在特定条件下可用？

条件——交互元素可用或不可用的场景——往往隐藏着真正的设计决策。

阶段4——走查流程

以用户视角叙述：“我是一名[任务故事场景]的用户。我来到[起始位置]。我看到[内容]。我想要[动机]。所以我[交互操作]...”

先走查完整的成功路径。然后走查边缘情况：

空状态：在有数据之前，这个位置是什么样子？这通常是新用户首先看到的界面。
加载/异步状态：在数据获取或操作处理时，用户会看到什么？
操作后状态：提交后会发生什么？停留在当前页面、重定向，还是内联确认？如果重定向到列表——是否会立即显示变更？如果有延迟，会不会让用户误以为操作未生效？
乐观更新vs.悲观更新：在服务器确认前显示预期结果，还是等待？明确偏好；如果实现方式不确定，标记为未决事项。
失败路径：针对每个操作——验证失败、服务器错误、网络断开、超时、并发编辑。用户会被带往何处？他们如何恢复？这些是面包板必须包含的步骤。
取消路径：如果用户想中途停止，会被带往何处？
替代入口：流程是否依赖可能不总是成立的前置状态？

每个缺口都是未做出的设计决策，需明确命名。

阶段5——挑战流程

是否存在用户可能放弃的步骤？它存在的原因是什么——是否必要？
是否存在用户预期但流程未提供的操作？
流程中的术语是否与概念模型的通用语言一致？
是否有更简洁的版本可以满足相同任务需求？

检查“破碎对象”： 针对概念模型中出现在此流程中的每个对象——其属性和操作是否关联在一起，还是分散在无交叉链接的多个屏幕中？如果是分散的，要么整合，要么在其各部分出现的位置之间添加明确的连接。

检查“孤立对象”： 针对概念模型中定义的每个关系——流程是否使该关系可见且可导航？如果模型中存在关系但流程中不可见，要么将其展示出来，要么明确决定在此流程中无需提供导航。

阶段6——生成面包板

生成完整的面包板：所有位置、所有交互元素及目标位置、每个位置的内容、标注关键条件状态。

生成从左到右的流程图——时间流转从左到右读取。使用Mermaid语法：

graph LR

。

注意：流程图仅用于定位——文本面包板是主要文档。流程图会丢失内容和条件细节。

Completion

交付成果

Produce:

Job story — the user need this flow serves
Breadboard — complete text notation
Flow diagram — Mermaid
```
graph LR
```
Open decisions — gaps, edge cases, conditional states not yet resolved
Risks — dependencies on unsettled conceptual model decisions or surface assumptions

Close with: "This breadboard defines interaction logic without committing to visual form. Whatever comes next — working in code, building in the real medium, or detailed visual design — make sure the conceptual model beneath this flow is stable first."

生成：

任务故事——此流程服务的用户需求
面包板——完整的文本符号表示
流程图——Mermaid
```
graph LR
```
格式
未决事项——缺口、边缘情况、尚未解决的条件状态
风险——对未确定的概念模型决策或表层假设的依赖

收尾提示：“此面包板定义了交互逻辑，未绑定视觉形式。无论后续工作是编码、在真实媒介中构建还是进行详细视觉设计，都要确保支撑此流程的概念模型先稳定下来。”