把一個表單設計到極緻的感受?編輯導語：近年來低代碼/無代碼的概念很火，它可以讓技術、運營同學通過少量甚至無代碼的方式快速搭建出網站、小程序、表單、協同表格等産品，幫助用戶解決實際業務問題本文從低代碼表單的概念和整體功能設計方面，對低代碼表單進行了分析，一起來看一下吧，下面我們就來聊聊關于把一個表單設計到極緻的感受?接下來我們就一起去了解一下吧!

把一個表單設計到極緻的感受

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

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

所以計劃寫一個低代碼專欄，介紹如何實現一個低代碼表單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）創建表單

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

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

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

模闆表單：默認模闆表單的名稱和圖标即新表單名稱和圖标

空白表單：用戶點擊創建後，商家還需要輸入表單名稱和圖标，才能真正創建成功

2）表單編輯頁

宜搭表單編輯頁面

輕流表單編輯頁面

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

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

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

3）表單規則設置

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

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

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

2. 用戶登記表單

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

1）怎麼合理觸達用戶

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

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

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

2）怎麼告知用戶表單狀态

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

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

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

3）表單處理功能

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

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

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

表單詳情頁信息展示：表單信息除了展示用戶提交的内容，還需要根據業務訴求提供更全的信息，比如提供創建日期、用戶信息、訂單信息、狀态處理信息等

表單狀态處理：對表單狀态進行操作，比如有申領、指派、狀态進度處理、回複用戶等

表單内容導入/導出：導入指的是商家可以代客發起表單申請；導出指的是商家可以将表單内容數據導出去

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

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

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

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

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

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

2）抽象原子組件

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

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

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

3）想清楚業務鍊路

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

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

最後，還有兩個問題：

商家内部哪些員工可以操作表單，對表單内的數據進行處理？

用戶提交表單後，内部ERP系統怎麼接收表單數據，無需多平台操作？

作者：蘇Eddie，蘇Eddies

本文由 @蘇Eddie 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!