邮件订阅

概念模型设计

概念模型 ｜ ｜

TL;DR

概念模型是产品设计中会用到的一种图形工具，通过图形来描述产品作为系统会出现哪些概念以及这些概念之间的联系。它可以帮助产品经理了解产品的未来，制定产品规划，也可以帮助设计师来设计网站的信息架构，对于工程师来说，概念设计实际上和数据库设计以及声明式编程的理念也很类似，也可以作为参考。

这个世界上的事物主要可以概括为：「概念」和「关系」。

概念是一种非常抽象的存在，它只存在于人的脑海中，例如「人」就是一个概念，你不知指着这个世界上的某个东西说它就是「人」，这里的是准确来说是 equal（等同于）的意思，而非 is，就像你和我都是人，但并不等同于「人」这个概念，而是由「人」这个概念的一个实体（Entity），并非所有的实体都有其物理存在，例如一个 PNG 的图片文件，它在这个世界上是没有物流形态，但我们依然认为它是一个实体。

关系也是一种虚拟的存在，例如我们说郭麒麟是郭德纲的儿子，你也不能指着世界上的某个东西说这就是父子关系。关系在实体与实体之间建立起连接，让原本独立的个体形成了各种组织，并最终形成了网络。就如同互联网一样，网络将一台台设备连接起来，形成一张巨大的互联网（Internet）。

与之类似的是物理学的标准模型（Standard Model），也就是描述目前已知构成物质的基本粒子和三种基本力的模型。在这个模型中，科学家将基本粒子分成两种：

  1. 费米子：是构成物质的基本粒子；
  2. 波色子：传递力的基本粒子，使得费米子能够连接在一起并组成物质；

费米子就像是概念，波色子是关系，这两者相互结合，共同构成了我们所在的宇宙。似乎软件开发也是如此，要么我们是在声明概念（class, type, interface），要么是在声明实体（var, let, const），要么是在声明关系（function, def）。

产品设计也是一样，当我们说到产品设计就不得不说用户体验，设计师们把用户体验拆分成了可寻性（Findability）、可访问性（Accessibility）、可用性（Usability）等等，但归根结底，软件的架构如果与用户的认知相一致，那么这些问题都不存在了。但是难点在于每个人对世界的认知都不完全相同，人们对世界的认知我们称之为「世界观」。虽然人们最终形成的世界观各不相同，但是他们形成世界观的过程都依赖于「隐喻」。回忆下当我们学习新事物的时候，总是把他比作另一个我们熟知的事物，虽然两种有所不同，但我们总能从中找出相似，并通过旧概念来理解新概念。软件设计的核心，也恰恰是基于「隐喻」的。软件，本身也是通过数字化的方式来反应现实世界，虽然这种反应并不完全一致，但对于用户来说他们是类似的。例如网络支付和现金支付，从技术上来说千差万别，对于用户来说，都是我的钱通过某种方式（现金/转账）去到了另外一个人的手里，对于用户来说只是方法变了，大体的逻辑是不变的，至于技术如何实现，用户不关心。软件设计中如何将用户的心智模型通过图形化的方法表现出来，就要提到我们今天要聊的「概念模型」图了。

在我从业初期，对概念模型有过一些探索，网络上对此的描述并不算太多，所以基本上都是靠自己理解，现在对概念模型的理解有了更深的理解，也经常应用在业务当中，感觉有必要在更新一版了。概念模型实际上是从用户的角度描述产品，软件将现实中的问题通过计算机来解决，但用户在使用软件的时候其心智模型还是和现实中类似，所以软件设计的时候这些概念如果能够尽可能的贴合用户的心智模型，那么对于用户来说上手成本就会很低，他可以预期每一步的操作之后应该发生什么。

我本打算用「交易模型」来介绍什么是概念模型，不过交易模型过于抽象，难以讲清楚和产品设计的关系，因此本文假设我们要设计一个支付类的产品，来介绍如何通过概念模型图来设计产品架构和产品可能的方向。在开始前我还是想用「交易模型」来介绍下「概念模型图」中都有哪些图例。

一个简单的交易模型图就类似于这样，概念模型图中有这样几个元素：

  1. 概念：就是一个抽象的概念，抽象是相对于元素 3 的实体来说，概念本身并不存在于这个世界，是人类主观的，也就是说你不能指着这世界上的某一个物体说这个东西就是概念。例如「人」是一个概念，你我都是人这个概念下的实体。
  2. 子概念 ：本身也是一个概念，只不过它是某个更大概念的子集，例如「消费者」是「人」这个概念下的子概念。只有满足某种特定条件的人才能被称之为消费者，从字面上来理解就是有了消费这歌动作的人才能称之为消费者。一个人如果所有的生活所需都可以自给自足那他就不是消费者。或者说子概念就是处于特定状态下的概念。
  3. 实体: 就是具体的事物，实体也可能是虚拟的，例如某个具体的订单，订单是一个实体，但它并不存在于这个世界上。他可能存在于某个数据库中。
  4. 关系: 用于描述概念与概念直接的关系，这种关系通常是由「动作」产生。动作在大多数情况下是由「人」发起的，几乎所有的概念中都会有「人」的参与，人的种种「动作」会导致其他概念的状态发生变化，从而导致一个概念/子概念的诞生、更新、消除（增删改）。
  5. 属性: 属性就是概念中存在的属性，对应数据库设计来说，概念就像是一张表，属性就是这张表里面的字段（field）。前面提到子概念是处于某种状态的概念，举例来说，假设「人」这个概念中有个字段是「消费记录」，当这个人发生消费行为的时候就会增加一条记录，那么「消费者」这个子概念指的就是消费记录不为空的人。

再结合图中的概念来理解，通常概念用实心的圆形元素来表示，子概念则用相近颜色的虚线框的圆形来表示，实体则是用长方形表示，动作则使用菱形表示。属性我用的比较少，经常是在 Google Sheet 里面记录，如果图表中需要用到，就用矩形表示。

表示关系的时候会用到几种线条：

  1. 虚线，表示概念与子概念的关系；
  2. 带箭头的实线：箭头发出的元素为动作的发起者，通常会指向一个动作，经由这个会产生同样是带箭头的实线则是指向接受动作的元素。
  3. 带箭头的虚线：经由动作之后也可能会产生额外的带箭头的虚线，箭头指向因该动作而受到影响的元素（增删改）

如果你了解数据库设计中常用的 ER（Entity-Relationship）图的话，那么概念模型图看起来可能就比较熟悉，两者实际上都是在描述概念/实体之间的关系，区别在于概念模型更倾向于描述用户的心智模型，而 ER 图则更倾向于描述软件开发中的数据模型。

从概念出发

现在让我们来设计一个支付工具，概念设计通常用在产品设计的最早期，这也是它被称之为概念模型的原因，此时的产品可能只是一个想法，至于是 Web 还是原生应用这些都不确定，甚至产品名称都不确定，我们只知道大概是要解决支付场景中的某个问题，同样技术上是否有难题，是否技术上可行也通通先不考虑，概念模型应用在最早期的时候实际上是在帮助我们理清产品要解决的这个问题到底是什么。

通常我们都是从概念出发，几乎所有的产品最核心的概念都是「人」，直接写「人」的话就没有意思了，既然是描述用户的心智模型，那么这个「概念」应该是目标人群，例如学生、男性白领、家庭主妇等等，无需太过详细，用户画像（Persona）距此还很远。如果你的产品就是类似于微信这样的面向大众的软件，那么写「人」也没有什么问题。所以我们先从人开始。

有「概念」就会有一个对应的「实体」（熟练以后你可以不管实体），所以我们假设有一个人的名字叫「张三」。毫无疑问「张三」是一个「人」，所以通过虚线来将人和张三连接起来。既然是做支付，那也不可避免的会涉及到「钱」，对于张三来说，钱就是「资产」，于是我们再加上「钱」和「资产」这两个概念。

接下来有好几个方向可以深入，我们可以继续探讨张三和资产的关系，例如张三和资产之间肯定存在一个实体叫做「张三的资产」，它连接了「张三」和「资产」；我们也可以探讨「资产」和「钱」的关系，例如「钱」是否也是一种资产，即「钱」是否是资产的子概念？不过我们无需在这个阶段就解决这些问题，让我们先把这些关系标记出来。

我觉得「货币」可能是一个比「钱」更好的概念，「钱」的概念过于宽泛，例如冥币算不是算是钱？显然在这里的场景不是，你可以注明说这里的「钱」就是指「法定货币」，但既然如此那何不直接改用「货币」这个概念。这样一来我们也不用去纠结钱和资产的关系了，货币显然不是一种资产，但是货币和资产这两个概念则可以组合成「货币资产」这个子概念；同样资产和张三也有一个子概念「张三的资产」，再继续延伸，张三的资产中也可以有一部份是货币资产，于是我们又多了一个子概念叫「张三的货币资产」。

到此为止，我们最关键的「支付」活动还没有出现。要完成一次支付，只有一个张三肯定是不行的，左手倒右手的这种行为我们不能将其称之为「支付」，支付必须是一个人支付给另外一个人。你会发现我们其实对「支付」这个行为做了定义，即付款人和收款人不能是同一个人。你可能也发现我们其实又引入了两个概念「付款人」和「收款人」。这里我们有必要对这两个概念下定义，为什么上面那些概念不用，有当然最好，介于上面几个概念非常普遍，如果大家的认知相一致，就无需定义了。

我们定义「付款人」是发起支付的人；「收款人」是接收支付的人。那么张三算是付款人还是收款人？这取决于我们再讨论那一次支付活动，张三在昨天的支付中可以是付款人，但是在今天的活动中可能是收款人，所以「付款人」和「收款人」的概念是动态的，取决于具体的支付活动。这里我们又引入了一个新的概念「支付活动」。我们先看看这些关系。

要发起「支付活动」我们必须有请另外一个人「李四」加入。显然李四也是人，所以我们用虚线连接「李四」和「人」。同时，我们也引入了「支付活动」这个概念，并且其对应的实例是「支付活动 A」。「支付活动 A」由「张三」发起，转账给「李四」，所以张三是付款人而李四是收款人。

你可能会提出，有没有可能李四发起了支付活动，但是是张三付钱的，例如张三钱了李四一笔钱，李四发起了一次还款请求让张三还钱，听起来也比较合理。但是我们引入了一个新的概念叫「还款请求」，在这个概念中，发起「还款请求」的人是「收款人」，接收到「还款请求」的人是「付款人」，引入这个概念的同时我们还修改了「付款人」和「收款人」的定义。

当然还有另一种方式就是我们将「付款人」的定义修改支付「支付活动」的人；而「收款人」定义为从「支付活动」中收到钱的人，听起来也比较合理。但是如果作为软件，或者提供支付的平台方要从「支付活动」中抽佣，那么「从支付活动中收到钱的人」这个定义就不够准确了。

让我们把支付活动改个名字叫「订单」吧，虽然不是做电商，但是这两个概念确实有相似之处，所以借来用一下。实际上概念模型中的名称也很重要，最贴近现实最能反映用户的心智模型，但有时候不得不用一些新的名词，那么就选用户比较熟悉也比较接近的，最不行就是创造一个新的概念，然后教用户理解这个概念（这并非总是坏事，有时候可以纠正用户的错误认知，反而对用户有帮助）。

将「支付活动」改名为「订单」之后，我们同时引入了「未付款订单」「已付款订单」「未收款订单」和「已收款订单」这几个子概念，之所以要引入是因为在前面的定义中，我们将「付款人」和「收款人」的概念和「支付」这个行为绑定了，同时「支付」这个行为会影响「订单」的状态，而子概念实际上就是状态发生变化的概念，同时「付款人」和「收款人」与不同状态的订单的关系也不同，因此有必要将这些子概念都引入。

图中没有引入「平台」这个概念，只是因为会太复杂，实际上作为系统本身也是一个经常会出现的概念，上图中从「已付款订单」到「未收款订单」的状态变化就是由「平台」这个隐藏概念操作的，同时平台也可以「驳回」订单，那么还需要引入「已驳回订单」的子概念。

到这里，基本上概念模型的设计就是在不断的重复上面的步骤：

  1. 列出最基本的概念；
  2. 定义概念；
  3. 找出概念之间的关系（动作）；
  4. 通常关系总是发生在子概念之间，审视是否需要引入新的子概念；
  5. 定义子概念；
  6. 找出概念之间的关系；
  7. …

不断重复这样的步骤，整个系统的概念和关系就如同一张网一样，不断地有新的概念涌现，不断地有新的关系被建立。听起来像是一个无尽的工程，事实上也确实如此，你当然也希望自己的产品可以无尽的延伸下去。只是随着产品的延伸，不可避免的会引入更多的概念，每引入一个概念相应的就需要引入的关系可能成指数级上升，不可能在一张图里面放下所有的概念、子概念以及关系。当系统足够复杂的时候，你需要一张图在描述主要概念之间的关系，在深入到每个概念当中，描述这个概念及其子概念，以及子概念某另外某一个概念的关系。

当你看最外层的那一张图的时候里面就只要最主要的概念，他们之间有着某种很宽泛的关系。看起来有点像是系统架构中的微服务或者中台，每个概念就是一个中台，提供了所有可能产生的关系。这也是我认为概念模型是一个很强大的工具，它其实将产品设计中的产品方向、信息架构设计、程序架构和开发都关联起来。所以你要问谁适合用概念模型图，我认为产品经理、设计师和开发都可以。

产品经理的概念模型

事实上产品经理就是那个创作概念模型的人，当中可能还有会信息架构师/交互设计师参与。对于产品经理来说，在指定产品方向的时候你首先得知道有哪些方向可以走。

回到我们的支付案例中，我可以对货币进行拓展，我们都知道有一种货币是虚拟货币，另一种就是法定货币；同时我们资产也可以延伸出虚拟资产，例如积分就是虚拟资产的一种；同时资产有可能是负数，这个时候就会产生债务，所以张三可能有自己的债务，李四可能也有，债务的产生是张三和王五借了钱，因此张三的债务就由此产生了。

概念和关系是无穷尽的，当我们做产品的时候不可能一次性把所有的东西全都做进去，这个时候就要做取舍。尤其是在 MVP 阶段，就尽可能的减少概念，能不引入的都不要引入，仅保留服务于最核心流程的概念，例如我们不考虑债务，也不考虑虚拟货币，但是要支付，就一定要有人、资产和订单，这个时候的资产可以等同于货币，虽然概念不同，但因为我们只有货币资产这种资产，所以就无需用两个概念了。图中蓝色的部分就可以成为产品在 MVP 需要完整的主要概念。

之后产品的延伸基本上就是在现有的概念中拓展子概念，即增加为现有的几个概念增加更多的关系（功能）；或者是引入权限的概念，也就是拓展业务方向，从转账做到借贷，从实体货币做到虚拟货币，甚至是其他的虚拟资产、或者元宇宙等。只要产品有足够的竞争力，就可以无限的扩展下去。

设计师的概念模型

概念模型最初其实是用来做网页的「信息架构设计」，所谓信息架构简单来说就是网站中的页面是如何组织的，对于电商网站或者公司的产品介绍页面这种注重内容而非功能的网站，网站的结构决定了用户能否更高效的找到自己想要的内容。

概念和子概念实际上就是在描述网页内容的类型，例如在电商网站中有个概念是「产品」，对应的就有一个「产品详情页」和「产品列表页」，产品同样有很多子概念，例如「服装产品」「电子产品」，或者「进口产品」「本地产品」等，这些子概念也都有各自对应的页面。。概念与概念之间的关系同样也描述了页面与页面或者页面与内容之间的关系。

例如张三和订单之间有一个子概念即「张三的订单」，无论我们做的是 App 还是 Web 也都会存在一个页面叫「我的订单」，那么在这个页面中需要呈现某个人的所有订单，订单按照状态有不同的类别，那么在页面中可能就需要使用 Tab 或者 Dropdown Box 来允许用户快速查找不同类型的订单（也就是改善可寻性）。

但是对于注重于功能的 App，概念设计虽然尤其一定的逻辑表述，但是不同于交互的流程图，概念模型中的「逻辑」更多是通过「定义」来描述的。即哪个子概念才能执行某个操作，而至于如何完成这些操作，概念模型并不能提供参考，正如其名，他只表述概念，而不表述具体的行为。这点很类似 RESTful API 的设计，每个 Endpoint 都对应一个资源（Resource），关系则是通过 POST, GET, PATCH, DELETE 等方法表述，而至于用户是通过何种方式，通过 UI 或者 Curl，或者 Postman 来发起的请求 API 都不关心。

工程师的概念模型

前面提到在数据设计中会用到 ER 图和概念模型非常类似，不仅仅是在数据设计中，实际在开发者，每个概念也对应着一个对象或者类型（Class，Type，Interface），这点类似于声明式编程（Declarative Programming），不关注执行过程，只关注关系和结果。

例如在 Swift 中我们可以这样表述人和订单之间的关系：

enum 订单状态 {
    case 未付款
    case 已付款
    case 未收款
    case 已收款
}

struct 订单 {
    let 发起人: 人;
    let 付款人: 人;
    let 收款人: 人;
    let 金额: Double;
    let 状态: 订单状态;

}

struct 人 {
    let 名字: String;
    private(set) var 订单列表: [订单] = []

    mutating func 发起订单(付款人: 人, 收款人: 人, 金额: Double) throws -> 订单 {
        // 发起人就是发起订单的人自己，状态永远是「未付款」
        let 新未付款订单 = 订单(
                                发起人: self,
                                付款人: 付款人,
                                收款人: 收款人,
                                金额: 金额,
                                状态: .未付款)
        订单列表.append(新未付款订单)
        return 新未付款订单
    }
}

在这里，订单和人都是一种数据类型，因为只有人（图例中的张三）可以发起订单，所以人就会拥有「发起订单」这个能力（function）。同时发起订单这个能力会创建一个新的未付款订单，在我们的定义中，未付款的订单就是状态等于「未付款」的订单，所以这个功能返回的订单的状态就一定是「未付款」的。

至于说创建订单可能要写数据库以及可能的报错问题等，这些都是过于细节的描述，不是概念模型所关注的。

概念模型的应用

对于产品经理来说，一个好的概念模型能够让我从更宏观的角度去理解这个产品未来可能有哪些发展，以及产品目前所处的阶段，用来制定下一个阶段的目标。而对于在团队内部分享这个产品愿景，概念模型也是一种很好的表现形式，每个人都很容易理解产品未来可能的形态。我会在这些场景中使用概念模型：

  1. 产品构思阶段： 这个阶段产品还只是脑海中的一个想法，我们从零开始去设计一个产品，最重要的是知道这个产品未来可能的形态。
  2. 产品规划： 这个阶段的产品已经在进行中了，作为产品经理需要去决定 MVP 的范围有多大；或者在产品持续的迭代中，下一次个版本的范围有多大。
  3. 产品架构设计： 前面提到概念模型对于设计产品的导航来说也非常重要，没有人希望每次新增一个新功能就需要重新调整产品的导航和结构。

产品导航的调整实际上是在调整用户已经养成的习惯和认知，好的概念模型可以让产品的架构从一开始就非常清晰。很早的时候我们设计一款手机 App 的时候就尝试过通过「概念模型来设计产品的导航」，尤其对于复杂的产品来说，这种方法非常好用。虽然说在 MVP 产品，通常不需要投入太多的精力在架构上，毕竟产品都还没有产品-市场契合（Product-Marke Fit），再好的架构也是无用。这里的架构更多是在说技术上的架构，但是产品的架构，或者用户的心智模型是需要从第一天就需要的，它关系到用户是否理解，在没有其他人的帮助下用户能否自主的使用产品，也是人们所说的 Product-Led Growth（PLG）的关键。

概念模型是一个非常强大的工具，因为它首先足够简单，只有寥寥几个元素来描述概念与概念之间的关系，这种理念却可以把产品设计中的各个环节都串联起来。同时它也是反应我们/用户如何理解世界的方式。概念模型并不是一个每天都得去看的模型，一个产品的延伸可能是以年为单位的事情，概念模型所描述的也是非常宏观的概念，当你在思考产品方向，整体的结构的时候会需要用的，到具体的细节的时候，就需要用的其他的工具了。

但概念模型也仅仅是一个工具，好的概念模型还需要结合对行业的理解，如果现在让我去设计一个航天飞机的导航系统我是根本无从下手的，因为我跟不理解这个系统，不理解当中都有哪些概念以及他们之间的关系。

或许你可能会问在如今产品迭代速度如此之快，Lean Startup 和 Agile 这种关注短期的假设来快速调整产品方向的方法似乎更实用。在我看来并不冲突，有一句话说「小心求证，大胆假设」，Lean Startup 或 Agile 的方法就是小心的验证产品所提出来的假设；而概念模型图就是大胆假设的来源。另一方面无论技术如何进步，一些最基本概念的关系是不会随着时间和技术的变化而变化的。例如案例中我们提到的付款人和收款人的概念，无论使用的是现金支付、银行转帐还是数字货币，这些基本的概念的定义和关系都没有发生变化，只是履行（fulfill）这个关系的方式发生了变化。技术改变了人与人沟通和建立联系的方式，但是沟通本身和保持联系的目的实则一直都没有变化，而概念模型就是描述这种不变的东西。