Back to Details

layers-intro

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/layers-intro

/layers-intro

Load this skill at the start of any design session. It provides the framework context that all other 
/layers-*
skills depend on.
在任何设计会话开始时加载此技能。它提供了所有其他
/layers-*
技能依赖的框架上下文。

The framework

框架

Layers of Product Design organises design work into seven layers across three zones. Layers have logical dependency: lower layers are foundations for upper ones. Weak lower layers create UX debt that propagates upward.
Reality — complex, contradictory, evolving. Source of all learning.
Problem space — knowledge gathered from reality:
  1. Observed behaviour — what users actually do
  2. The domain — concepts, terminology, and mental models that exist independently of any product
  3. User needs — what we think users are trying to achieve, and why
Solution space — deliberate decisions about what to build: 4. Product & service strategy — which needs to serve, and what business outcomes to target 5. Conceptual model — objects, relationships, states, vocabulary — independent of any interface 6. Interaction structure and flow — places, affordances, connections, and flow logic 7. Surface — words, visuals, feedback, hierarchy — what users actually encounter
The layers are not a linear process. Enter anywhere — but always check whether the foundations below are sound.
Inspired by Jesse James Garrett's The Elements of User Experience (2000).
Layers of Product Design 将设计工作划分为三个区域下的七个层级。各层级之间存在逻辑依赖关系：下层是上层的基础。薄弱的下层会产生向上传导的UX债务。
Reality——复杂、矛盾且不断演变。是所有认知的来源。
Problem space——从现实中收集的认知：
  1. Observed behaviour——用户实际的行为
  2. The domain——独立于任何产品存在的概念、术语和心智模型
  3. User needs——我们认为用户试图达成的目标及其背后的原因
Solution space——关于构建内容的审慎决策： 4. Product & service strategy——要满足哪些需求，以及瞄准哪些业务成果 5. Conceptual model——对象、关系、状态、词汇——独立于任何界面 6. Interaction structure and flow——场景、功能入口、关联关系和流程逻辑 7. Surface——文字、视觉元素、反馈、层级结构——用户实际接触到的内容
这些层级并非线性流程。可以从任意层级切入——但始终要检查下方的基础是否稳固。
灵感来源于Jesse James Garrett所著的《用户体验要素》(The Elements of User Experience, 2000)。

Design is decision-making

设计即决策

Design = making decisions about the form of a solution (Christopher Alexander). Form is the solution; context is the requirements, constraints, and environment it must fit. Good design is good fit.
Four kinds of progress:
  1. Making decisions — resolving something undecided
  2. Uncovering unmade decisions — discovering what hasn't been decided yet (often more valuable than 1)
  3. Evaluating decisions — identifying decisions already made that are risky, inconsistent, or wrong
  4. Prioritising decisions — lower layers are more foundational and carry more risk if wrong
The job of every skill is to help the designer make better decisions — not to make decisions for them.
设计 = 针对解决方案形态做出决策（Christopher Alexander）。形态即解决方案；上下文是它必须适配的需求、约束和环境。优秀的设计意味着完美适配。
四种进展类型：
  1. 制定决策——解决未确定的事项
  2. 发现未制定的决策——找出尚未决定的内容（通常比第1种更有价值）
  3. 评估决策——识别已做出的具有风险、不一致或错误的决策
  4. 优先级排序决策——下层更具基础性，若出错则风险更大
每个技能的作用都是帮助设计师做出更好的决策——而非替他们做决策。

Principles — apply across all sessions

原则——适用于所有会话

  1. Decisions, not outputs. Artefacts are useful only insofar as they represent decisions made or surfaced. Name the decision, not just the diagram.
  2. Uncover before you resolve. Surfacing decisions the designer didn't know they needed to make is often more valuable than answering the ones they did.
  3. Work at one layer at a time. Conflating problem space and solution space, or surface and conceptual model, produces confused outputs.
  4. Check foundations before building upward. Before working on an upper layer, audit the layer below. Flag instability.
  5. The conceptual model is the most neglected load-bearing layer. Give it more attention than feels comfortable.
  6. Flag bad decisions, not just missing ones. A decision already made that's risky or inconsistent needs to be named, not worked around.
  7. Steer, don't be steered. Don't jump to surface output before foundational decisions are made.
  8. Design principles vs. implementation decisions. Some decisions can be stated without knowing system constraints — what should happen from the user's perspective. Others are entangled with implementation: articulate the user experience requirement, form a well-shaped question, and carry it into a design+engineering conversation. Don't force a premature answer.
  1. 聚焦决策，而非产出。只有当工件代表已制定或已发现的决策时，它们才有用。要明确决策内容，而不只是标注图表。
  2. 先发现，再解决。找出设计师未曾意识到需要做出的决策，往往比回答他们已知的问题更有价值。
  3. 一次专注一个层级。混淆问题域与解决方案域，或表层与概念模型，会导致产出混乱。
  4. 向上构建前先检查基础。在处理上层之前，审核下层。标记不稳定的部分。
  5. Conceptual model是最被忽视的承重层。要投入超出舒适区的精力关注它。
  6. 标记错误决策，而非仅遗漏的决策。已做出的具有风险或不一致的决策需要被明确指出，而非回避。
  7. 引导方向，而非被引导。在基础决策完成前，不要急于产出表层内容。
  8. 设计原则vs.实现决策。有些决策无需考虑系统约束即可确定——从用户视角看应该发生什么。其他决策则与实现紧密相关：明确用户体验需求，提出清晰的问题，带入设计+工程的讨论中。不要强行给出不成熟的答案。

The time dimension — probe proactively

时间维度——主动探索

Temporal decisions are frequently overlooked. They cluster at two layers:
Conceptual model layer:
  • Intermediate action states — does an object pass through transitional states (saving, processing, pending approval) before resolving? Those are model states.
  • Read model lag — gap between when data is written and when it's visible? Articulate the user need; flag as a named open question for engineering.
  • Relationship temporality — "all products in Europe" means the group now, or membership as it changes? This is a design decision.
  • Deletion semantics — archive, trash, hard delete, or regulatory delete? State which and why. Implementation follows.
  • History — does it matter what an object was in the past? Stating it matters is a design decision.
Interaction structure layer:
  • Post-action state — after submitting, what does the user see? Does a redirected list immediately reflect the change?
  • Optimistic vs. pessimistic updates — show assumed result before server confirms, or wait? State the preference; flag as an open question if implementation is uncertain.
  • Empty, loading, partial states — every place has a temporal lifecycle. Design all of them.
  • Error and failure paths — validation failure, server error, network disconnection, concurrent edit. Required design steps, not afterthoughts.
时间相关的决策常被忽视。它们集中在两个层级：
Conceptual model层：
  • 中间操作状态——对象在解决前是否会经历过渡状态（保存中、处理中、待审批）？这些属于模型状态。
  • 读取模型延迟——数据写入到可见之间的间隔？明确用户需求；将其标记为需与工程团队讨论的公开问题。
  • 关系时效性——“欧洲的所有产品”指当前的群组，还是随时间变化的成员？这是一个设计决策。
  • 删除语义——归档、放入回收站、硬删除还是合规删除？说明选择及原因。实现方式随之而定。
  • 历史记录——对象过去的状态是否重要？明确其重要性是一个设计决策。
Interaction structure层：
  • 操作后状态——提交后用户会看到什么？重定向后的列表是否立即反映变更？
  • 乐观更新vs.悲观更新——在服务器确认前显示预期结果，还是等待？说明偏好；若实现方式不确定则标记为公开问题。
  • 空状态、加载状态、部分加载状态——每个场景都有时间生命周期。要设计所有状态。
  • 错误与失败路径——验证失败、服务器错误、网络断开、并发编辑。这些是必需的设计步骤，而非事后补充。

Failure mode signals

失败模式信号

OOUX object failure modes (Sophia Prater):
  • Shapeshifter — same object in significantly different forms across contexts. Surface fix: consistent object treatment. Deeper fix if the model doesn't define the object clearly.
  • Masked — different object types look identical. Surface fix: distinct visual treatments. Deeper fix if the model doesn't differentiate them.
  • Broken — object's data and actions scattered across screens with no cross-linking. Interaction structure problem → 
    /layers-interaction-flow
    .
  • Isolated — objects exist without visible relationships to other objects. Conceptual model problem → 
    /layers-conceptual-model
    .
Nielsen's heuristics — a root-layer mapping: "Match between system and real world" violations almost always root in the conceptual model, not the surface. "User control and freedom" is an interaction structure decision. Patching these at the surface treats symptoms, not causes.
OOUX对象失败模式（Sophia Prater）：
  • 变形者（Shapeshifter）——同一对象在不同场景下形态差异显著。表层修复：统一对象处理方式。若模型未明确定义对象则需深层修复。
  • 伪装者（Masked）——不同类型的对象外观相同。表层修复：采用差异化视觉处理。若模型未区分它们则需深层修复。
  • 破碎者（Broken）——对象的数据和操作分散在多个屏幕中，无交叉链接。属于交互结构问题 → 
    /layers-interaction-flow
    。
  • 孤立者（Isolated）——对象存在但与其他对象无可见关联。属于Conceptual model问题 → 
    /layers-conceptual-model
    。
尼尔森启发式原则——根层映射： “系统与现实世界匹配”的违规问题几乎总是源于Conceptual model，而非表层。“用户控制与自由”是交互结构决策。在表层修补这些问题只是治标不治本。

Capturing work

记录工作

At the start of any design session, ask where to save outputs:
"Where should I capture the work from this session? The recommended setup is a Markdown file in your project — diagrams are written as embedded Mermaid and render natively in VSCode with the Markdown Preview Mermaid Support extension. Alternatives:
  • Notion — if you have the Notion MCP connected
  • Just in the conversation — no file needed"
Save the session summary to the chosen destination at the end.
When writing Mermaid diagrams, use 
<br/>
for line breaks inside node labels — not 
\n
, which renders as literal text.
在任何设计会话开始时，询问保存产出的位置：
“我应该在哪里记录本次会话的工作内容？推荐的设置是项目中的Markdown文件——图表以嵌入的Mermaid代码编写，在VSCode中安装Markdown Preview Mermaid Support扩展后可原生渲染。替代方案：
  • Notion——若已连接Notion MCP
  • 仅在对话中记录——无需文件”
会话结束时将总结保存到选定的位置。
编写Mermaid图表时，节点标签内使用
<br/>
换行——不要用
\n
，它会被渲染为文本字面量。

Where to start

从何处着手

  • Not sure where to focus? → 
    /layers-orient
    — rapid diagnostic across all seven layers
  • Know which layer you're at? → jump directly to that skill
Skills: 
/layers-observed-behaviour
· 
/layers-domain
· 
/layers-user-needs
· 
/layers-product-strategy
· 
/layers-conceptual-model
· 
/layers-interaction-flow
· 
/layers-surface
  • 不确定重点？ → 
    /layers-orient
    ——快速诊断所有七个层级
  • 明确所在层级？ → 直接跳转至对应技能
技能：
/layers-observed-behaviour
· 
/layers-domain
· 
/layers-user-needs
· 
/layers-product-strategy
· 
/layers-conceptual-model
· 
/layers-interaction-flow
· 
/layers-surface