正文
所以，在产品正式进入开发以前，绘制一个完整的产品架构图就成为必然：
架构的根本目的就是为了梳理产品思路，从整体上把握产品的发展方向，把控产品的功能重点（卖点），它决定了产品必须要实现的功能，以及什么时候必须完成的功能，也就是产品的架构决定了产品的发展路径。
同时，为了满足我们所设定的“架构”构想，还必须配备相关的产品研发和市场运营资源以及具体的落地计划，包括技术选型和技术路径，市场营销规划等一系列的策略和措施。
产品架构是团队基于某一独特市场和用户痛点的统一沟通语言，也是在产品迭代过程中的业务边界。
如果你足够细心的话，会发现本文的案例“O2O产品架构示例”中，右侧有标记“接口层”、“服务平台”、”终端用户“等字眼，并做了一个标记，说明他们说代表的含义和使命，比如”响应终端的服务请求“，意味着这一层级的所有功能，都是为”用户“服务的，是针对用户行为的一个信息接受和反馈机制。
比如，在O2O的服务过程中，用户有一个设备的维修请求，他通过“用户界面”向平台发送一个状态信息和请求信息，平台端通过一个有效的机制，及时的接受这一信息，并让用户理解到，“我已经知道你这边除了状态，我正在安排人采用一些措施来协助你解决问题”。
这就是一种响应机制，这一过程就是整个平台的服务端开始处理用户请求的起点，然后整个平台基于这一个被“触发”的机制，去调动整个平台的资源，包括各项数据的查阅、各种资源的调动，来协同处理这一个业务请求的系列动作。
所以，整个产品的架构设计，也就是基于这一个连锁反应进行的业务层和逻辑层的解耦分拆，系统性的规划整个O2O平台的前后端如何高效的协同。
同时，基于这一个基本规则，我们再考虑平台的未来业务发展，甚至我们还需要考虑到未来三五年的业务容量会达到什么量级，由此需要采用怎样的技术设计和资源配置（云端服务资源）。
由此可见，
产品架构设计，首先就是一个分层设计的过程
。
通常来说，最容易实现的产品层级结构就是三层，即用户层、功能层和数据层，这种层级关系即可完整的实现前、后台关系的业务系统：
1、统一的用户感知层
解决的是用户触达的问题，考虑在何种场景下通过何种方式触达用户，最表层的业务体验，也就是我们常说的“用户体验”，包括界面，布局，配色等直观可见的每一个产品页面。
在这个层面，我们考虑的是如何更好的表达我们想要表达的业务元素，如何能够更吸引用户的注意力和停留决策，它在一定程度上决定了用户是否会立即卸载，或者是带着好奇之心在有效的引导下探索产品。
这是产品经理的必修课，因为它能直观的让人直接评断产品，最常见的说辞就是“丑爆了”，而且是任何一个产品都会遭受到这一批评，哪怕你是微信也毫不例外。
但真正决定体验的，并不是这一层，但又无可奈何必须面对的现实。所谓人靠衣装吧，一个打扮时髦的美女你甚至都会觉得她特别让你感觉亲密，甚至你会直觉认为她根本就是一个好人，一个让你喜欢的人。
2、解耦的业务功能层
多少产品经理实际在这个层级就开始陷入迷糊状态，根本不知道甚至没有意识到“功能”的分解和层次设计，在他们眼里，任何产品都只需要一个界面+一个数据库，即可愉快的完成所有业务。
