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

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

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

因?yàn)樾畔⒌拿舾行?，涉及到?xiàng)目的具體內(nèi)容不會(huì)在本文中呈現(xiàn)，我會(huì)用盡可能通用的語言，帶大家一起回顧整個(gè)設(shè)計(jì)過程及背后的思考。

01

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

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

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

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

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

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

02

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

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

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

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

03

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

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

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

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

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

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

04

下面聊聊我在這次項(xiàng)目中遇到的具體訴求。

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

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

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

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

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

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

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

于是我們?cè)谙?，是不是?yīng)該換個(gè)思路了。

05

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們?cè)谶@兩種方案間搖擺了很久，最終決定堅(jiān)持高天花板的設(shè)計(jì)思路。因?yàn)槲覀兿嘈盼覀兊牡痛a平臺(tái)最終需要能夠以極小的成本搭建出更復(fù)雜的系統(tǒng)，這是它的價(jià)值所在。

06

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

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

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

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

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

但到了實(shí)際的業(yè)務(wù)場(chǎng)景中，我們發(fā)現(xiàn)經(jīng)常會(huì)有某一列的數(shù)據(jù)其實(shí)是通過對(duì)數(shù)據(jù)的實(shí)時(shí)加工完成的，而這個(gè)能力已經(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，可以搭建一套商品管理后臺(tái)，同時(shí)也可以搭建一套人力資源管理平臺(tái)。

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

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

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

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

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

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

07

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

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

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

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

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

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

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

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

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

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

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

專欄作家

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

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

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

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