编辑导语：产品设计的过程与建筑设计的过程是很相似的，建筑设计过程中的很多理念也能引申到做产品的过程中。这个观点是不是听起来很独特呢？本文作者基于这个观点，将编码模式与土木工程世界里的建筑模式进行了打通，希望能对各位产品设计师们有所启发。
开门见山，一句话总结这篇文章的中心思想：产品设计与建筑设计是一脉相通的。本观点引申于高阶程序员世界里，将编码模式与土木工程世界里建筑模式的相通。
站在伟大是视角总会发现我们的世界最终呈现出一种模式，如果要用一个现实世界的案例来类比软件产品设计，我觉得用建筑来形容最恰当不过。
私以为：
- 需求文档就是建筑设计的图纸；
- 信息架构就是建筑的导航系统；
- 设计师懂建筑产品经理就要懂技术；
- 软件产品也会超出承受极限。
一、需求文档就是建筑设计的图纸
前几年有一则新闻的题目是《西班牙47层摩天大楼竟忘设计电梯》。
最后这则新闻被辟谣的真相是20层的公寓增建到47层，但设计规划20层容量的电梯却要支撑47层的人流，业主入住之后会导致很难挤上电梯。
大厦增高后电梯容量不够，而不是“忘记装电梯”。虽然是个非真实的新闻，但这个故事不失是个形象的例子。
不要等到房子快要竣工的时候发现忘了设计电梯，产品经理不要等到了产品快要上线的时候提出遗漏需求，在文档阶段就要将需求考虑全面遍历到边角case，我想这就是产品经理的宿命。
二、建筑的通道就是产品的导航
经历过很多次在建筑内迷失，进入楼房内部就像进入了迷宫。
印象最深的是大学某座教学楼，很多同学到了毕业都没能摸清里面的布局，每次遇到大型的考试，都会有同学不幸的为找考场而迟到。
房子内部的通道设计就对应产品的导航系统，好的导航系统能让用户自然的知道自己身处何方，甚至不用做引导。我
从哪里来、我现在身处在何方、我能到哪里去，一目了然，用户不用思考便能做出决断。房子一旦建成，内部的导航几乎没有了重构的机会，除非推翻重建。软件产品就比较有幸，可以进行版本迭代，再次优化产品的信息架构。
三、设计师要懂建筑，产品经理需懂技术
如果产品是房子，那么产品经理就是房子的设计师，设计师要懂得房屋的结构设计和施工原理，清楚建筑的技术边界，否则设计出来的房子就是无法落地的空中楼阁。
理想的设计和物理的限制必须有效结合，不存在真正的空中花园和通天塔。产品经理懂技术不是要求要会敲代码，是要清楚技术的边界，可以预估需求的可行性。
四、软件产品也会超出承受极限
很多产品做着做着就成了烂尾楼，产品经理的共同理想是从0到1建造一个完全融合自我理念的房子，那是一个完美花园。奈何，现实情况是大多数产品经理接到需求的都是房屋的二次改造工程。
虽然说没有技术实现不了的需求，遇到有的需求，程序员誓死不接。说需求可以做，但产品可能随时会崩溃。
《给产品经理讲技术》作者援引了一个很恰当的故事：
隔壁老王原来家里有两室一厅的平房，一个卧室改成了书房，两口子和刚出生不久的儿子住在大卧室里，日子过得还算滋润。儿子长大了，老两口就计划在平房上再盖一层，让儿子住二楼，以后结了婚也可以把二楼当婚房使用。
又过了几年，儿子娶了媳妇。儿媳妇在二楼住了不久，开始抱怨二楼没有阳台，连个晒衣服的地方都没有。于是老王两口请来设计师，准备给二楼添个阳台。
设计师说：“这个二楼本身就是在平房上加盖的，楼梯设计的不规范，上下楼不安全，而且原来的平房承重结构勉强承担现在两层楼的重量，如果再从二楼外延出阳台，很可能超出系统承重的极限，一旦出现问题，后果不堪设想。”
建房子如此，做软件设计也是如此。一个好的产品必然具有好的扩展性，但扩展性也有一定的限度。
五、软件设计与建筑设计是一脉相通的
产品的需求设计属于显性层面的设计和程序员的编码属于隐形层面的设计。作者纵然对技术了解不多，但已然意识到技术世界里，编码和建筑有所相通。
在编程里有模式语言这么一说，上升到哲学层面，编程和建筑模式是相通的。
在建筑学科有一本书叫《建筑的永恒之道》，具有讽刺意义的是，这本书在软件工程师中的名气要比城市规划师中大得多。
建筑师就像一个语言使用者，模式就是他的单词，用不同的单词构成一句话，再由一句句话构成文章，也就是最终的建筑。既然编程公认与建筑相通，那么作者苟且也认为产品设计也有自己的模式语言，产品和建筑的终极目标都是为了处理人与自然的关系。
产品设计师何尝不是一种语言的使用者，产品经理做的原型图、业务流程以及产品策略也是一种建模语言。
万法归一，我们无法了解事物形态上的所有变化，但是我们却有可能认知这些变化背后更加深层的、稳定的实质。万变不离其宗，通过理解这些实质，我们可以从容应对各种变化。
作者：产品范，微信公众号：产品范，O2O新零售电商产品经理
微信扫一扫 
支付宝扫一扫 
