在高级产品经理眼里，产品架构是怎样的？

一般来说，搭建产品架构这件事情，只有少数的高级PM才能胜任，绝大多数刚入门的产品经理或产品专员，还涉及不到任务这么艰巨的工作(简单的产品功能结构不算)。

经历过需求的采集、分析和筛选，我们对产品的定位和用户的需求有了越来越深刻的认识，对整个产品标的目的的把控和版本迭代节奏也会更有感觉。这种感觉你也可以称之为“产品感”，虽然讲得有点悬乎，可又的确存在。以我个人的经验来看，不停地了解用户需求和场景，也是积累产品感的一种良好的方式。有了不错的产品感，我们要继续往前走，才能将产品推向一个更高的高度。

产品经理之前已经将产品第一个版本的功能需求都整理好了，也输出了一份详细的功能需求列表，这个时候要做的工作就是为产品搭建一个好的架构，也就是产品设计的第三个环节——搭框架了。任何一款互联网产品都应该有一个产品架构，有了这个强大而坚实的架构作为产品的基础，我们才能将产品需求给一个一个填充进去，让产品变的丰富立体，更有血有肉起来。

那究竟什么是产品架构，产品经理又该如何来搭建一套好的产品架构，我们来接着往下看。

什么是产品架构

任何一个产品都有本身的产品架构(也有很多人把它称为信息架构)，就比如每一个人都有本身的骨骼系统一样，你的骨架大小决定了你大致的身材会是如何，每个人的身材都纷歧样，高、矮、胖、瘦各有差别。

有些产品的产品架构比较繁杂，例如大部分to  b 的产品，如客户关系办理系统、ERP软件、电商网站的办理后台、物流办理后台、SaaS软件等;有些架构则比较轻便、简单，好比绝大多数的to  c 的产品，像我比来在玩的图友、摩拜单车、直播APP映客、花椒等，当然还包孕微信(虽说现在功能越来越多了，但大体架构依然是简单、清晰明了的)。

我们直接看几个例子：

天猫商家工作后台

这是天猫商家的工作后台，看到左侧这一排满满的导航菜单了吗，是不是感觉超级复杂，光店铺办理就有超过10个二级菜单，要梳理好淘宝、天猫这种量级的电商平台产品架构可真不是一件简单的事。不过我也常常好奇一点，这么复杂的后台，卖家们都能清楚地知道每一个功能在哪里么。

复杂架构的产品，对产品经理的能力要求较高，需要产品经理能提供功能完备、结构严谨的架构系统，让用户能通过操作流程来使用各个功能。所以这样一个架构的特点是，它会带来必然的学习成本，有些甚至需要对产品的用户进行培训(像淘宝开设了淘宝大学以及淘宝社区)。这种架构产品的用户群体一般比较聚焦，只针对某一类人群，需要对海量功能进行合理整合、灵活布局来聚焦核心用户场景。

脸萌官网

再来看一个例子，这是曾经爆红一时的脸萌app的产品官网，仔细分析一下这个官网的产品架构，是不是超级简单，简单到只剩下2个菜单——首页、关于我们。这里要注意一点，即使是简单的2个菜单(有些官网只有一个菜单)，也依然构成了完整的用户体验，因为通过这个架构，网站的目标和用户的需求都已经得到了充分的满足。当然，如果你想要重新定义网站的目标，或是用户的需求发生了变革，那你就该去准备重新调整产品架构了。

轻架构的产品，它的目标就是提供给用户一个简单明了的信息架构，让用户使用便利、体验流畅。对于产品经理来说，设计轻架构的产品，难点在于体验和创新。我们可以通过给产品做减法来不停聚焦用户的核心使用场景，让用户简单易上手，等产品的用户体量上升到一个新的台阶的时候，再去拓展产品的使用场景，延展产品架构。

典型的几个产品架构模型

Jesse James Garrett在《用户体验要素》这本书中，为我们系统阐述了互联网产品的几个典型的产品信息架构模型。第一种信息架构模型比较符合我们产品经理对产品架构的理解和定位，后面三种信息架构模型，你可以当作是第一种模型的增补，或者你也可以把它当作页面级另外信息架构梳理。

第一种，层级结构(hierarchical structure)

层级结构模型

书中原文是这么来描述这种产品架构的——“在层级结构中，节点与其他相关节点之间存在父级/子级的关系。子节点代表着更狭义的概念，从属于代表着更广义类另外父节点。不是每个节点都有子节点，但是每个节点都有一个父节点，一直往上直到整个结构的父节点。层级关系的概念对于用户来说非常容易理解，同时软件也是倾向于层级的工作方式，因此这种类型的结构是最常见的。”