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

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

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

圍繞表單mvp產品落地，從表單基礎功能設計、表單應用權限管理、表單數據自動化對接三個功能來介紹低代碼表單產品。

這篇文章會跟大家介紹低代碼表單的概念和整體功能設計，接下來會接著發(fā)應用權限管理和數據自動化對接文章，可以關注下哦。

一、概念介紹

1. 低代碼/無代碼

低代碼/無代碼可以讓技術、運營同學通過少量代碼甚至無代碼的方式在平臺快速拖拽模塊，搭建出網站、小程序、表單、協(xié)同表格等產品，幫助用戶解決實際業(yè)務問題。

國內比較有名的低代碼平臺有阿里的宜搭，騰訊云的微搭，輕流、明道云、金數據等，國外有OutSystems、webflow等。

市面上常見的低代碼平臺

2. 表單

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

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

二、為什么要做低代碼表單

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

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

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

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

2）協(xié)同流程較復雜，進度獲取困難

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

3）多端操作成本高

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

小王打算著手解決以上的售后客服痛點，小王調研商家后，發(fā)現可以通過售后表單（工單）來解決上訴問題。用戶填寫標準化場景表單后，客服收到用戶的表單訴求，通過表單處理狀態(tài)實時跟進。

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

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

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

• 無代碼表單：商家根據模板表單或者是空白表單，在頁面編輯器中通過拖拽組件和編輯組件屬性，搭建出符合需求的表單。表單支持客服代客發(fā)起和用戶自助填寫。
• 權限和流程管理：商家可根據角色設定表單權限，進行表單功能和狀態(tài)處理操作。
• 數據自動流轉：通過webhook功能實現數據打通，減少多端操作成本，提升效率。

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

當然落到具體方案上還需要考慮更多的業(yè)務細節(jié)，這里介紹下我針對這個售后表單的方案設計思路。

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

1. 原子組件

什么是組件？

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

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

回到商家售后表單的真實訴求中來，以售后退差價場景（商家自主承諾價保）和用戶物流催促（長時間未更新物流狀態(tài)）來看，用戶需要告知商家以下信息：

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

• 通用組件：這類組件兼容性強，不依賴登記場景特性，比如圖片組件（用戶上傳圖片憑證）、選擇組件（用戶單選或者多選內容）、輸入框（用戶輸入內容說明情況）等
• 業(yè)務組件：這類組件帶有業(yè)務或某類場景特性。比如訂單填寫，通過配置一個輸入框，讓用戶輸入

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

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

2. 業(yè)務數據建模

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

商家應該怎么做？

這就涉及到業(yè)務數據建模，業(yè)務數據建模是指將業(yè)務的核心數據對象特征進行提煉，歸納并設計對應的底層數據模型的過程。

說人話就是商家在配置表單組件過程中，需要創(chuàng)建什么，操作什么，具體操作業(yè)務對象有哪些？

我將核心的業(yè)務對象梳理成商家、表單、表單場景類型、組件、用戶、表單內容。

• 商家：配置表單的商家賬號（賬號權限在本章不展開，下一篇會講到）
• 表單：承載組件的容器
• 表單模板類型：表單歸屬于某一場景模板（比如退差價場景、物流催促場景等），歸屬后該表單會先配置了部分組件
• 組件：組件包括基礎組件和業(yè)務組件，可以在配置表單時，對組件進行屬性配置
• 用戶：填寫表單的用戶
• 表單內容：表單配置好后，用戶和商家都可自助填寫表單從而產生的內容。商家對表單的管理顆粒度要落到內容，可以對表單內容進行增、改、內容狀態(tài)處理等

這些業(yè)務對象之間的關系如下圖的UR圖所示：

上面ER圖表達的意思是：

• 一個商家可以創(chuàng)建n個表單
• 一個表單對應0個或1個表單模板類型，同時1個表單模板類型可以對應n個表單
• 一個表單由n個組件組成，同時組件也可以用于別的表單
• 一個表單可以被登記n條表單內容，該條表單內容只能屬于一個表單
• 用戶和商家都可以登記1個到n個表單內容

抽象出這些業(yè)務對象和梳理好關系后，說明我們已經初步弄清楚了業(yè)務邏輯。后續(xù)的流程設計和界面設計可以根據ER圖去細化細節(jié)。

3. 業(yè)務流程

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

1. 表單配置功能

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

• 創(chuàng)建表單：支持模板選擇或者是創(chuàng)建空白表單
• 表單編輯頁：支持商家拖拽控件和編輯控件屬性，搭建表單
• 表單規(guī)則設置：對表單配置對應的規(guī)則，比如配置狀態(tài)流程功能、用戶填寫次數等

1）創(chuàng)建表單

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

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

創(chuàng)建表單功能核心是要提供模板表單和空白表單給商家選擇，商家選擇后，產品側要做的事情是記錄商家創(chuàng)建了一個表單：

• 模板表單：默認模板表單的名稱和圖標即新表單名稱和圖標
• 空白表單：用戶點擊創(chuàng)建后，商家還需要輸入表單名稱和圖標，才能真正創(chuàng)建成功

2）表單編輯頁

宜搭表單編輯頁面

輕流表單編輯頁面

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

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

這塊功能后續(xù)核心要做組件的擴展，通過提供更多原子組件來滿足商家場景訴求。

3）表單規(guī)則設置

用戶是否可以多次填寫同一個表單（重復校驗），表單是否要開啟狀態(tài)流轉處理，表單是否允許商家代客填寫等，這些規(guī)則統(tǒng)統(tǒng)可以收攏在表單規(guī)則設置頁面。

設置好之后，我們就可以獲取用戶側表單投放鏈接了。

關于表單投放，后續(xù)可以再進行重點迭代，具體原因下文會講到。

2. 用戶登記表單

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

1）怎么合理觸達用戶

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

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

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

2）怎么告知用戶表單狀態(tài)

表單狀態(tài)同步更新在表單詳情中，讓用戶可視目前的表單處理進度，產品核心要做表單提交后的處理進度展示功能。

表單完結后，可以通過客服自動化發(fā)信息告知用戶。

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

3）表單處理功能

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

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

• 表單列表：提交的表單內容展示在列表中，支持列表內容自定義展示、排序、內容查詢等功能
• 表單詳情頁信息展示：表單信息除了展示用戶提交的內容，還需要根據業(yè)務訴求提供更全的信息，比如提供創(chuàng)建日期、用戶信息、訂單信息、狀態(tài)處理信息等
• 表單狀態(tài)處理：對表單狀態(tài)進行操作，比如有申領、指派、狀態(tài)進度處理、回復用戶等
• 表單內容導入/導出：導入指的是商家可以代客發(fā)起表單申請；導出指的是商家可以將表單內容數據導出去

五、總結

以上為低代碼表單產品設計思路介紹，不展開詳細功能方案設計，比如怎么設計組件功能配置、表單狀態(tài)處理流程等。

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

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

1）了解做低代碼產品目的和價值

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

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

2）抽象原子組件

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

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

組件足夠原子化，才能兼容不同場景。

3）想清楚業(yè)務鏈路

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

功能頁面能跑通，核心是業(yè)務處理層和數據層在支撐。所以我們在設計功能頁面前，可以通過業(yè)務數據建模理清楚業(yè)務對象和數據底層，通過業(yè)務流程圖想清楚系統(tǒng)之間的流轉關系。

最后，還有兩個問題：

1. 商家內部哪些員工可以操作表單，對表單內的數據進行處理？
2. 用戶提交表單后，內部ERP系統(tǒng)怎么接收表單數據，無需多平臺操作？

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

本文由 @蘇Eddie 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

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