編輯導語：近年來低程式碼/無程式碼的概念很火，它可以讓技術、運營同學透過少量甚至無程式碼的方式快速搭建出網站、小程式、表單、協同表格等產品，幫助使用者解決實際業務問題。本文從低程式碼表單的概念和整體功能設計方面，對低程式碼表單進行了分析，一起來看一下吧。

近些年低程式碼/無程式碼概念很火，本人之前有專門做過低程式碼產品，也對低程式碼很感興趣。

所以計劃寫一個低程式碼專欄，介紹如何實現一個低程式碼表單mvp產品0-1落地。

圍繞表單mvp產品落地，從

表單基礎功能設計、表單應用許可權管理、表單資料自動化對接

三個功能來介紹低程式碼表單產品。

這篇文章會跟大家介紹低程式碼表單的概念和整體功能設計，接下來會接著發應用許可權管理和資料自動化對接文章，可以關注下哦。

一、概念介紹

1. 低程式碼/無程式碼

低程式碼/無程式碼可以讓技術、運營同學透過少量程式碼甚至無程式碼的方式在平臺快速拖拽模組，搭建出網站、小程式、表單、協同表格等產品，幫助使用者解決實際業務問題。

國內比較有名的低程式碼平臺有阿里的宜搭，騰訊雲的微搭，輕流、明道雲、金資料等，國外有OutSystems、webflow等。

市面上常見的低程式碼平臺

2. 表單

大家對錶單產品應該不陌生，我們上學時經常填的問卷調查、日常也會接觸到的線上測評、投票、報名等，都是透過表單產品實現的。

表單通常用來解決的場景有問卷調查、線上考試、售後工單、投票、預約登記等。目前國內低程式碼平臺專門做表單產品的有金資料、問卷星、輕流等。

二、為什麼要做低程式碼表單

為了讓大家閱讀更有體感，我們假設做這個低程式碼表單MVP產品的背景和目的。

小王是某交易平臺的產品經理，今年核心okr是幫助商家售後客服降本提效。小王深耕售後多年，瞭解到平臺的商家售後客服有以下幾個痛點：

1）售後問題登記量大，客服成本高

大部分場景有標準化的問題和登記內容，使用者回答具體問題後，再由客服代客發起。這種方式客服人力成本高，效率低。

2）協同流程較複雜，進度獲取困難

客服在接待過程中，有部分場景是客服當下無法給出答案的，比如改地址、質量問題處理等，需內部協同流轉處理。但協同進度幾乎不可視，無法給使用者準確反饋。

3）多端操作成本高

在平臺產生的諮詢問題，有些客服還會在自家erp系統再重複錄入處理，多端操作導致處理效率低下。

小王打算著手解決以上的售後客服痛點，小王調研商家後，發現可以透過售後表單（工單）來解決上訴問題。使用者填寫標準化場景表單後，客服收到使用者的表單訴求，透過表單處理狀態實時跟進。

當小王準備出標準化表單方案時，發現一個問題。

即便是同一個場景，商家的表單內容也可能是不一樣的，標準化表單解決不了大部分商家訴求。

小王想到了低程式碼/無程式碼表單，即提供基礎的表單內容，商家可根據自身需求靈活拖拽元件組成新的表單。跟技術同學溝通後，大家一致認為這個方案可行，小王整理思緒後，給出了產品策略：

無程式碼表單

：商家根據模板表單或者是空白表單，在頁面編輯器中透過拖拽元件和編輯元件屬性，搭建出符合需求的表單。表單支援客服代客發起和使用者自助填寫。

許可權和流程管理

：商家可根據角色設定表單許可權，進行表單功能和狀態處理操作。

資料自動流轉

：透過webhook功能實現資料打通，減少多端操作成本，提升效率。

再說明下，小王是虛構人物，舉這個例子是想透過一個售後場景讓大家瞭解低程式碼表單產品應該如何設計，如何解決類似的登記場景和流程處理問題。

當然落到具體方案上還需要考慮更多的業務細節，這裡介紹下我針對這個售後表單的方案設計思路。

三、無程式碼表單產品設計思路

1. 原子元件

什麼是元件？

在低程式碼/無程式碼產品中，搭建表單/網頁就好比拼樂高，透過一塊塊積木可以拼出樂高，你可以理解一個通用的積木就是我們接下來要說的元件。

這就要求元件必須足夠抽象化和原子化，才能拼出不同的樂高（滿足商家搭建不同表單場景的訴求）

。

回到商家售後表單的真實訴求中來，以售後退差價場景（商家自主承諾價保）和使用者物流催促（長時間未更新物流狀態）來看，使用者需要告知商家以下資訊：

從以上兩個表單登記場景來看，我們初步可以找出些填寫內容的格式和要求。根據填寫的內容，我將我們的元件梳理成兩類元件，分別是通用元件和業務元件。

通用元件

：這類元件相容性強，不依賴登記場景特性，比如圖片元件（使用者上傳圖片憑證）、選擇元件（使用者單選或者多選內容）、輸入框（使用者輸入內容說明情況）等

業務元件

：這類元件帶有業務或某類場景特性。比如訂單填寫，透過配置一個輸入框，讓使用者輸入

訂單id也可以解決，但這種方式使用者體驗太差，所以透過做一個訂單選擇器元件，使用者點選下拉選擇在店鋪購買過的訂單。

根據咱們的售後場景，我初步梳理了以下元件：

2. 業務資料建模

我們現在只知道要做一個無程式碼表單和需要的元件，那麼商家要接入表單進行元件配置。

商家應該怎麼做？

這就涉及到業務資料建模，業務資料建模是指將業務的核心資料物件特徵進行提煉，歸納並設計對應的底層資料模型的過程。

說人話就是商家在配置表單元件過程中，需要建立什麼，操作什麼，具體操作業務物件有哪些？

我將核心的業務物件梳理成商家、表單、表單場景型別、元件、使用者、表單內容。

商家

：配置表單的商家賬號（賬號許可權在本章不展開，下一篇會講到）

表單

：承載元件的容器

表單模板型別

：表單歸屬於某一場景模板（比如退差價場景、物流催促場景等），歸屬後該表單會先配置了部分元件

元件

：元件包括基礎元件和業務元件，可以在配置表單時，對元件進行屬性配置

使用者

：填寫表單的使用者

表單內容

：表單配置好後，使用者和商家都可自助填寫表單從而產生的內容。商家對錶單的管理顆粒度要落到內容，可以對錶單內容進行增、改、內容狀態處理等

這些業務物件之間的關係如下圖的UR圖所示：

上面ER圖表達的意思是：

一個商家可以建立n個表單

一個表單對應0個或1個表單模板型別，同時1個表單模板型別可以對應n個表單

一個表單由n個元件組成，同時元件也可以用於別的表單

一個表單可以被登記n條表單內容，該條表單內容只能屬於一個表單

使用者和商家都可以登記1個到n個表單內容

抽象出這些業務物件和梳理好關係後，說明我們已經初步弄清楚了業務邏輯。後續的流程設計和介面設計可以根據ER圖去細化細節。

3. 業務流程

四、無程式碼表單產品功能設計

1. 表單配置功能

前面的業務流程裡有說明商家配置表單的操作，這裡簡要說明下商家側表單配置需要的功能：

1. 表單配置功能

：支援模板選擇或者是建立空白表單

建立表單

：支援商家拖拽控制元件和編輯控制元件屬性，搭建表單

表單編輯頁

：對錶單配置對應的規則，比如配置狀態流程功能、使用者填寫次數等

表單規則設定

無程式碼上手搭建對於商家運營同學來說，依然是有非常高的學習和上手成本，提供售後模板場景能極大提高表單生成率和使用率。

所以我們要提供開箱即用的模板表單。

建立表單功能核心是要提供模板表單和空白表單給商家選擇，商家選擇後，產品側要做的事情是記錄商家建立了一個表單：

模板表單：預設模板表單的名稱和圖示即新表單名稱和圖示

空白表單：使用者點選建立後，商家還需要輸入表單名稱和圖示，才能真正建立成功

1）建立表單

宜搭表單編輯頁面

輕流表單編輯頁面

如上圖所示，我體驗了下宜搭和清流的表單編輯器頁面，都是常規的三分編輯器，左邊區域是元件庫，中間區域是編輯畫布，右邊區域是元件的屬性配置。

舉個例子，從左邊拖入單選元件進到中間的畫布區域後，可在右邊元件屬性配置區域配置選項名稱、選項內容等。

這塊功能後續核心要做元件的擴充套件，透過提供更多原子元件來滿足商家場景訴求。

2）表單編輯頁

使用者是否可以多次填寫同一個表單（重複校驗），表單是否要開啟狀態流轉處理，表單是否允許商家代客填寫等，這些規則統統可以收攏在表單規則設定頁面。

設定好之後，我們就可以獲取使用者側表單投放連結了。

關於表單投放，後續可以再進行重點迭代，具體原因下文會講到。

3）表單規則設定

使用者側的表單功能重點關注兩個地方：

2. 使用者登記表單

觸達使用者渠道越多，表單UV越高，表面上看起來表單產品價值越高，但實際上可能會給使用者造成非必要的觸達。

售後核心是要解決使用者購後問題，提升使用者體驗。所以在觸達渠道投放設計上要剋制，應該結合售後場景進行合理觸達。

以催促物流場景為例，當用戶物流狀態24小時未更新，可以在物流詳情頁有工單入口供使用者進行登記和投訴；以改地址場景為例，當用戶下單後，客服可以自動下發表單卡片，供使用者進行改地址表單申請。

2. 使用者登記表單

表單狀態同步更新在表單詳情中，讓使用者可視目前的表單處理進度，產品核心要做表單提交後的處理進度展示功能。

表單完結後，可以透過客服自動化發信息告知使用者。

還是那句話，觸達使用者的設計要剋制，可以考慮設計每天最多觸達次數和使用者可自主關閉觸達機制功能。

1）怎麼合理觸達使用者

使用者填寫表單後，表單管理列表會記錄表單內容，如下圖所示：

表單處理功能核心是給商家進行表單內容處理，以下為主要功能介紹：

2）怎麼告知使用者表單狀態

：提交的表單內容展示在列表中，支援列表內容自定義展示、排序、內容查詢等功能

3）表單處理功能

：表單資訊除了展示使用者提交的內容，還需要根據業務訴求提供更全的資訊，比如提供建立日期、使用者資訊、訂單資訊、狀態處理資訊等

表單列表

：對錶單狀態進行操作，比如有申領、指派、狀態進度處理、回覆使用者等

表單詳情頁資訊展示

：匯入指的是商家可以代客發起表單申請；匯出指的是商家可以將表單內容資料匯出去

五、總結

以上為低程式碼表單產品設計思路介紹，不展開詳細功能方案設計，比如怎麼設計元件功能配置、表單狀態處理流程等。

如果要展開講，那就是一篇上萬字的prd了。

如果你要去設計類似的低程式碼產品或者是偏抽象化元件的設計，我覺得可以參考：

表單狀態處理

並不是所有表單產品都需要做成低程式碼形式，核心要看標準化表單是否能滿足大部分商家需求。如果符合大部分商家訴求，直接提供標準化表單，對商家來說才是更佳方案。

所以我們在出方案前，一定要想清楚解決的問題是什麼，怎麼衡量低程式碼產品價值。

表單內容匯入/匯出

低程式碼搭建就如同拼樂高，所以抽象出最基礎的原子元件是非常重要的。

無論是表單類元件，或者是中臺類元件，都需要從業務視角出發，抽象出業務真實要用的東西和共性。

元件足夠原子化，才能相容不同場景。

1）瞭解做低程式碼產品目的和價值

有些同學在出方案的時候，直接一步到位就到功能頁面設計，後期往往漏洞百出。

功能頁面能跑通，核心是業務處理層和資料層在支撐。所以我們在設計功能頁面前，可以透過業務資料建模理清楚業務物件和資料底層，透過業務流程圖想清楚系統之間的流轉關係。

最後，還有兩個問題：

商家內部哪些員工可以操作表單，對錶單內的資料進行處理？

使用者提交表單後，內部ERP系統怎麼接收表單資料，無需多平臺操作？

作者：蘇Eddie，微信公眾號：蘇Eddies

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

題圖來自 Unsplash，基於 CC0 協議