㈠ 产品入门，如何绘制产品功能结构图和产品信息结构图
下面是笔者通过实践和资料整理对这两个结构图进行定义区分，并辅以实际demo分析阐释：
一般在实际工作中，一个产品需求从创意、构想到最终输出给设计、开发，不一定会用到这两种图，视情况选择使用。如要有要求先输出产品方案时，还是建议绘制“产品功能结构图”和“产兄散品信息结构图”，方便直观地让开发人员了解该产品的架构，同时自己参照结构图绘制产品原型时也避免模块早尘仿和功能的遗漏。
一、产品功能结构图
作用 ：梳理产品架构功能点。
说明 ：我们绘制产品功能结构图一般是在原型绘制前，所以大多不以页面为模块去罗列，而是以功能划分模块，以产品的主要功能及其他围绕主要功能而展开的下级功能点进行罗列。
一般做竞品分析时会倒推已经成型的产品来练手，此时需要反复使用软件，列出其主要功能，涉及的功能细节需要不断测试得出。
在自己构想一个新的产品时，也需要大量使用同类或者有借鉴意义的产品，在绘制功能结构图的过陆纤程要结合过往或者同类产品经验罗列功能模块、细化功能点。
功能和信息的概念有时比较模糊，如果想要更清晰的让自己的表达更清晰可以采用“动词+名词”的形式对功能点命名，比如：登录/注册账号；查看/取消收藏等。
操作过程 ：
我们在绘制功能结构图之前，要先梳理主要功能逻辑，下面是笔者参照B站功能模块拆解的主要功能：
在主要功能的基础上添加下级功能和细节点，产品功能结构图就绘制出来啦！
如下图：
二、产品信息结构图
作用： 梳理系统页面的模块功能显示信息，是绘制原型的基础，信息结构图类似数据表结构设计，揭示了需要哪些数据，这些数据需要有怎样的元素组成，才能达到每个功能模块需要展现的内容表达。如果说功能结构图是产品的功能抽象，那么信息结构图则是产品的数据抽象。
说明： 产品信息结构图罗列了产品需要的信息字段，是在我们绘制原型前构想如何布局页面信息的依据。在C端产品中对产品信息页尤其重要，为避免原型绘制时遗漏，此时需要绘制产品信息结构图穷尽页面内容。信息结构图中同一个对象的信息出现在多个页面是非常常见的事情。
例如个人简历，在招聘官使用招聘网站时，姓名、性别、年龄、职位、工作时间等关键信息既会出现在候选人的列表页，也会出现在候选人的详情页，还会出现在搜索结果页等等。
操作过程 ：
结合功能点，对设想的功能进行主页面布局。
根据需求调研、竞品调研报告、结合自己的产品经验确定具体功能模块布局:
总结 ：
1.功能结构图，关键词是功能，是功能的结构化表达；
2.信息结构图，关键词是信息，是信息的结构化表达；
互动作的细节不用体现在产品功能结构图和产品信息架构图中，比如页面布局细节、交互手势、动画效果等，属于交互设计的范畴。
绘制产品结构图时，你就要想象这是你产品的最终形态，每个页面要有哪些功能和数据，类似于开发做的不同静态页面，展现在你面前的就是产品的雏形了。
㈡ 互联网的“产品结构图”应该如何绘制
这位兄弟想问的可能是信息架构，科普一下： （Information Architecture），简称IA，来源于早期IT软件开发的架构设计，现在互联网时代多用于对网站、产品在开发前的结构设计，能够给高层或产品经理带来最直观的未来既视感，也可提供给架构师们参考和进行下一步工作分解等。教程和图示网上一找一大堆，方法多种多样，因人、公司、业务而异，复杂程度参差不齐，不一定最专业的就是最适合你或你的团队的，所以无法给出具体教程，这里我简单介绍个小方法供参考： 1.确定你要做的产品的所有功能将所有功能一一列在纸上，确定产品的核心功能（这属于设计方法了，这里不铺开讲目标导向），并以核心功能为主，将每个功能要实现的目标和可能的业务逻辑大概罗列在下面。 2.确定产品的模块一个或多个功能可能会组成一个模块，便于架构师、设计师、开发工程师等几乎所有干系人理解，更便于用户使用，将功能用线条跟模块进行组合。 3.确定子模块或子功能某些大功能或大模块可能会由多个子功能\模块组成，将他们依次用线条连起来，需要注意是将主模块、子模块\功能依优先级或从属关系画成树状图。需要注意的是，某些子功能可能和其他模块进行交互，或多入口，或各种各样的业务流，没错，都把他们用线条连起来，无非就是换个颜色的线条（通常会带箭头）。可以用Mindmanager或OmniGraffle等，工具不限，ppt也可以做到。 4.大功告成接下来你就得到了你产品的第一版IA（之所以说第一版就是因为肯定要迭代）。 没错，就这么简单，这就是IA的制作方法，只是其中会涉及到很多设计方法论如目标导向，会涉及到用户使用场景，还有Taskflow、Pageflow等，这些都是扩展知识点。 另外最重要的一点，这个IA不是一次完成就ok了，应该是个闭环，每次的讨论、评审，或战略变更、业务变更，市场情况变化，产品经理和公司高管肯定会对产品做调整。 当然IA的制作方法多种多样，一定要结合自己公司业务特点、团队合作方式等，定制出最适合自己的方式，才能起到作用。 希望能帮到你。
㈢ 产品设计-(3)产品结构
基于前期的需求分析以及市场竞品分析等为依据，将各个需求点以某种逻辑系统化的组织起来所形成的立体结构。
基于该结构，可以顺利的引导用户行为或将各类信息进行顺畅的流转。
产品结构图是综合展示产品信息和功能逻辑的图表，简单说产品结构图就是一种将产品原型以机构化的方式展现的图表，结构内容也如同产品原型一样，从频道到页面，在细化页面功能和元素。产品结构图是产品经理设计原型之前的一种思路梳理的方式，通过产品结构图可以对产品结构一目了然，也方便思考。一般使用思维导图工具。
如：微信产品结构图
小结：我们做的产品结构的构建，就是把原本无序的各个需求点以某种结构的方式展现出来。产品结构图实际上就是一种结构化的产品原型。这样做的目的就是梳理产品结构逻辑，更清晰知道产品有几个频道，频道下面有没有子频道或者有多少页面，这些页面又有哪些功能模块，这些功能模块又有哪些元素。
1.人民了解产品的第一印象，结构是否清晰也代表着用户理解的难易度。
2.产品结构的稳固与否，也代表着在增加和减少功能模块时的难易程度。
微信的结构tab一直没有改变，结构比较稳固。
思考：我们应该以什么维度去设计产品的结构？用户需求？功能相关性？定位？战略？
《用户体验要素》讲解了几个典型的信息架构模型：层级结构、自认结构、矩阵结构、线性结构。
1.层级结构
书中描述：在层级结构中，节点与其他相关节点之间存在父级/子级的关系。子节点代表着更狭义的概念，从属于代表着更广义类别的父节点。不是每个节点都有子节点，但是每个节点都有一个父节点，一直往上直到整个结构的父节点。层级关系的概念对于用户来说非常容易理解，同时软件也是倾向于层级的工作方式，因此这种类型的结构是最常见的。
特点：结构清晰易懂、有较高的操作效率、扩展性强。
在使用层级结构时，需要注意层级的深浅和宽窄。 宽而浅的产品架构和窄而深的产品架构，各有优势和劣势，具体使用哪一种产品架构，关键是要结合自身产品的定位、业务特性和用户特征及使用场景来进行取舍和判断。
产品结构设计时，理论上不要超过3层。
2.自然结构
书中描述：自然结构不会遵循任何一致的模式。节点是逐一被连接起来的，同时这种结构没有太强烈的分类概念。自然结构对于探索一系列关系不明确或一直在演变的主题是很合适的。但是自然结构没有给用户提供一个清晰的指示，从而让用户能感觉他们在结构中的哪个部分。
如果你想要鼓励自由探险的感觉，比如某些娱乐或教育网站，那自然结构可能会是个好的选择；但是，如果你的用户下次还需要依靠同样的路径，去找到同样的内容，那么这种结构就可能会把用户的经历变成一次挑战。
特点：鼓励人们探索、提高产品趣味性、常见在游戏、咨询类产品
3.线性结构
书中描述：线性结构来自于你最熟悉的线下媒体。连贯的语言流程是最基本的信息结构类型，而且处理它的装置早已被深深地植入我们的大脑中了。书、文章、音像和录像全部都被设计成一种线性的体验。
在互联网中线性结构经常被用于小规模的结构，例如单篇的文章或单个专题；大规模的线性结构则被用于限制那些需要呈现的内容顺序对于符合用户需求非常关键的应用程序，比如教学资料。
特点：如同看电影一般，一个场景向一个场景推进；引导用户跟着走，目的性较强。
4.矩阵结构
书中描述： 矩阵结构允许用户在节点与节点之间沿着两个或更多的“维度”移动。由于每一个用户的需求都可以和矩阵中的一个“轴”联系在一起，因此矩阵结构通常能帮助那些“带着不同需求而来”的用户，使他们能在相同内容中寻找各自想要的东西。
举个例子来说，如果你的某些用户确实很想通过颜色来浏览产品，而其他人偏偏希望能通过产品的尺寸来浏览，那么矩阵结构就可以同时容纳这两种不同的用户。 然而，如果你期望用户把这个当成主要的导航工具，那么超过三个维度的矩阵可能就会出现问题。在四个或更多维度的空间下，人脑基本上不可能很好地可视化这些移动。
特点：可以同时满足不同用户；承载的信息更多；
小结： 具体使用哪一种产品架构，关键是要结合自身产品的定位、业务特性和用户特征及使用场景进行判断。
一个好的产品结构所需的要素： 1.与产品目标和用户需求相对应 2.具有一定的可扩展性 3.层级深度适合 4.用户理解
㈣ 一张图讲清楚产品架构，手把手教你画产品框架图
什么是产品架构图
产品架构图是产品经理用来表达自己产品设计机制的一张概念图：
它将可视化的具象产品功能，抽象成信息化、模块化、层次清晰的架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路。
由于产品架构图通常用于比较复杂的产品项目中，目前介绍产品架构图的相关书籍和资料极少（尤其是入门级别的资料很少提及），却是设计复杂产品时不可或缺的文档之一。
没有资料的探索过程漫长且没有方向，在终于有所沉淀后，我花了四周写下了这篇总结，希望可以为你绘制产品框架图时提供简明的参考。
为什么要画
梳理自己对产品方向的判断：
思考这张图如何设计的过程，也是帮助你梳理“半年内自己的产品该往何处去、需求应该如何分期和落地、和其他产品的依赖&竞争关系是什么、未来的可拓展性在哪里”等问题的过程。
为技术&运营的输出形成支撑：
当这张图被设计出来后，按照产品架构图的结构和路径，项目的里程碑（RoadMap）就可以被清晰的拆解出来，同时项目成员也可以根据这张架构图产出运营计划、技术系统架构方案等强依赖产品方向的方案。
让他人可视化的理解你的产品架构：
能较为清晰简单的呈现自己的思路、明确自己的产品边界、指明发展的方向，常用于在项目规划或项目总结中进行演示，帮助不了解你的产品的人快速的建立对你的产品结构、功能、复杂度的认知。
何时需要画
建议在复杂项目开始前写：
当你要开始设计一个系统性、完整的需求时，如果跳过画产品架构图的步骤，直接开始画原型、写PRD、kick off，就很容易发生“改了又改”、“做了一版需求然后又推翻”的情况。
但“种一棵树最好的时间是十年前，其次是现在”：
如果你的项目已经进行到一半，自己却从未产出过这张图，那么就从此刻开始，按照下文的步骤尝试为自己的产品产出一张产品架构图吧。
如何画
之前我们分享了【AR最全干货及资料】设计AR产品，你一定要看的总结 ，你可能对AR相关的背景知识已经有所了解。为了分享的延续性，我们来做一个大胆的假设*：
假设你是 微信-扫码功能 的产品经理，有一天老板把你叫到办公室，一番鼓励后拍着你的肩对你说：
“苹果发布会看了没？苹果这么重视对AR能力的支持，我们微信也要赶紧把AR功能做起来。这是个Allen（张小龙）很重视的项目，你回去好好设计一下，明天来跟我过方案。记住，要能够一炮打响，全民参与喔！”
啊，张小龙级别的项目啊！明天就要出方案，怎么办 ？
画前准备
列出问题域
在需求初期，产品经理得到的往往只是一句比较模糊的需求描述，它们可能来自于老板、运营或用户。
直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品所有的问题域列清楚。
“问题域”是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能要解决的问题放入产品框架的范围，能够帮助你的产品架构图拥有更高的可拓展性，在后续具备迭代和优化的空间。
以微信AR的需求为例，问题域是这样一个集合：
详细操作步骤：
1. 找到收到的需求中，跟产品形态、产品目标相关的词句，去列出“XX的流程会是什么样”、“XX该怎么达成”之类的问题，直到如果这些问题解决，能够实现核心需求的方向和业务目标。
2. 去逐次寻找这些问题需求被解决的过程中，是否有其他要先解决掉的问题、或者其他跟业务相关的问题能够被解决/改善。
3. 按照层级去罗列出所有的问题，并附上自己的初步回答，从而形成一个初步的、自己的产品能够解决的“问题域”。
确定产品方向
在经过问题域的罗列后，你应该能够得到一个模糊的产品方向和功能范围。把这些问题域的答案抽象总结成一个确定的产品需求。
以微信AR的需求为例，根据问题域，我们发现需求不只是扫码组件增加AR识别能力这么简单，整个需求里需要引入广告主的角色，并且需要和广点通、腾讯开放平台等团队合作。最终得到的产品方向描述是这样的:
详细操作步骤：
问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充、拓展和翻译成一个在商业模式和用户体验上能够形成闭环的产品需求。
1. 核心需求确定：我的产品核心解决的是哪批用户、哪个用户需求？
2. 产品目标：如果以一个数字指标衡量我的产品，它应该是什么？
3.用户场景：核心需求基本的产品形态、用户使用的路径是怎样的？
清晰的业务流程
这一步需要根据核心产品需求和问题域的答案，画出简单的业务流程。业务流程是产品设计中常见的图表，绘制方法就不再多做说明。
以微信AR的需求为例，从广告主准备AR互动，到用户在前台使用摄像头参与互动，整个业务流程如下:
着手绘制
搭建基础框架
基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。
详细操作步骤：
1. 对照业务流程，根据自己设想的产品机制、基本产品形态和用户的使用路径，列出需要的页面&功能&模块等前后端逻辑。
2. 将刚刚得到的多个流程图中所有功能类似或者范围有包含关系的机制/功能放在一起，以模块化的形式形成一张简单的矩阵图。
3. 将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。
明确架构分层
一个具备前后台关系的产品架构图至少分为三层：用户感知层（在何种场景下通过何种方式触达用户）、功能模块层（通过哪些功能模块实现产品的核心功能、和哪些外部平台功能有信息交互）、数据层（产品的数据从哪里来、产品的数据沉淀到何处去）。
在上一步进行简单分层后，我们已经得到一个初步框架，但是难免会有分层不明确的问题。此时需要按照两种维度来处理架构图的层级：不同信息层级的边界、同一层级内模块和模块的边界。
1. 处理不同信息层级的边界：
架构图的层级表达的其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。
其中用户感知层和数据层通常可以简化为一层（用户端的功能表达往往逻辑简单、数据的来源问题则不是自己产品的核心功能），而功能模块层则需要按照自己产品的逻辑去将功能模块层内的主要模块变成新的层级。
2. 处理同一层级内子模块的边界：
各层次之间虽然相关，但同一层次内的子模块之间一定是互相独立、界限分明的（常常对应着不同的开发团队和系统应用）。将解决不同问题的功能拆分成两个子模块，做到一个问题只在同一层解决，避免牵一发而动全身的情况出现。
3. 明确产品间的边界：
产品边界对于开发设计系统架构、业务间的合作模式都非常重要。用不同颜色标识清楚产品框架中，各个部分所属产品的边界，通常其中属于自己团队的部分用亮色表示。
加入信息流转机制
产品架构图在表达产品的核心功能外，也应该体现信息流动的路径：当前层级数据的交互形成产品功能，产品功能又产生新的数据，从而推动下一层级的功能运转起来。
如果当前产品的主要使用角色只有一个，则只需要用箭头标明模块间信息流动的方式即可。如果当前产品会涉及的主要角色比较多，则需要用不同颜色的线条将他们和各个模块之间的信息交互关系外化出来。
最终检查
一张好的产品架构图，应该具备以下特点。
清晰的模块功能边界
功能经过抽象，做到标准化、互相独立
上下游产品功能边界清晰，架构分层明确合理
具备迭代优化的能力
记得不断根据你的产品的发展情况来更新产品架构图，每次修改的过程对提升产品架构能力的帮助非常巨大。
————————————————
原文地址：https://blog.csdn.net/pmcaff2008/article/details/78111282