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