Salesforce的設計原則

Clarity-Eliminate ambiguity. Enable people to see, understand, and act with confidence.

Efficiency-Streamline and optimize workflows. Intelligently anticipate needs to help people work better, smarter, and faster.Consistency-Create familiarity and strengthen intuition by applying the same solution to the same problem.Beauty-Demonstrate respect for people』s time and attention through thoughtful and elegant craftsmanship.

比起Fiori的晦澀難懂,Salesforce的設計原則不但非常的簡潔,而且非常實用。不論是入門還是資深的設計師,不論什麼類型的企業級應用,我覺得這4條原則都是適用的。清晰,高效,一致,美觀,優先順序依次遞減,非常有指導意義,比較容易遵從。

Salesforce非常強調的是這4個原則的優先順序,目的是為了做設計決策。對於設計師來說,指出一個不一致的問題非常容易,但解決這一問題很難。設計上所有的地方都一致了,問題就解決了麼?在實際項目的討論中,分歧是最常見的現象,每個人都會基於自己的立場看問題,那麼設計決策應該怎麼做?很多時候會因為無止境的討論而得不到有效的結論。項目越大,這個現象越嚴重。Salesforce的設計原則的本質是要制定一個所有人都接受的共同立場,大家在碰到衝突的時候能夠基於這個準則快速的得出結論並且做出決策。

那麼,Salesforce為什麼按照清晰,高效,一致,美觀這樣的順序來安排優先順序?詳細的解讀可以看一下Salesforce的UX Design Architect的這篇文章(來自Medium,需要翻牆)。我在這裡大概的翻譯一下。

  • 清晰:用戶需要清晰的完成任務,達成目標。如果我們能夠通過不斷的讓用戶成功的達到目標,那麼我們會贏得他們的信任,忠誠和感謝。所以把這個原則放在第一位。
  • 高效:這是個在用戶嘴裡被不斷重複的高頻詞。本來我們想把它放在第一位,但是我們還是決定把它放在第二位。因為我們注意到一個問題:一個命令行對於一個專家級用戶來說是很棒,但對新手來說就晦澀難懂了。如果我們把高效做到極致,那我們大部分用戶將會不知所措,他們會不斷的犯錯,並且因此耗費大量時間。所以高效是第二位的。
  • 一致:無論是構建用戶的直覺還是設計師遵從設計規範,一致性非常重要。如果把一致性排第一,系統會因為創新被遏制而止步不前。如果有個設計很棒但是違反了一致性怎麼辦?所以我們把一致性放在第三位。
  • 美觀:雖然說美觀對設計師來說非常重要,但是這不是定義產品的指標。在這個領域裡,設計的目標是解決問題,設計了一個美觀但是難用的系統並沒有什麼意義。美觀可以引人注目,但是對企業級應用來說並不是第一位的,所以放在第四。

作為一個企業級應用的設計師,覺得這4個原則真是說到心坎上去了,乾脆利落,振聾發聵。Talk is cheap, show me the design. 我們來看一看Salesforce的系統是怎麼把這些原則融入到設計中去的吧。

系統結構和導航

Global Navigation

Setting - Vertical Navigation

App Launcher

Salesforce系統的信息結構不同於傳統的模塊式的結構,採用了混合的形式,引入了角色的概念。在App Launcher中,一個App對應一個角色,一個Item對應一個功能模塊,一個App其實是多個Item的集合。當你選擇一個角色,比如Sales,系統自動把整個導航欄切換成對應的Sales的內容,這些內容都是和Sales相關的Item。除此之外,業務模塊和配置模塊在系統上是隔離開來的,可以理解為兩個平行的系統。我們可以看到設計都是為業務服務的,通過App Launcher和Global Navigation用戶能夠非常清晰的瞭解系統的結構,只關注和自己有關的內容。一致性在這個層面優先順序很低,如上圖中,系統的導航形式並不一致。

Salesforce Global Navigation - 展開

Salesforce的菜單的導航效率非常的高效。點擊區域分為Label和下拉圖標兩塊。拿Opportunities(銷售機會)來舉例,直接點擊Opportunities區域顯示的最近查看的,而不是所有銷售計劃的列表,因為all其實並沒有太大的意義,對於實際的業務操作人員,通常還是需要一個過濾條件來縮小目標的範圍。Recent Records會顯示最近查看的3條銷售機會,可以在菜單上跳過列表層直接訪問具體的一個銷售機會,對於追溯一個銷售機會非常方便。Open "Recently Viewed" in New Tab則是一個非常靈活實用的功能,方便在導航標籤上掛起一個最近查看的列表,可以方便的來回切換進行比對。Salesforce的導航菜單完全不同於傳統的導航,傳統的導航非常在意層級的表現力,但是在這裡,我們可以清楚的看到,它是怎麼以業務為導向,為用戶設計出高效的導航菜單。

創建行為

Global Navigation上的創建

列表頁上的創建

全局創建

創建一個單據的同時創建一個主數據

系統中存在4種創建行為,分別對應著不同的業務場景,非常典型的為了高效犧牲了一致性。

  • 菜單上就有直接創建的按鈕,不需要用戶導航到對應的列表頁再點擊創建按鈕。
  • 列表頁保留的創建按鈕符合用戶傳統的認知。
  • 全局創建可以在任何頁面任何狀態喚起創建窗口,該創建過程應對著是突發,會打斷用戶,優先順序較高的任務(比如突然接到客戶的電話)。全局創建喚起的窗口屬於shell層的內容,所以是獨立的進程,用戶只需要填寫最基礎的4個欄位,即可將單據快速創建出來,後期再補充完整。非常Nice的一個功能,Salesforce特有。
  • 創建單據的同時創建主數據。這在業務中比較常見,當你創建一個單據的時候發現少了一個主數據,這時候不需要跳轉到主數據的模塊,直接在當前頁面喚起創建主數據的窗口完成創建,並且不會中斷單據的創建。

編輯行為

圖1 Quarterly Performance - Goal的編輯

圖2 卡片上觸發一個單據或主數據的編輯

圖3 列表上的編輯,假冒的Inline Edit

圖4 詳情頁上的編輯,假冒的Partial Edit

圖5 普通編輯

圖6 Update Active - 直接編輯

Salesforce的編輯行為可以說五花八門,基本上在任何一個用戶想要編輯的地方都可以觸發編輯的行為。不像傳統的軟體,必須到對象的詳情頁,才能觸發編輯的行為。如果只是為了考慮一致性,很多創新的設計會被遏制,系統中根本不會存在這麼多樣化的編輯行為。又是典型的為了高效犧牲了一致性。

還有一個非常有意思的地方就是在列表頁和詳情頁觸發的實時編輯(圖3圖4),雖然可以直接編輯,但是不能實時保存,還是需要點擊頁面下方的save,所以我叫它們假冒的實時編輯。有經驗的設計師一下就能明白為什麼是假冒的,實時編輯在開發上實現的成本很高,如果是產品半路改成這樣的行為需要動到開發架構。Salesforce的設計師用了一個非常聰明的方法,權衡了體驗和技術上的衝突,在設計和實現上找到了一個平衡點。非常值得學習的小細節,很多時候設計上的精益求精對於設計師本身沒錯,但是對於整個產品和項目來說,是需要權衡的。

頁面佈局

銷售機會

這個頁面的佈局從業務的角度看非常清晰,信息的優先順序排布的很有序。橙色部分優先順序最高,藍色部分其次,綠色部分最後。把裡面的內容分別提取出來是一個這樣的結構(字體的顏色和上圖遮罩區域顏色對應,優先順序依次遞減)

頭部

  • 關鍵信息(從整個業務對象中提煉出來的核心內容用於快速識別)
  • 銷售機會的進度條

內容部分

  • 動態(為了更好的追溯當前銷售機會的變化)
  • Chatter(一個輕量級的Slack,為了團隊內部成員之間更好的交流)
  • 詳情(顯示一些靜態的信息,創建單據的時候填寫的內容)

邊欄卡片

  • 相關的快捷鏈接(可以通過滑鼠懸停直接顯示列表的預覽)
  • 活動影響
  • 聯繫人
  • 報價
  • 產品
  • 筆記
  • 附件

Nesting Tabs

整個銷售機會的內容其實很多,但是可以很好的被一個頁面有序的呈現出來,Nesting Tabs這個控制項很關鍵。通常來說,兩層Tab的堆疊是一個挺難處理的設計用例,但這裡是一個很巧妙的解決方案(第二層的Tab採用卡片來包裹裡面的內容),用一個簡潔的控制項承載了複雜的結構和大量的信息,讓頁面看起來非常整潔清晰。

Salesforce設計原則的總結

在實際的項目中,每個設計決策都要去權衡來自於各個方面的因素,4大原則的優先順序在這一點上非常的實用。Salesforce的Lightning在2015年第四季度發布,整個系統在2017年之後趨於穩定,一直到現在,視覺和交互上幾乎沒有太大的變化,可見這些設計還是經得起業務和市場的考驗的。除了上面舉例的部分,系統裡面還有很多精妙的設計,在業務的上下文中體驗很好,限於篇幅,無法把更多的細節逐一分析。但總的來說,清晰,高效,一致,美觀,四個原則貫徹落實的很好。

從設計師的角度而言,清晰和高效兩個原則是需要設計師對用戶的角色和業務有著深入的理解的,不能僅限於表現和框架層面。Salesforce的控制項如果脫離了業務的上下文,看起來索然無味。它很好的解釋了業務驅動設計的產生,而不是先造控制項,再往裡面填內容。如果像第一章的實驗一樣,只是考慮控制項和框架的特性,硬把內容塞進去,會導致用戶使用起來非常違和。


推薦閱讀:
相關文章