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

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

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

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

01

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

數(shù)據(jù)表格能夠?qū)σ幌盗袛?shù)據(jù)信息作展示，同時提供常用的增、改、刪、查功能。說數(shù)據(jù)表格是 B 端產(chǎn)品的核心模塊之一可能一點也不為過。

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

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

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

無論是開發(fā)者配置還是業(yè)務(wù)人員配置，低代碼產(chǎn)品經(jīng)理面臨的挑戰(zhàn)是：我們見到的這個表格呈現(xiàn)出的功能和樣式，只是配置結(jié)果眾多可能性中的一個，我們需要考慮更多的可能性。所以低代碼產(chǎn)品經(jīng)理看待表格的視角需要且必須更抽象。

02

從低代碼產(chǎn)品的角度出發(fā)，對數(shù)據(jù)表格的設(shè)計有兩種思路，也是兩種不同的原則：高易用性和高天花板。

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

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

但無論是哪種原則，數(shù)據(jù)表格首先都應(yīng)該關(guān)注數(shù)據(jù)源的問題，這也是模型驅(qū)動的低代碼產(chǎn)品的特征之一。

03

模型驅(qū)動，是指數(shù)據(jù)模型和數(shù)據(jù)展示是分離的。數(shù)據(jù)模型層負(fù)責(zé)數(shù)據(jù)的獲取與加工，數(shù)據(jù)展示層負(fù)責(zé)對加工好的數(shù)據(jù)做展示，并提供對應(yīng)的增改刪查功能。

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

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

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

關(guān)于低代碼的數(shù)據(jù)模型功能，不是本文的重點，在此不做贅述。我只想表達(dá)，如果做數(shù)據(jù)表格的產(chǎn)品經(jīng)理不了解表格背后的數(shù)據(jù)源，是不可能做好數(shù)據(jù)表格的。

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

04

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

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

數(shù)據(jù)表格和圖表是該系統(tǒng)的兩個核心模塊。

接到項目之后，我們立刻著手做需求分析，發(fā)現(xiàn)該系統(tǒng)對數(shù)據(jù)表格的能力要求，是當(dāng)時已有的數(shù)據(jù)表格組件所無法滿足的。

這就要說到在那個節(jié)點，我們已有的數(shù)據(jù)表格的能力。

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

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

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

于是我們在想，是不是應(yīng)該換個思路了。

05

我們接著去調(diào)研市面上更多優(yōu)秀的產(chǎn)品是如何做數(shù)據(jù)表格的，發(fā)現(xiàn)還有另一種解法，他們的設(shè)計思路正是高天花板原則。

簡單來說，他們將數(shù)據(jù)表格進(jìn)一步分解為兩個部分：內(nèi)容和容器。

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

那容器和內(nèi)容是如何聯(lián)系起來的呢，通過上下文（context）。

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

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

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

在這種思路下，表格的搭建流程就變?yōu)椋和先肴萜?，關(guān)聯(lián)數(shù)據(jù)源，拖入組件，綁定數(shù)據(jù)源中的某個字段。

但我們進(jìn)一步調(diào)研發(fā)現(xiàn)，盡管很多低代碼產(chǎn)品提供了容器和內(nèi)容分離的功能，但面向用戶提供表格搭建的功能時，卻很少有像 bubble 這么做的。

我們自己用起來也發(fā)現(xiàn)，太難用了，跟我們?nèi)粘?shù)據(jù)表格的印象相比，這樣的搭建思路簡直反人類。

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

空白列的特征是，可以根據(jù)業(yè)務(wù)的訴求自己設(shè)計單元格插槽內(nèi)要使用的組件。

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

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

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

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

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

06

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

1）做前端組件的低代碼產(chǎn)品經(jīng)理，必須要懂?dāng)?shù)據(jù)模型

在整個項目的早期，內(nèi)容和容器分離的設(shè)計思路就已經(jīng)確定下來，且經(jīng)歷過大量調(diào)研后，我們認(rèn)為這是項目中表格搭建的最好方案。

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

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

但到了實際的業(yè)務(wù)場景中，我們發(fā)現(xiàn)經(jīng)常會有某一列的數(shù)據(jù)其實是通過對數(shù)據(jù)的實時加工完成的，而這個能力已經(jīng)超越了常規(guī)的數(shù)據(jù)表格所能承載的能力。

后面通過反反復(fù)復(fù)的溝通，才最終確認(rèn)下方案。而我作為直接參與的產(chǎn)品經(jīng)理，最大的感受便是，做前端組件的低代碼產(chǎn)品經(jīng)理，必須要懂?dāng)?shù)據(jù)模型。

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

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

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

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

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

所以需要在兩者間取得平衡，但從來不存在完美的平衡點，只能在業(yè)務(wù)發(fā)展中不斷摸索適合你的最優(yōu)解。

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

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

07

最后，我想說說競品調(diào)研。

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

而國外的低代碼行業(yè)發(fā)展更早，2008 年時salesforce 的paas 平臺上就已經(jīng)存在了近百萬個應(yīng)用。

所以在這個階段做低代碼產(chǎn)品，很多時候我們都需要去調(diào)研國外優(yōu)秀的低代碼產(chǎn)品。

我在日常做產(chǎn)品設(shè)計時，有三種問題需要通過競品調(diào)研解決：

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

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

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

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

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

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

專欄作家

大力哥呀，微信公眾號：大力哥，人人都是產(chǎn)品經(jīng)理專欄作家。一個90后產(chǎn)品經(jīng)理，已經(jīng)寫了6年的公眾號，通過輸出獲得了許多意料外的成長。

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

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

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。