B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

本文將為大家介紹 B 端產品在移動端使用中的反向導航設計,以及它的分類類型與設計要點。

B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

01 什麼是反向導航

反向導航的概念官方定義出自Material Design:

從用戶行為維度,分成三類:Lateral navigation(橫向導航)、Forward navigation(前進導航)以及Reverse navigation(逆向導航)。

橫向導航和前進導航分別指引用戶操作的水平漸進和層級漸進。逆向導航則負責對反向軌跡進行定義和實施,三者結合,實現對頁面的全局操控(來源見圖)

B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

PC產品,通過頁面常駐的導航欄+麵包屑+瀏覽器的返回鍵,用戶可以很輕易地返回或者向上跳轉。相較之下,Mob端的反向導航需要進行更多的設計。

因此,本文主要討論Mob端。

02 什麼時候需要反向導航

根據觸發的方式,筆者將反向導航分為用戶觸發和系統觸發兩類。

1. 用戶觸發

APP是通過一個個頁面來進行信息傳遞的。用戶在使用過程中,會主動中斷頁面流,進行回退。

從理論上來說,用戶進行的N+1步操作,都有回到第N步,或者B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

2. 系統觸發

系統觸發的頁面回退,如提交失敗、系統異常、網絡異常等,相對是可預期的情況。當頁面因為網絡或後端等原因,出現崩潰或錯誤提示時,需要給用戶提供“返回”或者“關閉”的選項。

如果用戶此時只能選擇殺進程,那麼體驗就太糟糕了。(反面例子見下圖)

B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

03 反向導航的設計要點

反向導航設計的要點,可以從邏輯和體驗兩方面來考慮:

1. 邏輯:操作閉環

不管是由用戶還是系統觸發,都必須保留回退的通路。

使用過程中不能給用戶留下死衚衕、斷頭路。這是反向導航設計最基本的要求。

2. 體驗:滿足預期

在完成第一步的基礎上,需要對反向導航做更多的思考。

例如,當用戶進入比較深的頁面,並不一定希望按照順序依次返回。

例如,當任務流結束的時候,用戶更期待返回“首頁”,而不是“上一步”。

B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

04 反向導航,“返回”哪去?

討論之前,我們先把反向導航分為兩類:一類是頁面層級相同;一類是頁面層級不同。

1. 頁面層級相同

在這種情況下,用戶並沒有跳轉頁面,“返回”只需要回到當前頁面即可。

如付款時彈出密碼頁,需要修改支付金額,返回支付信息填寫頁:

B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

如打開側邊欄之後再收起:

B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

這種情況的反向導航,並不需要PM額外的設計,只要UI設計師把控具體的交互方式就好,比如手勢返回、觸摸空白處收起等方式。

需要注意的是,最好給用戶提供足夠明確的“退回方式”,如在“觸摸空白處收起”的基礎上,保留“取消”或“收起”按鈕。

B端產品|APP的反向導航,只能“從哪來回哪去“嗎?

用戶在使用產品的時候,其過程就是探索未知之地。如果有清晰的指示牌,會帶來安心感,即使他不一定每次都需要憑藉指示牌去認路。

2. 頁面層級不同

當用戶進行了頁面之間的跳轉時,反向導航的設計就變得複雜了,需要我們花更多的心思。

90%的情況下,我們可以用 “從哪來回哪去“的方式滿足需求。

但是在B端產品中,容易出現鏈條很長的任務流。用戶需要一個頁面一個頁面地操作,最後完成提交或者保存。如果用戶進入層級太深,“逐層返回“的方式就不太人道了。

或者,在某些情境下,從N+1回到N,並不符合用戶的心理預期。

當我們在討論這種情況的時候,實際上討論的是整個產品的頁面結構該如何設計。

這個問題是值得我們深入思考的,筆者將在“下篇”裡用整個篇幅展開討論。

參考文獻

“返回”功能應該怎麼設計

“逆向導航”體驗探究

5種“返回”方法,幫你做好反向導航

http://www.visionunion.com/article.jsp?code=201907010030

本文由 @可可可可 原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議


分享到:


相關文章: