做產品就像是在“建房子”
編輯導語:產品設計的過程與建筑設計的過程是很相似的,建筑設計過程中的很多理念也能引申到做產品的過程中。這個觀點是不是聽起來很獨特呢?本文作者基于這個觀點,將編碼模式與土木工程世界里的建筑模式進行了打通,希望能對各位產品設計師們有所啟發。
開門見山,一句話總結這篇文章的中心思想:產品設計與建筑設計是一脈相通的。本觀點引申于高階程序員世界里,將編碼模式與土木工程世界里建筑模式的相通。
站在偉大是視角總會發現我們的世界最終呈現出一種模式,如果要用一個現實世界的案例來類比軟件產品設計,我覺得用建筑來形容最恰當不過。
私以為:
- 需求文檔就是建筑設計的圖紙;
- 信息架構就是建筑的導航系統;
- 設計師懂建筑產品經理就要懂技術;
- 軟件產品也會超出承受極限。
一、需求文檔就是建筑設計的圖紙
前幾年有一則新聞的題目是《西班牙47層摩天大樓竟忘設計電梯》。
最后這則新聞被辟謠的真相是20層的公寓增建到47層,但設計規劃20層容量的電梯卻要支撐47層的人流,業主入住之后會導致很難擠上電梯。
大廈增高后電梯容量不夠,而不是“忘記裝電梯”。雖然是個非真實的新聞,但這個故事不失是個形象的例子。
不要等到房子快要竣工的時候發現忘了設計電梯,產品經理不要等到了產品快要上線的時候提出遺漏需求,在文檔階段就要將需求考慮全面遍歷到邊角case,我想這就是產品經理的宿命。
二、建筑的通道就是產品的導航
經歷過很多次在建筑內迷失,進入樓房內部就像進入了迷宮。
印象最深的是大學某座教學樓,很多同學到了畢業都沒能摸清里面的布局,每次遇到大型的考試,都會有同學不幸的為找考場而遲到。
房子內部的通道設計就對應產品的導航系統,好的導航系統能讓用戶自然的知道自己身處何方,甚至不用做引導。我
從哪里來、我現在身處在何方、我能到哪里去,一目了然,用戶不用思考便能做出決斷。房子一旦建成,內部的導航幾乎沒有了重構的機會,除非推翻重建。軟件產品就比較有幸,可以進行版本迭代,再次優化產品的信息架構。
三、設計師要懂建筑,產品經理需懂技術
如果產品是房子,那么產品經理就是房子的設計師,設計師要懂得房屋的結構設計和施工原理,清楚建筑的技術邊界,否則設計出來的房子就是無法落地的空中樓閣。
理想的設計和物理的限制必須有效結合,不存在真正的空中花園和通天塔。產品經理懂技術不是要求要會敲代碼,是要清楚技術的邊界,可以預估需求的可行性。
四、軟件產品也會超出承受極限
很多產品做著做著就成了爛尾樓,產品經理的共同理想是從0到1建造一個完全融合自我理念的房子,那是一個完美花園。奈何,現實情況是大多數產品經理接到需求的都是房屋的二次改造工程。
雖然說沒有技術實現不了的需求,遇到有的需求,程序員誓死不接。說需求可以做,但產品可能隨時會崩潰。
《給產品經理講技術》作者援引了一個很恰當的故事:
隔壁老王原來家里有兩室一廳的平房,一個臥室改成了書房,兩口子和剛出生不久的兒子住在大臥室里,日子過得還算滋潤。兒子長大了,老兩口就計劃在平房上再蓋一層,讓兒子住二樓,以后結了婚也可以把二樓當婚房使用。
又過了幾年,兒子娶了媳婦。兒媳婦在二樓住了不久,開始抱怨二樓沒有陽臺,連個曬衣服的地方都沒有。于是老王兩口請來設計師,準備給二樓添個陽臺。
設計師說:“這個二樓本身就是在平房上加蓋的,樓梯設計的不規范,上下樓不安全,而且原來的平房承重結構勉強承擔現在兩層樓的重量,如果再從二樓外延出陽臺,很可能超出系統承重的極限,一旦出現問題,后果不堪設想。”
建房子如此,做軟件設計也是如此。一個好的產品必然具有好的擴展性,但擴展性也有一定的限度。
五、軟件設計與建筑設計是一脈相通的
產品的需求設計屬于顯性層面的設計和程序員的編碼屬于隱形層面的設計。作者縱然對技術了解不多,但已然意識到技術世界里,編碼和建筑有所相通。
在編程里有模式語言這么一說,上升到哲學層面,編程和建筑模式是相通的。
在建筑學科有一本書叫《建筑的永恒之道》,具有諷刺意義的是,這本書在軟件工程師中的名氣要比城市規劃師中大得多。
建筑師就像一個語言使用者,模式就是他的單詞,用不同的單詞構成一句話,再由一句句話構成文章,也就是最終的建筑。既然編程公認與建筑相通,那么作者茍且也認為產品設計也有自己的模式語言,產品和建筑的終極目標都是為了處理人與自然的關系。
產品設計師何嘗不是一種語言的使用者,產品經理做的原型圖、業務流程以及產品策略也是一種建模語言。
萬法歸一,我們無法了解事物形態上的所有變化,但是我們卻有可能認知這些變化背后更加深層的、穩定的實質。萬變不離其宗,通過理解這些實質,我們可以從容應對各種變化。
#專欄作家#
知行之間,微信公眾號:知行之間,人人都是產品經理專欄作家。資深信息化產品。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Pexels,基于 CC0 協議
- 目前還沒評論,等你發揮!