思考元件這件事，對於產品經理的產品思維訓練是有幫助的。本篇文章圍繞元件展開了一系列的思考，包括如何拆解元件以及元件的未來，感興趣的小夥伴們快來一起看看吧，希望對你有所幫助。

這篇文章是我對過去半年工作的一些思考，閱讀過程中需要一些背景知識的支撐，例如你需要理解「應用」、「低程式碼」、「元件」等概念。

當然，我會盡可能用簡單的語言去表達，但還是要首先說明，

這篇文章有一定的閱讀門檻。

一、元件背後的產品思維

在介紹什麼是元件之前，我想首先說明一下元件背後的產品思維，因為這是理解元件價值的關鍵。

所謂思維，

是從感性到理性的提煉結果

。感性是我們面對世界看到的現象，理性是我們從繁雜的現象中抽象出來的概念和規律。

例如，在外賣平臺沒有出現之前，我們感受到的現象是「無法堂食」和「想要立刻吃到東西」之間的矛盾，當這個矛盾成為一種普遍的社會現象時，能解決矛盾的外賣服務便出現了。

起初是門店給顧客留電話，顧客打電話訂餐品，門店老闆自己送。後來供應商多了，顧客需求多了，就出現了更高效地解決這個矛盾的平臺。外賣產品從一種感性的矛盾中脫胎出來，成為了一種新的概念和規律。這種規律就是，我開啟外賣 app，就可以獲得我周圍的可配送的美食。

外賣產品不是從天而降的，而是

感性層面的現象不斷累積，最終變成了理性的概念。

元件也是一樣。在網際網路早期，可能並沒有元件的概念（產品領域沒有，可能在技術領域是存在的），後來出現了一種現象是什麼呢？那就是

不同的業務應用，往往採用的都是同一種或者相似的產品框架來完成。

例如很多公司都有自己的後臺管理工具，他們很多時候可以抽象為對資料的增改刪查；又例如很多公司內建自己的專案管理工具，核心也是一種狀態機。

哪怕是現在的電商領域，無論是以天貓、京東為代表的貨架式電商，還是以抖音為代表的興趣電商，他們 app 首頁的產品框架也都是以記錄列表（什麼是記錄，此處就不展開）為核心。

這樣的現象隨著網際網路的高速發展而愈發明顯，繁雜的業務應用背後是通用的產品架構。但由於每個業務獨立核算、獨立運營，導致一套產品框架往往要在不同的業務中開發多次，也就是很多人討厭的

重複造輪子

現象。

誠然，在方案設計環節，產品經理會透過儘可能複用已有的成熟方案降低開發成本，但只要有一點點改動，從開發流程上來說就需要走一遍完成的流程。

這就導致業務方經常會問：“我就改這麼一點點東西，為啥還要排期到那麼晚”。我只能告訴你，生產關係就是這樣，在原有的系統裡無論你改的是什麼，可能都需要把所有干係功能都測一遍。

從上述現象中我們可以提煉出哪些矛盾呢？

很多業務應用的核心是相似的，但需要多次開發

凡是動程式碼的，可能就是慢的，程式碼開發、測試和釋出的速度趕不上業務變化的速度

在這種矛盾日益劇增時，元件出現了。

元件背後的產品思維，就是儘可能

將邏輯相似的程式碼塊抽象為通用的可配置的功能單元

，從而高效解決複用和個性化的矛盾。

它背後體現出元件的兩種特性：高通用、高可配。

並帶來兩種鮮明的業務價值：複用價值、相容價值。

二、為什麼要討論元件

在介紹元件的具體特性之前，我想說一說「為什麼要討論元件」。

首先，思考元件這件事，

對於產品經理的產品思維訓練是有幫助的。

我們知道，大多數產品經理以擁有好的抽象能力而自居。然而他們的抽象能力，大多是建立在業務需求上的抽象能力，非產品角度的抽象能力。

業務需求的抽象能力，追求的是用一個產品化的方案解決多樣化的業務需求。

例如業務方希望透過打折的方式在特定時間點對產品做促銷，這是一種從經濟學和心理學角度出發的業務訴求。當然要對哪些商品做促銷，促銷力度如何，促銷規則怎麼樣，都依賴於不同的業務方有不同的玩法。

有些希望做滿減促銷，有些希望做限時打折，有些希望搭贈一些臨期商品，從各自業務的角度看都是合理的，產品經理要做的事情就是用產品來滿足業務訴求。

但元件要求產品經理具備的抽象能力，是對產品的進一步抽象，並對最終抽象而成的模組做產品化。

例如我們經常在大促期間見到的各種活動頁面，雖然看起來風格不同，且每個頁面也都是跟業務溝通之後，確定下來的共識，但從產品角度看其核心是相似的。

很多電商促銷頁面主要包括商品、券、轉盤、動圖、按鈕、連結跳轉等要素，但抽象出來其實都是一系列的元件。

而這種從多樣化的頁面到元件的抽象過程，就是對產品的進一步抽象，這是一種產品思維的訓練。

其次，思考元件這件事，也有助於對產品經理這個行業未來的思考奠定基礎。

當我從事低程式碼行業的第一天我就在思考，如果我們在做的這件事做成了，那很可能意味著大批的程式設計師和產品經理的失業或轉型。

本質原因在於，

社會的發展會使得資源最終會流轉到最能用好它們的人手中，這是客觀的經濟學規律，不以人的物質為轉移。

還記得我們在第一部分提出的兩點矛盾麼：重複開發和慢迭代。須知這種矛盾的背後是人力和機器資源的巨大投入。這種投入還存在，是因為當下我們沒有更好的解決辦法。

但如果我們往5年、10年後看去，如果產品經理這個崗位帶來的業務價值已經低於他們存在本身帶來的資源消耗，那資源就會轉移到其他崗位上。

會不會出現這種現象呢，我不確定，但我認為應該警惕和思考。

像輕流這樣已經商業化的低程式碼產品，正在幫助中小型企業搭建一些簡單的表單應用，那原來準備投入到自研或外包中的資源，就節約下來了。

我一直在想，有沒有可能5 年後的網際網路產品生產端，

負責標準化模組（評論、訂單等）的產品經理會消失，取而代之的是低程式碼產品經理和業務產品經理，前者負責不斷完善底層工具和生態，後者負責面向不同業務方落地產品實施

。

僅作一猜測，擺在這裡。

三、拆解元件

這節，我將以騰訊微搭產品為例子，帶大家一起拆解元件。要拆解元件，首先要對元件做定義、分類和內部結構分析。

在我看來，

元件是可被複用的完整的產品功能模組。

可被複用是元件最顯著的特徵。因為它是對產品的進一步抽象，說明它可以出現在不同的產品中，進而在搭建應用時，它可以出現在不同的頁面中。

完整是指元件代表了一個完整的使用場景。例如下圖中的文字元件，它代表的場景是在頁面中展示一段文字。且頁面中任何使用到文字的地方，都可以拖入這個元件，它也是通用的。

從這個定義出發，線條就不是一個元件，因為單單一個線條不能代表任何完整的使用場景，儘管它是可複用的。

最後，元件是一個功能模組，我所理解的功能，是它具有處理資訊的能力。再抽象一些，它有自己的輸入、作用和輸出。

要進一步拆解元件，首先要對元件做分類。

原子元件：不能被進一步拆解的元件，代表了某個功能場景下的最小粒度。

例如上述的文字元件就是一個原子元件，因為我不可能再進一步拆解出一個字元元件。它也代表了當我需要在頁面展示文字資訊時，在這個場景下我需要的最小功能模組。

複合元件：由原子元件組合而成的元件，代表了複雜場景下的功能模組。

例如下圖的表格元件。這種元件往往更貼合某種實際的使用場景，比如管理一張表格，或者填寫一個問卷，他們的目標是在對應的複雜業務場景下，可以有更便捷的方式搭建出對應的功能模組來。

原子元件由於粒度小，所以在搭建時的

自由度更高

，理論上如果一個平臺的原子元件足夠豐富，那麼可以搭建出非常複雜的應用出來。但它的劣勢在於，

搭建門檻非常高

。

以上圖的表格元件為例，拆開來看它包括的原子元件是：按鈕、複選框、文字、搜尋框等元件，但如果我只給你提供這四個原子元件，讓你搭建出上圖這樣的效果，估計你會崩潰的。

複合元件由於更貼近實際使用的場景，所以

搭建門檻更低

。

例如對上述表格來說，我只需要給元件關聯對應的資料模型，然後做一些欄位和樣式配置，基本上在 5 分鐘內就可以搭建出一個能對資料表做增改刪查的管理表格。

但另一方面，它的靈活性也相對被降低了，因為很多佈局和樣式都是預設好的，沒有可以進一步編輯的功能，所以

相容性較差。

從上面的分析可以看出，不同的元件儘管都可以代表完整的功能場景，但設計上還是有不同的考慮，這種考慮往往是

自由度和使用體驗之間的平衡

。這也是元件本身固有的矛盾。

元件的功能拆解，需要從輸入、作用和輸出三個角度來說。我們以經常用到的美食篩選場景為例。

上圖是大眾點評美食頻道頁裡的篩選功能，我可以透過選擇美食的種類，進一步縮小我看到的頁面資訊的範圍。那在低程式碼產品中，這種功能模組怎麼搭建出來呢。

首先我們需要使用一個下拉選擇元件，注意，這個元件是一個抽象的元件，它既不代表美食的篩選，也不代表距離的篩選。它表達的意思是：

這個元件提供了在下拉框中完成單選的功能。

要給這個元件賦以業務含義，就必須向它注入資料。例如，給這個元件關聯美食品類的資料表，這樣下拉選擇後的每一個選項，代表了一種美食品類。

有了輸入之後，就需要對輸入做處理，那下拉選擇元件是怎麼處理的呢？它提供了一種特性，叫做

使用者在 app 上點選選中的資料，就代表了這個元件最新的值

。

你選擇了火鍋，業務上代表了你在美食品類中選擇了火鍋，產品上代表了你在下拉選擇元件中，透過前端頁面的點選，給元件賦值，這個值就是火鍋這個選項資料。

最後是輸出，輸出是該元件作為一個獨立的功能模組，能夠給頁面、或者頁面內的其他模組傳遞的資訊。在上述例子中，從業務上看，當我們選擇了火鍋之後，商戶列表就完成了一次重新整理，並且重新整理之後只展示跟火鍋相關的商戶。

但產品原理上並不簡單。首先，在搭建的時候，需要在頁面內建立下拉選擇元件和商戶列表元件之間的關係，是的，看起來內容很多的商品列表，其實也是一個元件。建立的是什麼關係呢？是一種

篩選邏輯關係

。

在商戶列表元件的篩選條件中，我們需要加上，這個列表中每個商戶的美食品類需要等於下拉元件中選擇的美食品類。

在這個邏輯關係中，下拉元件的值作為輸出，就被商戶列表元件使用了，這種關係，用偏技術的話說叫做「消費」，就是我用了你給我的東西。

以上只是下拉選擇元件在實際 app 中的一個很簡單的應用，事實上元件的輸入、處理和輸出遠比這個場景要複雜很多。

但無論有多麼複雜，從這三個角度去分析元件的功能我理解基本都是可以的。

如何設計一款元件呢？這是很多低程式碼產品經理面臨的課題，也是我在過去半年內從事的主要工作。一個完整的元件設計方案，需要重點考慮三個問題：

屬性：這個元件的功能是什麼

樣式：它長什麼樣子

行為：它跟其他模組之間如何互動

屬性如我們剛剛所述，需要考慮元件的輸入、處理和輸出。還是以微搭中最簡單的文字元件為例。

可以看到微搭的文字元件提供了兩個最基本的屬性配置項：內容和格式。它解決的就是一個問題：這個元件需要以什麼方式展示什麼內容。

樣式決定了這個元件長什麼樣子，例如它在展示區域內的間距、位置，它是否有背景色等等。樣式的配置能力跟很多設計軟體提供的能力很像，在此就不贅述。

最後是行為，它告訴系統的就是一個問題：

當發生了什麼事情時，會執行什麼動作。

發生了什麼事情，我們一般叫做觸發事件。

它往往是一個可被捕獲的前端事件，例如點選、失焦、hover 等。而執行的動作，就是產生了這些事件時，接下來需要做什麼。

例如下圖是一個表單複合元件，當我們點選提交按鈕時，它捕捉到的是 click 這個事件，接著會執行的動作可能就是，將提交的資料更新到資料庫。

行為往往是進行元件和元件之間以及系統和系統之間通訊的橋樑，如果有機會我們可以再好好聊聊元件的行為。

四、元件的未來

我先丟擲我的看法：

元件未來一定要建立起生態，且元件生態一定是市場化的。

元件要解決的問題，類似於 SaaS 產品在現階段想要解決的矛盾：以標準化的解決方案滿足多樣化的業務訴求。

從發展的眼光看，業務訴求豐富度的增長，一定是快過產品解決方案能滿足的場景的增長，所以一定要部分場景是標準化的解決方案覆蓋不了的。這一點從國內外的 SaaS 廠商紛紛佈局自己的 PaaS 能力可以看出。

同樣的，雖然元件滿足的是快速搭建業務應用的場景，但目前絕大多數的低程式碼產品，其元件的設計還是中心化的：

平臺負責設計，開發者使用

。當開發者的訴求無法被滿足時，他們提出了新的需求，平臺開發新的元件。

問題是：這種中心化開發的模式下，元件可以被稱為元件的前提是，它必須要有一定的通用性，不受場景的侷限。這個前提本身就限制了元件模式的天花板。

事實上回歸元件的定義：可複用的完整功能模組。在這個定義下，我們並不強調元件一定要由平臺生產和定義，平臺能不能提供生產元件的能力，由眾多開發者自己生產，自行使用呢。我理解是可以的，且在國外產品中已經構建起這樣的市場了。

在一款低程式碼產品中，我們已經能看到，當系統提供的元件不能滿足你的搭建訴求時，你可以在元件市場中安裝更多的元件，而這些元件可能就是由第三方服務商開發完成的。

透過平臺，充分連線起元件生產者、元件使用者、應用使用者等不同的利益相關方，這樣的生態會使得有越來越多的為垂直行業而服務的複合元件出現。

五、結語

這篇文章大致呈現了我對元件相關的思考，由於篇幅的限制，以及出於可讀性的考慮，與元件相關的頁面、流程、模型、變數等概念就沒有提及，但你需要知道對於一款完整應用來說，以上這些都是很重要的系統。

其實，從 0 到 1 開發一款應用並沒有那麼容易，

當我從事低程式碼之後，我才體會到一款應用產生的背後會牽涉到如此複雜的系統，這是我以前工作的盲區。

在這之前我作為產品經理，更多關注的是使用者和客戶的價值，較少關注產品的實現邏輯。這也是絕大多數產品經理的通病，否則也不會出現「這個需求很簡單，怎麼實現我不管」這樣的段子。

但如果你真正走到產品背後，去從搭建的角度思考一款應用的從 0 到 1 ，你會對這份工作

產生更多的敬畏之心的。

這是我半年來最大的收穫。

專欄作家

大力哥呀，微信公眾號：大力哥，人人都是產品經理專欄作家。一個90後產品經理，已經寫了6年的公眾號，透過輸出獲得了許多意料外的成長。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。