編輯導(dǎo)語：產(chǎn)品工業(yè)化對于產(chǎn)品經(jīng)理和開發(fā)而言，有著重要的意義。本篇文章中，筆者結(jié)合React哲學(xué)分享了自己對產(chǎn)品思考。感興趣的小伙伴不妨來看看，說不定能幫到你哦。

在經(jīng)歷了許許多多的項目之后，我發(fā)現(xiàn)我累積了大量原型圖，好奇再次打開，發(fā)現(xiàn)其實里面有大部分是大同小異的；

但是基本每個項目的原型都是重新做過，重新做過就意味著邏輯需要重寫，重寫又意味著會跟研發(fā)有理解上的沖突。

在以往的項目中也遇到過其他產(chǎn)品經(jīng)理跟開發(fā)們發(fā)生了爭執(zhí)，甚至還鬧得要離職。

一直以來，我在反思兩個問題：

1. 是否有辦法能快速產(chǎn)出原型？
2. 產(chǎn)品與開發(fā)的想法是天然沖突的嗎，是否只有產(chǎn)品去學(xué)習(xí)代碼知識才能解決這個問題？

剛好最近學(xué)習(xí)了React，從中得到了一些思考和解決方案，特別是它崇尚的哲學(xué)：

單一責(zé)任原則 與 組件化（當(dāng)然React的哲學(xué)有很多，但這兩樣是令我最深刻的），或許解決問題二的關(guān)鍵，正是先解決問題一。

首先，簡介一下React：這是一個開發(fā)行業(yè)內(nèi)比較著名的JS框架，開發(fā)會用這些JS框架去編寫APP、小程序、web。

而React最核心的哲學(xué)也就是：“組件化”，將一個頁面分成一個個小組件，各司其職。

一、原型不應(yīng)該成為最花時間的部分

沖突來源于大家對同一事物的理解不同，例如做項目A時，開發(fā)會覺得這樣寫，代碼會簡潔；

但是產(chǎn)品會覺得那樣做，用戶更加方便；

當(dāng)我們另外做一個相近的業(yè)務(wù)時，開發(fā)覺得業(yè)務(wù)差不多，想引用之前代碼；

但這時候產(chǎn)品會因為具體的業(yè)務(wù)場景，去改動某一些的功能（例如可能在公告中，延時關(guān)閉變更為主動關(guān)閉）。

這時候會帶來一些問題：

1. 產(chǎn)品需要重新做出這個功能的原型、交互、寫好該公告的邏輯 ；
2. 開發(fā)可能無法知道是否要另外寫一個【公告】組件，還是把之前的【公告】改一下，抽成公用的組件呢？

這些問題幾乎每天都在發(fā)生，我打開了我之前的原型圖，發(fā)現(xiàn)里面也充斥著這類的問題，例如一個對話框：

（兩個都是對話框，但在原型上來說，每一個項目，對話框都要重新做一次，包括顏色、圓角、按鈕的大小與位置）。

然后像React完成組件一樣，將對話框的參數(shù)抽離出來：

對話框的寬、高、標(biāo)題，按鈕觸發(fā)后的交互、是否存在cancel按鈕、內(nèi)容……

再將這些內(nèi)容的交互邏輯定義好，例如標(biāo)題超過X個字會截斷，點擊【確定】完成業(yè)務(wù)后會關(guān)閉對話框，什么場景下才允許使用對話框？

以后任何原型需要用到對話框時，只需要拿以前的框架，再往里面填充內(nèi)容就可以了。

至此，我們可以將大量的時間放到用戶調(diào)研以及觀察身上，而不是去畫原型圖或者擔(dān)心這樣的交互是否，是否會導(dǎo)致開發(fā)成本過高，因為從組件建立之初，這種問題就討論過了。

二、是否遷就開發(fā)，降低體驗

以上這樣做，可能會觸碰到一個產(chǎn)品們經(jīng)常討論的問題，是否為了開發(fā)的便捷而犧牲用戶的體驗?zāi)兀?/p>

但其實并不會的，正如《微信背后的產(chǎn)品觀》而言的：“如果一個東西實現(xiàn)起來特別復(fù)雜，它大抵是錯的”。

而這樣做對于用戶也是大有益處的，統(tǒng)一標(biāo)準(zhǔn)及公用組件可以大大降低用戶的心智負(fù)擔(dān)。

特別是在一個產(chǎn)品鏈上時，不同的產(chǎn)品應(yīng)該統(tǒng)一的交互，統(tǒng)一的視覺，統(tǒng)一的組件（至少在TO B端的產(chǎn)品應(yīng)該如此）。

再在內(nèi)容上按照業(yè)務(wù)的需要定制（例如標(biāo)題，高度，內(nèi)容等）。

實際上，在業(yè)界早已有團(tuán)隊在探索這些方案，Antd Design就已經(jīng)有全套覆蓋的資源了：產(chǎn)品-》設(shè)計-〉研發(fā) ；

但這事情可以更進(jìn)一步討論。

這也正是今天的主題：由React的價值觀得出來的反思。

首先在TO B的復(fù)雜多變的業(yè)務(wù)里，是否每一個差不多的組件都應(yīng)該抽象成公用呢？

這問題就如上文所述的一樣，開發(fā)認(rèn)為差不多應(yīng)該抽成公用的組件。

但是產(chǎn)品說場景不一樣，從而做了一個功能差不多但又不完全一致的組件，這時候沖突就會爆發(fā)。

竊以為一個組件究竟該變成公用還是按照特殊例子來處理，需要的是知道其功能，也就是【單一責(zé)任原則】。

例如一個【操作成功的提示】，在任何的業(yè)務(wù)中即時操作成功都應(yīng)該用此提示，不應(yīng)該有變體。

但是如果這個操作是一個【異步】操作，例如【轉(zhuǎn)賬】，需要等待別的銀行或者中央財務(wù)系統(tǒng)返回信息的，這時候就不應(yīng)該用上述的提示。

因為一個異步的提示至少有兩個任務(wù)需要完成：

1. 告知用戶目前任務(wù)的進(jìn)行狀態(tài)（進(jìn)行中、完成、業(yè)務(wù)失敗、接口失?。?/li>
2. 成功或者失敗時告知用戶下一步的操作（例如失敗，需要前往哪里糾正；轉(zhuǎn)賬成功，有地方可以前往轉(zhuǎn)賬詳細(xì)的地方，因為此時用戶很可能已經(jīng)到訪了另外的頁面）；

如下例子：

以往經(jīng)常會有這樣的爭執(zhí)：

例如為什么兩個差不多的組件不把它做成同一個呢？這樣就不需要開發(fā)兩個組件了；

但如果組件在不同的場景下服務(wù)于兩個目的，即便這兩個組件只有一個按鈕之差，都不應(yīng)該抽象成一個組件；

因為后續(xù)業(yè)務(wù)可能會繼續(xù)有增刪，一開始兩個業(yè)務(wù)可能會很相近。

例如金融系統(tǒng)中的【對私人轉(zhuǎn)賬】，與【對公司轉(zhuǎn)賬】，剛開始甚至可能會做成一個頁面，判斷輸入的是公司類型還是個人類型，再顯示字段；

但隨著業(yè)務(wù)的增長，對公司的轉(zhuǎn)賬可能需要更多的認(rèn)證，更多的引導(dǎo)。

屆時產(chǎn)品會一直在業(yè)務(wù)中加邏輯，但是開發(fā)可能并不想在同一個頁面寫這么多的判斷！

若我們都遵循【單一責(zé)任原則】這樣的問題就迎刃而解。

三、組件化

這里應(yīng)該要感謝阿里與螞蟻金服，在經(jīng)歷了【餓了么】組件，【京東】組件，還有一些小型的組件之后，螞蟻金服的組件是最具理論價值和實用性的。

當(dāng)然，組件并不是螞蟻金服最早提出的，實際上我在前幾年接觸 cocos引擎的時候已經(jīng)是組件化的，而虛幻引擎是面向?qū)ο蟮摹?/p>

我亦好奇去查了一下知乎大家對這兩種編程方式的優(yōu)缺點爭論，這些就是后話了。

回到產(chǎn)品身上，為什么組件化對我們也如此重要呢？

在這里我需要借用一個概念：“設(shè)計工程化”，所以我們暫且稱為：“產(chǎn)品工程化”，產(chǎn)品工程化可以令業(yè)務(wù)明確時，大大減少我們畫原型圖的時間。

我們只需要確定一些基本的元件，然后按照業(yè)務(wù)搭配就可以了，每一個產(chǎn)品用同一套組件，可以大大剩下與研發(fā)溝通的成本。

例如在下圖中定義了一個素材組件，此組件有一個素材名稱、素材封面圖、素材類型、素材鏈接；

于是在任何產(chǎn)品的素材庫中，我都用了如下的原型，并將交互邏輯抽成一份公用的文檔(例如點擊可以查看，或在激活狀態(tài)下點擊名稱可修改名字)，這樣開發(fā)甚至可以直接把代碼copy過來。

然后我們再定義一個組件，叫右鍵菜單：這樣素材右鍵時會觸發(fā)一個菜單，這兩個組件就組成一個新的組件。

無論這個素材是圖片還是視頻，都會有這個右鍵菜單。

若對于某些項目右鍵菜單的某些選項是無法使用的，只需要將其隱藏或者disable就可以了。

無論怎么變化，這個組件的結(jié)構(gòu)始終沒有變，仍然是：一個右鍵菜單、素材名稱、素材封面圖、素材類型、素材鏈接。

有些產(chǎn)品會不同意這個做法，例如這個素材假如只剩下兩個操作的時候，最好的辦法是將操作平鋪出來。這樣做我們可以再做多一個組件：

這樣素材組件加上這個操作組件，又可以形成一個新的組件；

那么至少 “素材組件+操作組件” 和 “素材組件+菜單組件”，這樣已經(jīng)可以覆蓋90%業(yè)務(wù)。

而且具有高度可擴(kuò)展性，例如以后業(yè)務(wù)需要素材可以復(fù)制，那就在菜單增加【復(fù)制】就可以。

以后有別的業(yè)務(wù)，例如現(xiàn)在有一個項目管理的系統(tǒng)需求，同樣，我們可以將該組件用在這個系統(tǒng)里。

（同樣具有項目封面、項目名稱、項目鏈接，以及一個右鍵菜單）。

四、什么時候應(yīng)該增加新組件？

像《About Face》中說的：“遵守規(guī)則，除非有極好的選擇”；

特別對于TO B端的產(chǎn)品，更加需要的是提升業(yè)務(wù)的效率，復(fù)用組件可以降低學(xué)習(xí)的負(fù)擔(dān)（某些情況下，可以有情感化的設(shè)計，但這并不是主要的，特別是政府的系統(tǒng)，我從來就沒見過什么情感化的設(shè)計）。

但遵守規(guī)則，不代表墨守成規(guī)（這也是出自About Face的）。

如上面的例子，如果一個項目的操作只有1～2項，這時候右鍵菜單就會成為操作的負(fù)擔(dān)（即便右鍵是一個簡單的習(xí)慣用法）。

這時候可能把操作平鋪操作，是一個最佳的選擇，于是乎我們選擇添加一個新的組件。

在任何情況下，我們都應(yīng)該先采用已有的組件，直到無法滿足業(yè)務(wù)。

遵守規(guī)則，除非有極好的選擇——《About Face》

五、關(guān)于繼承與組件

在《微信背后的產(chǎn)品觀》中，張小龍分享了一個產(chǎn)品的方法：設(shè)計就是分類；

如果用戶有100個需求，應(yīng)該將其抽象成10個需求去解決這100個問題。

這是一種很聰明的做法，也是我現(xiàn)在一直在努力效仿的做法；

比如，現(xiàn)在有多個活動：砍價、簽到、抽獎、優(yōu)惠券等等；

通常的做法是將他們平鋪放在一個頁面（如下圖），每進(jìn)入一個活動，都各自有一個活動列表。

某個服務(wù)商的活動

這樣做可以顯得自己有很多功能，卻同時會帶來一個問題：

如果用戶創(chuàng)建了多個不同類型的活動時，他要查看一個活動的數(shù)據(jù)。

首先得記得這個活動是屬于什么類型，它究竟是屬于優(yōu)惠券，還是裂變優(yōu)惠券；再點擊進(jìn)入查看活動數(shù)據(jù)。

但我們細(xì)心觀察，會發(fā)現(xiàn)他們有幾個元素是一致的。

如它們都擁有一個活動標(biāo)題，活動的期限，活動的封面圖，活動的簡介。

只需要加多一個字段：活動類型，就完全可以在一張表中區(qū)分。

進(jìn)行了這樣的設(shè)計后，仍然會有人來問：如何創(chuàng)建活動，但我們只需要講解一次，后面用戶就知道在哪里創(chuàng)建。

像上述例子，還會誕生一個對開發(fā)不友好的問題，例如彈窗廣告；

彈窗廣告的功能是，用戶進(jìn)入后會彈出一個廣告；

但由于后臺是個列表，用戶可以創(chuàng)建多個彈窗廣告，這樣使得開發(fā)上不得不增加一個邏輯：

同一個時間內(nèi)，只允許彈出一個彈窗，并且以新創(chuàng)建的為準(zhǔn)。

用戶創(chuàng)建時必須小心翼翼地去調(diào)整彈窗的“活動時間”，看看有沒有與之沖突的彈窗。

但《微信》的書中對抽象這個產(chǎn)品的方法僅僅只是一頁紙，沒有更多的講解。

我們可以用組件化的方法將這個理論繼續(xù)擴(kuò)充。

活動中有共同的元素，例如活動名稱和時間，我們可以抽成兩個組件，這些組件擁有共同的樣式和交互（例如無法選擇超過結(jié)束日期的時間），每個活動的主體再另外配置。

甚至可以更進(jìn)一步：例如轉(zhuǎn)盤、九宮格等這些都是抽獎的活動。

同樣是配置概率與獎品，所以后臺大可以用一樣的組件去配置兩個在前端看起來完全不同的活動。

用10個功能去解決100個需求。

六、產(chǎn)品工業(yè)化

很久之前已經(jīng)有不少的廠商在探討【設(shè)計工業(yè)化】這個命題，之前也看了Antd關(guān)于這方便的分享。

設(shè)計工業(yè)化旨在減少設(shè)計師與開發(fā)之間的鴻溝，降低溝通成本。

那【產(chǎn)品工業(yè)化】至少有兩個目的：

1. 同樣是減少產(chǎn)品與開發(fā)之間的鴻溝，提高開發(fā)效率；
2. 降低用戶學(xué)習(xí)的負(fù)擔(dān)。

第一點：關(guān)于產(chǎn)品是否屬需要了解代碼知識，這個一直是有爭論的，業(yè)界亦有不是計算機(jī)科班出身的產(chǎn)品經(jīng)理做出很出色的產(chǎn)品（例如網(wǎng)易云，王詩沐是工業(yè)設(shè)計出身），可聚焦回日常的細(xì)節(jié)，大多數(shù)產(chǎn)品都是普通的產(chǎn)品。

不少因為各樣實現(xiàn)而跟開發(fā)吵得不可開交，但是不可能讓每個產(chǎn)品都去明白背后的實現(xiàn)邏輯（甚至我認(rèn)識的一些，是連接口文檔都不會看的）。

那有什么辦法讓不懂代碼的產(chǎn)品，可以降低與研發(fā)的鴻溝呢，我覺得就是需要產(chǎn)品工業(yè)化，產(chǎn)品用組件化的邏輯去思考。

例如對一個項目的操作，無論什么情況下都是右鍵擴(kuò)展菜單，這樣開發(fā)就不需要為了實現(xiàn)不同的交互而又一次再一次編寫新的代碼。

但上面的方案估計會帶來很多質(zhì)疑的聲音（包括我自己也曾經(jīng)有過疑問）：這樣不會因為要降低與開發(fā)的溝通成本而降低用戶的體驗嗎？

大多數(shù)場景下都不寫新的交互，甚至死板地遵守過往的規(guī)則。

但直到我讀到About Face一書后，才發(fā)現(xiàn)我們的目的是共通的。

保持交互的一致性，有助于降低用戶的學(xué)習(xí)負(fù)擔(dān)，用戶的預(yù)期總是一致的：點擊右鍵，出現(xiàn)菜單。在我們的工具鏈上，對于所有項目，想知道該項目的擴(kuò)展用法，唯一辦法就是右鍵。

（本來這里還想談一下，多交互以及豐富的功能會導(dǎo)致開發(fā)成本上漲，從而令每個客戶的攤分成本變得更高；但這個展開來說篇幅太長了，之后有空再談）。

七、互聯(lián)網(wǎng)、樂高與模具

我在之前砌樂高的時候，發(fā)現(xiàn)有個問題，為什么有一些步驟需要拿兩個一樣的高的積木砌成一個新的高度的積木（例如用兩個2cm高的積木，砌一個4cm的積木），為什么不直接出一個4cm的積木？

后來詢問做傳統(tǒng)企業(yè)的長輩才知道原來開模費(fèi)是很高的，如果這個模型只會用在一兩個產(chǎn)品上，是不值得的。

傳統(tǒng)企業(yè)的人會精打細(xì)算，算出模具產(chǎn)出來的價值，再決定產(chǎn)品是否會用新模具，還是用以前的舊模具。

對于產(chǎn)品開發(fā)工作來說，做一個新組件就相當(dāng)于開模，只有當(dāng)我們新的模具具有足夠的理由或者市場價值時才應(yīng)該去做一個新模具。

我一直覺得樂高是個很偉大的公司，他們用有限的積木類型，組建出近乎無限多的產(chǎn)品。

我相信這也是現(xiàn)在業(yè)界向往的一種狀態(tài)，無論是低碼平臺，還是antd的組件庫，都是希望用有限的組件類型，組建出近乎無限多的產(chǎn)品。

八、未竟之事

以上，是我歸納了這一年遇過的許許多多的事以及學(xué)習(xí)React對產(chǎn)品的一些反思。

產(chǎn)品與開發(fā)的鴻溝并非不可跨越，而降低開發(fā)與產(chǎn)品的溝通成本，亦會令產(chǎn)品更易于上手，用戶為之付出的成本更加低。

TO B產(chǎn)品并不是一定需要附贈一本超大加厚的說明書。

當(dāng)然，還有一些事情還未能有答案，例如：如何去評價一個組件的可用性？也就是當(dāng)新組件出來后，如何去測試用戶都能很好地理解呢？

一但沒經(jīng)過測試，所有產(chǎn)品就用上，這樣將會影響所有產(chǎn)品的用戶；而后面需要更改時，也會傷筋動骨，需要去思考對每個產(chǎn)品會造成什么影響。

不過好在，現(xiàn)在有些組件已經(jīng)經(jīng)過驗證，可以暫時先直接拿來用；但組件終有一天會不夠用，如何測試自己創(chuàng)造出來的組件，仍是個問題。

本文由 @蔡包 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議。