相信大多数产品同学都听过“产品信息结构”这个词，并经常在产品设计的时候需要交付产品信息结构图，但有多少同学真正了解了，恐怕不好说。如果你对产品信息结构仍存在疑惑，希望这篇文章能帮助你找到答案。当然我所说的也可能不是全对，如果有错的地方，欢迎交流。
个人对产品信息结构的觉悟过程
开始接触到“产品信息结构”这个词，如果没记错，是在产品经理大牛们写的PRD规范里面看到的，后来断断续续也有看到别的产品经理写的文章或者书籍里面有提到，不过这些文章都只是范范举了个例子说明了一下，当时看的时候以为自己明白了，觉得信息结构应该就是页面上字段的罗列。
后来有一次参加产品分享会，分享人提到一个问题，信息结构到底是由开发定还是产品定，结论当然是由产品定，他当时讲了由产品定的原因，我听了一知半解，以为信息结构应该就是开发的表结构。
真正对信息结构完全理解是在后来实际做项目的过程中，通过一个个项目的历练，自己才对产品信息结构不断地有了新的觉悟。
什么是产品信息结构
产品信息结构是产品设计完成后从产品设计中抽象出来的产品所需信息的整合，它是支持产品设计的底层逻辑，产品设计所需的信息都由它提供支持。
上述文字可能讲得有点抽象，可以这样理解：产品信息结构是建筑房子的必备原材料和基础架构，有了这些，我们想把房子设计方的还是圆的都可以。
产品信息结构有什么作用
对产品经理而言：产品信息结构可以帮助产品经理自己梳理产品的信息组成甚至是内在逻辑。
对开发而言：产品信息结构可以帮助开发更好地理解产品设计，并对开发着手设计数据库有指导性作用。
可以延用上文中所提到的例子，建筑设计师在房子开工前需要把建筑房子所需的原材料和基础架构梳理出来，以再次检视自己设计得是否合理，并把它交给建筑工人，建筑工人由此便有了开工的依据。
产品信息结构包括哪些信息
抽象出的所有信息集
从已确定的产品设计中将产品所需的所有信息抽象提取，并根据具体业务归类，这个过程中最需要注意的是信息提取不要遗漏或者重复。
信息与信息之间关系
信息与信息之间的一对一（1:1）、一对多（1：N）、多对多（N：M）关系需要标识清楚：
一对一（1:1）—— 如：一个用户只能绑定一个手机号（通常1：1关系无需特殊标注）；
一对多（1：N）—— 如：一个用户存在多个好友；
多对多（N：M）—— 如：一个商品类目（女装）可能存在多种规格（颜色、尺码），一种规格（颜色）也可能对应多种商品类目（女装、鞋）。
同一信息被处理为不同文案的标识
页面上多处使用同一个信息，但是文案不同的，需标识明确，比如：同一个时间，在A页面，被称之为“采购时间”，在B页面，被称之为“下单时间”，它们可能指的同一个时间，如果不标识清楚，开发就可能对此产生疑惑。
产品信息结构等于开发的表结构吗
产品信息结构仅会对开发的表结构有指导性作用，但不完全对等，简单点讲，就是产品所需的信息，开发全能提供即可，开发实际的表结构可能比产品信息结构要细，要全。实际开发过程中，开发设计完成表结构后也需要喊上产品经理一起评审，以防产品经理因为不了解实际的表结构而漏考虑部分逻辑的问题产生。
举个例子
光说理论可能很多人还是不理解，以微信为例，我列出了微信的部分信息信息结构：我的个人信息、我的地址、我的好友，如下图所示：
我的个人信息
我们在微信app中看到所有涉及用户基本信息的地方（个人信息、更多个人信息、好友信息）都可以抽象为“我的个人信息”，开发的数据库也会有这样一张表，用来储存用户个人信息，微信每新增一个用户，这个表里面就会多一行数据，而页面上所有涉及个人信息的地方都会从这个表取值。
我的地址
可能你会好奇为什么将用户地址从个人信息中独立出来，因为一个用户可能对应多个地址，分开罗列并标识其中的关系方便开发正确理解其中的关系，不会建错表结构，这样开发就会将用户地址独立成一张表，保证一个用户多个地址的关系成立。试想如果我们把个人地址跟个人信息罗列在一起，并且开发也不知道有1对N的关系存在，那么开发就会将用户地址与用户个人其他信息保存在一张表，一个用户便只能添加一个地址，满足不了一个用户添加多个地址的场景，最后导致返工，造成开发成本增加。
我的好友
好友备注、好友标签、好友添加来源等信息是属于我的好友的相关信息，与用户个人信息不同，需要单独归类，对于开发而言，用户的好友信息也会单独存成一张表，用户每新增一个好友，这个表也会新增一条数据。
最后
纸上得来终觉浅这句话是有它存在的道理的，看别人做跟自己做得到的感悟会不一样，大家如果在实践中有其他感悟，欢迎一起交流。
作者：青柠，微信公众号：一只进化中的产品汪（pm_move_forward），欢迎关注