一個好的産品設計到底有多難?編輯導讀：對于追求完美的人來說，一定會在工作中有非常糾結的地方，甚至備受煎熬，耽誤正常工作進度本文作者在産品設計中也有過類似經曆，和你分享，一起來看看吧，接下來我們就來聊聊關于一個好的産品設計到底有多難?以下内容大家不妨參考一二希望能幫到您!

一個好的産品設計到底有多難

編輯導讀：對于追求完美的人來說，一定會在工作中有非常糾結的地方，甚至備受煎熬，耽誤正常工作進度。本文作者在産品設計中也有過類似經曆，和你分享，一起來看看吧。

今天聊的話題，對産品經理來說是一個很有争議性的話題：就是在日常産品設計過程中常見的一些糾結點。

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

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

糾結點如下：

要不要展示這個？

這個有沒有用？會不會重複累贅？

會不會超長？

名詞的定義是否準确？

字段翻譯問題

……

在B端後台管理界面設計中，最容易糾結的就是字段問題，到底要展示多少個字段？每個字段是否都有用？過于極簡後續不好拓展，過于複雜則對用戶體驗不好，也顯得産品沒有進行過多的思考……

以「有贊」為例

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

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

我對SaaS的産品設計的一個根深蒂固的印象就是：不同的行業，不同的公司，不同的用戶會有不同的需求，為了減少後續頻繁的疊代和調整，所有的産品設計方案基本上都會做到最細化，采用最麻煩，最全面的方案來設計，隻是在前端包裝的時候做的簡單一些而已。

當然，我的看法有可能是錯誤的，這一點我持辯證性的态度。

除了确定要有什麼字段之外，還有一個糾結的點就是字段應該叫做啥名字？例如之前讓我最糾結的幾個名詞有：

FBA中轉/中轉FBA/FBA訂單/FBA備貨

物流下單/獲取面單/獲取跟蹤号/預報面單

更新時間/修改時間/最後更新時間/最後修改時間

訂單/出庫單/發貨單

運單号/跟蹤号/追蹤号

物流渠道/物流服務/物流産品

……

這裡面有很多名詞定義是不準确的，但是被一些行業中有影響力的産品使用了，用戶長時間使用這些産品之後，就被植入了根深蒂固的認知。

那我隻能「将錯就錯」去适應用戶的習慣，但是其他尴尬的是有些「正直」的用戶不希望叫這個名字，或者新用戶（之前沒有使用過其他産品）覺得定義不清晰不太好理解，希望能夠換個準确的名詞定義……

例如至今為止我都有點恍惚：FBA中轉到底是海外倉發貨到FBA去，還是FBA中轉一下發到海外倉.然後還要調用我的「系統2」來簡單換算一下才知道，原來這個是從海外倉發到FBA的意思。

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

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

當辛苦确定了字段之後，在畫原型的時候又出現了一個讓人糾結的點：那就是字段順序怎麼擺呢？

一般的後台字段擺放比較糾結的頁面或者模塊有：

現在很多後台管理系統的列表區一般都允許用戶自定義字段和排序了，所以産品隻需要定義好一開始的展示的字段和順序就好了，後續用戶可能自己也會打亂，所以這一塊的排序不會過度的糾結。

以「有贊」為例

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

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

以「有贊」為例

以創建商品為例，有贊将商品信息分成了5組，然後分别的将對應的字段放在組内，從上往下依次編輯錄入。

詳情頁的展示一般也會遵循「分組」的原則，但是分完了組之後，組内的字段怎麼排序也是一個頭痛的問題，如果都是一個産品來負責，可能還好一點。隻需要做好一個标準頁，然後批量的複制和微調即可。如果是多個産品來負責，那麼很有可能就會有兩種風格的展示出現。而有些産品是對這個東西敏感的，有些産品壓根就不敏感，反正把字段丢上去就完事了，協調性，美觀性，一緻性都抛之腦後了。

當然，最後可能還有一個解法就是靠UI來全局把控，鑒于我之前的項目經驗幾乎都沒有UI，所以我也不太好下定論是否真的有效果，但是我仍然會建議産品自己需要關注這種小細節。

再補充一個小細節，在畫原型的時候我覺得Axure可以提升優化的一個東西就是支持「AB互換」或者「自動排列」，導緻我每次要增加或者删減字段的時候，都需要重新調整一個位置。

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

拿上圖為例，我需要增加一個字段到預計到達日期這個位置，那麼預計到達日期之後的所有字段都需要重新挪一個位置，挺費時間的。後續如果我又需要删除某個字段，那麼其他的字段也要跟着一起向前挪一位。

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

B端後台管理系統，有很多單據号要生成，怎麼生成單據号也是一個值得斟酌考量的問題（一不小心就容易糾結）。

大多數業務都會要求單據号需要具有唯一性（作為内部數據交互的字段），然後具有語義性（能通過單号知道是什麼業務），最好還要足夠短（運維或者客服處理時方便記憶），最後可能還會要求開發簡單，能複用或減少維護成本。

從我多年的踩坑經驗來說，一般會有這麼幾種方案：

關鍵字 日期/時間 自增法

随機生成法

關鍵字 日期/時間 特定規則法

毫無章法

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

如果超過了阈值上限怎麼辦（自增隻有四位，超過了4位怎麼辦）？如果占用了一個自增序号又删除了，那麼下一個号是從該序号後自增還是繼續沿用删除了的那個序号？每次自增都需要查一次前一個單号遞增到哪了，如果有并發或者查詢超時怎麼辦？

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

「關鍵字 日期/時間 特定規則法」和第一種自增法類似，不過為了縮短單号的長度或者隐藏一些業務數據，也可以引入字母構成36進制或者字母數字随機組合，具體規則可以視業務情況而定。

「毫無章法」是我調侃的，最根本的原因就是一個産品經過多年的疊代，不同的産品經理經手，所以單号生成規則發生了各種演化，最後發現根本找不到什麼章法。如果是産品經理對此有執念或者強迫症，那麼建議在項目啟動的初期，就把單号生成規則和要求放在全局說明之中，這樣後續别人接手的時候也可以遵循規範，避免出現「毫無章法」的情況。

關于這個話題，我在2年前就想寫了，但是當時感覺自己工作經曆不是很多，所以可能一些疑惑是會在後續得到解決的。

直到我最近重新從0到1做一款産品的時候，我才發現，2年前糾結的一些事情到現在依然沒有很好的解決。該糾結的還是很糾結，該思考停頓的地方，還是要思考和停頓。

對于以上一些糾結的問題，大多數我都有了答案或者探索之後内心更加堅定和安心，但是這些糾結時刻确實是發生過的，以後也會繼續發生。所以我想記錄下來分享出來，如果這些描述能對大家有所幫助，那就更好了。

鑒于篇幅的問題，本文就先将這三個比較經典和常見的困擾，後續有了靈感和素材之後再來更新下文。

我們下期再見！

#專欄作家#

我叫維他命（Vitamin），PM維他命。前PHPer，做過在線教育類産品，也做過3年半的跨境倉儲物流方向的産品，目前是一位外貿SaaS領域的供應鍊産品經理。主要專注于WMS/OMS/TMS/BMS/ERP等領域，分享供應鍊相關的産品知識。

本文原創發布于人人都是産品經理，未經作者許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議