产品入门｜3种结构图

提到产品经理必须要会的技能，大概大部分人都会说需求分析，确实很重要，但我想先说3个结构图，这3个图可以让我们有序的思考，从最初的模糊概念到最终清晰的产品原型或者产品功能设计，我认为是产品思维方式之一，而且就是“很简单，知道后，刻意练习一次基本就会了，是一种思维方式和梳理方式，可以快速见效”；

三种结构图

3种结构图都是脑图形式，其实样子都差不多，只不过要表达的内容不一样而已‍

功能结构图

功能结构图是非常常见的，在我们就一个需求做专题讨论时，往往最开始大家往外冒的想法就是一个个功能模块或者最终的诉求；

比如一个API市场，往往大家第一次沟通时，除了背景，就是沟通功能诉求，可以搜索API，可以查看API详情，可以订阅API等……这些就是功能，把相关方的各方功能诉求合在一起用脑图展现，就是一个功能结构图了；

功能结构图可以帮助我们梳理产品功能模块或者功能点，颗粒度可以自己决定，能清晰就行，可以明确产品的功能清单，不需要想说这些功能怎么展现，那是后面设计的事情，先把最核心的能力和功能范围确定了再说；

信息结构图

一般信息图是到了产品进一步思考的时候会需要，比如API市场，了解了大家的诉求，回去梳理了功能结构图，但是有些功能往细节思考的时候发现，还需要很多信息才能明确；

比如“查看API详情”，这个详情里有啥啊，“订阅API”，需要填写啥信息才允许订阅啊，而且没有这些信息，开发也不从下手，连数据库都设计不了；‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

梳理信息结构图的时候不用想这些信息怎么交互或者展现，只需要考虑要完成这个功能需要哪些信息，把信息罗列出来即可，可能这些信息最终都没有在一个页面展现，但属于同一个功能模块就行，在梳理的时候，也不要想层级结构，直接一层把信息放进来就行；‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

产品结构图

有了功能结构图和信息结构图后，就比较明了想要啥功能，这些功能有啥信息了，这时候就需要产品结构图了，可以在画原型前思考清楚产品功能设计，它是将功能和信息以一种逻辑糅合在一起，直接表现用户看到这个产品的结构；‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

产品结构图就是产品的最终形态的静态形式，是产品原型的文字表达；‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

小结一下‍‍

3种结构图我说的很简单，给的例子也很简单，感兴趣的可以再深入了解一下，就是一个从抽象到具体的思考过程；

在功能结构图阶段，我们可能只有个大概认知，知道产品要具有什么能力或者功能模块，这个功能不一定是实际产品看到的一个个具体功能，可能是一个功能类型模块，一般功能结构有了，产品的核心定位就有了，或者核心价值就明确了；‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

在信息结构图阶段，我们逐渐明细了各个功能或者功能模块的所需要的信息，这些信息是开发者进行数据库表设计的参考，也是产品在做原型或者最终功能设计的一个信息备忘，因为如果信息很多了，可能在做原型设计或者写需求文档的时候就遗忘了；‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

在产品结构图阶段，就是让最初的概念具现化出来了，有了产品使用逻辑和结构；‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

最后

这3种结构图，实际工作中不会每次都3种都画，根据产品复杂程度，可以选择性使用，而且这些结构图多半是产品设计的过程产物，所以不必在意形式，可能一支笔草稿就画了，可能糅合在一起就画了，最主要的是通过这3种结构图梳理清楚功能的逻辑和流程，以便更好的完成功能设计，重点在于这个思考过程；‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

题图也是自己拍的，感觉那朵云后面就是天宫，有着10万天兵天将；

浅说一下这篇文章的出发点‍‍‍‍‍‍‍‍‍‍‍‍‍‍

我在公司的信息技术部，里面99%的同事就是程序员，所以作为产品或运营角色是参与到各个开发组，协助该开发组完成业务需求开发或者产品运营工作；

光参与进去还不行，领导还要求以教练的角色，教会开发组的开发人员自己能进行产品或者运营类工作，叫我们要给一些类似“产品指南”“运营指南”的东西，开发人员看了就照着步骤一步步来做产品或者做运营；

初听有点懵逼，“我也想要这样的一份指南啊，看了就会产品和运营了，如果有这份指南我一定去卖钱，肯定很多人想要”，后来仔细想了想，领导要的是一份指南么？或许也不是，他们只是希望开发者可以学会产品或者运营相关的知识、技能和思维，那么怎么可以满足这个需求呢？一些关于产品或者运营的入门教程呢，是不是能达到同样诉求？

基于这个想法，我仔细观察了开发者会怎么做产品讨论和沟通，他们会借助什么方法来阐述自己的想法或者构思，发现思考的方式和逻辑每个人都不同，没有一套行之有效的产品设计方法，好一点的会用到流程图，然后就靠零碎的、不成系统的口头沟通来达成业务和开发对于一个功能或者系统的共识，然后就开始喊设计师设计高保真原型了；

总之，就是基于此，我就想零零碎碎写一些产品或者运营会用到的入门方法，既可以自我总结沉淀，也可以作为“指南”给到参与的开发组，我真是小天才，一举两得；‍