無極五註冊平台_以B端產品Teambition為例,回顧和理解尼爾森10大可用性原則

Jakob Nielson(雅各布·尼爾森)是可用性領域的頂級專家,他提出的10大可用性原則(10 Usability Heuristics),被廣泛運用於人機交互的各個領域 [1]。已有不少文章通過舉例探討了尼爾森可用性原則,但選取的案例以C端產品為主,B端產品的案例總量較少。Teambition是一款主要面向B端團隊協作的SaaS(Software as a Service)產品。本文選取了這款產品Web端的案例,對尼爾森10大可用性原則進行回顧,旨在能更深入地理解這些原則在B端產品上的運用。本文在整體框架上有參考《用Airbnb 的產品,幫你快速理解尼爾森10大可用性原則》這篇文章[2],在此表示感謝。

用Airbnb 的產品,幫你快速理解尼爾森10大可用性原則!

本文聚焦 Airbnb 產品,描述10大可用性原則的應用場景,希望能夠幫助你更系統地理解10大可用性原則。 一、系統狀態的可見性 Visibility of system status The system should always keep users informed about what is…

閱讀文章 >>

系統狀態的可見性

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. ——Nielson

系統應該在適當的時間給與合適的反饋,以此讓用戶了解正在發生的事情。——尼爾森

1. 位置可見

相比於C端產品,B端產品在頁面層級往往更為複雜。因此,讓用戶明確當前所處的位置尤為重要,這也就突顯出了導航的重要性。Teambition中常見的有橫嚮導航、縱嚮導航和組合導航這3種。

2. 數量可見

Teambition支持對任務字段進行自定義配置,在「添加字段」的彈窗中,當用戶勾選了字段后,下方的「確定」按鈕上會显示已選數量,方便檢查核對。

3. 狀態可見

在企業管理後台將某個任務字段鎖定后,再次進入「添加字段」彈窗,被鎖定的字段後面帶有表示已鎖定的icon,告訴用戶該字段不可編輯。

貼近用戶的真實環境

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. ——Nielson

系統應該說用戶習慣的語言,比如:用戶熟悉的單詞、短語和概念,而不是系統導向的術語。遵循現實世界的約定,使信息以自然且合乎邏輯的順序出現。——尼爾森

Teambition中集成了眾多應用,比如:知識管理工具「Thoughts」、代碼管理平台「Codeup」等。在Teambiton和Thoughts的首頁中,用到的語言通俗易懂,無需特定的專業背景即可理解。而在Codeup的首頁中,用到的語言則是較為專業的開發術語,比如「代碼庫」、「代碼組」、「合併請求」等,因為Codeup的主要用戶群體是開發人員,以上這些詞語是開發人員習慣和熟悉的。

用戶有控制和來去自由的權利

Users often choose system functions by mistake and will need a clearly marked”emergency exit”to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. ——Nielson

當用戶錯誤地選擇了的某個功能后,系統需要提供一個明確的「緊急出口」,來讓用戶離開其不想要的狀態,而且無需額外的對話框。支持撤銷和重做。——尼爾森

1. 關閉與返回

在Teambition中,一個任務下可建立多個子任務,子任務從屬於父任務。因此,在子任務彈窗中,同時具有「返回上級」和「關閉」按鈕,對應的操作分別是返回父任務彈窗,或者直接關閉彈窗。

由於B端系統的複雜性,有些功能的層級會比較深。彈窗A中的某個操作可能會觸發彈窗B的彈出,如果彈窗A和B承載的功能具有父級和子級的關係,同樣需要考慮「返回」的功能。

2. 撤銷與重做

在「任務字段類型配置」的頁面中,當用戶更改了默認的初始配置后,右上角會出現「恢復為默認配置」的按鈕。這是一種支持高效重做的設計思路。

系統的一致性

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. ——Nielson

我們不應當讓用戶去懷疑不同的語句、狀態或操作是否在表達同一件事。設計需遵循平台的慣例。——尼爾森

1. 樣式一致

以Teambition中的彈出提示為例,在位置上,提示統一出現在頁面的左下角,經過一樣長的時間后自動漸出消失;在形式上,都是icon加上文字的形式,且右上角具有關閉按鈕;在顏色上,操作成功用綠色,操作失敗和報錯用紅色,功能推送用藍色;如果提示中存在文字按鈕,則文字按鈕的顏色統一用藍色。

2. 結構一致,交互一致

當用戶從Teambition進入到不同的應用時,左上角的導航欄也會相應地變化,但是在結構上都保持了一致:按照「應用logo>當前項目」的方式聚合。這樣的結構一致能讓用戶快速知曉當前所處的位置。

當鼠標懸停在應用logo上時,logo會變成首頁icon,並以tooltip提示「回到首頁」,在這個交互上,不同應用間也是一致的。然而,當鼠標懸停在「星標」按鈕上時,不同應用在樣式和交互上都出現了差異,或許在這點的一致性上,還存在着可優化的空間。

3. 功能一致

當具備排序功能時,Teambition以相同的icon表示,並且在功能操作上也保持了一致:通過拖拽來調整排序。美中不足的是,在進行拖拽時,鼠標指針的狀態不夠一致,這點小細節可能還有待改進。

防止錯誤

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. ——Nielson

比報錯提示更好的方法是,通過嚴謹的設計來防止錯誤的發生:要麼消除容易出錯的情況,要麼把這些容易出錯的情況找出來,並在用戶採取行動之前提供確認選項。——尼爾森

1. 預警和確認

在任務菜單中,當鼠標懸停在非危險操作上時,底色會變成淺灰色;但是,當鼠標懸停在「移到回收站」上時,底色會變成紅色,通過醒目的顏色來提示用戶,這是一個危險操作,從而降低用戶誤操作的可能。而當用戶點擊「移到回收站」時,二次確認的彈窗會彈出,進一步防止用戶錯誤操作。

2. 置灰

通常情況下,按鈕置灰表示對應功能或操作無法使用,這也是防止錯誤的一條有效途徑,因為用戶通過按鈕樣式就可獲知其狀態,省去了點擊的試錯成本。那麼,是不是只要功能或操作無法使用時,就應該將對應的按鈕置灰呢?不一定。下面的案例即可說明。

如上圖所示,若任務字段的默認配置未被更改,在創建任務時,只需填寫標題就可完成創建。這種情況下,彈窗在初始狀態時將按鈕置灰是合理的。然而,當有任務字段被設置為必填后,在創建任務時,即便填寫了標題,按鈕仍然置灰,滑動彈窗仔細查看后才發現是有一個必填項未填寫。這種情況下的置灰,就可能讓用戶感到困惑,甚至無法找到原因所在。筆者認為,這裏更合適的做法是:按鈕不置灰,點擊按鈕后定位到未填寫的必填項,並告知報錯原因。

系統識別勝過用戶記憶

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. ——Nielson

通過將對象、操作和選項進行可視化,最大限度地減輕用戶的記憶負擔。用戶不需要記住對話框中某一部分到另一部分的信息。系統操作的指示信息需要易於被用戶發現和獲取。——尼爾森

1. 保留歷史

提及保留歷史,最為常見的就是為用戶保留歷史搜索和歷史瀏覽。Teambition首頁中,縱嚮導航的「近期項目」模塊按項目打開時間由近至遠排序,方便用戶快速進到自己需要處理的項目中。

2. 可視化呈現

在「看板卡片字段显示配置」的彈窗中,當勾選了右側的字段后,左側的預覽區會實時展示字段显示在卡片中的位置和樣式。筆者認為這一點設計得很好。看板的單張卡片區域比較有限,但有時又需要在卡片中囊括較多的任務信息,這時通過勾選字段后實時地預覽,可以讓用戶反覆對卡片呈現效果進行配置和調試,很大程度上減輕了記憶負擔。

3. 指示信息易取

Teambition支持的任務打開方式有3種,分別是:彈窗、側邊滑出、全屏。但如果僅僅是3個名詞,還是有些抽象,不夠直觀。因此,Teambition將3種打開方式做成了對應的3個GIF圖,當鼠標懸停在上面時,GIF圖就開始播放。當用戶需要進行選擇時,必定會將鼠標移動到對應的打開方式上,也就必然會發現GIF圖中涵蓋的指示。這樣子設計,不僅讓打開方式直觀,而且易於被用戶發現和獲取。

靈活易用的使用體驗

Accelerators  —  unseen by the novice user  —  may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. ——Nielson

一些快捷操作的功能,雖然會被新手用戶忽略,但可能為專家用戶所使用並幫助提升其使用效率,因此,系統需要同時滿足新手用戶和專家用戶的需求。允許用戶頻繁地操作。 ——尼爾森

1. 靈活配置

以任務字段為例,Teambition支持對任務字段類型進行配置,包括添加字段、刪除字段、將字段設為必填等。另外支持對自定義字段進行編輯,包括字段的名稱、類型、默認值和提示文案。任務字段的配置僅對當前所在項目生效,因此,不同的項目可具備不同的字段配置,使得項目管理更加靈活。

2. 各取所需

以知識管理工具「Thoughts」中的文檔為例,如需對文本格式進行編輯,可以有多種方式。如下圖所示,當用戶需要對文本進行加粗時,在選中文本后,可以點選上方工具欄中的加粗按鈕,也可以按快捷鍵command/ctrl+B,或者使用Markdown語法。以上這3種方式都可以達到加粗的效果,但面對的用戶群體卻不太一樣。新手用戶可能會選第1種,熟練用戶或專家用戶可能會用第2種,習慣於用Markdown寫作的用戶則更傾向於第3種。因此,在設計功能時,最好能考慮到不同層次用戶的需求,以此來讓用戶「各取所需」。

3. 允許頻繁操作

在某些場景下,用戶可能會進行一些頻繁或重複的操作,因此需考慮:如何設計才能讓這些頻繁的操作更加方便。比如,在Teambition中創建任務時,會有「保存」和「完成並創建下一個」這2個按鈕,「完成並創建下一個」其實就為那些需要一次創建多個任務的用戶提供了便利。另外,在創建子任務時,點擊「保存」后,下方會自動彈出下一個子任務的文本框,用戶可選擇繼續創建或點擊「取消」按鈕結束創建,這樣設計同樣是為了提升頻繁操作的效率。

美觀且簡約的設計

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. ——Nielson

對話框中不應包含無關或很少用到的信息。在對話框中每增加一個信息,就意味着降低了主要信息的相對可見性。 ——尼爾森

原文中用到的是「對話框」,但這個原則的適用範圍不僅限於對話框,可以將範圍擴大到整個頁面。在Teambition的任務看板中,當任務狀態為「已完成」時,對應的卡片以置灰的方式呈現,從而突出了「待處理」和「進行中」的任務卡片。當任務的優先級為「緊急」時,卡片左側會以橙色進行標記,而優先級為「普通」或「較低」的任務,卡片左側就不會用顏色標記。這個案例通過弱化(置灰)和去除(去掉標記顏色),從而讓頁面簡潔,且使得重要信息得以突顯。

幫助用戶識別、診斷、並從錯誤中恢復

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. ——Nielson

報錯信息應該用通俗易懂的語言表達(而不是用代碼),準確地反應問題,並且提出可行的解決方案。 ——尼爾森

當某個自定義任務字段在企業管理後台被鎖定后,在「編輯自定義字段」的彈窗中,不僅通過置灰讓用戶明確不可編輯,還提示了原因所在(字段被鎖定),而且也告知了解決方案(被誰鎖定,可以找誰)。

如果報錯信息用到的是難以理解的語言或代碼,那起到的效果將會大打折扣。下圖中這個報錯提示出現的場景是:在任務彈窗中添加附件併發布時出錯。從「參數有誤: attachments」這句文案中,用戶獲知的僅僅是:附件問題導致發布不成功。但,「參數有誤」是什麼意思?附件格式不對?還是附件超出大小限制?還是不知道出錯的原因,就更別提解決方案了。

幫助文檔

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large. ——Nielson

儘管,能讓用戶無需閱讀文檔就會使用是最好的方式,但大多情況下,可能還得提供幫助文檔。幫助文檔的信息應該易於被搜索,聚焦於用戶的任務,並列出具體的步驟,而且,不能太龐大。 ——尼爾森

在Teambition中,如果是簡短且和簡單操作直接相關的幫助提示,則大多是tooltip的形式:當鼠標懸停時出現;如果是關於系統通知公告、功能提示、權限範圍的幫助信息,則以文字提示的方式呈現,且根據信息的重要程度,又分為可關閉和不可關閉這兩種;而對於很難用幾句話解釋清楚的幫助信息,則配置鏈接,點擊后可跳轉到幫助中心的對應位置。

總結

在設計B端產品時,對尼爾森10大可用性原則的運用可從以下方面進行考慮,但不僅限於以下這些。

  • 系統狀態的可見性:位置可見、數量可見、狀態可見。
  • 貼近用戶的真實環境:用到的語言應該是用戶所習慣的。
  • 用戶有控制和來去自由的權利:關閉與返回、撤銷與重做。
  • 系統的一致性:樣式一致、結構與交互一致、功能一致。
  • 防止錯誤:預警和確認、置灰。但置灰在有些情景下並不適合,需結合具體情況考量。
  • 系統識別勝過用戶記憶:保留歷史、可視化呈現、指示信息易取。
  • 靈活易用的使用體驗:靈活配置、各取所需、允許頻繁操作。
  • 美觀且簡約的設計:通過弱化和去除不重要的信息,讓重要信息突顯。
  • 幫助用戶識別、診斷,並從錯誤中恢復:問題需準確,方案要可行,勿用代碼。
  • 幫助文檔:根據幫助信息的長短與類型,綜合使用tooltip、文字提示、跳轉幫助中心等形式。

本文中頁面截圖的版權歸Teambition所有。

參考

  • [1] Nielsen J. Enhancing the explanatory power of usability heuristics[C]. human factors in computing systems, 1994: 152-158.
  • [2] 王晗陵. 用Airbnb 的產品,幫你快速理解尼爾森10大可用性原則[EB]. 優設網.

未经-摩登3注册-摩登3测速官网-允许不得转载:摩登3注册-摩登3测速官网 » 無極五註冊平台_以B端產品Teambition為例,回顧和理解尼爾森10大可用性原則

赞 (0)