從2個場景出發,深入解析B端系統的頁面跳轉

在一個普通 B 端產品(以瀏覽器為載體)的頁面中,相信很多產品設計師都有類似的經歷,這個頁面是要一直沿面包屑下沉,或者像 C 端產品一樣無限返回,還是新開網頁 Tabs 展示。在一次項目管理產品的設計中發現跳轉似乎有可循的邏輯。

信息結構的設計過程中,每一個功能模塊是經過深思熟慮做好定義的,如果想讓用戶的任務流程順暢、有所提效,那么信息架構的導航必須要發揮作用,也就是說用戶需要去記住或者被“教育”每個模塊的內容有什么。

更多B端干貨:

一、為什么要跳轉

1. 結構扁平化,減輕心理負擔

一次測試平臺項目迭代中,發現舊有版本的面包屑層級特別深,最多可有 5 級,而且是詳情頁面與新建頁面糅合在了一起,作為項目流程中的一個環節,不應該出現這種情況。于是調研了市面上能看到 B 端產品,騰訊云、阿里云和華為云等逐漸弱化了面包屑導航的使用,頁面層級一般不會超過 3 級,華為云和騰訊云已經取消了面包屑的使用,阿里云雖然保留了面包屑導航,但是二級頁面面包屑和返回同時存在,信息層級上也已經弱化了面包屑對信息層級的延伸。

從2個場景出發,深入解析B端系統的頁面跳轉

從2個場景出發,深入解析B端系統的頁面跳轉

在一次任務流程中,如果信息層級很深,意味著用戶會深入到更多的頁面,進而偏離主流程,同時需要接納的更多信息量,額外增加的信息負擔會給用戶的心理造成壓力,而且還會給產品扣上信息沉重的帽子。對于主流程,模塊提煉出的信息已經能夠滿足對用戶對該模塊的需求,如果仍有想了解顆粒度更小信息的需求,那么可以通過友好鏈接跳轉到信息的源始位置查看,而不是在當前頁面與主流程同級繼續下沉。

2. 增強記憶點,提高效率

在產品設計之初,每個一級模塊就已經做好了定位,比如騰訊云的私有網絡,包含了子網和路由表,如果用戶在私用網絡的詳情頁能繼續打開子網的詳情信息,那么私有網絡的定位就變成了私有網絡的信息+子網信息,進而削弱子網模塊的功能性,對用戶而言,會有多處可以查看子網信息,這會模糊用戶對產品結構的清晰認知。根據席克定律,下次信息查看時,面臨眾多的選擇,任務效率是變低了的。

另外,對于需要信息對比的場景,新開頁面可以滿足多種同類數據的對比需求。

從2個場景出發,深入解析B端系統的頁面跳轉

那么如果像騰訊云或者阿里云這樣,新開 tabs,直接跳到子網模塊的頁面,這會暗示用戶,這個功能信息點不屬于私有網絡,進而會強化子網模塊的定位,也會凸顯私有網絡的主要流程。

3. 關于用戶習慣

① 對于國內瀏覽器的用戶

國內的用戶對百度等搜索瀏覽器并不陌生,并且長時間的使用已經對頁面的跳轉有了一定的預期和習慣。通過友好鏈接跳轉到相應的頁面,點擊 tabs 回到搜索界面。同樣借助瀏覽器為載體的產品面對同一個用戶群體,其實不需要太多的再教育。

從2個場景出發,深入解析B端系統的頁面跳轉

另外,如果要處理或瀏覽的信息量很少,彈窗或者抽屜就可以即時獲取,這時候就不需要跳轉查看。

② 公司內部的用戶

當然,具體的產品還需要考慮聚焦的用戶人群,調研觀察當前產品的用戶習慣是怎么樣的。如果是與其他平臺或設計方向是有差異的,就要謹慎使用跳轉方式變更,總結當前的用戶習慣,通過引導或者多次迭代,統一使用正確的跳轉方式。

二、應用場景

什么場景適合

1. 平臺 A 跳轉到平臺 B

平臺 A 中的一個流程中有平臺 B 的信息,如果想點擊查看具體信息,需要新開 Tabs 網頁。

從2個場景出發,深入解析B端系統的頁面跳轉

從2個場景出發,深入解析B端系統的頁面跳轉

2. 同一個平臺內,當前模塊流程下查看/編輯其他模塊的內容,需要跳轉新開 Tabs。

從2個場景出發,深入解析B端系統的頁面跳轉

從2個場景出發,深入解析B端系統的頁面跳轉

跳轉新開頁面,如果信息的承載方式本身就是頁面,那么跳轉之后查看直接展示原來的頁面就可以。如果是彈窗或者抽屜,有三種展示方式:

  1. 當前頁面打開彈窗或者抽屜
  2. 新 tabs 回到原來的界面,打開彈窗或抽屜

從2個場景出發,深入解析B端系統的頁面跳轉

在 coding 的頁面中,如果在一個抽屜中打開另外一個子工作項,回到原來頁面后,詳情信息還是以抽屜展示。

3. 新 tabs 打開具體信息,不過原來的彈窗或者抽屜信息被鋪在了頁面中。

從2個場景出發,深入解析B端系統的頁面跳轉

當前抽屜中打開另外一個模塊的抽屜信息時,新開頁面的形式變成了頁面,沒有了返回等信息,頁面中的信息平鋪,引導用戶看完信息之后,關閉當前頁面。另外,這種展示方式還與權限有關系,方便信息在不同角色之間流轉。

三、特殊場景

當然,上述的結論并不是市面所有產品的一致方式,通過體驗還發現了以下不同的方式,以當前頁面所處的場景為維度解釋。

1. 信息為當前模塊流程的一部分

在產品層面該功能信息是屬于當面模塊定位的,不適合再打開 tabs。

2. 工作臺/概覽類的信息

這關于工作臺和概覽類功能的定位問題,大部分的產品都將工作臺定位成任務狀態的中轉站,用來做跳轉分發使用,因此從工作臺點擊跳轉到具體的任務模塊,可以直接在當前頁面跳到具體的任務頁面。不過對于一些大的平臺,還是建議新開頁面,這樣方便二次瀏覽待辦信息。

3. 其他

① 當前在一級頁面,如果跳轉到其他模塊可以選在當前頁面直接刷新,不需要新開 Tabs。如果產品的基本定位是其他模塊的內容都需要新開 Tabs 網頁,最好保持統一。

② 動態增減頁簽導航

一些產品的結構設計是導航欄常駐,所有的頁面都是以動態增減頁簽的形式展示,那么只要是本平臺內的信息都是不需要新開 Tabs 網頁的。不過使用這種方式設計者需要定義的是動態增減頁簽的使用邏輯。

從2個場景出發,深入解析B端系統的頁面跳轉

③ 導航模塊常駐

在一些產品中,導航模塊是常駐的,在一個模塊下的任務流程中,通過點擊友好鏈接跳轉到目標頁面,導航隨之變化,對用戶也會存在一定的暗示:模塊與模塊之間是有不同功能定位的。但是用戶當前用戶的任務流程并沒有結束,點擊了友好鏈接,相當于丟失了主流程,要是返回還需要不斷的點擊,如果是個新建流程會更糟糕,所以這種方式不是很友好,要謹慎使用。

從2個場景出發,深入解析B端系統的頁面跳轉

像阿里云這樣,左側導航欄收起的的時候,用戶從一個頁面到另外一個頁面,面包屑從 1-2-3,變成了 4-5,用戶對當前頁面的位置是無感的。從而會模糊任務路徑方向,沒辦法準確定位當前位置。所以,新開 tabs 網頁是很有必要的。

從2個場景出發,深入解析B端系統的頁面跳轉

從2個場景出發,深入解析B端系統的頁面跳轉

當然,層級越深用戶能觸及的頻率就會越小,于是團隊的一部分成員就會說既然頻率小那么對產品的影響很小,可以忽略的。但是,場景頻率小是對所有用戶而言,不是說用戶群少。對一個產品而言,讓用戶滿意很難,但是一個看似不起眼的跳轉,只要讓用戶用過一次覺得難用、頁面層級深,產品的整體印象就會大打折扣,因為用戶不會在意這個問題是產品定位的主流程還是低頻場景。往往用戶能記住的不是產品帶給業務的流暢感和增長,因為他們認為這是產品應該做到的,但是一次不好的體驗卻會歷久彌新。

頁面跳轉的總結有一定的局限性,特殊業務場景還需要做特殊處。

收藏 58
點贊 50

復制本文鏈接 文章為作者獨立觀點不代表優設網立場,未經允許不得轉載。