隱藏還是置灰?教你快速搞定按鈕的異常狀態

One
3 評論 10345 瀏覽 62 收藏 17 分鐘

“按鈕”是所有PM每天都會遇到的元素,那么針對按鈕的異常狀態我們該如何處理呢?換句話說當按鈕不可用時,我們應該怎么處理界面上的元素布局呢?

其實業內對這種場景的處理方式基本達成共識——置灰 > 隱藏 > 不處理。雖然處理邏輯的優先級基本確認,但還是要在實際場景中結合不同的設計目的來做處理。

下面從兩個出發點分別舉例說明:

商業目的

出于商業目的對部分功能入口做特殊處理在C端和B端產品中都非常常見,套餐分級就是典型場景。高級套餐的專有功能對低級套餐用戶要展示嗎?付費客戶的專項功能需要對免費用戶做引導嗎?

HubSpot對Marketing Hub的套餐分級

全部展示一定會損耗低級套餐用戶的產品體驗,增加基礎用戶的流失。不做任何導流,全部隱藏毫無疑問會影響產品的整體營收。如何平衡兩者的利弊,采取恰當的展示策略?一定要結合對應功能在產品整體架構中的不同定位,有取舍的采取不同的展示策略。

1. 產品核心功能

對于高級套餐專有的核心功能,對應入口一定會在低檔套餐中有足夠的露出。同時置灰不再是第一選擇,而是類置灰的特除處理,引導購買和Upsell是核心功能按鈕在低級套餐展示的首要目的。

HubSpot對Sequences功能的升級引導

直接隱藏一定會是最差的選擇,無論是B端還是C端產品,低檔或免費用戶的轉化都會是產品盈利的正向指標之一。

置灰在這里也不再適用,因為它會傳達錯誤的信息給用戶。讓用戶以為只是操作環境或條件不對,創建不一致的預期。

大多數產品會將對應的功能按鈕做一些UI樣式上的處理(其實也算是另類的置灰處理):

以Trello為例,當免費用戶創建的team board達到上限后,并不會直接隱藏或置灰創建board按鈕,而是將文案轉換為獲得無限board,巧妙的引導升級。

Trello免費版套餐正常創建Board時的按鈕

Trello免費版套餐創建Board達到上限時的按鈕

騰訊體育則更為粗暴,對于核心的藍光清晰度直接標識出VIP專有功能,這類操作在C端產品非常普遍,當然也很有效。

騰訊體育觀影時的清晰度設置

2. 產品非核心功能

考慮B端產品的功能會比較復雜且繁多,對于高級套餐專有的非核心功能,要有取舍的隱藏。不要過多的干擾客戶,影響客戶的正常使用。

以HubSpot的marketing 套件為例,在免費版的Marketing菜單里只保留了核心功能Landing Page的引導漏出,對于Blog這種相對沒那么高頻的功能,直接做了隱藏處理。

HubSpot免費版菜單

HubSpot付費版菜單

對于類似的場景,這里不再贅述,相信各位PM能夠良好的判斷自己產品的核心及非核心功能。

產品功能邏輯

敲黑板了,這里是本文的重點,也是PM日常工作遇到最多的地方。每個按鈕都有不同的功能邏輯,可能是下一個頁面的入口,也可能是某個功能的觸發器,或則是向系統提交一個表單,等等……下面還是區分為兩種使用目的來描述對應的處理方法:

1. 產品功能入口

簡單的理解就是這個按鈕其實本身沒有功能意義,它的存在只是為了承載用戶在不同頁面/功能之間跳轉。最典型的例子就是網頁的導航菜單,APP底部的多tab切換。

那么需要特殊處理的場景基本上只有兩大類:

(1)不滿足觸發條件

對于這種場景,大多數新人PM可能就是粗暴的采取隱藏了,當然這也很好理解,這種場景下后置功能/頁面是不可用的,那把按鈕展示在原位不是誤導用戶么?但是呢,這里還是要從結果出發,思考什么樣的處理才是最符合當前按鈕的設計初衷,沒有人想使用一個在大多數情況下不可用的按鈕。

可以方便的補全觸發條件

如果該按鈕的觸發條件可以方便且快速補全,那么不要幫用戶做決定。讓按鈕待在那里,我們只需要給客戶一些必要的提示就可以,置灰或則不處理都是合理的選擇。

比如抖音在沒有獲得相機權限時一定不會把添加短視頻的入口封掉,而是合理的引導打開對應權限。

抖音未獲得相機權限時的添加短視頻界面

HubSpot中contact的詳情頁有許多快捷操作,比如調起call或text面板。但是當前賬號沒有綁定個人號碼時,快捷操作的按鈕也不會隱藏,只是后續的流程做了調整,引導用戶快速補全必要的信息。

HubSpot中未綁定個人電話時點擊呼叫按鈕

另外第一大節介紹的在低檔套餐做核心功能升級引導也可以歸入此類。

(2)傳遞信息

這類場景主要是指信息展示功能的入口。數據不足導致信息展示不全也算相對常見的場景了,大部分PM都會遵循“減少不必要操作步驟”的設計原則,將跳轉功能禁用掉,那么前置按鈕是否隱藏,這里就需要大家多多思考了。隱藏肯定是不好的選擇,不然用戶會覺得是系統bug了,為什么操作按鈕突然沒了?所以比較好的方式是采用置灰或則“類置灰”的處理來傳達“這里沒有任何內容”的信息。

以淘寶的商品評論為例,如果沒有任何評論時,會對之前的評論模塊做個特殊展示,傳達這里沒有評論的信息,同時也禁用了往下個頁面跳轉的功能。

淘寶商品詳情頁無評論時的頁面展示

再對比下京東的商品評論,同樣對無評論時的模塊做了特殊處理,但是并沒有禁用下個頁面的跳轉。當然這樣處理的意義就仁者見仁智者見智了。

京東商品詳情頁無評論時的頁面展示

京東商品評論的詳情頁展示

2. 不滿足觸發環境

這里主要是指硬件上的障礙比如網絡環境或則設備不兼容等問題,理論上這種極端情況是不用再考慮個別按鈕的處理方式的。

(1)網絡環境

未開啟網絡在移動端設備相對常見,鑒于大多數產品都會采用強提醒的方式讓客戶盡快恢復網絡,所以對應的功能按鈕也不會采用任何處理。

微信無網絡狀態時的聊天面板展示

(2)設備兼容

比較典型的場景就是產品在移動端和桌面應用的多設備支持,有些功能是因為設備的限制,所以不在某個端口支持。比如掃碼這個功能,無論是微信還是淘寶,桌面端都不會保留功能入口,用戶也非常好理解,不會奇怪為啥我不能拿著電腦到處掃碼。

有些功能則是PM基于產品特性考慮,故意限制了對應端口的功能。比如微信桌面應用是無法處理任何與交易相關功能的,但是并沒有在聊天窗口隱藏領紅包的消息,而是做了“類置灰”處理,引導用戶在移動端處理。

微信桌面應用中聊天窗口對紅包消息的展示

總結下:對于功能入口按鈕的無效狀態,大多數情況下都是采用置灰或“類置灰”的處理,部分極端情況下可以考慮不做任何處理。當然直接隱藏也對部分場景適用,前提是判斷邏輯簡單,你的用戶能夠心領神會,不會引發歧義。

3. 產品功能操作

如果將一個產品比喻為一個完整的“人”,那么功能操作按鈕就像是人的“肌肉”,受到“大腦”的思維控制,將“想法”變為“行動”。比如IM產品的消息發送按鈕,電商產品的喜歡和購買按鈕,或則當你在某個網站注冊時的提交按鈕等等。

所以這里的異常狀態處理得格外小心,千萬不要阻礙用戶的核心轉化流程,要善用引導, 用信息元素來傳達合理的操作路徑。而且大多數情況下,功能操作按鈕的非可用狀態一般都是出于業務上的限制。如何做特殊處理,要根據對應的業務場景的復雜度來決定。

(1)業務場景簡單

對于C端產品而言,大多數產品的業務限制是非常好理解的,畢竟是貼近生活化的產品,因為一些基礎邏輯的限制對按鈕做特殊處理是非常好理解的。因此處理起來也相對省事,不用有太多顧慮,置灰或則不處理都是可以的。

以微信和QQ為例,產品的核心功能肯定是發送消息了。但是如果沒有消息內容,那發送按鈕該怎么辦呢?

微信選擇了置灰,QQ選擇了不處理(點擊后無反應),暫不評價這兩種處理邏輯的好壞,但是側面看出隱藏按鈕一定是個bad choice。因為用戶在輸入前看不到發送按鈕,一定會有不安全感,或則質疑我該怎么把消息發出去。

微信對無消息內容時發送按鈕的處理

QQ對無消息內容時發送按鈕的處理

再看下淘寶因為對應商品型號沒有庫存情況下的處理,也是簡單的置灰,沒有任何額外的提示。

淘寶商品詳情頁選擇商業型號彈窗

(2)業務場景復雜

相對而言,大多數B端產品的業務邏輯會更為復雜,特別是有些功能按鈕會與其他的功能相互耦合,有一定的理解成本。因此對于非可用狀態按鈕,要增加一定的說明和引導。

最典型的場景就是表單的提交按鈕了,當客戶沒有按照要求錄入必填字段的信息時,大多數產品并不會直接置灰提交按鈕,更不要說隱藏提交按鈕了。而是保留按鈕的可點擊態,采用后置的強提醒讓客戶補全表單。

Salesforce的注冊界面-未錄值時點擊提交按鈕

Zoom的注冊界面- 未錄值時點擊提交按鈕

另外對于特別復雜的功能,還可以在置灰的同時增加引導說明,讓用戶進一步理解產品功能的運轉邏輯。以HubSpot為例,Workflow屬于業務屬性非常強且操作步驟非常復雜的功能,當客戶想要激活workflow時,需要先指定流程的應用對象,這時置灰后加上提示浮層就是非常好的選擇。

HubSpot的Workflow編輯界面

總結

對于按鈕的不可用狀態,我們會有很多種處理手段:置灰、隱藏、不處理、甚至做一些類置灰的變形處理,以及隱藏按鈕后的后置引導等等。但是這里沒有通用解,理清自己用戶的場景,明確自己產品功能的目的,這樣自然而然你就有了最優解。

 

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

題圖來自Unsplash,基于CC0協議

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

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 如果一個按鈕是否可用,需要請求后臺數據呢?怎么考慮

    回復
    1. 需要考慮后臺數據的判斷延時?這種不適合隱藏,可以直接顯示按鈕,有一個加載態過度。即使服務端返回數據不可用也可以顯示業務側的判斷原因

      回復
  2. 好文,對我很有幫助,感謝版主!

    來自江蘇 回復