起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品工業化思考與React哲學對產品的一些啟發
編輯導語：產品工業化對于產品經理和開發而言，有著重要的意義。本篇文章中，筆者結合React哲學分享了自己對產品思考。感興趣的小伙伴不妨來看看，說不定能幫到你哦。
在經歷了許許多多的項目之后，我發現我累積了大量原型圖，好奇再次打開，發現其實里面有大部分是大同小異的；
但是基本每個項目的原型都是重新做過，重新做過就意味著邏輯需要重寫，重寫又意味著會跟研發有理解上的沖突。
在以往的項目中也遇到過其他產品經理跟開發們發生了爭執，甚至還鬧得要離職。
一直以來，我在反思兩個問題：
- 是否有辦法能快速產出原型？
- 產品與開發的想法是天然沖突的嗎，是否只有產品去學習代碼知識才能解決這個問題？
剛好最近學習了React，從中得到了一些思考和解決方案，特別是它崇尚的哲學：
單一責任原則 與 組件化（當然React的哲學有很多，但這兩樣是令我最深刻的），或許解決問題二的關鍵，正是先解決問題一。
首先，簡介一下React：這是一個開發行業內比較著名的JS框架，開發會用這些JS框架去編寫APP、小程序、web。
而React最核心的哲學也就是：“組件化”，將一個頁面分成一個個小組件，各司其職。
一、原型不應該成為最花時間的部分
沖突來源于大家對同一事物的理解不同，例如做項目A時，開發會覺得這樣寫，代碼會簡潔；
但是產品會覺得那樣做，用戶更加方便；
當我們另外做一個相近的業務時，開發覺得業務差不多，想引用之前代碼；
但這時候產品會因為具體的業務場景，去改動某一些的功能（例如可能在公告中，延時關閉變更為主動關閉）。
這時候會帶來一些問題：
- 產品需要重新做出這個功能的原型、交互、寫好該公告的邏輯 ；
- 開發可能無法知道是否要另外寫一個【公告】組件，還是把之前的【公告】改一下，抽成公用的組件呢？
這些問題幾乎每天都在發生，我打開了我之前的原型圖，發現里面也充斥著這類的問題，例如一個對話框：
（兩個都是對話框，但在原型上來說，每一個項目，對話框都要重新做一次，包括顏色、圓角、按鈕的大小與位置）。
然后像React完成組件一樣，將對話框的參數抽離出來：
對話框的寬、高、標題，按鈕觸發后的交互、是否存在cancel按鈕、內容……
再將這些內容的交互邏輯定義好，例如標題超過X個字會截斷，點擊【確定】完成業務后會關閉對話框，什么場景下才允許使用對話框？
以后任何原型需要用到對話框時，只需要拿以前的框架，再往里面填充內容就可以了。
至此，我們可以將大量的時間放到用戶調研以及觀察身上，而不是去畫原型圖或者擔心這樣的交互是否，是否會導致開發成本過高，因為從組件建立之初，這種問題就討論過了。
二、是否遷就開發，降低體驗
以上這樣做，可能會觸碰到一個產品們經常討論的問題，是否為了開發的便捷而犧牲用戶的體驗呢？
但其實并不會的，正如《微信背后的產品觀》而言的：“如果一個東西實現起來特別復雜，它大抵是錯的”。
而這樣做對于用戶也是大有益處的，統一標準及公用組件可以大大降低用戶的心智負擔。
特別是在一個產品鏈上時，不同的產品應該統一的交互，統一的視覺，統一的組件（至少在TO B端的產品應該如此）。
再在內容上按照業務的需要定制（例如標題，高度，內容等）。
實際上，在業界早已有團隊在探索這些方案，Antd Design就已經有全套覆蓋的資源了：產品-》設計-〉研發 ；
但這事情可以更進一步討論。
這也正是今天的主題：由React的價值觀得出來的反思。
首先在TO B的復雜多變的業務里，是否每一個差不多的組件都應該抽象成公用呢？
這問題就如上文所述的一樣，開發認為差不多應該抽成公用的組件。
但是產品說場景不一樣，從而做了一個功能差不多但又不完全一致的組件，這時候沖突就會爆發。
竊以為一個組件究竟該變成公用還是按照特殊例子來處理，需要的是知道其功能，也就是【單一責任原則】。
例如一個【操作成功的提示】，在任何的業務中即時操作成功都應該用此提示，不應該有變體。
但是如果這個操作是一個【異步】操作，例如【轉賬】，需要等待別的銀行或者中央財務系統返回信息的，這時候就不應該用上述的提示。
因為一個異步的提示至少有兩個任務需要完成：
- 告知用戶目前任務的進行狀態（進行中、完成、業務失敗、接口失?。?。
- 成功或者失敗時告知用戶下一步的操作（例如失敗，需要前往哪里糾正；轉賬成功，有地方可以前往轉賬詳細的地方，因為此時用戶很可能已經到訪了另外的頁面）；
如下例子：
以往經常會有這樣的爭執：
例如為什么兩個差不多的組件不把它做成同一個呢？這樣就不需要開發兩個組件了；
但如果組件在不同的場景下服務于兩個目的，即便這兩個組件只有一個按鈕之差，都不應該抽象成一個組件；
因為后續業務可能會繼續有增刪，一開始兩個業務可能會很相近。
例如金融系統中的【對私人轉賬】，與【對公司轉賬】，剛開始甚至可能會做成一個頁面，判斷輸入的是公司類型還是個人類型，再顯示字段；
但隨著業務的增長，對公司的轉賬可能需要更多的認證，更多的引導。
屆時產品會一直在業務中加邏輯，但是開發可能并不想在同一個頁面寫這么多的判斷！
若我們都遵循【單一責任原則】這樣的問題就迎刃而解。
三、組件化
這里應該要感謝阿里與螞蟻金服，在經歷了【餓了么】組件，【京東】組件，還有一些小型的組件之后，螞蟻金服的組件是最具理論價值和實用性的。
當然，組件并不是螞蟻金服最早提出的，實際上我在前幾年接觸 cocos引擎的時候已經是組件化的，而虛幻引擎是面向對象的。
我亦好奇去查了一下知乎大家對這兩種編程方式的優缺點爭論，這些就是后話了。
回到產品身上，為什么組件化對我們也如此重要呢？
在這里我需要借用一個概念：“設計工程化”，所以我們暫且稱為：“產品工程化”，產品工程化可以令業務明確時，大大減少我們畫原型圖的時間。
我們只需要確定一些基本的元件，然后按照業務搭配就可以了，每一個產品用同一套組件，可以大大剩下與研發溝通的成本。
例如在下圖中定義了一個素材組件，此組件有一個素材名稱、素材封面圖、素材類型、素材鏈接；
于是在任何產品的素材庫中，我都用了如下的原型，并將交互邏輯抽成一份公用的文檔(例如點擊可以查看，或在激活狀態下點擊名稱可修改名字)，這樣開發甚至可以直接把代碼copy過來。
然后我們再定義一個組件，叫右鍵菜單：這樣素材右鍵時會觸發一個菜單，這兩個組件就組成一個新的組件。
無論這個素材是圖片還是視頻，都會有這個右鍵菜單。
若對于某些項目右鍵菜單的某些選項是無法使用的，只需要將其隱藏或者disable就可以了。
無論怎么變化，這個組件的結構始終沒有變，仍然是：一個右鍵菜單、素材名稱、素材封面圖、素材類型、素材鏈接。
有些產品會不同意這個做法，例如這個素材假如只剩下兩個操作的時候，最好的辦法是將操作平鋪出來。這樣做我們可以再做多一個組件：
這樣素材組件加上這個操作組件，又可以形成一個新的組件；
那么至少 “素材組件+操作組件” 和 “素材組件+菜單組件”，這樣已經可以覆蓋90%業務。
而且具有高度可擴展性，例如以后業務需要素材可以復制，那就在菜單增加【復制】就可以。
以后有別的業務，例如現在有一個項目管理的系統需求，同樣，我們可以將該組件用在這個系統里。
（同樣具有項目封面、項目名稱、項目鏈接，以及一個右鍵菜單）。
四、什么時候應該增加新組件？
像《About Face》中說的：“遵守規則，除非有極好的選擇”；
特別對于TO B端的產品，更加需要的是提升業務的效率，復用組件可以降低學習的負擔（某些情況下，可以有情感化的設計，但這并不是主要的，特別是政府的系統，我從來就沒見過什么情感化的設計）。
但遵守規則，不代表墨守成規（這也是出自About Face的）。
如上面的例子，如果一個項目的操作只有1～2項，這時候右鍵菜單就會成為操作的負擔（即便右鍵是一個簡單的習慣用法）。
這時候可能把操作平鋪操作，是一個最佳的選擇，于是乎我們選擇添加一個新的組件。
在任何情況下，我們都應該先采用已有的組件，直到無法滿足業務。
遵守規則，除非有極好的選擇——《About Face》
五、關于繼承與組件
在《微信背后的產品觀》中，張小龍分享了一個產品的方法：設計就是分類；
如果用戶有100個需求，應該將其抽象成10個需求去解決這100個問題。
這是一種很聰明的做法，也是我現在一直在努力效仿的做法；
比如，現在有多個活動：砍價、簽到、抽獎、優惠券等等；
通常的做法是將他們平鋪放在一個頁面（如下圖），每進入一個活動，都各自有一個活動列表。
某個服務商的活動
這樣做可以顯得自己有很多功能，卻同時會帶來一個問題：
如果用戶創建了多個不同類型的活動時，他要查看一個活動的數據。
首先得記得這個活動是屬于什么類型，它究竟是屬于優惠券，還是裂變優惠券；再點擊進入查看活動數據。
但我們細心觀察，會發現他們有幾個元素是一致的。
如它們都擁有一個活動標題，活動的期限，活動的封面圖，活動的簡介。
只需要加多一個字段：活動類型，就完全可以在一張表中區分。
進行了這樣的設計后，仍然會有人來問：如何創建活動，但我們只需要講解一次，后面用戶就知道在哪里創建。
像上述例子，還會誕生一個對開發不友好的問題，例如彈窗廣告；
彈窗廣告的功能是，用戶進入后會彈出一個廣告；
但由于后臺是個列表，用戶可以創建多個彈窗廣告，這樣使得開發上不得不增加一個邏輯：
同一個時間內，只允許彈出一個彈窗，并且以新創建的為準。
用戶創建時必須小心翼翼地去調整彈窗的“活動時間”，看看有沒有與之沖突的彈窗。
但《微信》的書中對抽象這個產品的方法僅僅只是一頁紙，沒有更多的講解。
我們可以用組件化的方法將這個理論繼續擴充。
活動中有共同的元素，例如活動名稱和時間，我們可以抽成兩個組件，這些組件擁有共同的樣式和交互（例如無法選擇超過結束日期的時間），每個活動的主體再另外配置。
甚至可以更進一步：例如轉盤、九宮格等這些都是抽獎的活動。
同樣是配置概率與獎品，所以后臺大可以用一樣的組件去配置兩個在前端看起來完全不同的活動。
用10個功能去解決100個需求。
六、產品工業化
很久之前已經有不少的廠商在探討【設計工業化】這個命題，之前也看了Antd關于這方便的分享。
設計工業化旨在減少設計師與開發之間的鴻溝，降低溝通成本。
那【產品工業化】至少有兩個目的：
- 同樣是減少產品與開發之間的鴻溝，提高開發效率；
- 降低用戶學習的負擔。
第一點：關于產品是否屬需要了解代碼知識，這個一直是有爭論的，業界亦有不是計算機科班出身的產品經理做出很出色的產品（例如網易云，王詩沐是工業設計出身），可聚焦回日常的細節，大多數產品都是普通的產品。
不少因為各樣實現而跟開發吵得不可開交，但是不可能讓每個產品都去明白背后的實現邏輯（甚至我認識的一些，是連接口文檔都不會看的）。
那有什么辦法讓不懂代碼的產品，可以降低與研發的鴻溝呢，我覺得就是需要產品工業化，產品用組件化的邏輯去思考。
例如對一個項目的操作，無論什么情況下都是右鍵擴展菜單，這樣開發就不需要為了實現不同的交互而又一次再一次編寫新的代碼。
但上面的方案估計會帶來很多質疑的聲音（包括我自己也曾經有過疑問）：這樣不會因為要降低與開發的溝通成本而降低用戶的體驗嗎？
大多數場景下都不寫新的交互，甚至死板地遵守過往的規則。
但直到我讀到About Face一書后，才發現我們的目的是共通的。
保持交互的一致性，有助于降低用戶的學習負擔，用戶的預期總是一致的：點擊右鍵，出現菜單。在我們的工具鏈上，對于所有項目，想知道該項目的擴展用法，唯一辦法就是右鍵。
（本來這里還想談一下，多交互以及豐富的功能會導致開發成本上漲，從而令每個客戶的攤分成本變得更高；但這個展開來說篇幅太長了，之后有空再談）。
七、互聯網、樂高與模具
我在之前砌樂高的時候，發現有個問題，為什么有一些步驟需要拿兩個一樣的高的積木砌成一個新的高度的積木（例如用兩個2cm高的積木，砌一個4cm的積木），為什么不直接出一個4cm的積木？
后來詢問做傳統企業的長輩才知道原來開模費是很高的，如果這個模型只會用在一兩個產品上，是不值得的。
傳統企業的人會精打細算，算出模具產出來的價值，再決定產品是否會用新模具，還是用以前的舊模具。
對于產品開發工作來說，做一個新組件就相當于開模，只有當我們新的模具具有足夠的理由或者市場價值時才應該去做一個新模具。
我一直覺得樂高是個很偉大的公司，他們用有限的積木類型，組建出近乎無限多的產品。
我相信這也是現在業界向往的一種狀態，無論是低碼平臺，還是antd的組件庫，都是希望用有限的組件類型，組建出近乎無限多的產品。
八、未竟之事
以上，是我歸納了這一年遇過的許許多多的事以及學習React對產品的一些反思。
產品與開發的鴻溝并非不可跨越，而降低開發與產品的溝通成本，亦會令產品更易于上手，用戶為之付出的成本更加低。
TO B產品并不是一定需要附贈一本超大加厚的說明書。
當然，還有一些事情還未能有答案，例如：如何去評價一個組件的可用性？也就是當新組件出來后，如何去測試用戶都能很好地理解呢？
一但沒經過測試，所有產品就用上，這樣將會影響所有產品的用戶；而后面需要更改時，也會傷筋動骨，需要去思考對每個產品會造成什么影響。
不過好在，現在有些組件已經經過驗證，可以暫時先直接拿來用；但組件終有一天會不夠用，如何測試自己創造出來的組件，仍是個問題。
本文由 @蔡包 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議。
感覺現在大廠的design足夠滿足大部分toB端的設計
我覺得歸根結底，很多產品欠缺的不是技術知識，而是程序設計的知識。做產品可以不懂具體的語言、代碼和實現，但是必須得有程序設計理念上的了解，對一個軟件產品到底是如何由一個一個組件和模塊搭建起來的，什么時候聚合什么時候解耦，最終產品設計需要兼顧的就是用戶體驗（或者業務需要）和程序設計，在這兩者之間找到一個最優解。
現在很多程序設計的理念，比如DDD之類的其實之所以要有一套領域建模的工具，其實更多的就是幫助不寫代碼的人能夠用其他的“語言”來理解程序的設計，統一項目內多方的理解方式。其實現在很多產品完全不理解程序設計，是得益于代碼只要有充分的時間幾乎是個萬能工具，不管如何設計最終都能完成99%的需求，限制非常低，放在其他領域的產品經理身上這是很匪夷所思的，比如一個手機產品經理不知道手機的元器件和構造，元器件之間的限制關系和關聯關系，手機的設計瓶頸，他幾乎沒辦法去規劃一款手機產品
B端產品、設計交互組件統一是必經之路啊，不用出一個新頁面必須等設計交付， 除非觸發未涉及到的元件
居然沒太看明白，但是看起來很厲害的樣子。期待更新
??這只是自己的一些思考，所以寫得很亂，沒有怎么去排版
產品工程化可以令業務明確時，大大減少畫原型圖的時間。