在做低代碼產品的過程中，產品經理可能會遇到各種各樣的問題，比如部分產品經理可能會因為對數據模型的不熟悉，而在實際對接中產生一定障礙。所以產品經理要如何在低代碼工作中鏟除障礙、并進行決策？本篇文章里，作者結合低代碼平臺的數據表格組件重構進行了案例解讀，也許會對你有所啟發。

我在之前寫過關于低代碼工作的兩次復盤，一次是關于做低代碼工作的整體思考，一次是關于做組件的一些思考。但無論是哪一篇，我自認為都不夠落地，沒有能夠呈現我們在具體做事情時會遇到哪些問題，我們又是如何決策的。

正好這段時間在做一個比較大的項目，涉及到對我們低代碼平臺已有數據表格組件的重構，而數據表格又是一個講出來大家都能懂的模塊，我覺得很適合用來復盤，讓那些即使沒有做過低代碼的產品經理，也可以看的懂，看得進去。

因為信息的敏感性，涉及到項目的具體內容不會在本文中呈現，我會用盡可能通用的語言，帶大家一起回顧整個設計過程及背后的思考。

01

如果你做過中后臺產品，那么你對數據表格一定不陌生。下圖是一個 SaaS 產品中包含數據表格組件的頁面。

數據表格能夠對一系列數據信息作展示，同時提供常用的增、改、刪、查功能。說數據表格是 B 端產品的核心模塊之一可能一點也不為過。

但不同的產品在設計數據表格時，所采用的視角是不一樣的。如果是一名 SaaS 產品的產品經理，在設計時需要從業務訴求出發，考慮這個表格如何能夠更好的為業務服務。這就包括：需要有哪些字段，每個字段展示什么內容，這些內容是否支持點擊跳轉，表格中的每行記錄需要提供哪些操作，對整個表格需要提供哪些操作等等。

所有這些設計的出發點，可能會受到用戶的背景、使用習慣、操作場景等因素的影響。

但低代碼產品經理去設計數據表格時，面對的場景是，這個數據表格是搭建出來的，如果有一些特別高級的功能，可能需要一些 coding 工作，但對于場景的操作，應該都是通過拖拉拽配置出來的。

無論是開發者配置還是業務人員配置，低代碼產品經理面臨的挑戰是：我們見到的這個表格呈現出的功能和樣式，只是配置結果眾多可能性中的一個，我們需要考慮更多的可能性。所以低代碼產品經理看待表格的視角需要且必須更抽象。

02

從低代碼產品的角度出發，對數據表格的設計有兩種思路，也是兩種不同的原則：高易用性和高天花板。

高易用性的原則是：組件的所有功能都做成配置項或者封裝邏輯，搭建時需要的所有功能，都能通過一個組件的配置就可以搞定，這樣對開發者來說，使用起來就十分爽了。

高天花板的原則是：將獨立的模塊盡可能原子化，通過原子化組件的排列組件，尋求能支持的業務場景的最大可能性，這樣對開發者來說，使用門檻會高得多，有時候甚至是違反直覺的，但功能會更強大。

但無論是哪種原則，數據表格首先都應該關注數據源的問題，這也是模型驅動的低代碼產品的特征之一。

03

模型驅動，是指數據模型和數據展示是分離的。數據模型層負責數據的獲取與加工，數據展示層負責對加工好的數據做展示，并提供對應的增改刪查功能。

以國內低代碼平臺微搭為例，在它的核心模塊中，就包括「數據源」這個模塊。

數據源模塊完成的就是對某一個業務場景做建模，例如對一篇文章來說，我需要記錄它的標題、作者、文檔分類等等信息，于是在建模過程中，我需要定義這些字段和對應的數據類型。微搭還提供了API接口，可以接入第三方系統的數據。

而國外的低代碼平臺retool，甚至提供了在前端直接用 sql 對數據做加工的能力，開發者自定定義數據的 query，且組件可以直接消費這個 query。

關于低代碼的數據模型功能，不是本文的重點，在此不做贅述。我只想表達，如果做數據表格的產品經理不了解表格背后的數據源，是不可能做好數據表格的。

講到這里你應該清楚了，數據表格組件是對加工好的數據做前端展示，并提供增、改、刪、查、導出等基本能力。而數據的獲取和加工，則是在數據模型層內解決。

04

下面聊聊我在這次項目中遇到的具體訴求。

在今年下半年，我們低代碼團隊接到了一個項目，需要完成公司內部一個復雜系統的遷移工作，從之前的 fullcode 模式遷移為 lowcode 模式。該系統的核心功能是提供不同角度的數據展示與分析結果給內部的業務leader，幫助他們做更好的業務決策。

數據表格和圖表是該系統的兩個核心模塊。

接到項目之后，我們立刻著手做需求分析，發現該系統對數據表格的能力要求，是當時已有的數據表格組件所無法滿足的。

這就要說到在那個節點，我們已有的數據表格的能力。

前面提到，行業內的數據表格組件有兩種設計思路，而我們已有的數據表格采用的是高易用性原則：即所有的擴展能力都做成組件的配置功能。核心功能包括：接入數據源，添加數據字段，添加數據操作按鈕，添加搜索、篩選、導出、排序等周邊能力。

而這個復雜系統在這些基本功能之外，還希望實現表格內嵌表格 （主子表）、單元格展示圖表、自定義某一列的展示內容（一個列可以展示多個字段的值）等能力。

到了這里，我們就開始推演，如果已有的數據表格都補齊這些能力，成本多大，產品會變成什么樣子。我們發現，如果延續之前的高易用性設計原則，會使得整個組件變得非常冗雜，變成一個看起來什么都能支持，但用起來配置項巨多的怪物。

于是我們在想，是不是應該換個思路了。

05

我們接著去調研市面上更多優秀的產品是如何做數據表格的，發現還有另一種解法，他們的設計思路正是高天花板原則。

簡單來說，他們將數據表格進一步分解為兩個部分：內容和容器。

內容就是表格的表頭和單元格中顯示的內容，包括文本、圖片、按鈕等等，這些內容分別都用對應的組件去展示。而容器是數據表格的行和列，是一個具備表格框架的且可以綁定數據源的空白插槽，里面可以放置任何東西。在這個點上做到極致的是 bubble.io，拖入該組件時呈現的是一個完全空白的容器，你很難將它跟表格聯系在一起。

那容器和內容是如何聯系起來的呢，通過上下文（context）。

以 bubble.io 的容器為例，當該容器綁定了下圖所示的球星資料表時，容器的每一行會自動關聯表格的每一條記錄，此時的容器盡管看起來還是空白的，但它的背后是有數據的。

這時候，如果我向第一行第一列這個單元格內拖入一個文本組件，并且關聯「球隊」這個字段，那文本組件展示的信息會是「老鷹」。

你可能會問，上面這個表有 12 行，如果按照這個搭建方法，我需要在容器中拖入 12 次文本組件，才能將所有球星的「球隊」信息展示出來么？ 事實上，該容器是一個可重復容器（有的產品叫也循環容器），僅需要在第一行拖入組件，那后面的所有行都會重復第一行的配置。這是因為，對數據源來說，行與行之間的字段是相同的，有差異的僅僅是字段的值。

在這種思路下，表格的搭建流程就變為：拖入容器，關聯數據源，拖入組件，綁定數據源中的某個字段。

但我們進一步調研發現，盡管很多低代碼產品提供了容器和內容分離的功能，但面向用戶提供表格搭建的功能時，卻很少有像 bubble 這么做的。

我們自己用起來也發現，太難用了，跟我們日常對數據表格的印象相比，這樣的搭建思路簡直反人類。

微搭和 outsystems 等低代碼廠商提供的解法是，當表格綁定數據源時，盡可能給到完整的默認配置。他們會默認展示數據源中的一些字段以及對應的字段值，但同時也支持空白列的形態，從而滿足某些個性化程度很高的業務訴求。

空白列的特征是，可以根據業務的訴求自己設計單元格插槽內要使用的組件。

最終，我在本次項目中采用的設計原則是：兼顧易用性和天花板。一方面通過綁定數據源之后的默認配置，讓開發者在搭建表格的常規功能時，只需要盡可能少的步驟；另一方面通過內容、容器分離的設計思路，讓開發者需要搭建復雜表格時，可以通過空白插槽+組件的配置方式滿足其訴求。

這種兼顧并不容易，理論上，所有的平衡都沒有一個統一的標準，有時候隨著面對大家的肯定或吐槽，我們也會在不同的平衡度之間徘徊不定。

最典型的例子是，很多數據表格會自帶搜索、排序、篩選等功能，這些是對數據的基本查詢操作。而讓我們感到為難的是，這些功能是應該作為一個獨立的組件，還是作為表格自身的一個配置屬性。

如果作為組件，那就代表著這些組件除了跟表格一起使用，也可以跟其他組件一起使用。理論上，任何使用數據源的組件，都可以帶有搜索、排序、篩選等功能，因為這些功能的底層，就是數據查詢中的filter、sort、search 等函數。如果作為配置屬性，那開發者就不需要關心這些屬性的底層邏輯，他們只要關心從業務的角度來說，當前這個表格是否需要支持終端用戶自己對表格數據做對應的查詢即可。

我們在這兩種方案間搖擺了很久，最終決定堅持高天花板的設計思路。因為我們相信我們的低代碼平臺最終需要能夠以極小的成本搭建出更復雜的系統，這是它的價值所在。

06

到這周，整個項目進入了最后的研發階段，我也終于可以抽時間對這個歷時近3 個月的項目做一個相對完整的復盤。如果說要從這次項目中總結出哪些經驗的話，我想分享這兩點：

1）做前端組件的低代碼產品經理，必須要懂數據模型

在整個項目的早期，內容和容器分離的設計思路就已經確定下來，且經歷過大量調研后，我們認為這是項目中表格搭建的最好方案。

在第一個月，我就完成了相對完整的設計，唯獨只有數據源的解決方案一直沒有確認。

但就是這個沒有確認的數據源問題，我們卻來來回回討論了一個月之久。在這次做數據表格之前，我對于數據的加工是沒有太多概念的，因為平時很少會跟諸如 groupby、lookup、join 等數據模型中的概念打交道。

但到了實際的業務場景中，我們發現經常會有某一列的數據其實是通過對數據的實時加工完成的，而這個能力已經超越了常規的數據表格所能承載的能力。

后面通過反反復復的溝通，才最終確認下方案。而我作為直接參與的產品經理，最大的感受便是，做前端組件的低代碼產品經理，必須要懂數據模型。

2）易用性和天花板的平衡沒有完美的解決方案，不能純粹靠邏輯解決問題

低代碼的特征之一，是它可以服務不同的垂直行業，例如我們這一套表格搭建機制，即可以搭建一套 CRM，可以搭建一套商品管理后臺，同時也可以搭建一套人力資源管理平臺。

每一個垂直行業的開發者在使用低代碼產品時，骨子里都是帶著「既要又要」的美好愿望。他們既要這個產品使用體驗好，又希望這個平臺功能強大。

但是從產品設計的角度出發，易用性意味著少讓用戶操作，意味著邏輯封裝；天花板意味著完全解耦，靈活組合，這兩個原則是天然違背的。

這也是我們低代碼產品經理經常會經歷的痛苦，當我們千辛萬苦提供了一套更抽象更通用的解決方案時，卻會被開發者吐槽看不懂，用不明白。

所以需要在兩者間取得平衡，但從來不存在完美的平衡點，只能在業務發展中不斷摸索適合你的最優解。

但我愈發擔心一種現象，產品的抽象本身會變成一種邏輯游戲，體現在為了抽象而抽象，最終在邏輯上給了一個自洽的解決方案，但作為一個產品解決方案，用戶用起來很難受。

我也在思考，盡管低代碼產品和普通 SaaS 產品的思考視角和設計習慣可能是不一樣的，但從產品經理這個崗位的本質來說，某些東西是共通的，不能純粹靠邏輯解決問題，必須要聽聽客戶的聲音。

07

最后，我想說說競品調研。

低代碼行業在國內外有明顯的差距，國內的低代碼行業從 2015 年左右開始到現在，還處于比較初級的階段，雖然涌現出了很多低代碼廠商，但大多數都是表單驅動型的低代碼平臺，能夠快速搭建一些諸如「疫情申報」的簡單應用，但涉及到諸如 CRM 的復雜應用時，表單驅動不如模型驅動。

而國外的低代碼行業發展更早，2008 年時salesforce 的paas 平臺上就已經存在了近百萬個應用。

所以在這個階段做低代碼產品，很多時候我們都需要去調研國外優秀的低代碼產品。

我在日常做產品設計時，有三種問題需要通過競品調研解決：

1. 想要做一個需求，不知道該怎么做；
2. 想要解決一個問題，不知道該怎么設計解決方案；
3. 想要做某個模塊的產品規劃，不知道該怎么設計規劃方向。

對第一個問題，競品調研看起來會最有用，說白了，你有現成的答案可以抄，但很多人會局限在第一個問題里。比如我想做表單組件，看到某個競品沒有表單組件，于是我就不去看它了。

那很有可能那個競品是通過其他方式實現了表單功能，也許那個方式是更合理的方式，但如果只是看山是山，確實可能會錯過很多信息。

第二個問題某種程度上也是抄，只是抄的范圍更廣了，我不只是關注別人有沒有跟我一樣的模塊，而是關注面對這一類的業務場景，其他產品都是如何解決的，這種抄法會更高級一些。

第三個問題，本質上是培養起一種上帝視角。你需要通過調研回答以下問題：你要做一款什么產品，競品是如何做的，他們的優勢和劣勢是什么，行業目前的趨勢是什么，未來可能會往哪個方向演化。最終，你應該順著趨勢做設計，并以此為目標，設計你的產品演化路線。

當然，這一切的前提是，你得下功夫好好研究。不下這樣的功夫，這些理論都是白扯的。