編輯導(dǎo)讀：對于追求完美的人來說，一定會在工作中有非常糾結(jié)的地方，甚至備受煎熬，耽誤正常工作進(jìn)度。本文作者在產(chǎn)品設(shè)計中也有過類似經(jīng)歷，和你分享，一起來看看吧。

今天聊的話題，對產(chǎn)品經(jīng)理來說是一個很有爭議性的話題：就是在日常產(chǎn)品設(shè)計過程中常見的一些糾結(jié)點。

有些人覺得完全不需要糾結(jié)，有些人則每一步都很慎重、很糾結(jié)，還有一些人壓根可能沒有經(jīng)歷過這種感受，都沒想到這么多。而我就是慎重、糾結(jié)派，甚至有些時候會干擾到我的正常工作節(jié)奏，所以我決定將自己的思考和糾結(jié)的點寫出來。

一方面可以通過文字來放慢自己的思路，回顧和總結(jié)自己的過往的方案和考量是否還有值得改進(jìn)的點，另一方面也可以與大家分享一些背后的故事，看看不同的人分別是什么立場，什么「派系」。

一、字段問題

糾結(jié)點如下：

• 要不要展示這個？
• 這個有沒有用？會不會重復(fù)累贅？
• 會不會超長？
• 名詞的定義是否準(zhǔn)確？
• 字段翻譯問題
• ……

在B端后臺管理界面設(shè)計中，最容易糾結(jié)的就是字段問題，到底要展示多少個字段？每個字段是否都有用？過于極簡后續(xù)不好拓展，過于復(fù)雜則對用戶體驗不好，也顯得產(chǎn)品沒有進(jìn)行過多的思考……

以「有贊」為例

有贊的整體風(fēng)格就是簡約和克制，例如拿采購訂單來說，有贊沒有展示操作日志和記錄，沒有展示關(guān)鍵節(jié)點的時間（采購審核時間，采購入庫時間），也沒有采購訂單的備注等……

對于有贊的這種克制我表示很欽佩，但是也很困擾，這么極簡的功能如果遇到了一些管理要求比較嚴(yán)格的公司，真的能夠滿足嗎？

我對SaaS的產(chǎn)品設(shè)計的一個根深蒂固的印象就是：不同的行業(yè)，不同的公司，不同的用戶會有不同的需求，為了減少后續(xù)頻繁的迭代和調(diào)整，所有的產(chǎn)品設(shè)計方案基本上都會做到最細(xì)化，采用最麻煩，最全面的方案來設(shè)計，只是在前端包裝的時候做的簡單一些而已。

當(dāng)然，我的看法有可能是錯誤的，這一點我持辯證性的態(tài)度。

除了確定要有什么字段之外，還有一個糾結(jié)的點就是字段應(yīng)該叫做啥名字？例如之前讓我最糾結(jié)的幾個名詞有：

• FBA中轉(zhuǎn)/中轉(zhuǎn)FBA/FBA訂單/FBA備貨
• 物流下單/獲取面單/獲取跟蹤號/預(yù)報面單
• 更新時間/修改時間/最后更新時間/最后修改時間
• 訂單/出庫單/發(fā)貨單
• 運(yùn)單號/跟蹤號/追蹤號
• 物流渠道/物流服務(wù)/物流產(chǎn)品
• ……

這里面有很多名詞定義是不準(zhǔn)確的，但是被一些行業(yè)中有影響力的產(chǎn)品使用了，用戶長時間使用這些產(chǎn)品之后，就被植入了根深蒂固的認(rèn)知。

那我只能「將錯就錯」去適應(yīng)用戶的習(xí)慣，但是其他尷尬的是有些「正直」的用戶不希望叫這個名字，或者新用戶（之前沒有使用過其他產(chǎn)品）覺得定義不清晰不太好理解，希望能夠換個準(zhǔn)確的名詞定義……

例如至今為止我都有點恍惚：FBA中轉(zhuǎn)到底是海外倉發(fā)貨到FBA去，還是FBA中轉(zhuǎn)一下發(fā)到海外倉.然后還要調(diào)用我的「系統(tǒng)2」來簡單換算一下才知道，原來這個是從海外倉發(fā)到FBA的意思。

還有物流渠道、物流服務(wù)和物流產(chǎn)品的定義，也是讓新人一臉懵逼，每次講這種概念的時候都要一通解釋，但是如果用英文來解釋我覺得直接就可以頓悟了。

物流服務(wù)/物流渠道（Shipping Service）物流產(chǎn)品（Shipping Service Group）物流產(chǎn)品其實就是一個打包的物流渠道的集合，用Group來定義簡單明了，而用產(chǎn)品來定義，則每次都需要額外的解釋。

二、字段順序問題

當(dāng)辛苦確定了字段之后，在畫原型的時候又出現(xiàn)了一個讓人糾結(jié)的點：那就是字段順序怎么擺呢？

一般的后臺字段擺放比較糾結(jié)的頁面或者模塊有：

1. 列表/表格區(qū)；
2. 編輯頁/表單頁；
3. 查看詳情頁；

現(xiàn)在很多后臺管理系統(tǒng)的列表區(qū)一般都允許用戶自定義字段和排序了，所以產(chǎn)品只需要定義好一開始的展示的字段和順序就好了，后續(xù)用戶可能自己也會打亂，所以這一塊的排序不會過度的糾結(jié)。

以「有贊」為例

有贊的列表區(qū)不支持用戶自定義展示字段和排序，符合他極簡的風(fēng)格，但是不知道用戶是否有提過相關(guān)的反饋，需要增加自定義字段和排序的的需求。

對于編輯區(qū)和表單頁，目前基本上都是會遵循「分組」原則，把一些同類的字段放在一起，而至于同類中怎么排序那就看產(chǎn)品怎么畫的原型了。

以「有贊」為例

以創(chuàng)建商品為例，有贊將商品信息分成了5組，然后分別的將對應(yīng)的字段放在組內(nèi)，從上往下依次編輯錄入。

詳情頁的展示一般也會遵循「分組」的原則，但是分完了組之后，組內(nèi)的字段怎么排序也是一個頭痛的問題，如果都是一個產(chǎn)品來負(fù)責(zé)，可能還好一點。只需要做好一個標(biāo)準(zhǔn)頁，然后批量的復(fù)制和微調(diào)即可。如果是多個產(chǎn)品來負(fù)責(zé)，那么很有可能就會有兩種風(fēng)格的展示出現(xiàn)。而有些產(chǎn)品是對這個東西敏感的，有些產(chǎn)品壓根就不敏感，反正把字段丟上去就完事了，協(xié)調(diào)性，美觀性，一致性都拋之腦后了。

當(dāng)然，最后可能還有一個解法就是靠UI來全局把控，鑒于我之前的項目經(jīng)驗幾乎都沒有UI，所以我也不太好下定論是否真的有效果，但是我仍然會建議產(chǎn)品自己需要關(guān)注這種小細(xì)節(jié)。

再補(bǔ)充一個小細(xì)節(jié)，在畫原型的時候我覺得Axure可以提升優(yōu)化的一個東西就是支持「AB互換」或者「自動排列」，導(dǎo)致我每次要增加或者刪減字段的時候，都需要重新調(diào)整一個位置。

在兩個字段中間插入一個新字段：

拿上圖為例，我需要增加一個字段到預(yù)計到達(dá)日期這個位置，那么預(yù)計到達(dá)日期之后的所有字段都需要重新挪一個位置，挺費時間的。后續(xù)如果我又需要刪除某個字段，那么其他的字段也要跟著一起向前挪一位。

目前來說，我只在Figma上看到了相關(guān)的解決方案，Axure不知道啥時候能解決這個問題。

三、單號生成規(guī)則

B端后臺管理系統(tǒng)，有很多單據(jù)號要生成，怎么生成單據(jù)號也是一個值得斟酌考量的問題（一不小心就容易糾結(jié)）。

大多數(shù)業(yè)務(wù)都會要求單據(jù)號需要具有唯一性（作為內(nèi)部數(shù)據(jù)交互的字段），然后具有語義性（能通過單號知道是什么業(yè)務(wù)），最好還要足夠短（運(yùn)維或者客服處理時方便記憶），最后可能還會要求開發(fā)簡單，能復(fù)用或減少維護(hù)成本。

從我多年的踩坑經(jīng)驗來說，一般會有這么幾種方案：

• 關(guān)鍵字+日期/時間+自增法
• 隨機(jī)生成法
• 關(guān)鍵字+日期/時間+特定規(guī)則法
• 毫無章法

最常見的，也是最不需要動腦筋想的一個方案就是「關(guān)鍵字+日期/時間+自增法」，這個方案簡單粗暴也能讓用戶從單號上快速get一些信息，使用此方案需要注意的是：閾值上限的問題和刪除/棄用的占用問題。

如果超過了閾值上限怎么辦（自增只有四位，超過了4位怎么辦）？如果占用了一個自增序號又刪除了，那么下一個號是從該序號后自增還是繼續(xù)沿用刪除了的那個序號？每次自增都需要查一次前一個單號遞增到哪了，如果有并發(fā)或者查詢超時怎么辦？

「隨機(jī)生成法」一般用于一些不希望用戶從單號看到蛛絲馬跡的場景，例如電商中的訂單號，如果用自增法就會被人猜到具體的業(yè)務(wù)單量，顯然不合理。大家日常聽說的「雪花算法」，就是用來生成單號隨機(jī)數(shù)的一種常用方法。

「關(guān)鍵字+日期/時間+特定規(guī)則法」和第一種自增法類似，不過為了縮短單號的長度或者隱藏一些業(yè)務(wù)數(shù)據(jù)，也可以引入字母構(gòu)成36進(jìn)制或者字母數(shù)字隨機(jī)組合，具體規(guī)則可以視業(yè)務(wù)情況而定。

「毫無章法」是我調(diào)侃的，最根本的原因就是一個產(chǎn)品經(jīng)過多年的迭代，不同的產(chǎn)品經(jīng)理經(jīng)手，所以單號生成規(guī)則發(fā)生了各種演化，最后發(fā)現(xiàn)根本找不到什么章法。如果是產(chǎn)品經(jīng)理對此有執(zhí)念或者強(qiáng)迫癥，那么建議在項目啟動的初期，就把單號生成規(guī)則和要求放在全局說明之中，這樣后續(xù)別人接手的時候也可以遵循規(guī)范，避免出現(xiàn)「毫無章法」的情況。

四、總結(jié)

關(guān)于這個話題，我在2年前就想寫了，但是當(dāng)時感覺自己工作經(jīng)歷不是很多，所以可能一些疑惑是會在后續(xù)得到解決的。

直到我最近重新從0到1做一款產(chǎn)品的時候，我才發(fā)現(xiàn)，2年前糾結(jié)的一些事情到現(xiàn)在依然沒有很好的解決。該糾結(jié)的還是很糾結(jié)，該思考停頓的地方，還是要思考和停頓。

對于以上一些糾結(jié)的問題，大多數(shù)我都有了答案或者探索之后內(nèi)心更加堅定和安心，但是這些糾結(jié)時刻確實是發(fā)生過的，以后也會繼續(xù)發(fā)生。所以我想記錄下來分享出來，如果這些描述能對大家有所幫助，那就更好了。

鑒于篇幅的問題，本文就先將這三個比較經(jīng)典和常見的困擾，后續(xù)有了靈感和素材之后再來更新下文。

我們下期再見！

#專欄作家#

我叫維他命（Vitamin），微信公眾號：PM維他命。前PHPer，做過在線教育類產(chǎn)品，也做過3年半的跨境倉儲物流方向的產(chǎn)品，目前是一位外貿(mào)SaaS領(lǐng)域的供應(yīng)鏈產(chǎn)品經(jīng)理。主要專注于WMS/OMS/TMS/BMS/ERP等領(lǐng)域，分享供應(yīng)鏈相關(guān)的產(chǎn)品知識。

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

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