Back to Details

layers-conceptual-model

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/layers-conceptual-model

/layers-conceptual-model

Assumes 
/layers-intro
has been loaded for framework context.
The conceptual model is the most neglected load-bearing layer. It defines the objects the product recognises, their relationships, what states they can be in, and the vocabulary used for everything. It lives in the solution space: it is not a capture of users' existing mental models (which are contradictory and messy — that's the domain layer's job), but a deliberate design decision about how the product will model its domain.
What it is — and isn't:
  • A design decision that resolves the messy domain into a coherent, opinionated structure
  • Not a database schema — engineers make their own data decisions, but the gap between this model and what they build matters. A large, unexamined gap is both UX debt (users encounter a product that contradicts the model) and technical debt (the system is harder to evolve).
  • Not a wireframe or flow — no screens, no navigation. Those belong to the layers above.
  • Not neutral — every naming decision, every relationship boundary, every included or excluded object reflects a point of view.
Decisions this layer needs to make:
  • What objects will this product recognise, and what are their boundaries?
  • How do those objects relate to each other?
  • What can users do with each object?
  • What states can each object be in, and what transitions matter?
  • What is the product's vocabulary — one name per concept, chosen and committed to?
Methods:
MethodWhen
Noun foraging + OOUX (Sophia Prater)Default when you have research or domain notes to mine. Extracts objects from naturalistic language.
Semantic IxD / action grammar (Daniel Rosenberg)When you have many actions across many objects and want to audit verb consistency and precision.
Event storming — commands/policies phase (Brandolini)Domain has complex processes. Start from what happens, work backwards to objects involved.
Card sortingVocabulary is unclear or contested across users or teams.
DDD bounded context mappingMultiple user types use the same words differently — surfaces where the model has natural seams.
Walking the existing productRedesigning. The current UI reveals the implicit model — compare it to how users actually think.
Default: noun foraging and object definition.
Quality signals — what good looks like:
  • Every object is independently meaningful to the user — not a UI element, not a vague abstraction
  • Relationship roles are explicitly named when an object can play multiple roles
  • Attributes that are really relationships have been challenged and converted
  • No speculative additions — every object, attribute, and relationship traces to a user need
  • State transitions are defined for objects whose status materially changes what users can do
  • Temporal decisions are addressed: deletion semantics, relationship temporality, history
  • Ubiquitous language is established: one name per concept, one concept per name
假设已加载
/layers-intro
以了解框架背景。
概念模型是最容易被忽视的核心支撑层。它定义了产品可识别的对象、对象间的关系、对象可处于的状态，以及用于所有事物的词汇。它属于解决方案空间：它不是对用户现有心智模型的捕捉（用户心智模型往往矛盾且杂乱——这是领域层的工作），而是关于产品如何建模其领域的刻意设计决策。
它是什么——以及不是什么：
  • 一项设计决策，将杂乱的领域梳理为连贯、有明确立场的结构
  • 不是数据库 schema——工程师会做出自己的数据决策，但该模型与实际实现之间的差异至关重要。未经审视的巨大差异既是UX债务（用户会遇到与模型矛盾的产品）也是技术债务（系统更难演进）
  • 不是线框图或流程——不涉及界面、导航，这些属于上层层级
  • 并非中立——每个命名决策、每个关系边界、每个包含或排除的对象都反映了特定立场
该层级需要做出的决策：
  • 产品将识别哪些对象，以及这些对象的边界是什么？
  • 这些对象之间如何关联？
  • 用户可以对每个对象执行哪些操作？
  • 每个对象可处于哪些状态，哪些状态转换是重要的？
  • 产品的词汇体系是什么——每个概念对应一个选定并确定的名称？
方法：
方法适用场景
Noun foraging + OOUX（Sophia Prater）当你有研究或领域笔记可以挖掘时的默认方法。从自然语言中提取对象。
Semantic IxD / action grammar（Daniel Rosenberg）当你有跨多个对象的大量操作，且需要审核动词的一致性和精准性时。
Event storming — commands/policies phase（Brandolini）领域存在复杂流程时。从发生的事件入手，反向推导涉及的对象。
卡片分类词汇在用户或团队间不清晰或存在争议时。
DDD bounded context mapping不同用户群体对同一词汇有不同理解时——可发现模型的自然边界。
梳理现有产品进行重设计时。当前UI会暴露隐含模型——将其与用户实际认知进行对比。
默认方法：名词挖掘与对象定义。
质量信号——优秀模型的特征：
  • 每个对象对用户都有独立意义——不是UI元素，也不是模糊的抽象概念
  • 当一个对象可扮演多个角色时，关系角色会被明确命名
  • 本质是关系的属性已被识别并转换为关系
  • 无推测性内容——每个对象、属性和关系都可追溯到用户需求
  • 对状态会实质性影响用户操作的对象，已定义状态转换规则
  • 已处理时间相关决策：删除语义、关系时效性、历史记录
  • 建立了统一语言：一个概念对应一个名称，一个名称对应一个概念

Guided session

引导式会话

Tell me what product or feature you're defining a model for, or say "guide me" to start noun foraging and object definition.
Ask: "Where should I capture the work from this session?" (see 
/layers-intro
for options)
Check what the designer has from the problem space — domain notes, research, user needs. If nothing: proceed but flag that a model built without domain knowledge often reflects assumptions more than users' reality.
If redesigning: "Describe the current model, even informally — what implicit model does the existing product have?"
Phase 1 — Frame the scope
  1. What product or feature are we defining a conceptual model for?
  2. What's the core job users are trying to do with it?
  3. What material are you working from?
Phase 2 — Discover objects
From research or domain notes: Extract every noun — things, people, roles, documents, places, states, concepts, events. Cast wide; don't filter yet. Present the raw list, then ask: missing nouns? Same things with different names?
From an existing product: Walk it together. "What is a user looking at here? What is this thing called?"
From first principles: "If a user could reach in and hand something to a colleague, what would they hand?"
Sort into:
  • Objects — things that persist, have their own attributes, and matter to the user in their own right
  • Attributes — properties that describe an object, not objects themselves
  • Set aside — UI elements, vague abstractions, actions dressed as nouns
A true object must be independently meaningful to the user, not just a property of something else.
Phase 3 — Define each object
Work through each core object:
Object: [Name]
What it is: [one sentence from the user's perspective]
Attributes: [properties a user knows or cares about]
Relationships: [connections to other objects — cardinality and role names]
Actions (CTAs): [what a user can do to or with this object]
Four discipline checks:
  1. Relationship roles: When a relationship connects to an object that can play multiple roles (e.g. a User who is both referrer and referred), name the role explicitly: "belongs to one User (as referrer)" not "belongs to one User."
  2. Attributes that are really relationships: If an attribute is just the name or ID of another object in the model, it's a relationship — model it, don't duplicate it as an attribute.
  3. No speculative additions: Don't add attributes, relationships, or actions not grounded in a stated user need. Scope creep at the conceptual model layer propagates through every layer above.
  4. Implementation vs. design decisions: When conversation drifts to how something is generated, stored, or computed — redirect: "How it's generated is engineering. What matters here: can a user change this? What happens to things that already referenced it?"
  5. Verb precision: For each action, ask whether the verb tells the user what they'll end up with or what real-world operation they're performing. "Enter a PIN" fails because it implies the PIN already exists — "Create" is precise. More critically: check whether a generic verb (Edit, Delete, Update) is hiding operations with meaningfully different real-world consequences. "Edit address" conflates correcting a typo with recording a house move — two operations where one preserves history and one doesn't, requiring different system behaviour and different user intent. A deductive interface uses generic verbs and asks users to map their intent to them; an inductive interface names the real-world operation ("Register change of address") and preserves its meaning. When a generic verb could mean different things depending on what the user is actually trying to do, name the operations separately.
Phase 4 — Object map
Generate a relational object map: entities as nodes, relationships as labelled lines with cardinality markers. No fixed orientation — follow what makes the relationships most readable. In Mermaid: 
erDiagram
.
When presenting, explain cardinality: 
||
= exactly one, 
o{
= zero or many, 
|{
= one or many. The crow's foot is always on the "many" side. Relationship labels read in the direction declared (first entity → second entity).
Ask: "Does this reflect how you think about these things? Relationships missing, directions reversed, connections that shouldn't be there?"
Phase 5 — State transitions and temporal decisions
For each object where lifecycle or status matters: "What states can a [Object] be in? What moves it between states? What becomes impossible in each state?"
Generate a state diagram: states as nodes, transitions as labelled arrows, with a clear start state. Top-to-bottom or left-to-right depending on the number of states. In Mermaid: 
stateDiagram-v2
.
Also probe temporal decisions (from 
/layers-intro
): intermediate action states, read model lag, relationship temporality, deletion semantics, history. For implementation-entangled questions, don't force a premature answer — articulate the user experience requirement and flag as a named open question for an engineering conversation.
Phase 6 — Ubiquitous language
The ubiquitous language covers both nouns (objects, attributes) and verbs (actions). The same principle applies to both: one word per concept, one concept per word.
Nouns: List every chosen object and attribute name. For any noun with synonyms or naming conflicts:
Term: [chosen name]
Rejected alternatives: [other names that appeared]
Decision: [why this term was chosen]
Verbs — action vocabulary: Compile all action verbs across all objects. Apply two tests:
Synonym check: Are multiple verbs being used for the same operation? "Create" and "Add" for the same action type should be consolidated. Minimising the verb vocabulary reduces what users have to learn — the same verb working identically across all objects (like cut/copy/paste) means users learn once and transfer everywhere. Every synonym is a new thing to memorise.
Flattening check: The opposite risk — one verb covering operations that are genuinely different. "Edit address" sounds simple until you realise it conflates two things: correcting a typo (overwrite is fine) and recording a house move (which should create a new record and preserve the old one). The domain treats these differently; the interface shouldn't hide that. For each generic CRUD verb (Edit, Delete, Update, Create), ask: could this cover operations with different real-world consequences — different history implications, different downstream effects, different things the user is actually trying to accomplish? If so, give them separate names. "Register change of address" and "Correct address" are not verbose — they're precise.
Verb: [chosen action name]
Applies to: [which objects]
Rejected alternatives: [other verbs considered]
Decision: [why this verb; what real-world operation it names]
"This is your product's ubiquitous language. Use these terms consistently — in the UI, in help text, in API names, in internal conversation. Every inconsistency between this model and the surface creates cognitive load for users."
告诉我你正在为哪个产品或功能定义模型，或者说"guide me"以启动名词挖掘和对象定义流程。
可提问："我应该在哪里记录本次会话的成果？"（详见
/layers-intro
中的选项）
确认设计师是否有问题空间的相关资料——领域笔记、研究成果、用户需求。如果没有：继续流程，但需指出，缺乏领域知识构建的模型往往更多反映假设而非用户真实情况。
如果是重设计："描述当前的模型，即使是非正式的——现有产品隐含的模型是什么？"
阶段1——界定范围
  1. 我们正在为哪个产品或功能定义概念模型？
  2. 用户使用它的核心目标是什么？
  3. 你手头有哪些可用资料？
阶段2——发现对象
*从研究或领域笔记中：*提取所有名词——事物、人物、角色、文档、地点、状态、概念、事件。广泛收集，暂不筛选。展示原始列表，然后询问：是否遗漏名词？是否有同一事物的不同名称？
从现有产品中：共同梳理产品。"用户在这里看到的是什么？这个东西叫什么？"
从第一性原理出发："如果用户可以伸手把某个东西递给同事，他们会递什么？"
将收集到的内容分类：
  • 对象——持续存在、有自身属性、对用户有独立意义的事物
  • 属性——描述对象的特征，而非对象本身
  • 暂存——UI元素、模糊抽象概念、伪装成名词的操作
真正的对象必须对用户有独立意义，而不仅仅是其他事物的属性。
阶段3——定义每个对象
逐个梳理核心对象：
Object: [名称]
What it is: [从用户视角出发的一句话描述]
Attributes: [用户知晓或关心的属性]
Relationships: [与其他对象的关联——基数和角色名称]
Actions (CTAs): [用户可对该对象执行的操作]
四项准则检查：
  1. *关系角色：*当关联的对象可扮演多个角色时（例如，同时作为推荐者和被推荐者的User），需明确命名角色："属于一个User（作为推荐者）"而非"属于一个User"。
  2. *本质是关系的属性：*如果某个属性只是模型中另一个对象的名称或ID，那它属于关系——应建模为关系，而非重复作为属性。
  3. *无推测性添加：*不要添加未基于明确用户需求的属性、关系或操作。概念模型层的范围蔓延会传导至所有上层层级。
  4. *实现决策vs设计决策：*当讨论偏离到事物的生成、存储或计算方式时——及时引导："生成方式属于工程范畴。这里需要关注的是：用户能否修改它？已引用它的事物会发生什么？"
  5. *动词精准性：*针对每个操作，询问动词是否能告知用户最终结果或实际执行的现实操作。"Enter a PIN"不够精准，因为它暗示PIN已存在——"Create"才是准确的。更关键的是：检查通用动词（Edit、Delete、Update）是否掩盖了具有不同现实影响的操作。"Edit address"混淆了纠正拼写错误和记录搬家这两种操作——前者可覆盖记录，后者需要保留历史，这需要不同的系统行为和用户意图。演绎式界面使用通用动词，要求用户将自身意图映射到动词上；归纳式界面则命名现实操作（"Register change of address"）并保留其含义。当通用动词可能因用户实际意图不同而有不同含义时，应为操作单独命名。"Register change of address"和"Correct address"并非冗余——它们是精准的。
阶段4——对象映射
生成关系对象图：实体作为节点，关系作为带有基数标记的带标签连线。无固定方向——以最易理解关系的方式呈现。使用Mermaid语法：
erDiagram
。
展示时解释基数：
||
= 恰好一个，
o{
= 零个或多个，
|{
= 一个或多个。乌鸦脚标记始终在“多”的一侧。关系标签按声明方向读取（第一个实体→第二个实体）。
询问："这是否符合你对这些事物的认知？是否缺少关系、方向颠倒或存在不应有的关联？"
阶段5——状态转换与时间相关决策
针对生命周期或状态至关重要的每个对象："[对象]可处于哪些状态？是什么触发状态转换？每个状态下哪些操作是不可行的？"
生成状态图：状态作为节点，转换作为带标签的箭头，明确起始状态。根据状态数量选择从上到下或从左到右布局。使用Mermaid语法：
stateDiagram-v2
。
同时探讨时间相关决策（来自
/layers-intro
）：中间操作状态、读取模型延迟、关系时效性、删除语义、历史记录。对于与实现高度关联的问题，不要强迫过早给出答案——明确用户体验需求，并标记为待与工程师讨论的公开问题。
阶段6——统一语言
统一语言涵盖名词（对象、属性）和动词（操作）。两者遵循相同原则：一个概念对应一个词汇，一个词汇对应一个概念。
**名词：**列出所有选定的对象和属性名称。对于存在同义词或命名冲突的名词：
Term: [选定名称]
Rejected alternatives: [出现过的其他名称]
Decision: [选择该术语的原因]
**动词——操作词汇：**整理所有对象的操作动词。应用两项测试：
*同义词检查：*是否有多个动词用于同一操作？例如，同一类操作同时使用"Create"和"Add"应合并。减少动词词汇量可降低用户学习成本——同一动词在所有对象上的行为一致（如剪切/复制/粘贴）意味着用户只需学习一次即可在所有场景复用。每个同义词都是需要记忆的新内容。
*扁平化检查：*相反的风险——一个动词涵盖了真正不同的操作。"Edit address"看似简单，但实际上混淆了两种操作：纠正拼写错误（可覆盖）和记录搬家（应创建新记录并保留旧记录）。领域将这些视为不同操作，界面不应掩盖这一点。针对每个通用CRUD动词（Edit、Delete、Update、Create），询问：它是否可能涵盖具有不同现实影响的操作——不同的历史记录影响、不同的下游效果、不同的用户实际目标？如果是，应为它们单独命名。"Register change of address"和"Correct address"并非冗长——它们是精准的。
Verb: [选定的操作名称]
Applies to: [适用的对象]
Rejected alternatives: [考虑过的其他动词]
Decision: [选择该动词的原因；它所指代的现实操作]
"这是你的产品统一语言。请在UI、帮助文本、API名称和内部沟通中始终使用这些术语。该模型与产品界面之间的任何不一致都会增加用户的认知负担。"

Completion

交付成果

Produce:
  1. Object definitions — attributes, relationships, and actions
  2. Object map — 
    erDiagram
  3. State transition diagrams — for objects with meaningful lifecycles
  4. Ubiquitous language — chosen nouns and verbs with resolved conflicts and decisions
  5. Open questions — deferred decisions, objects that felt thin, anything flagged but unresolved
Close with: "The conceptual model defines what exists in this product. Next: design how users interact with those objects. Run 
/layers-interaction-flow
."
If domain work hasn't been done: "This model was built without domain research — it's a hypothesis. Plan to revisit it once you have evidence."
产出：
  1. 对象定义——属性、关系和操作
  2. 对象图——
    erDiagram
  3. 状态转换图——针对具有重要生命周期的对象
  4. 统一语言——已解决冲突的选定名词和动词及决策依据
  5. 公开问题——待决策事项、不够清晰的对象、所有标记但未解决的内容
收尾："概念模型定义了该产品中存在的事物。下一步：设计用户与这些对象的交互方式。运行
/layers-interaction-flow
。"
如果未开展领域工作："该模型是在缺乏领域研究的情况下构建的——它只是一个假设。计划在获得相关证据后重新审视它。"