header_v1.7.40

通過動效助力業務拿結果

2天前發布

原創文章 / UI / 觀點
大寶蛋 原創,如需商業用途或轉載請與大寶蛋聯系,謝謝配合。

2018年10月-滴滴國際化乘客側項目,歷經2個版本迭代,已于19年1月全量海外
有問題請及時告知,請不要討論除設計之外的產品問題



寫在前面


什么時候該使用動效,什么時候該保持應有的克制,什么樣的動效是好的動效我在之前寫過一遍文章,感興趣都盆友可以了解下,標題《動效/動畫在直播類應用中都運用和落地》,本篇文章應該可以算是上篇文章的下半場


接下來要說的這個案例,它可能和我們平常所見的動效體驗原則是“背道而馳”的,因為它終究是一個等待運力調度的場景(簡單的說就是等待司機接駕的過程)每天成百上千萬訂單的背后有著一套非常復雜的算法去支撐,這就造成了這個場景它本身不會像動效指導原則那樣順利,平滑,愉悅,但是既然是做設計,核心是去解決問題,所以繞不開這個場景本身。通過數據去解讀用戶的想法和行為,將設計與業務進行更緊密的結合,從而達到更好的效果


對用戶 “等待應答“這個場景的動效改進,以拉美地區最終AB測試數據為結論,使我更加確信動效能做的不僅僅是體驗上的提高,在特殊場景下完全可以解決視覺感知層面無法解決的痛點,為業務方拿結果


所有數據對外均作了隱藏處理~



項目背景


滴滴出行在拉美地區飛速發展,單量持續增高的同時,用戶對產品本身的期望也越來越大,我們一如既往的重視用戶體驗。無論嚴寒酷暑,早晚高峰,我們和我們的用戶都不希望等待接駕變成一件漫長、無預期、盲目的行為



數據分析


* 乘客等待時長主要分布在A時段左右,多數乘客會選擇在此時間段內取消訂單,而消訂單的乘客并不會停止叫車服務,而是進行二次發單,重新進入等待隊列,這就造成了因個人因素延長了等待應答的總時長


* 等待應答B分鐘左右,是較容易叫車階段,數據顯示用戶處于這個時間段內容易被接單


*延長乘客等待預期,調節愿等時長閾值的操作空間,乘客愿等時長的具有較大彈性,如在打車較為容易的時段為 xx 秒,在打車較難時段為 xxx 秒


結論:用戶對于排隊規則的并不理解,使得用戶在最容易叫到車的時間段之前會選擇二次發單,取消訂單會導致重新排入隊列,進行排序


抓手:知悉乘客取消應答集中時間段和容易打車時間段后前提后,在不通過增加物理運力/調整算法的前提下,通過設計的手法去緩解用戶的等待感知,從而增加用戶的等待應答時長,將用戶的等待時長延伸至容易打車時段,從而促成訂單的完成,是這次設計的突破口



了解問題,明確挑戰


對用戶的調研我們發現用戶對等待應答動畫存在以下感知


通過對用戶數據進行分析后得出結論,篩選出核心問題進行優化,讓用戶對等待應答有一個新的認知,是這次的關鍵所在。我們希望通過這次設計的優化,乘客能強感知此刻所處運力調動的狀態,并最大程度上弱化時間概念降低人腦對時間的敏感程度,減緩用戶的焦慮情緒,使其相信這是一個可以等待運力到來的排期



面對的挑戰有:


1.增強播單動畫感知,讓用戶明確自己所處狀態,從而減少應答前的取消率  P0助力業務

2.通過設計吸引視覺弱化時間概念,降低人腦對時間的敏感,從而增長應答前平均取消時長  P0助力業務

3.符合用戶打車預期的前提下,盡可能讓動畫用起來連貫,順暢,可預期,讓用戶感到愉悅,用戶體驗提高  D1體驗提高

4.符合品牌調性的場景動畫,讓應答場景融入App保持體驗上的流暢,統一和性能平衡  D1體驗提高

5.涉及到地圖開發/端上研發同學的密切配合,高度還原設計文件也將是一個挑戰  D2設計訴求



決策方向,設計執行


明確目標之后,就開始了設計的決策方向和關鍵詞


作為一個單量百萬級的應用,面對的用戶群年齡分布也是非常廣泛,因此動畫的效果一定要適合大眾群體的認知,不應該為了吸引視覺焦點而有個性化存在-> 波紋效果


運力調度本身是一件等待的過程,長時間的等待消耗用戶的耐心,應該給予更多的可預見的可期待的暗示 ->路徑


俯視視角更適合對周圍環境,路況,運力的的觀察和掌控,適合打車前對環境的觀察,而一旦進入等待場景,用戶需要做的只是等待接單,將場景透視化,貼近高空觀察事物的視角,更加符合真實世界-> 透視視角


老版本沿用的等待應答場景,可以在地圖上進行交互操作,但是無法帶來明確的有效信息。新版設計為了增強調度的感知,增強了動畫效果。而動畫效果在地圖上需要一直靠渲染運算生成,任何的地圖移動都將加大運算量,耗電發熱則會大大增加,因此這里為了保證性能將一個可自由操作的場景,變成了一個固定的場景 -> 蒙層




設計執行


明確了方向和關鍵詞之后,設計的思路其實就已經非常清晰。在框架層考慮清楚信息布局,整體頁面交互流程。在表現層吸引用戶視覺,加強感知,降低用戶對時間敏感度即可

初稿的設計其實非常順利,整個設計稿從需求分析到第一個DEMO落地大概用時1天左右,而且1稿過完設計內部。在設計之初,leader建議不需要考慮太多落地問題,可以適當天馬行空的,不要因為技術的限制而限制自己的想法。在完成設計稿之后我們與技術評審之前就開始與端上開發同學進行邏輯層的分析,發現這個設計稿雖然滿足要求,但是在細節位置需要分情況考慮,造成研發成本的大額增加,開啟漫 漫 改 圖 路 (細節就略過了)~


最終效果以這個動效為基礎進行研發,中間涉及到了地圖視角的偏移/定位點跟蹤/X-panel規則/最佳view調整等復雜邏輯的調整



設計改進的細節


優化進入等待應答頁的動效,優化頁面布局

設計進場動效不僅僅是為了視覺上有強感知和更好的體驗,核心是防止用戶多次取消,多次叫單的行為發生


當長時間打不到車時,乘客會選擇取消訂單讓系統重新派單,認為這樣有可能會更快有司機接單。而真實情況則很像排隊買票,前面的走不完買票流程后面的人則無法前進,所以當乘客選擇取消,離開排隊隊列,只能重新回到對尾,重新排隊


下方的等待應答信息卡片包含了等待時長和取消功能,規則是展示3s之后隱藏取消按鈕,如果乘客要取消,需要上滑拉起卡片點擊取消


通過調整視角和擴大蒙層動畫范圍,用戶的視覺將會集中在屏幕的上方避免地圖上的無效信息干擾,視覺持續注意力集中在3-6s左右,從而很好的為隱藏取消做了掩護


當用戶的視覺從上方移動到其他位置的時候運力調度已經開始了6s+,無形中給用戶時間感知的緩沖時間,使得平均等待時長延長,等待時長閾值向易接單時間段靠攏


后期通過數據分驗證現乘客拉起卡片的幾率相比之前剛發布時候已大幅下降,也從正面說明乘客已經適應了這種收起的策略



優化頁面樣式

舊版的等待應答,地圖外露供乘客拖動地圖觀看周圍情況。但是用戶在等待接駕的情況下,是沒有辦法看到周圍運力這條非常有用的信息,而地圖上卻外透了街道/店鋪的信息,會使這個頁面看起來非常沉重卻沒有很大的意義,且會弱化波紋擴散的感知


新版的等待應答,會在地圖上方蓋住一個80%透明度的的蒙層,同時會讓地圖視角整體抬高。讓用戶感覺到的是更大范圍的運力調度,并且隨著地圖視角的抬高,街道/店鋪的名稱會得到隱藏,減少無意義信息的透傳。通過對地圖的縮放,自動減少了街道信息外透,無需通過代碼層面的修改,減少了rd的工作量的同時讓界面整體看起來更加清爽,拉美在發單前會有定位點的二次確認定位點,也保證用戶正確感知到自己在空間上所處位置


舊版本的波紋,速度緩慢并且不夠明顯,很難給人一種強感知,不像是一個等待運力調度的場景

新版本的波紋,會增強波紋的速度,調整波紋的速率,讓用戶有一種強感知,此刻正在進行最大范圍的進行運力調度的搜索


不再支持用戶操作手機地圖,查看周圍信息。減少波紋因地圖位移而產生的實時渲染,減少不必要的耗電行為發生



保證應答前后體驗連貫性


在重新設計等待應答這個場景時,我不希望它是一個很重的loading的感覺


不希望像loading的原因在于loading處于數據調取狀態,而數據調取一旦完成,會立刻跳轉進入下個場景,會讓整個體驗被割裂,不流暢。而這里通過設計手法的表達我覺得可以做到體驗上前后的一致,從而打通設計上的從發單->接單->送駕 這一小閉環


在得到了數據請求后,我們會將View_3D視角返回到正常2D的俯視視角,而車作為最終的載體則會自然而然的出現,同時會根據最佳視角算法自動調整到,人和車同時出現在屏幕正中(距離越遠地圖View縮放越大,人車始終出現在屏幕當中)


接著,真實的車載路線會以路徑生長的方式呈現于用戶的手機當中,會根據距離的遠近來控制路徑生長速度的快慢,同時司機卡片同時加載出來~


等待應答的收尾過程不會像競品那樣直接進行頁面跳幀而是一種 合理的 有意義的(2D->3D->2D)完完整整的過程




推動落地,保證還原


完成了設計稿/產品/技術評審過后我們便開始與開發同學進行詳細的對接

因為此次設計相對復雜,涉及到了端上和地圖上的rd同學,所以非常考驗研發的效果還原能力,既要把動效實現原理拆分的非常明確又要保證聯調的時候前后一致性



這里就不多贅述,貼個輸出圖好了 (開發動效邏輯拆分圖by zhoulu)

其中有用到lottie輸出(感興趣的可以翻看我之前的文章)-》《動效/動畫在直播類應用中都運用和落地》


結論~Rd同學非常OK的完成了最終的效果DEMO,還原度90%+


非常感謝rd (鞠躬)



數據驗證


在拉美地區上線,進行了的AB測試,核心評估指標收益顯著,整體數據遠超當初的預期~



總結


成長方面:這是我來國際化團隊的參與的第一個項目,也是設計內部帶頭發起的一個項目,現在回頭來看還有些地方能做到更好,可能那多一點的“更好”能讓我在產出的時候更加細致,和研發對接思考的更加的完整,對業務的提升也許會更好


在說點題外的,現在的大環境講究“全鏈”,賦予了設計師更多的權利,對于設計來說絕對是利大于弊,這點深有體會,更多的上游思考,更前一步對業務的理解,把業務的場景想的明白,把數據看懂,站在全局的高度看問題,站在產品的角度去設計,設計賦能,通過設計去助力業務去拿結果



謝謝老板的觀看~


你們2019都變成高富帥,白富美,齊家平天下




346

    文章信息

    • 文章標簽

    沒有新消息

    提示文案

    提示文案

    提示失敗
    提示成功
    波音平台菠菜网排名 昌宁县| 荃湾区| 新余市| 四川省| 辰溪县| 凤翔县| 雷波县| 朝阳县| 康定县| 东乡族自治县| 武夷山市| 合水县| 宝鸡市| 连江县| 东方市| 嘉荫县| 长葛市| 明光市| 剑川县| 积石山| 建平县| 准格尔旗| 二手房| 故城县| 镇赉县| 冀州市| 十堰市| 佛学| 泊头市| 朝阳区| 东台市| 房产| 修武县| 菏泽市| 平谷区| 屏南县| 启东市| 天柱县| 大丰市| 根河市| 浏阳市| 鄂伦春自治旗| 赫章县| 比如县| 泽普县| 建湖县| 攀枝花市| 和平区| 娄底市| 盘锦市| 石河子市| 襄汾县| 太仓市| 大关县| 峨眉山市| 科技| 逊克县| 中宁县| 镇坪县| 威宁| 延寿县| 土默特左旗| 贵港市| 泽库县| 闵行区| 兰西县| 肇源县| 台山市| 庄河市| 庄浪县| 喀喇沁旗| 怀安县| 务川| 清涧县| 庆安县| 莱西市| 盐源县| 新竹县| 广灵县| 曲阜市| 徐州市| 喀什市| 麟游县| 礼泉县| 温宿县| 民乐县| 麦盖提县| 达拉特旗| 嫩江县| 扶沟县| 洛隆县| 崇左市| 沙湾县| 漠河县| 台江县| 锡林浩特市| 徐州市| 绍兴市| 长白| 陇西县| 烟台市| 峨眉山市| 兰州市| 比如县| 山西省| 临桂县| 铜山县| 大理市| 冷水江市| 汽车| 军事| 广平县| 峨山| 滦南县| 油尖旺区| 榆社县| 黔东| 利辛县| 大理市| 建湖县| 牟定县| 富平县| 丽江市| 马关县| 平凉市| 镇原县| 昌都县| 丘北县| 龙海市| 红桥区| 海门市| 高台县| 禹城市| 敦煌市| 台山市| 平潭县| 浑源县|