【轉載】物流的場景化設計

移動互聯網的普及、消費升級以及懶人經濟的興起等因素,為即時配送帶來海量用戶。新零售經濟在中國的快速發展,也萌生了一些新型的場景,來自新型超市的訂單增長迅速。但不管如何發展,對於物流設計而言,就是解決新增場景下騎士的觸點問題。面對複雜多樣的場景,我認為物流的設計更適合稱作「場景化設計」。我們可以通過分析場景要素來定義設計的基本原則,通過發現特殊場景挖掘新的機會點。接下來,我來介紹一下在配送過程中運用場景化設計的例子。

案例1:蜂鳥眾包卡片信息改版

在18年底我們對「蜂鳥眾包」App的主流程做了一次改版。對於一款工具類產品來說,使用效率是我們最基本的設計原則。從下圖我們可以看到,配送整個流程由3個大場景組成,也就是配送的3大任務:搶單、取貨和送貨。因為即時配送對配送時間要求極高,所以如何通過設計降低配送時長是設計的價值所在。在這3個場景中,騎士面對的任務和關注的信息是完全不同的,對於不同場景下的訂單卡片信息進行針對性地設計可以有效提升騎士的配送效率。通過對場景的拆解和重組,我們最終把整個配送過程中騎士的行為抽象為兩種,一種是「決策」,一種是「專注」,所有的研究和設計都是圍繞這兩種行為進行的。

首先,我們以發問卷的方式,通過收集騎士對訂單卡片信息的關注程度來判斷他們產生決策時所關注信息的優先級。為了保證最後結果的有效性和準確性,針對3個場景我們分別設立兩個問題:一個是讓騎士直觀地選出他認為最重要的信息,另一個是挖掘騎士產生行為的動機來源。我們分別來看下這3個場景:

第一個場景:搶單

通過第一個問題「在搶單時,您主要根據哪些信息來判斷是否要搶該單?」,我們得到騎士搶單時,最關心剩餘時間、訂單方向和取送距離,對於小費、預訂單等信息考慮較少,但在之前的版本中,小費和預訂單的信息層級卻很高。第二個問題「以下訂單同時出現在搶單列表,您最先搶哪種單?」,從結果我們可以發現,騎士心中對訂單是有要求、有選擇的。內心最真實的需求是希望搶到位置更好、時間更充裕的訂單。

用問卷收集騎士對訂單卡片信息的關注程度

兩個問題從不同的角度相互映證,基本確定了騎士在搶單時最關注的是訂單的配送難度而非價格。在這次優化中,我們通過加強文字對比使信息層級更清晰;強化地址信息、弱化價格和預訂信息,突出搶單的決策信息;去除了圓角卡片和陰影效果,降低代碼繪製特殊效果產生的性能問題;通過壓縮模塊間的間距,提升屏效。

第二個場景:取貨

通過數據可以發現,在待取貨頁面,騎士關注剩餘時間是為了避免遲到,關注備註信息是為了看有沒有特別需要注意的,以免造成後續不必要的麻煩。而問到「什麼時候會看待取貨列表」時,看訂單流水號、顧客備註、剩餘時間佔據了前幾位。因為取貨時,場景發生了變化:到達商家處,需要憑流水號取餐,所以流水號信息變得異常重要。

用問卷收集騎士在取貨場景中對信息的關注程度

在這次問卷過程中,我們還發現了一個有趣的問題。在待取貨卡片中,我們原本認為騎士取貨主要看商家地址信息,但我們收到問卷後卻很意外地發現,在取貨時,選擇送餐地址的比例遠遠高於商家地址。於是我們進行了線下訪談,得到的答案是:路上是在看商家地址,但取貨時需要核對送餐地址,以免拿錯,造成嚴重的後果。通過這個事情,我想說的是,用研是設計的第三隻眼,要用。

在取貨場景的卡片設計中,我們強化了訂單流水號方便騎士快速尋找商品;強化備註內容方便快速查看特殊要求;去除了搶單時的標籤,剔除干擾信息,提升閱讀效果。

第三個場景:送貨

這個場景和取貨場景比較類似,騎士同樣關注剩餘時間、送餐地址,不同的是送達前的必備操作換成了「聯繫顧客」。

用問卷收集騎士在送貨場景中對信息的關注程度

通過對3個場景的分析,可以看到不同場景下騎士的關注點是完全不同的,信息的展示方式也就有所不同,但都是在堅持「效率優先」的設計原則。其實,除了這3個場景,還有幫買幫送訂單的場景,決策信息和取貨方式也是不同的。針對這樣的場景,在細節上也做了區分,這裡就不做贅述。另外,我還想說設計改版不一定要大刀闊斧,更多是對細節的打磨。

上述項目主要是應用場景化設計提升基礎體驗的例子,接下來再來看一下通過發現特殊場景挖掘機會點的例子。

案例2:滑動確認

在騎士配送的過程中,訂單卡片頁作為 App 主流程頁面,它的操作非常頻繁。我們發現部分騎士因為一些個人的操作習慣,極易誤觸操作按鈕。雖然為了防止誤觸,做了二次確認彈窗,騎士可以關閉彈窗,但是在搶單過程中時間稍縱即逝,多一次關閉操作,極大地降低了騎士搶單的效率,對心理也有一定影響。其次,在送達場景下,如果不小心又誤觸了彈窗的確認鍵,這個操作是不可逆的,將導致「提前點擊確認送達」,可能造成用戶的投訴和相應的處罰。雖然可以通過申訴去解決問題,但是如何判斷行為的真實性,又給審核造成了一定的難度,而且申訴需要時間,這也增加了騎士的申訴成本。

這樣的高頻場景在其他產品中是很少見的,在考慮如何設計時我們想到了 iPhone 的滑動接聽,適當提高操作按鈕的門檻,避免觸碰造成的直接響應。同時為了滿足不同騎士的需求,我們增加了設置選項,把選擇權交到騎士手中。

案例3:離線送達

在17年初有條微博非常火,講的是一個騎士小哥送餐時,訂單即將超時,在電梯裡急哭的場景。看到這樣的故事,大家在表示同情的同時也會指責平臺對於騎士送餐超時的處罰過於嚴格。但嚴格的制度和高效率本身就存在一定的矛盾性,作為設計師,我們必須面對矛盾和約束,沒有約束的設計又怎麼能在商業體系中體現價值呢?

舉一個在約束下設計的例子。相信大家都遇到過打電話時進了電梯,電話突然沒信號的情況。我們在以往的反饋中也收到了很多騎士說在電梯裡斷網,無法點擊「確認送達」,導致訂單超時,要花大量時間進行申訴,申訴還可能不成功,給他們帶來了很大的困擾。按照以往我們的思考邏輯會是「電梯沒網我們也沒有辦法」,但是以場景化思維來考慮的話就不一樣了。打電話是即時通話,一旦無信號,打電話這個行為就中斷了,而點擊「確認送達」這個行為是整個配送完成後進行的一次中斷行為,只不過給這個中斷行為增加了一個「截止時間」,而這個「截止時間」是可以通過技術手段進行延遲的。所以我們只要把電梯沒網的這段時間掐掉就好。

和技術同學多次溝通後,他們建議在無網絡時若騎士點擊「確認送達」,通過打點的方式記錄打點時的地理座標和打點時間,當網絡恢復時判斷地理座標的有效性,然後自動確認送達。地理座標打點能保證騎士是在送餐點執行操作,避免騎士的作弊行為。功能上線後有非常好的效果:

1、每天挽回1.5萬單的超時單;

2、降低了騎士對該問題的申訴成本和客服成本;

3、體驗的提升讓騎士對平臺更有信心。

上面兩個例子是兩個簡單的場景,還有很多場景化設計的例子,就不在這裡一一介紹了。除了在界面上的應用,還有對細分場景的挖掘。在整個配送過程中,從取貨到送貨,最難的是最後送餐給用戶的這幾百米距離,如剛才說的電梯,在中午高峰期可能等一趟電梯就要花去好幾分鐘;對於地形複雜的學校公寓,找到最終位置也是騎士送餐的一大痛點;還有部分高檔小區,不讓騎士騎電動車進去,需要步行找到送餐的樓棟。這些無疑大大降低了騎士送餐的效率,影響他們的收入。這其中有很多場景可以通過場景細分的方式來解決,如使用送餐機器人、園區無人車、無人櫃還有物業大媽來完成最後這幾百米配送。

我們也正在做這樣的事情,送餐機器人、無人車已經在部分樓宇和園區進行試運行。相信在不久的未來,當你收外賣時將會看到一個餓了麼送餐機器人,如果你在電梯上遇到它,也請大家給它讓個位置。

最後

一切產品都是基於場景進行設計的,想要做好產品要從研究場景出發。同時,更多的場景也代表了更多的機會,設計師要儘量避免給自己設邊界。設計的價值不應該只停留在界面上,要去挖掘整個鏈路的服務系統,通過用戶的使用場景研究人與人、人與物之間的觸點,去發現更多的機會點,而這些機會點才是設計價值的體現。

那麼,你所做的產品又有哪些機會點呢?

作者 | 吳磊

來源丨餓了麼UED


分享到:


相關文章: