產品設計的思路和方法（設計產品需要考慮什麼）
編輯導語：產品在設計過程中可能會遇到許多困擾，例如某個功能應該選擇何種呈現方式、產品應該如何交付原型……這些問題都會造成糾結。本篇文章裡，作者便結合自己的工作經驗，對自己在專案中遇到的幾大糾結點進行了總結，不妨來看一下。
上一篇文章發出去了之後似乎沒有引起很多讀者的共鳴，讓我感覺有一點小小的失落。在我看來，我闡述的那些場景，應該對每一個後端產品經理都會有所感觸，但是實際的閱讀反饋讓我有點懷疑到底是標題不夠吸引人，還是內容不夠吸引人，還是我的公眾號讀者就不是很多……
不管怎麼樣，這些糾結時刻確實伴隨了我很久，剛好借最近的新專案的機會，又重新復現並記錄了這些糾結的東西。所以我決定還是應該寫下來，在寫作的時候再次思考和整理，同時如果寫完的文章能對大家有所幫助，也是一個好事情。
那就繼續開始我的「糾結」之旅吧，不過這一次，我打算換過一些行文方式：拆碎點來寫。
一、沒有UI的時候如何交付原型
很多時候，初創型團隊中往往都會有人員不齊，而這個時候UI往往是最容易被忽視的一個崗位。我之前做過的很多專案都沒有UI，甚至更極端的情況下團隊中可能連前端都沒有，所有的前端介面和樣式都是要後端Java來做……
但是工作始終是要繼續推進的，困難雖多，也有想辦法解決。如何交付高保真的設計稿就是一個常見的糾結問題。
之前我在這一塊糾結過很多次，同時也踩過很多坑。雖然說現在網路上很多開源的大廠的UI框架的元件庫可以直接使用，但是實際用起來的時候還是會發現這些元件庫總是有些地方不那麼暢快。
- 例如在做一些國際化（多語言）產品的時候，很多元件庫預設的對齊方式並不支援，還是需要手動改造。
- 元件庫中只有基礎的按鈕和一些元件，但是寬度和間距等沒有給出規範頁；即使給出了規範頁，但是有很多子頁面或者新頁面還是需要自己單獨標註。
- 元件庫支援的場景不夠，很多頁面還需要根據業務而重新定製，需要在保持原來的規範基礎上，進行自由發揮。
- ……
最後經過了幾次踩坑實戰之後，我的解決辦法是：
- 畫業務原型的時候，把自己當做產品看，畫原型的規範的時候把自己當做UI看。先出業務原型的草圖，最後根據制定好的原型規範套進去，再修改一次。
- 不需要所有的頁面都給出精細化的標準，這樣會很費時間。先出一兩個標準頁，給出詳細的長度，寬度，間距和大小等，評審之後先開發，看看實際情況。後續類似的原型頁面，只需要大概把元素和互動說明清楚就可以，就無需精細化的標準了。
之前我經常困於一些新業務的頁面設計，就是因為一方面又考慮了業務問題，另外一方面又考慮了UI規範的問題，最後導致效率不高，畫出來的東西也不太好。其實拆分成兩個角色，看似多耽誤了時間，但是其實反而是最高效的做法。
先畫業務草圖
再套上UI規範
二、令人又愛又恨的啟用和停用
啟用和停用這兩個狀態在B端管理系統中很常見，但是對於設計者來說這是一個又愛又恨的東西。
截圖來源：Ant Design
最根本的原因就是：不統一的規則很容易導致遺漏。
例如說在客戶管理中有啟用和停用的狀態，那麼意味著如果某個客戶的狀態是停用了，他應該不能登入或者不能使用某些功能之類的。
同樣地，如果是在倉庫管理中有啟用和停用的狀態，如果倉庫停用了，則意味著倉庫的員工登入不了這個倉庫，使用這個倉庫的客戶不能建立對應的單據到倉庫中，某些和倉庫相關的業務資訊也不會從上游系統同步過去……
截圖來源：有贊
這樣看起來，似乎這個啟用和停用其實也沒啥大毛病，沒啥好糾結的。
但是如果類似的「xx管理」多了，你就會發現，你需要時刻提醒開發同事，這個地方的判斷需要加上啟用或者停用的判斷。因為如果開發忽略了眾多規則中的其中某一個，就很容易出現BUG。
例如明明上游系統停用了某些配置，但是在下游系統還是可以正常使用某項功能，而資料繼續往下傳的時候又發現因為停用的問題導致了下游的下游不能接收這些資料，所以就報錯了。
啟用和停用本身其實沒啥糾結的，但是B端管理系統設計到要管理的物件太多了，而並非所有的物件都需要啟用或者停用，所以業務一旦變得複雜就容易讓產品和開發都迷糊，到底這個地方是隻要判斷「有沒有」還是要先判斷「有沒有」然後再判斷「啟用還是停用」。
對於這一塊，我個人看法是：
如無必要，請勿搞事。
如果是被管理的物件比較關鍵和核心，不能刪除或者要填寫的內容也比較多，那麼可以考慮使用「啟用和停用」。如果是一些管理一些的物件，應該考慮使用「刪除」而不是「啟用和停用」。
例如：
- 庫位和倉位管理，可以使用刪除。
- 產品管理，xx對映管理等，可以使用刪除。
- 品類管理，地址管理，基礎資料管理，可以使用刪除。
- ……
三、搜尋區域內的下拉選擇是單選還是多選
列表頁的搜尋區域是B端管理系統中最最最常見的頁面了，所謂的CRUD（增刪改查）在這個頁面中可以得到充分的體現。
搜尋區域一般常見的元件就是下拉選擇器和輸入框，輸入框一般就是使用者自己輸入相應的內容進行查詢，主要就是查詢的內容和查詢的方式（精確還是模糊匹配），而下拉選擇器比較糾結的一個點就是：用單選還是多選。
截圖來源：有贊
大多數情況下，大家不太會注意到這個問題，所以會普遍使用下拉單選，也就是上圖中的「存貨類別」這樣的。
但是隨著業務的增長，這種查詢的弊端也逐漸出現：每次都只能查詢一個狀態下的資料，不能支援多個狀態。於是乎，我們需要尋找更好的解決方案，如下圖所示。
截圖來源：TAPD
採用下拉多選框，可以支援查詢其中一個狀態，也可以查詢多個狀態，極大地滿足了不同使用者的不同場景下的需求。
我個人認為，下拉單選其實是下拉多選的一種特殊（常見）的形式，而顯然下拉多選可以滿足更加豐富的場景，比下拉單選有更大的優勢。
是選擇單選還是多選，其實可糾結的點不算多，因為從業務發展的角度來看，多選是應對複雜度更好的選擇，產品要做的更重要的事情，是如何向團隊宣講自己的理念和設計的初衷。
當然，使用下來單選也能在很多場景下滿足業務，而是否要改進它，還是取決於作為產品的你是否有get到它的好處。
四、是寫死還是可配置
- 開發：“這個地方是要寫死，還是要動態配置？”
- 產品：“這裡未來可能需要拓展，所以還是動態配置吧，把配置項維護到資料字典中，後續方便調整……”
- 開發：”沒問題，那就按你說的辦。“
「可配置」聽起來很簡單也很方便，頗受大家的歡迎。但是從我過往實際的專案經驗來看，「可配置」埋下的坑也挺多的，並不是一把梭，拿來即用就萬事大吉。
「可配置」會引發幾個問題：
- 誰來配置；
- 怎麼確定配置成功了；
- 這麼多配置，怎麼知道什麼配置會起什麼作用。
隨著業務的越來越複雜，可配置的內容也會越來越多，上面提到的3個問題就很容易引發一些BUG，因為人總是會出錯的，尤其是複雜度逐漸變高的情況下。
所以未來當開發問你是「寫死」還是「可配置」的時候，應該要留個心眼揣摩一下，有些東西到底會不會很容易變，如果不容易變，是否可以寫死；如果容易變，是否一定需要配置化……
五、是展示名稱還是編碼
近期比較糾結的一個問題就是：到底是展示名稱還是編碼，還是兩者都展示。
對於供應鏈系統而言，很常見的物件有：
一般來說有貨主就會有貨主程式碼，有倉庫也會有倉庫程式碼，有物流也會有物流程式碼……
名稱具有語義性，可識別性；而程式碼具有唯一性和準確性，也有保護性。
如果是對於SaaS系統來說，不同的使用者有不同的使用者習慣，我們很難確保使用者填寫的資料是符合我們理想的資料格式的。所以我們往往會讓使用者自定義填寫「名稱」然後系統自動生成「程式碼」，或者是讓使用者自定義輸入「名稱」和「程式碼」，但是隻校驗程式碼是否重複，而不校驗名稱是否重複……
於是乎，糾結的問題就出現了，在系統的各處介面中，到底要展示使用者填寫的名稱還是編碼，亦或是都展示？
截圖來源：有贊
有贊對倉庫名稱做了重複性校驗，所以沒有展示編碼，只展示的倉庫名稱。這種方案也很常見，不過弊端也是有的，例如當需要批量匯入資料的時候，在Excel中，倉庫這一欄就需要填寫中文名稱，然後進行模糊匹配，很容易就會匯入錯誤。當然前提是兩個倉庫的名字取的很接近，否則也不會很容易出錯。
以倉庫為例
在實際的專案中，我沒有采取有讚的這種方案，因為跨境電商海外倉的業務場景有點特殊。需要用到「倉庫」這個欄位的人不僅僅有國內的人，也有海外的工作人員。
如果只展示名稱，而名稱又是可以很容易就修改的，一方面會造成大家對這個倉庫的理解有偏差；另外一方面海外工作人員不認識漢字，並不能區分「888倉」和「888 倉」的區別，深圳可能「深圳倉」和「香港倉」在他們看來，都是方塊字，也不知道到底哪個是深圳，哪個是香港……
所以我們採用了名稱 程式碼的方式來展示，可能初次看有點冗餘，但是實際用起來應該是會比只展示名稱要好一些的。
六、總結
本文是關於「產品設計中的糾結點」的下篇，至此為止一些比較關鍵的、印象深刻的糾結點我都寫完了。其中的一些糾結點我想了很久，糾結了很久，甚至在不同的公司中，在不同的業務系統中，都嘗試並思考總結過，所以一邊寫，腦海中一邊浮現之前那種抓耳撓腮的痛苦狀……
產品設計有點類似於戴著鐐銬跳舞，但凡設計決策必然就會有糾結。我認為糾結不是一件壞事，恰恰相反，糾結過程其實就是思考和沉澱的過程，這也契合了「看山還是山」的道理。
當你在產品設計過程中不再糾結或者少有糾結的時候，可能是你已經到了「看山還是山」的階段，也有可能你從未思考過這些細節，所以還在「看山是山」的階段。
不論處於什麼階段，專研與思考，都是產品工作中的制勝法寶，願此文對你有所啟發。
#專欄作家#
我叫維他命（Vitamin），微信公眾號：PM維他命。前PHPer，做過線上教育類產品，也做過3年半的跨境倉儲物流方向的產品，目前是一位外貿SaaS領域的供應鏈產品經理。主要專注於WMS/OMS/TMS/BMS/ERP等領域，分享供應鏈相關的產品知識。
本文原創釋出於人人都是產品經理，未經作者許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議