移動設計需摒棄的幾大PC應用設計方法

　　伴隨著移動大潮的到來，移動優先設計理念已深入人心。鑑於移動裝置的特殊性，PC應用的設計思路往往不適於移動設計，但很多設計者不思變通，照搬PC應用的設計方法，造成所設計產品存在很多缺陷。Luke Wroblewski在《An Insider’s View of Mobile-First Design: Don’t Make These Mistakes》一文中指出了移動優先設計需要避免的幾大錯誤，並分別結合例項給出瞭解決方案。

　　無論是使用者、企業家，還是廣告商，都喜歡涉足“移動”這個領域，因為移動產品時刻陪伴著我們，並可隨時訪問。但這一機會同時也面臨著設計所帶來的諸多限制：移動產品螢幕小，且通過觸控來控制，所連線的網路參差不齊。鑑於此，Facebook、Google、PayPal及無數迅速投身於移動優先設計的創業公司也都意識到針對移動產品進行設計並不同於桌面PC。

　　針對桌面PC的設計思路往往不適於移動設計，但這些思想因根深蒂固而被隨意使用。這正是本文分享移動設計中常見錯誤的主要原因。設計者、產品經理及企業家不僅要了解如何針對移動進行設計，同時也要以不同的思路來考慮移動設計。

　　在移動上，有時必須假裝“請求事件已完成”

　　行動網路較網際網路慢很多，這毫無疑問。沒有什麼比超長的登入時間更讓使用者灰心的了。Instagram的聯合創始人Mike Krieger曾表示：“誰希望在等待的過程中繼續等待呢？”

　　然而使用者在移動應用上提交請求後時，往往需要繼續等待。典型的PC處理過程是這樣的：

　　● 使用者在應用中提交某一請求；

　　● 應用向伺服器傳送資訊，告訴伺服器發生了什麼；

　　● 伺服器作出回應，並處理請求；

　　● 應用進行更新，以告知使用者，他們的動作已成功完成。

　　……這是一個漫長的等待過程。

　　將之與Instagram移動應用的處理過程相對比：當使用者喜歡或評論Instagram中的圖片時，其結果會立刻顯示出來。事實上，他們的請求仍在後臺的處理過程中——但Instagram假設它已經成功，而避免了繼續等待它返回實際的執行結果。 

　　設計者雖然無法加快網路速度，但可以給使用者一種感覺，讓他們感覺響應速度很快。

　　Instagram技術幫助我們解決了移動應用“Polar”中的早期錯誤。Polar允許使用者收集、分享、投票某一調查。當使用者在Polar上建立一個調查，上傳其中的任何圖片平均需要12秒。

　　在首個版本中，Polar會等到所在圖片上傳到伺服器後，才會將整個調查展示出來。而在現在的版本中，我們選擇了相反的做法：我們假設使用者的所有調查都可成功建立於伺服器上。只要他們建立了新的調查，就會馬上顯示在他們的Feed中。

　　實際上，我們在本地建立了臨時的調查副本，並將它新增到前臺列表中。該調查的臨時版本完全可以正常使用：使用者可對它進行投票與評論，我們確保一旦該調查在後臺建立成功，這些動作可應用於此調查上。（為了確保該調查能成功建立，我們使用了很多後臺處理程式，以保證它可存放於本地。在最後告訴使用者發生錯誤之前，會多次向伺服器傳送請求。）

　　似乎增加了很多額外工作？確實。可以讓應用看起來更及時，這還是很值得做的。這種情況下，快速的感覺可以掩蓋掉現實中速度較慢的行動網路所帶來的缺陷。

　　在移動應用中，顯示載入過程往往更遭

　　很顯然，速度代表著移動使用者體驗。因為行動網路作出響應往往需要一段時間，當載入、處理某事件時，移動應用往往會顯示一個進度條或旋轉指標（Spinner）。該做法似乎昭示著我們應該告訴使用者，該事件需要花費一點時間。

　　這些指示器背後的動機很好，但對於使用者來說，結果卻很糟糕。為什麼呢？因為這些過程指示器好像突出了使用者需要等待這一現實。這正如盯著表、電梯按鈕皮膚看，反而感覺時間過得更慢了。

　　具有諷刺意味的是，大部分指示器使使用者專注於指示器本身——而非實際過程。情況應該反過來，讓使用者可清晰地感覺他們正向目標前進，而非只是在那裡等待。

　　為此，當我們在Polar上使用“Web View”載入部分本地應用介面時，我們付出了很大的代價。（Web View猶如一個小小的內嵌Web瀏覽器，可以從伺服器端獲得頁面，只有當所有頁面載入完之後，才會顯示在應用中。）為了讓使用者知道這些元素正被下載，我們增加了旋轉指標以表示Web View正在伺服器中檢索（在一個應用中，我們使用了多個Web View）。但我們卻得到了這樣的反饋：“重新整理、載入頁面好像需要大量的等待時間；它似乎沒有之前版本快速了。”

　　這麼做，使使用者更專注於該指示器，而非過程。

　　Google的Search應用注意到了這個問題，它將使用者請求的頁面從一側滑動顯示。該設計將載入指示器作為請求頁面載入過程的一部分，從而讓使用者更加關注過程，給使用者一種內容即將呈現的感覺。

　　讓使用者專注於過程的另一個方法是使用“輪廓屏”——先展示頁面的空白版本，再逐漸地載入其中的內容。資訊逐漸顯示在頁面中，會給使用者一種所請求內容即刻可完成的感覺。

　　我們已經在應用的多個地方使用了該技術，刪掉了旋轉指標。這使得使用者的注意力轉移到內容載入的過程，而不是內容載入這個事實。

　　不要轉移使用者的注意力

　　在桌面中，會增加更多的連結、選單和按鈕，以方便使用者與應用互動。但在移動應用中，我們需要重新考慮該方法。可顯示大量使用者介面控制元件、使用者通過滑鼠來操作的大屏時代已經過去。現在的移動裝置螢幕很小，只有巴掌大小，卻需要使用相對較大的手指進行輸入。

　　我們不能僅僅考慮如何在小螢幕中增加更多的控制，現在，我們還必須考慮把這些動作放在哪裡——使用者在應用中花費最多流量的地方。

　　移動設計者應該將主要精力花費在使用者的主要目標上，而不要讓使用者的注意力從主要任務上轉移。

　　使用者給調查投票是我們應用的核心功能，使用者在投票頁面停留的時間最長（平均每人每天會為40個調查投票。）我們知道，如果列表中的調查來自使用者認識的人，該應用的體驗將會更好。所以我們在應用的頭部放置了明顯的按鈕，讓使用者可方便地找到Polar上的好友。

　　但結果卻是很少有人使用該功能。後來發現，我們將使用者的注意力轉移到了其他地方，如尋找、邀請好友。

　　現在，當使用者沉浸於投票過程時，在第20個調查處，我們會詢問“你是否想在Polar中尋找你的好友？”該改變（刪掉了頭部的尋找好友按鈕）使尋找好友的功能獲得了很大關注。

　　從那時起，我們又利用該法設計了很多其他功能，包括設定喜好、請求評價應用等。將主要功能（為調查投票為Polar的主要功能）作為應用的主要部分，而不是很多功能中的一組，將會產生很大的不同。

　　總結

　　進行移動體驗設計時，應避免使用在PC上進行應用設計時慣用的方法：

　　● 等待伺服器回應，而不是假設請求已完成，將會成功；

　　● 當事件回應需要一段時間，專注於指示器，而非過程；

　　● 增加更多的介面控制元件，代替突出應用的主要功能。

　　為了避免這些及其他移動錯誤，我們需要用挑剔的眼光審視現有的最好實踐，不要將PC世界完全照搬入移動領域，只採用適合移動的方法。

　　不只是避免錯誤，移動優先更要探索、分享、擁抱新的設計方法。

　　原文連結： An Insider’s View of Mobile-First Design: Don’t Make These Mistakes