產品經理,你真的了解web導航么?

16 評論 20477 瀏覽 159 收藏 14 分鐘

本文作者依據工作中實踐的所思所想,并結合案例等分享了web導航相關知識,供大家一同參考和學習。

上次寫了一篇概述B端產品經理的三項基本功的文章(B端產品經理要掌握的硬核基本功)后,很多朋友私信說想讓我寫寫導航,想來網上跟導航有關的文章也比較少,這次就聊聊web導航,也讓各位產品經理多一個參考。

我一直都認為產品經理是一個非常專業的職業,很多事情都有一套方法論,導航設計也不例外,本文既然要詳細聊聊導航,那就得把跟導航有關的所有事情都聊清楚,各位看官不要急,我們先從信息的最初來源——元數據講起。

一、從信息元數據說起

元數據這個概念相信所有PM都不陌生,在大家的潛意識里,好像元數據這個玩意是后端開發才需要了解的。

但是我認為,一個PM應該比開發更了解元數據,不是了解各個接口的每行代碼如何寫,而是要了解這個系統有現在有哪些數據,是如何組織的,將來要有哪些數據?

元數據是信息的信息,可以理解為一塊塊磚,在搭建一個系統的信息架構時,每一處地方都需要這一塊塊不同的磚來填充.

元數據主要分為三大類——固有性元數據、管理型元數據、描述性元數據。

  1. 固有性元數據是指和信息構成有關的數據,比如如一條任務的ID,一個視頻文件的大小。
  2. 管理性元數據是指與信息處理方式有關的數據,比如一條申請的審批狀態,編輯人賬號名等。
  3. 描述性元數據是指對信息本質進行描述的數據,很多時候以標簽的形式展現,比如你在B站上搜索“騷”,會出現很多跟“洪世賢”有關的視頻,說明在B站的元數據中,“洪世賢”的本質是“騷”。

為了讓大家更好的理解三種元數據區別,我舉一個例子,請看下圖。

一張照片的元數據

上圖是我去年在重慶北站接K總時用手機拍的照片,左邊可以很清晰的看出照片的三類元數據,如果這張照片被上傳到攝影論壇,一個用戶要是想找到它,很可能到火車站標簽下尋找,或者直接檢索重慶火車站,而不是去用ID”6781″去檢索。

這也說明了一個事實:大家更愿意去使用描述性元數據檢索,而不是難以記憶和識別的固有性元數據。

元數據是確定信息組織形式最關鍵的信息,可以把元數據看成一個個標簽,不僅能夠為產品經理提供分類的依據,還可以很方便的根據元數據做信息關聯。

了解你的元數據,是設計導航的前提。

二、用戶是怎樣尋找信息的

導航的目的是幫助用戶查找信息,那么你有沒有想過一個問題——用戶究竟是怎么查找信息的呢?

一般來說,用戶查找信息有以下四個場景。

場景一:用戶知道想要什么,且知道如何找

對于C端產品來說,由于同類產品對市場的教育,讓用戶接觸到你的產品時就知道如何操作,但是對于B端產品,基本不會出現一上手就會用的情況。

對于該場景下的用戶,其實他們已經可以很熟練的使用系統了,此時在首頁提供一個高頻頁面入口或者一個搜索更能讓這類用戶心花怒放。

場景二:用戶知道想要什么,但不知道如何找

這種場景經常會出現,比如用戶想看知道自己的消費記錄,但是不太確定是在哪個頁面找。

再舉一個更直觀的例子,你想要買一個能頂餓又美味的零食,你該如何鍵入關鍵詞,或者你該在哪個頁面找到它。

這類情況就需要通過優化信息元數據,增加更多的描述性元數據來解決,淘寶的很多面包商品都有頂餓的標簽,直接搜索“頂餓美味”就可以搜出來。

當然,同時也要注重導航架構的優化,如果你的很大一部分用戶都在搜“頂餓美味”,你是否考慮將頂餓美味做為食品下的一個子類目呢?

場景三:用戶不知道自己想要什么

這種場景在B端很少出現,畢竟使用B端產品的人都是有著明確目的的。但是在C端卻經常出現,比如很多人在逛淘寶的時候可能僅僅是無聊,而不是因為自己想買東西。

為了應對這類用戶,就需要搬出C端大殺器——關聯導航,就是說在瀏覽某一頁面時,會給你推薦相關的商品或者算法算出你可能會感興趣的商品,有時候也叫關聯推薦。

關聯導航可以使用描述性元數據實現,將有相同標簽的商品在商品詳情頁做推薦展示。

場景四:再次搜索

再次搜索是指用戶可能想返回去找到他們過去發現的某些東西,這個其實很好解決,無非就是一個瀏覽記錄和合理的結構導航設置罷了,這個很多產品都實現了,有一套比較成熟的解決方案。

只要抓住了以上這四類場景,在設置導航時,充分考慮用戶在每個頁面會遇到哪些問題,針對問題修改導航的邏輯與布局,導航設計其實是一件很簡單的事情。

三、結構導航、關聯導航與可用性導航

好了,講了這么多,終于說到導航了,導航分為三類——結構性導航、關聯導航、可用性導航。下圖可以很直觀的看出三類導航的區別。

三類導航形式

1. 結構性導航

結構性導航表示了網站的層次結構,有全局導航和局部導航兩種,一般展示網頁主體的信息架構,告訴用戶這個網站有什么,結構性導航是一個網站最重要的導航。

全局導航往往都是一級導航,在大多數頁面都會出現,方便用戶跳轉以及隨時查看這個網站有哪些內容。

局部導航和全局導航是有層級關系的,局部導航幫助用戶瀏覽到更加特定的頁面,有的產品也會把全部的下級導航都放在全局導航上,鼠標畫上去時有個下拉的hover效果,這個要看具體的業務情況。

阿里云官網的結構導航

值得一提的是,全局導航也不是所有頁面都需要的,比如京東的支付頁面,在這個頁面,產品經理只希望用戶趕快完成支付行為,而不受其他頁面干擾,所以在這一頁不應該出現全局導航,在這里不支持用戶跳轉到別的地方。

京東收銀臺的支付頁面

2. 關聯導航

關聯導航是一種跨越信息架構的層次,快速跳轉到相關頁面的一種導航形式,在B端產品中不多見,但是在C端產品中極其常見,比如在B站上面看漫威蜘蛛俠的視頻,旁邊就有相關視頻的推薦。

關聯導航有兩個作用:

一是給用戶提供下一步的內容,當用戶看完這個視頻后,很可能點擊下一個視頻,這樣就很有可能把一個5分鐘的訪問行為擴大到15分鐘,甚至一個小時;

另一個作用是給自己的產品提供了一層“安全網”,如果用戶對正在觀看的視頻不感興趣,你覺得他會重新回到主頁再輸入其他關鍵詞還是會直接離開呢?不要挑戰用戶的耐性,再給他推薦幾個,留住他的心。

關聯導航的實現可以通過增加描述性元數據來實現,對于很多相關的標簽,可以建立受控詞匯表來進行關聯。

B站的相關推薦

3. 用性導航

可用性導航是指一些幫助提升網站可用性的功能,不是主要功能,但是一個也不能少,比如賬戶信息、網站幫助、操作手冊等。

這些信息有個通用的慣例,都是放在網站的右上角,各位產品經理在設計網站的時候,要注意跟隨慣例,不要讓用戶摸不著頭腦。

淘寶網的可用性導航

四、一些導航設計小技巧

最后給各位聊聊一些導航設計的小技巧,都是我在產品設計中積累的經驗,相信能夠讓你在導航設計中少踩坑。

1. 一定要明確希望用戶做什么

在設計導航前,產品經理應當好好考慮一下,自己究竟希望用戶在網站上做什么,希望用戶四處瀏覽,還是緊盯著手上的任務,不需要其他的干擾。

比如上文說到的B站關聯導航和京東的支付頁面,產品經理對用戶有著不同的行為期望,所以設計出了不同的導航。

2. 不要忽視分頁導航

分頁導航主要是針對表單和過程設計的,在表單或者過程步驟過多的時候需要采用此類導航,這時每頁內容展示量以及是否支持跨頁跳轉是考量的關鍵。

百度貼吧的分頁導航

3. B端隱藏導航最好不要超過兩級

隨著各種產品的體驗越來越好,現在的用戶也變得挑剔,無法忍受體驗不好的產品。

如果你細心觀察,你會發現一般的B端產品的隱藏導航一般不超過兩級,加上展示出來的全局導航,一共不超過三級。

層級越多,用戶體驗越差,如果迫不得已,可以采用一些手段來優化用戶體驗,例如有贊微商城的導航很復雜,就采用把一二級導航直接展示出來的方式來提升用戶體驗。

有贊微商城的三級導航

4. 水平導航巧用“more”

web端導航有兩種常見的布局形式——水平導航和側邊導航。

水平導航更方便使用且不會縮短頁面寬度,是很多產品都喜歡采用的形式,但是由于屏幕的寬度有限,水平導航無法展示太多內容,這個時候就可以使用一個“more”來增強水平導航的信息量。

站酷使用“more”來擴展水平導航

以上是我對導航設計做的一個整體梳理,篇幅有限,細節難免有疏漏,如有問題可在評論區留言,或者關注我的公眾號——pmhenry。

希望每一個產品經理都能設計出屬于自己的錦繡藍圖。

 

本文由 @王撼宇 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 您好,請問有關固有性元數據、管理型元數據、描述性元數據這三個元素,我是否可以理解為一個大的標簽,在數據庫中,除了ID這類唯一標識,都是多對多的關系呢?

    來自北京 回復
    1. 是的

      來自重慶 回復
  2. 寫的很好,受教了

    來自四川 回復
    1. 感謝認可

      來自重慶 回復
    2. 很好

      來自北京 回復
  3. 我好像在公眾號搶先看了

    回復
    1. 關注公眾號,精彩搶先看

      來自重慶 回復
  4. 等了這么久終于又更了

    來自重慶 回復
    1. 7總久等了

      回復
  5. 收藏

    回復
  6. 驚現撈叔客串

    來自江蘇 回復
    1. 一般不都是叫撈姐么

      來自重慶 回復
  7. nb學習了

    回復
  8. 我是K總,他沒有去接我,他吹牛的

    回復
    1. K總還是健忘

      回復
  9. 等了這么久終于又更了,這樣催更是不是不太好 ?

    來自重慶 回復