产品结构图视为同时展现产品信息和功能逻辑的综合图表，即产品原型的简化版本。它有助于快速调整和展示产品功能结构，降低产品经理的工作成本，并在需求评审等早期阶段作为产品原型的替代品使用。通过合理构建信息和功能的逻辑关系，产品结构图能有效支持产品设计和团队协作。
定义
相较于功能结构图和信息结构图，产品结构图的定义就很混乱和模糊了，为什么会出现这种情况呢？
最重要的原因是：对于产品结构图，产品从业人员这个群体自身都还没有达成共识啊。作者在网上搜了搜相关文章，对于产品结构图大家的主要理解有3种：
大部分产品人认为：产品结构图即产品功能结构图的简称，可能在产品没有强调信息结构的概念时，有部分PM开始简称产品功能结构图为产品结构图，之后便默认了这种称呼，当出现产品信息结构图后，概念就产生了混淆；
一部分产品人认为：产品结构图是综合展示产品信息和功能逻辑的图表；
少部分产品人认为：产品结构图就是产品信息架构图。
在这里，作者更认同第2种观念：
产品结构图是综合展示产品信息和功能逻辑的图表，简单说产品结构图就是产品原型的简化表达。它能够在前期的需求评审中或其他类似场景中作为产品原型的替代，因为产品结构图相较于产品原型，其实现成本低，能够快速对产品功能结构进行增、删、改操作，减少PM在这个过程中的实现成本。
产品结构图就是通过信息架构设计，将功能和信息以一种合理自然的逻辑，把功能结构图和信息结构图中的内容放入产品中的每一个页面的结果。
而现在许多PRD、竞品分析中提到的信息结构图、功能结构图其实大多数都是同时含有功能和信息元素的简化版产品结构图。如下图所示：
绘制产品结构图步骤
思考一级功能点
菜单层级的功能点。比如说商品管理，营销管理，这种大的业务模块。
思考二级功能点
一级功能点下面要具体实现的事情。比如商品管理需要增、删、改功能。二级功能点有着承上启下的作用，是一级功能点的细化，页面的总领。
思考每个功能点下的页面
如果是给开发看，从整体上讲述要做的功能点，列到上面一步已经可以了。但如果是写完结构图后，直接交给交互来画原型，下面的步骤就一定要做了。不然交互不知道有哪些页面，页面里面有哪些字段，分为以下几种情况：
- 一级下没有二级，即只有一个页面或小功能
- 一级下有二级，但二级也是只有一个页面，这时改成页面就可以了
- 一级下有二级，且二级会有多个页面组成，这时需要详细列出。
- 有时候多个功能点只需要一个页面就可以解决了，比如说活动的创建，都会有2个页面：新建页面，列表页面。但活动的上/下架可以在这2个页面里面包含。
如下图，把拼团具体的页面列出来，页面里面包含的重点功能也写上。
思考每个页面下面的字段
页面里面具体的字段写出来就会比较多了。先确定页面里面的结构，再根据不同的结构写具体的字段。比如列表页面一般是由2部分组成的：筛选和表格。可以先写表格里面的字段，再根据实际需要，提炼出需要筛选的字段。
举个上面营销模块，活动创建编辑相关的字段层级结构图：
思考页面/字段涉及的规则
页面可能会对应一些总规则，需要在设计页面结构时就先提出来，下面的字段都要符合这个规则。字段涉及的规则，交互类的尽量不要写，写重点的，比如说要调用其他模块，必须对此说明一下。还有一些按钮触发的规则，比较重要的可以写下来。比如说保存时校验是否活动有冲突。
比如拼团新增页面的一些规则，可以写上：
我们在自己写功能点的时候，最好都写到第5步，这样不管是自己画原型还是交互画原型，都会简单很多，那时可以把重点都放在交互上。但把结构图放到PRD文档中时，不要把整个都放上去，到功能点加页面总规则就可以了。因为那个时候主要目的是给开发测试介绍整体功能，就算和他们说到页面字段和字段规则，看过也就忘了，具体开发和测试时还是要看具体的原型页面及规则。
绘制产品结构图的建议
- 形容一个功能点时建议多采用“动词+名词”的语言描述形式，这种方式不仅信息传达更加准确而且可以避免读者不必要的困惑。
- 一个层级一个层级的结构，先思考一级功能点有哪些，再思考二级功能点有哪些。
- 可通过业务流程中所涉及到的功能需求去提炼出主功能模块，提炼完成后再通过业务流程走查一次，看是否有遗漏的主功能模块。
- 功能结构图中的颗粒程度刚开始的颗粒度一般比较大，可能仅涉及到某个功能模块，随着设计的不断推进，功能结构图的颗粒度会不断细化，最终可以拆分至某个具体的功能操作。
如何检验产品框架合理性？
这是一个反向审查的过程。我们从产品需求到流程图，再到结构图，很可能在这一漫长的过程中遗漏了一些重要的东西，或者写着写着偏离了目标。最后的审查，能让我们避开一些原则上的错误，减少后期的返工和优化。
可以从这几方面去看结构是否合理：
完整闭环
看一级功能点和二级功能点，是不是能够串起来？用户是否能完成一整个流程？这个流程中的痛点和需求我们是否已经解决了？
比如说拼团，我们有活动管理，商品管理，订单管理模块了，但没有统计模块。那用户如何评估活动效果呢？如何后续优化活动？
主要的模块我们一般不会遗漏，一些不影响主流程的功能很可能会遗漏，自己查不出来的话，可以团队讨论下。完整的闭环才是一个完整的功能。
结构清晰
看功能点和页面，以及页面规则之间的关系，是不是结构比较混乱？是不是页面上的字段不合逻辑？是不是页面间共用的字段对应不起来？是不是页面之间的规则相互冲突？
结构清晰指整个功能逻辑没有错误，且能清晰的表达出来。逻辑要符合用户行为习惯，符合产品原有逻辑。细到每个字段都有他的用处，放在正确的页面位置，没有多余，没有缺少。结构清晰能让团队间沟通起来更加的简单，开发时更加的顺畅，提升整体的效率。
有了功能框架，功能就已经完成了一半，这也是产品设计中最难的部分。有些产品经理可能不重视这一块，认为功能设计的重点是给出原型图，所以一上来就画原型，后面发现画不下去了，逻辑不通了，字段也不知道放什么，放哪里。但我们看到，当我们把结构图理完了，脑子里也已经有了页面的样子，还愁不好画吗？
没有回复内容