B端設計總結(二):基本字段 Basic Fields

1 評論 7007 瀏覽 60 收藏 12 分鐘

在一些B端后臺中,最基礎的就是字段了。除了“系統字段”、“業務字段”、“管理型字段”、“規則型字段”之外,還可以在通用的業務場景中按照輸入類和系統類再細分,本文作者從這兩個方面進行了分析,一起來看一下吧。

輸入和選擇控件果然鴿了,寫點偏業務的。

01 字段 Field

前陣子在一個群里參與了關于「字段(Field)」的討論。

無論是在黑帕云、飛書多維表格、維格表、Airtable 還是在一些 B 端后臺中,最基礎的就是字段。

有個文章對字段做了區分,分為“系統字段”、“業務字段”、“管理型字段”、“規則型字段”,定義是:

  • 業務型字段:體現業務要求的字段,承載業務信息的展示。
  • 系統型字段:系統交互之間的的請求日志信息字段,如系統主鍵、業務 ID、創建時間、創建人、版本號、最后修改時間、最后修改人等。以及系統之間的交互的請求編號、請求時間、請求相應信息等。
  • 管理型字段:為了管理需要設置的字段,如操作時間、操作人、日志信息、操作意見、備注等。
  • 規則型字段:系統為了某一規則而存續的字段。比如商品是即將下架的產品,可以設置下架時間、庫存量等,自動觸發后將商品下架。

這樣的方式非常適用于一些后臺產品設計,很好和技術去溝通需求。

在這個基礎上,我想補充一些更通用的字段類型和字段格式。

在通用的業務場景中可以按照輸入類和系統類兩個大類去往下根據不同業務來再細分。

這兩個很好區分:需要業務人員填寫的就是輸入類,自動計算的則是系統類。

B端設計總結 03:基本字段 Basic Fields

一般來講,系統字段都是指自動生成的,比如說修改時間、創建時間、流水號、創建人、操作人。

輸入類字段都是可以編輯的。

02 輸入類字段 Input Type Fields

輸入類字段再往下分,首先是根據數值進行分類。

常見的數值類型有以下幾種:

B端設計總結 03:基本字段 Basic Fields

在確定了數值類型之后,可以對數值進行一些格式填寫的校驗,不同的數值類型有不同的校驗方式。

其中有兩個通用的是:

  1. 「必填」校驗:是否允許這個字段為空。
  2. 「重復」校驗:是否允許這個字段值和其它值重復,如果不允許重復則無法保存或提交,常見于錄入線索聯系人手機號或身份證、商品編碼等場景,比如要求身份證號碼必填并不允許重復,避免了重復錄入。

其它的校驗要根據字段值的結果進行區分。

1. 字符串 String

字符串通??梢砸恍┱齽t表達式用來做以下業務常見格式的校驗:郵箱手機號身份證號碼網址。

這幾個類型都很好理解,其中要特殊說明一下「身份證號碼」類型。

大家知道,身份證號碼最后一位可以是 X 的,當時我們在做這個校驗規則的時候沒有了解正規的身份證號碼的 X 應該是大寫還是小寫。

有用戶就問了,這個 X 是否大小寫敏感?我看了一下,當時沒有做大小寫敏感。正規的身份證號碼 X 應該是大寫,也就是說我們輸入小寫 x 也是會通過校驗可以順利提交的。

如果不校驗的話,會發生什么?——用戶因為按照身份證號碼字段設置了自動化的觸發,用“線索表”的身份證號碼去自動查詢“機會表”客戶的身份證,如果已經存在,就不會在機會表中新增這個聯系人,而是直接更新這個聯系人的其他信息。而自動化查詢時是大小寫敏感的,也就是說如果在“機會表”中, 假設有一個 “61010119941120003X” 的身份證號,如果銷售再在“線索表”錄入了“ 61010119941120003x”就會把這條數據自動觸發重復錄入到機會表中。

現在的問題是要解決重復錄入,重復的根源是身份證格式校驗要更精確。一拍腦門的做法可能是會告訴開發,在校驗身份證時,要大小寫敏感,必須要填寫大寫”X”才能通過校驗。

但是站在用戶的角度思考,這種處理方式就很惡心,因為“X”要大寫這件事不是一個熱知識。我們需要保證效率,而不是我們知道用戶錯了,我們會改,但我們就是要讓用戶自己改。

所以,我想到了更優雅的解決方式:如果用戶輸入了小寫的“x”,在存數據時,我們主動幫用戶修正為大寫的“X”。

2. 數字 Number

對數字進行數值校驗時,首先需要設置數字的格式。

B端設計總結 03:基本字段 Basic Fields

其次,如果業務需要,可以用最大最小值來限制數字的輸入范圍。

B端設計總結 03:基本字段 Basic Fields

3. 貨幣 Currency

貨幣字段和數字字段很像,都是只允許輸入數字,區別是貨幣沒有百分比顯示的開關,貨幣字段能夠設置貨幣符號,小數點位數至多只允許設置四位。

B端設計總結 03:基本字段 Basic Fields

4. 日期和日期時間 Date&Date Time

在不同的業務場景中對日期還是時間有不同的需求,比如在一些會議時間中就需要「日期時間」,在一些合同簽訂場景則需要的只是「日期」。

二者都可以參與如 DateAdd、DateTime_Diff 這樣的日期運算。

關于多時區協作的問題可參考之前這篇文章《多時區協作如何保證時間不會產生歧義》。

B端設計總結 03:基本字段 Basic Fields

默認值、支持時間、必填都比較基礎,就不用再寫了。

簡單寫一下關于日期格式校驗一些總結。

當時在做這個功能設計的時候,模擬了以下場景:

  • 某旅游團只允許 18 歲-65 歲購買,出生日期早于 2003 年,晚于 1956
  • 某博物館門票預定只能購買第二天門票
  • 酒店預定開始日期只能預定最近 7 天(不含今天)
  • 管理發票的回款,在填寫回款明細的時候,回款日期不能超過今天。
  • 機票回程日期不能早于啟程日期
  • 酒店預定結束日期不能早于開始日期

比較清楚的是,可以將以上場景收斂為三個分類:

  1. 某個具體的日期參與的校驗范圍
  2. 動態的“今天”參與的校驗范圍
  3. 其它日期字段字段值(動態值)參與的校驗范圍

從業務的角度和成本考慮,對“今天”的需求概率會更高并且成本適中,所以在 Phase1 中, 做了前兩個分類的功能。

在應用管理員設置校驗時,可以設置這些規則:早于晚于在范圍內是不是

范圍可以選擇為:

  • 指定日期:可以根據字段類型設置指定的日期或日期時間
  • 填寫日期(“今天”)
  • 填寫日期前(“今天”):選擇這項后,可以動態設置范圍是填寫日期前[1,3650]區間的整數
  • 填寫日期后(“今天”):選擇這項后,可以動態設置范圍是填寫日期后[1,3650]區間的整數

提供以上幾種的規則和范圍,就能覆蓋除了需要其他日期字段值的任何校驗場景了。

5. 選擇 Select

選擇在表單中非常常見,可以分為單選和多選。

單選的表現形式有以下兩種:Select 和 Radio Button。

B端設計總結 03:基本字段 Basic Fields

03 系統字段 System Fields

對于系統類字段再細分下去是系統自動生成的基礎信息,就是創建人、創建時間、修改人等,但是還有幾類,一個是公式計算的,比如商品價格*數量這種公式。

如果已經接觸了關系型數據庫,知道表和表之間的關系,那就需要了解以下兩個字段:

  1. 「聚合(Rollup)」:用于計算所選數據的匯總、求平均值、最大、最小值
  2. 「引用Lookup」:引用它表的數據

04 寫在最后

以上就是基本的字段的幾種類型,在 B 端產品中,這些字段類型非常常見。

復雜高級的字段后續會繼續再寫,比如地址字段(Address)、多級選擇(Multi-Select)、動態關聯(Dynamic Link Record)。

作者:高拉,微信公眾號:高拉

本文由 @高拉 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 感覺這個基本都是約定俗成的,閉著眼睛來做…

    來自廣東 回復