去年秋天，Luke Wroblewski發(fā)了一篇名為“Requiring Less Taps in Mobile UI”的文章，并在其中提出了“流體點擊手勢”的概念，旨在減少用戶在特定操作過程中需要執(zhí)行的點擊次數(shù)。
他提出的新概念挺有意思；對于“如何控制點擊次數(shù)”這一問題萬分關切的設計師顯然也不止Luke一人。
不過我(英文原文作者)個人覺得“更少的點擊次數(shù)”并不能算是一個很得當?shù)脑O計目標。在UX設計的過程中，將過多的注意力聚焦在一個特定的點上，相應的風險就是對其他痛點和問題的失控。我們更應該著眼全局，并思考“怎樣使這些界面用起來更容易些”。
還有哪些是需要控制的？
如果說點擊次數(shù)是我們需要關注的痛點之一，那么還有哪些是我們需要從整體的角度加以控制和優(yōu)化的？
Apple在自家產(chǎn)品及其app設計規(guī)范當中始終強調一點 - 缺乏一致性的設計會給用戶帶來疲勞感。雖然并不是指會令用戶放下手機打個盹的那種疲勞，但比喻的說法是正確的。缺乏一致性的設計，也是我們需要控制的痛點之一。
另一方面，以注重產(chǎn)品性能和效率而聞名的Google則強調“如果界面加載時間超過1秒，用戶的使用流程就會被中斷。”
所以我們在設計和開發(fā)流程當中要加以控制的痛點其實有很多，這些都是需要我們綜合考慮進來的；將過多資源聚焦在其中的一點，很可能導致其他方面問題的爆發(fā)。
降低使用負荷
上面提到的這些痛點，例如過多的點擊次數(shù)，缺乏一致性的界面，較長的加載時間等等，都可以看做是軟件工具強加給用戶的負荷。我們真正的目標是從整體上減輕這些負荷，使用戶更流暢更高效的使用產(chǎn)品提供的功能來完成目標。
你甚至可以試著通過量化的方式來評估產(chǎn)品的使用負荷，數(shù)數(shù)看在整個流程中存在多少“負荷點”，例如：
界面加載過程中的每一秒都算作一個負荷點。 每次點擊算作一個負荷點。 用戶為了尋找那些默認隱藏起來的導航或CTA(Call To Action)而花費的每一秒都算作一個負荷點。 在所有這些之前，用戶為了使用產(chǎn)品而必須將手機從口袋中掏出來的整個過程算作至少一個負荷點。(Hello Apple Watch!)
著眼于整體體驗
要全面的進行量化評估，應該從哪里開始計算呢？完整的流程起始于用戶產(chǎn)生了使用產(chǎn)品完成特定目標的動機的那一時刻。
以天氣類app為例，用戶的使用動機多種多樣，我們不妨聚焦于最簡單最基本的那一種需求 - “外面天氣如何？”
通常，你需要拿出手機，解鎖，找到你想要使用的天氣app，打開并等待界面與信息加載，查看信息。大體是這樣，從使用負荷的角度來講不算太壞，我們長久以來也就是這樣做的。
不過也請試想一下：
抬起手腕看看你的Apple Watch，當前的天氣信息直接顯示在表盤四周的“復雜功能”區(qū)域當中。 如果你的Android手機就在身邊，你可以直接提問“OK Google Now：What’s it like outside?”，然后手機將天氣情況朗讀出來。
相比于前面提到的“傳統(tǒng)”使用流程，這些新方式對使用負荷的降低程度是不言自明的。你可以具體的數(shù)一數(shù)這些流程當中的“負荷點”，數(shù)據(jù)也會告訴你誰是贏家。
當然，通知(Notification)對于簡化流程、減輕負荷也起著重要的作用。實際上，某些特定類型的通知，譬如Foursquare基于用戶所在位置發(fā)送的信息，其目標就是在特定的情境中無需用戶主動發(fā)起查詢行為便可以推送正確的信息，極大的簡化了流程。
不過，只有在設計的得當時，通知機制才能發(fā)揮出智能減負的作用。如果設計不當，它們只會增加用戶的負擔 - 要么在根本不需要的時候提供信息，要么在用戶需要的時候提供沒有實際價值的信息 - 如果發(fā)現(xiàn)這種情況，你最好把它們當做兩個負荷點計算到評估結果當中。
此外，如今越來越多的所謂“隱形app”也在簡化流程方面有著自己獨到的特性。嚴格的講，這些“app”不能被稱作app，它們本質上是bots，依存于現(xiàn)有的短消息、郵件或其他社交平臺而存在，本身并不擁有獨立的UI體系。你在這些現(xiàn)有平臺中輸入特定的信息，便能完成相應的任務。Slackbot的眾多用戶會告訴你這樣的東西有多好用。
形成競爭力
一款產(chǎn)品在降低使用負荷方面的能力強弱，將是決定它能否走向成功、甚至與龐大對手進行競爭的關鍵要素之一。
以天氣類app“Dark Sky”為例。這款app會在首屏詳細而生動的顯示出接下來一個小時內將要發(fā)生的天氣狀況變化，這是人們在生活中常會關注的信息。
我們將Dark Sky與著名而且流行的The Weather Channel app做以比較。下面的截圖演示了后者從首屏到展示下一小時天氣狀況信息的整個流程：
對于查看下一小時天氣狀況這一常見需求來說，Dark Sky相比于TWC至少省掉了3個負荷點，包括兩次橫向輕掃的手勢，以及用戶對于“小時天氣信息”所在位置的思考，甚至是對該信息是否存在的疑慮。
讓我們把情況設想的更加實際和復雜一些：鑒于TWC的流行程度，在你第一次嘗試Dark Sky的時候，你的手機里很有可能已經(jīng)安裝著TWC了。所以對于Dark Sky來說，使用負荷當中還包括下載新app這一行為，不過好在只有一次，所以不用計算進常規(guī)的流程當中。
對于The Weather Channel這樣的“類別霸主”來說，通常會提供龐大的功能體系來一一解決它所占領的產(chǎn)品類別當中的各種需求。功能越來越多，其中總會有一部分被逐漸埋沒到需要依靠多次點擊、輕掃等操作才能發(fā)現(xiàn)的地方，例如漢堡包菜單或是一層層深入的下級界面。一屏界面只有那么大的空間，顧此失彼的矛盾狀況將越發(fā)嚴重。
如果你的產(chǎn)品不需要用戶背負如此之高的認知與操作負荷便能發(fā)現(xiàn)并高效使用其核心功能，并且在這一功能上將體驗打磨到極致，那么你就擁有與那些龐然大物進行競爭的力量 - 你至少可以拉攏到那些在多數(shù)時間只會用到這些特定功能，卻被那些復雜的產(chǎn)品搞的疲憊不堪的用戶。
這也是為什么很多龐大產(chǎn)品開始自我解綁的原因，譬如Facebook已經(jīng)了解到一個小而美的獨立app可以幫用戶更加輕松的收發(fā)消息，用戶不必因為這種高頻需求而淹沒在大型產(chǎn)品的各種復雜功能當中 - 所以我們看到了Facebook Messanger。
小結
降低使用負荷所帶來的好處是多方面的。其實作為產(chǎn)品設計人員，我們心里或多或少都知道這樣的原則，只是在實際當中，我們時常會忘記從全局層面來考慮各方面的問題。不妨嘗試以量化的方式統(tǒng)計產(chǎn)品流程當中的“負荷點”，從整體上對這些問題進行調控和優(yōu)化，或是嘗試不同的產(chǎn)品設計模式來從根本上簡化流程、降低負荷。
