Mobile App 開發的順用與好用
幾個月前，我開始參與開發 mobile app 時，就打算以 usability 為主軸，而非「美感」，因為「美感」顯得非常主觀 — 任何的設計，都無法完全讓每個人滿意，只能最貼近普羅大眾的共通感受，所以對於視覺設計來說，也沒有完美的模型，因此，過度只是強調「美感」，而不去在乎使用者的體驗，反而容易讓原本應該專注的重點顯得失焦了。
Usability 這個字很有意思，可以解釋為功能上的使用很容易，也可以說很符合使用者的習慣。不過，無論是「很容易」或「符合習慣」，其實都非常主觀，每個人的學習曲線不同，所以「理論上」沒有完美的 usability model，只有針對使用者的回饋不斷的修正、改善，才容易找到最接近的模式。
為什麼要先關注順用度？
我喜歡把 usability 這個字翻譯為「順用度」 — 暨好用、易用，還要順手，因為一切的設計都應該圍繞在「使用者的感受」來思考，而不是設計者單方向的預設模式，這也是為何在開發產品時，我們必須先假定目標使用者的使用情境（use case）來著手。
許多人談到「設計」，通常都是比較表面的視覺感受 — 雖然對大部分人來說，第一印象真的很重要，但是一個 app 被開啟的那一刻起，能否成為「經常使用」的其中一個 app，除了第一印象以外，取決關鍵卻在於「順用度」。這跟我們認識一個人很像，長相俊美的人固然吃香，但空有長相，相處起來卻不愉快，也就無法長久。
個人認為著重在「順用度」的考量目的主要有以下幾項：
1. 降低使用者學習曲線：
有句話是這麼說的「不需要說明書才是好設計」 — 但這是完美模型，事實上並不盡然存在，我們能夠做到的只能盡量讓學習曲線扁平化，這樣即使是一個新的 app，使用者也可以在很短的時間內很快地上手，真正使用到你所開發的服務，而不是圍繞在「如何使用」的陷阱裡。
2. 貼近使用者原有的習慣，降低使用者排斥感：
為了讓學習曲線扁平化，我們必須回頭看看不同的 mobile 平台[1][2]的設計原則與規範，瞭解不同平台的常見使用習慣，盡量在設計的時候，貼近這些習慣，不過儘管如此，我們還是得回頭審視這樣的習慣是否符合所有使用者的真正習慣，稍後我們會探討到這個部分。
3. 讓使用者想經常使用：
每個人的手機裡都安裝了為數不少的 mobile app，但每天經常使用的 app 只有四、五個，如何讓使用者經常想使用變成一項很重要的課題，因為未來的 mobile 世界裡，大家要致力的除了成為「經常使用」的 app 外，還需要搶佔使用者的 share of time。
貼近使用習慣，降低排斥感
行動通訊平台很多，但我想在此以 iOS 與 Android 的探討為主。
前面我們提到了不同平台的設計規範（design guideline），這些規範主要說明了每一個平台的各個元素與設計原則，但不盡然代表使用者的「使用習慣」，亦即，這些設計規範是由平台設計者所用來引導使用者「習慣」他們的平台，學習不同的操作模式，並非就代表這是使用者平常的使用習慣。當然，有部分習慣的確需要依賴學習而養成，例如：以前沒有觸控螢幕，使用者自然沒有這樣的使用經驗可以依循，而必須重新學習建立習慣。
我們要記住一點：iOS 與 Android 雖然是兩個不同的平台，但背後的使用者卻是相同的，使用者有選擇平台的自由，因此在不同平台間選擇或變換會變得越來越頻繁，我們從 Apple 與 Google 近年來在 iOS 與 Android 上的競逐中發現，兩大公司近年來也不斷的修正、改善自己的設計，目的就是想盡量貼近使用者的習慣。
舉例來說，前幾年 iOS 6 上更新了新的 system notification 的顯示方式，可以直接從螢幕上端拖曳往下拉，即可顯示 — 而這項設計早在 Android 中就有了；許多 iOS app 中有的 sliding sidebar menu，在 Android 4 以後也大量的看到 Android developer 的類似設計。類似的「相互觀摩」的現象未來會越來越常見，我個人認為兩個平台 85% 以上的使用者體驗與設計最終會產生黃金交叉，而僅僅保留部分彼此的特色，因為那樣對使用者的利益最大。
因此，即使不同平台的設計規範很重要，但我們必須謹記一點：操作這些平台的背後都是使用者。所以我們在設計這些使用習慣時，必須回到「使用者的利益」觀點思考，在設計這些操作習慣時，必須以使用者利益為主，而非完全遷就於特定平台的習慣。
比方說，Android 主要的 navigation 以上方的 Action Bar 為主，並透過 Tabs 切換不同的內容的橫向切換。
iOS 則是依賴上方的 Navigation Bar 以及下方的 Tab Bar。
兩者在設計上考量的邏輯大不相同，個人認為除了平台本身的特性外，與螢幕尺寸有很大的關係。Android devices 的尺寸不一，但有逐漸往 5 吋為標準的趨勢，手持比較不易，所以單手操作的習慣可能跟 iOS 有很大的不同。iOS 的設計邏輯，由於螢幕尺寸較小，便於單手持有，則考量在單手及雙手兩種狀況的操作習慣的搭配，下方的 Tab Bar 主要以單手操作時左手拇指畫四分之一圓的存取便利性為主。
個人雖然較偏好 iOS 的設計規範，但 Android 的 Tab Bar 在切換不同內容時，則顯得十分方便。我認為兩者最終會回到使用者利益的原點，很多設計會變得十分接近。所以在設計 app 時，可以依照所提供的服務的特性，在兩個平台習慣間截長補短，從服務開發與提供者的角度來看，如果同時開發兩個平台的 mobile app，則可以思考盡量讓兩個平台的 mobile app 的設計與使用經驗一致，
不要讓使用者等待
我常常在使用的時候，因為網路的因素使得 app 在載入新的內容時延遲，而 idle 在等待載入，這個時候最常看到的反應就是離開該 app。
在去年的「取消吃到飽讓手機上網變快？」文章裡，我曾經提到真正造成手機上網速度變慢的原因，不在於吃到飽的用戶「佔滿」了頻寬，而是使用人數大量激增的情況下，單一基地台的胃納量有限，造成大部分人其實都在「排隊」 — 我們來打個比方，每一個基地台其實都像是高速公路的交流道，所有的車輛想要上高速公路（手機上網），都必須經由交流道，交流道的容納量是固定的，車輛（手機上網人數）快速增加時，自然就開始塞車了，這樣即使高速公路有 20 線道，足以容納更多的車流量，但是所有人還是塞在交流道了。理論上這樣的情況會持續存在，所以設計者必須考量在這樣的情況下，該提供給使用者什麼樣的體驗。
這樣的情形不僅僅會發生在都會區（例如：捷運站），也可能發生在人潮眾多的趨勢（例如：百貨公司、火車站），由於連線速度變慢，使用者透過手機上網的體驗會特別差，我們可以盡量避免在這樣的情況下讓使用者等待。在開發過程中，要特別感謝中華電信的3G上網與台北的網路環境，使得我們有很多機會可以體驗這樣的情況（test cases）。
貼近使用者原有的習慣
什麼是使用者原有的習慣？沒有標準答案。但通常可以從自己的使用習慣，以及身旁朋友的使用習慣觀察得到一些啟發，我喜歡觀察人，常常在公車、捷運，或是餐廳、各種公共場合觀察每一個人使用手機跟 app 的習慣跟模式，得到了一些自己觀察到的經驗模型。
例如：（以下舉例並非絕對，僅是個人觀察）
- 絕大部分人是右撇子（當然，不是說左撇子的使用者不重要），因此絕大多數人單手拿著手機時，都是使用左手。
- 使用較大尺寸的手機螢幕時，通常會以左手托住手機，使用右手食指操作。
- 絕大部分的人在通勤時，都是瀏覽的狀態。除非使用通訊軟體時，兩手才會握助手機下半部輸入。
關於貼近使用者習慣，一直有兩派議論：
A. 應該依循不同平台的操作習慣（設計規範）。
假設你的服務要同時開發 Android 及 iOS，贊成此論點的開發及設計者堅持兩個版本要「長得不一樣」，然而，這樣卻使得維護成本變高，使用者教育的成本也會相對變高 — 假設你要撰寫使用說明的話，那麼你必須同時維護 2 * N 個版本（N = 語系）。
B. 應該從服務本身對使用者的使用體驗來盡量建立單一使用體驗。
假設你的服務要同時開發 Android 及 iOS，贊成此論點的開發及設計者堅持兩個版本要「盡量長得一樣」，使用同一個服務的使用者，必須要盡量在不同平台得到同樣的使用經驗，在自由轉換平台的今天，這顯得更為重要，同時在維護成本上也較低。
個人偏好揭露：我個人比較偏向 B 的論點。
這兩種論點並沒有對錯，不過如同文章前面所提及：個人認為未來不同的行動通訊平台的使用體驗會漸漸激盪出許多共通的使用者體驗，僅保留一部分因為不同平台特性的操作習慣。對於服務提供者而言，降低維護成本（這裡頭也包括對使用者的教育成本）應該是最重要的，而非為依循而依循不同的使用規範。
如何讓使用者覺得好用？
「好用」對於使用者而言很重要，對於開發及設計者而言卻是一項很大的挑戰。
我們常常會見到開發者想要把一百個功能全搬到 mobile app 上，卻得不到使用者的青睞，其實都是因為與使用者習慣與期待有了落差所導致。最明顯的例子是 Microsoft Word，這是每天使用的文書處理軟體，但是幾千個功能，卻往往讓使用者暈頭轉向，這一點從坊間的相關工具書多寡可以看得出端倪。
思考一下：我們要開發一個使用者必須要看完一本厚厚的說明書才能開始使用，還是馬上就可以不需要或借助簡單的導引就可以上手的軟體呢？
先留下一個課題讓大家思考：使用者的學習與體驗是一層一層累積的，也是慢慢地熟悉、學習。使用者的期待感，也會有相同的效果，與其一開始端了一盤大菜上桌，卻沒有特色，不如先從觀察使用者的使用習慣，針對「痛點」（trigger point）的釋壓開始下手。
好感度的累積
前面我們提到了順用度（usability）的重要性，在此且讓我用男女交往的情感堆積法來作一個比喻：當你看見一個人時，第一印象很重要，有的人很亮眼，第一眼看了就喜歡她，看久了卻不耐看，甚或覺得有點艷俗了；有的人第一眼看起來沒有特別突出，但是很耐看 — 看越久越喜歡（加分），這個時候剛好相處也愉快（加分），談吐風趣（加分），慢慢地好感度就會上升許多。
使用者對 app 的好感度也有相同的道理，首先要達到的目標是「流暢」。因此，在設計時，我們的目標是加分，而且是持續的加分。要如何找出加分項目呢？首先可以從我們自己的使用習慣開始觀察起。
首先，除了部分不同的應用以外，例如：遊戲。使用者在每次使用 mobile app 的平均時間（average session duration）都不長[1][2]，因此我們必須考慮在使用者每次使用你的 app 時的體驗，瞭解他們可能會遇到的障礙，並加以排除、改善或設計相對應的體驗。
這些體驗主要有兩個面向：顯性、隱性。
顯性的部份包含了存取的便利性（accesibility），例如：在設計你的 app 的 navigation system 時，首先我們要從使用者使用的頻率下手，來決定哪個功能應該放在哪裡，是在上面的 navigation bar，還是下方的 tab bar，或是有其他對使用者而言更便利存取的方式或位置。
此外，常見的顯性設計還包括視覺上適當的回饋（feedback），使用者已經被養成看到按鈕會 take action，你必須回頭審視使用按鈕的形式是否恰當，而使用者點選按鈕時，需要的回饋方式該如何設計，是改變按鈕的底色，還是增加陰影，或是連文字顏色也要一起改變。按鈕的各種狀態（pressed、long-pressed、released、pressed-and-drag、tap/click、frequent-tap）需不需要有相對應的回應。
最常見的遺漏就是：沒有反應。使用者按了按鈕，卻沒有相對應的視覺回饋，就會開始感到焦慮，他們會以為 app 有問題或是自己沒點選到，於是重覆不斷的點擊按鈕，結果往往可能就是造成 app 閃退（crash）。
隱性的部分包含了使用時機、時間與網路狀態等的考量。當網路斷線或忙碌時，我們該做什麼樣的設計，需要告知或提醒使用者嗎？
時間很晚了，使用者雖然開啟了音效通知，我們需不需要多替使用者設想，提供選項詢問他的意見，或是預設開啟「睡眠模式」，讓他的生活作息可以減少被干擾呢？
替使用者設想周到將可以提升使用的滿意度，甚或延長每次的使用、停留時間，獲致使用者的好感。
從移動便利性出發的設計思考
使用者之所以選擇行動裝置使用你的服務或產品，一定有其在電腦或其他裝置上無法做到原因，最明顯的差異就是：移動便利性（mobility）。因此，我們必須考量使用者在使用行動裝置的時機、地點、時間。
使用者為了移動便利性而使用服務，大致上可以分為幾種：
1. 降低人際尷尬：這樣的現象在人口密集的都會區特別明顯。由於都會區的人際關係相對冷漠，在手持設備興起後，為了減少在電梯、公共場合、交通工具上面對面的尷尬，順手拿起手機開始看著螢幕，可以避過短暫的時間。
2. 殺時間：通常發生在開會、等紅綠燈、等人、無聊、通勤的時候。過去無法隨時隨地上網，所以可能是其他活動所取代，例如：看書。但行動上網興起後，這樣的情況在都會區也非常明顯。
3. 通訊需求：在行進間收到訊息（簡訊、行動通訊、Email 等），需要立即回覆。
4. 使用手機特有的功能或搜尋：例如：拍照、定位（找地址、餐廳）、需要上網搜尋資訊。
由於單次使用時間不長，又可能在行進間或戶外使用，除非在非行進的狀態下，絕大部分人仍然以瀏覽為主要的行為。在戶外的場合，由於 3G 上網擁擠、忙碌，時常需要遇到等待的狀況，大部分使用者雖然會先想到電信商的服務導致，但如果我們可以在這些狀況下，多設想可能的情境，作相對妥善的設計，也會提升使用者的好感。
如何不讓使用者等待？
在前一篇文章中提到了「不要讓使用者等待」，當網路忙碌或中斷時，就可能延長載入內容的時間，因此如何減少「空白畫面」或讓使用者等待載入，在設計上其實可以有一些小技巧可以巧妙地避過。
1. 善用快取管理：現在的行動通訊費率仍然不低，網路狀況不佳的時候，任何通訊如果都經過網路重複傳輸，除了會使得使用者體驗不佳外，也會無形中增加使用者的行動上網負擔。例如，你常常會打開一個 app，卻看到白色背景上有一個圈圈一直轉，這個符號只是告知你「請稍候」，但是並沒有解決「不要讓使用者等待」的需求 — 因為告知你再載入的同時，還是在等待載入。
因此，如果可以透過快取，縮短這種挫折，那麼狀況便會好一些。
這個時候規範一套好的快取管理顯得更重要。在開發前公司 mobile app 時，我們考量了這些點：
- 訊息快取：所有使用者看到的訊息都會快取一份在 SQLite 資料庫裡，同步的部份則透過 API 及 mobile message push 來維持。
- 熱門討論：我們定義熱門討論為回應數 > 30 時，該話題就會被標記為熱門討論，存放在手機的 SQLite 資料庫裡，由於更新的回應會自動推送（push），並且回應異動的頻率較低，因此每次載入熱門討論時，只會向伺服器端索取上次的時間（timestamp）後新增的回應。
- 表情符號：針對表情符號，我們在 SQLite 裡建立了一張對應表，分別是在 raw data 理儲存的表情符號對應關鍵字，例如：(smile)，以及實際的對應表情符號檔案。系統內建的表情號預先就附在 app 裡，使用者第一次登入時，我們只針對個人的「自訂表情符號」同步、下載，下載後同樣置放在 SQLite 裡，當使用者在時間軸瀏覽討論時，看到對應的表情符號就會從 SQLite 直接讀取，而不會透過 API 再次向伺服器索取。同樣地，如果看到在 SQLite 裡沒有出現的新表情符號，也會在第一次看到後被存放到 SQLite 裡。
- 圖片快取：我們用了 delay loading，亦即當使用者在滑動時間軸時，使用者看不到的圖片先不載入，只有該圖片被看到時才即時從伺服器端下載顯示，圖片下載後會先在 SQLite 內建立索引，下次再瀏覽到同一張圖片時，app 會直接從 SQLite 裡讀取。
綜合上述作法，在這裡我們採取的策略是：當使用者打開 app 時，立即顯示本地快取的內容，另外建立一條連線，非同步在背景與伺服器端溝通、下載更新的內容，經過比對後，才在前端做相對應的變化與使用者界面的更新。
2. 告知使用者網路狀況：行動上網基地台的建製永遠比不上行動上網人口增加的速度，因此「網路塞車」是常態，也因此，每家電信業者都另外建置了WiFi服務來紓解基地台的壓力，以台北來說，另外還有台北市政府的 TaipeiFree 及新北市政府的 NewTaipei 免費公眾無線上網，3G、WiFi 互用，或是使用公眾免費無線上網對很多人來說並不陌生。因此，我們在這些狀況下會提示使用者網路的狀況跟變化：
- 網路斷線：網路斷線時，我們會告知使用者目前的網路狀況，讓使用者瞭解事實，而不會重複一直嘗試，搭配前面的快取管理，「至少」使用者還可以在網路斷線時瀏覽快取的版本。
- 網路切換：當使用者從 WiFi 網路切換至 3G 時，我們會提示使用者可能使用行動數據服務增加負擔（使用者可以選擇下次不再提示）。
- 網路忙碌：網路忙碌有幾種狀況，一般人並不會特別注意到：
- 3G網路忙碌：在人潮眾多的地區，例如上下班時的捷運站、百貨公司等，3G網路會變得異常擁擠，這個時候我們在 app 裡設計了 API response time 的機制，每次 API call 都會啟用這個 timer，當任何一個 API call 超過 3000 ms 沒有任何回應時，我們就判斷為 3G 網路忙碌，並告知使用者。Public WiFi 未登入：在都會區的 Public WiFi 經常會擁擠、切換不同的 AP（Access Point），這些公眾服務一律採用 Web login，當我們在使用 Android app 時，WiFi 雖然正常使用，但連上的卻是 Web login，如果沒有作特別的偵測設計，根本無從得知，而會形同斷線的狀態。這裡我們採用了一個小技巧：當網路切換至 WiFi 時，我除了從系統得知網路目前的狀態，我們會自伺服器載入一個 dump.txt 的小檔案，如果無法正常從伺服器端載入這個檔案即代表可能 WiFi 有問題，或是停留在前述提及的 Public WiFi 的 Web login 狀態。這個時候我們也會告知使用者狀況。
後面我想探討一個開發過程中發現的 iOS 與Android 在網路存取設計上邏輯不同的地方。
iOS與Android的判斷邏輯差異
前面我們稍微提到了在不同平台間對於使用者習慣在使用者經驗上的設計該如何考量，其實在開發的過程中，我還發現了一個 iOS 與 Android 兩種平台很有趣的差異。
當切換至 WiFi 網路時，iOS 與 Android 系統都會視同「網路正常」，理論上這樣的狀況是正常的，但當遇到 Public WiFi 這種需要 Web login 的服務，兩者的判斷邏輯差異就出現了。
就 iOS 系統來說，其邏輯是：無論如何要讓使用者可以使用網路連線，無論是 3G 或 WiFi，因此當網路從 3G 切換至 WiFi 時，除了將內建 WiFi 晶片連線功能打開外，另外會針對 apple.com 檢查是否能連線來判斷網路的狀況。當 iOS 在判斷網路可能有問題，無法使用時，會立即切換至另一個可使用的網路（3G網路），所以在戶外使用 3G、Public WiFi 時，使用者幾乎感覺不到「斷線」。
Android 系統的邏輯不太一樣：未經使用者同意前，必須替使用者節省行動上網數據傳輸費用。因此，當網路從 3G 切換至 WiFi 時，對於 Android 系統而言，WiFi 功能就是正常可以使用的，因此，針對需要 Web login 的 Public WiFi 服務，從 Android 系統的角度來看：WiFi 是可以使用的，但並未確保可以連線。這也是為何我們要在開發 Android app 時，針對這種狀況特別處理來判斷是否可以連線。
iOS 與 Android 版本該不該一樣的使用者界面呢？
至於不同平台的版本是否該使用一致的使用者界面呢？我的答案是：應該盡量接近。
iOS 與 Android 雖然是不同的平台，但都是智慧型手機的作業系統，只是受限於手平台由不同公司開發及不同的考量，所以有了不同程度的差異，但終歸一句，使用智慧型手機的人是相同的，他們有選擇的自由，所以隨時可能切換到不同的平台。再者，服務提供者是相同的，有兩套截然不同的操作界面、方法，乃至邏輯，那麼非但會增添使用者的負擔、拉長學習或重新學習曲線，另一方面也會提高維護成本，以及客服成本。
但兩個平台有基本上的設計邏輯差異時，怎麼辦？如果無法取得一致性，也只能依照平台特性跟規範打造了。但是在允許的範圍內，個人認為未來兩個平台間的許多規範跟習慣會逐漸趨於一致，僅存的差異可能會小於 10% 的情況下，還是要從服務提供者如何看待使用者使用自己的服務而定。
也許不同的服務提供者會有不同的見解與作法，不過最好的作法就是坐下來傾聽使用者的聲音，試著從使用者的角度去思考。
其實還有很多小細節非常有趣，也是開發 app 的開發者及設計者理論上應該知道的：必須給使用者適度的回饋（feedback） — 壓下按鈕、釋放、拖曳，以及載入內容時顯示動畫圖示，諸如此類的基本的設計上的回應，對於使用者的感知很重要，也可以減少使用者連續點擊卻增加挫折感及誤用的機率。
附錄：
[1] Study: Average App Session Lasts About 1 Minute (2012)
[2] Report: App Session Times Run Longer On Tablets, But App Usage Is More Frequent On Smartphones (2013)