Q：使用者說我的應用在處理資訊時提示不明確，老是會誤以為程式失去響應了，有什麼好的方法改進嗎？
A：系統應該在合理時間內給予適當反饋，讓使用者隨時瞭解系統狀態。
在 UI 方面，如果使用者進行操作後需要等待一段時間，那麼此時，系統就應當告知使用者操作完成進度。與載入圖示相比，我們更建議開發者採用進度條，並在上面顯示上傳或者下載百分比。這樣使用者就可以知道自己在等什麼，還要等多久。
而在 API 方面，API 應該提供查詢當前進度的方法。例如：開發者可以通過 AnimatedVectorDrawable 類來檢視動畫究竟是否在執行狀態： boolean isAnimationRunning = avd.isRunning();
API 可以藉助某種回撥機制提供反饋：當物件狀態發生變更時，通知 API 使用者 —— 有點類似於動畫開始和結束時的推送通知。AnimatedVectorDrawable 物件就允許通過註冊 AnimationCallback 函式，達到上述目的。
Q：“撤回” 的操作在變得越來越流行，這類功能有什麼意義呢？如何在我的應用內加入類似的功能？
A：給予使用者撤回操作的權利，會讓您的應用變得更加友好易用。
在 UI 方面，有時使用者進行的操作可能會產生歧義，例如刪除和歸檔郵件，此時系統應當彈出資訊確認操作，並提供撤回選項。
而 API 應允許使用者 “放棄” 和 “重置” 操作，方便 API 返回正常狀態。比如，Retrofit 中的 Call#cancel 可以取消已經傳送的網路呼叫請求或者確保該呼叫永遠不會被執行（前提是在使用 Call#cancel 前，執行尚未發生）。而通過 NotificationManager API，開發者既可以建立又能夠取消訊息通知。
Q：有使用者反饋說我的應用和其他的產品 “不一樣”，進行某些按鈕和手勢操作後沒有進行他們預想的功能，我該去哪裡瞭解其他開發者都是怎麼設定這些內容的呢？
A：好的應用，不應該讓使用者對不同的措辭、情況和操作究竟指的是不是一件事而感到煩惱。
在使用您的 App 之前，使用者已經接觸過許多別的 App，因此他們會期望常見的互動元素在各個 App 之間保持一致性。一旦脫離常規，就容易產生錯誤。
因此開發者須要和平臺保持一致性，並且採用使用者熟知的 UI 控制元件，確保使用者能夠快速識別並使用它們。此外，開發者自己的 App 也須要保持一致性：多屏操作 App 時，採用相同的用詞和圖示表示同種操作。例如，保持編輯圖示統一，讓使用者可以在 App 內編輯多種元素。
至於 API，所有設計應當保持統一，如方法命名應一致；方法內容相同，名字也務必相同；方法中引數排序也要保持一致，等等。
Q：我覺得進行很多操作都額外彈出提示可能會讓部分使用者感到厭煩，那麼究竟怎樣的設計才能在不打擾使用者和可靠之間找到平衡？
A：從一開始就預防使用者在使用中 “犯錯” 的發生，是開發者應當遵循的一個原則。
很多情況下，使用者無法一直專注於手頭的任務，因此開發者應該正確引導，以防使用者無意識犯下無法補救的錯誤。譬如，在進行破壞性行為（比如刪除）前先獲取使用者同意，或者設定良好的預設值。
比如說，Google Photos 新增了確認對話方塊，避免使用者不小心刪除相簿。而收件箱的鬧鐘功能（讓郵件打個盹兒），則可以一鍵設定在某段時間後讓郵件重新出現在眼前。
API 應該正確引導使用者使用 API，在需要的地方使用預設值。API 應該操作簡單容易上手。開發者可以通過提供預設值，幫助使用者使用 API。比如說，當建立 Room 資料庫時，其中一個預設值可以保證在資料庫版本升級過程中，資料量保持不變。這意味著基於 Room 開發的 App 可用性大大增強，因為資料沒丟而且資料庫版本也是透明的。
而 Room 中的另一個方法 fallbackToDestructiveMigration 則可以更改此行為：在未提供資料遷移的情況下，資料庫版本變更後，該方法能夠破壞並重建資料庫。
Q：有越來越多的操作符號已經在使用者的心中形成了固有印象，是跟隨潮流使用這些東西，還是用一些有新意的元素裝點我的應用好呢？
A：識別出熟悉的物件造成的認知負荷最低，也容易被場景觸發；“回憶” 則要求主體從記憶中追溯細節，花費更長的時間。因此挑出滿意的選項遠比從記憶中 “讀取” 選項要來的容易。就 UI 設計來說，“識別” 派的互動介面多使用使用者熟悉的圖示，而 “回憶” 派則以命令列見長。資訊和功能應儘量視覺化、直觀化並且易獲取。
Q：我的應用功能有點多，但有些使用者說我的應用功能很豐富，他們喜歡嘗試裡面的各種功能，也有一些告訴我我的應用看上去眼花繚亂，讓他們不知道怎麼用，有什麼好的解決方法嗎？
A：App 的使用者可能是操作熟練的老手，也可能是沒有經驗的新手。因此在設計 UI 時，您應該把兩種情況都考慮到，讓他們都可以逐漸熟悉 App 操作。據統計，App 內只有 20% 的功能使用量達到 80%，這要求開發者在 “簡潔介面” 和 “強大功能” 達到一種平衡。找到屬於您 App 中的 20% 常用功能，讓這部分功能儘量簡單易上手。在設計過程中應用 “逐漸披露原則”，讓其餘使用者在下拉頁面獲取高階功能選項。
Q：對無關資訊遮蔽似乎可以提升使用者的專注度，有哪些方法可以強化這點呢？
A：UI 的設計應該簡約，僅包含和使用者有關的資訊。無關緊要或者幾乎用不到的資訊應剔除或者轉移到其它螢幕，避免使用者分心，或者弱化重要資訊。
比如上圖播客 App 的節目列表介面就僅僅顯示了最精、最有用的資訊：如果使用者無法下載節目，介面內就會顯示下載檔案大小和下載鍵；如果使用者已經完成下載，就顯示節目長度和播放鍵。同時所有上述內容和其他資訊都會顯示在詳情頁面中，滿足好奇心強的使用者需求。
API 使用者只有一個目的：用 API 更快解決問題。所以讓您的 API 快準狠，用最少的時間，最有效的方法，解決使用者痛點。所以，請不要暴露 API 內部邏輯，API 做到的，不要勞煩使用者自己做。
API：從 22.1.0 版本起，Android 支援庫就開始提供 RecyclerView 擴充套件包，讓開發者能夠藉助大資料集和易變資料更好地設計 UI 介面元素。如果列表發生改變，開發者需要在 RecyclerView.Adapter 內更新相關資料。這意味著開發者需要自己去解決不同列表之間的差異運算問題。從 25.1.0 開始，支援庫引入 DiffUtil 幫開發者免去這個枯燥的苦差事。DiffUtil 採用優化演算法，減少開發者程式碼編寫量，同時提高效能。
Q：這個年代，幫助文件還有必要存在嗎？會不會顯得我的應用像個老古董？
A：使用者無須藉助文件應該就能使用您的 App。不過對於複雜程度或者領域專業性很高的 App，可能有點不切現實。如果不得不撰寫文件，請確保文件覆蓋所有常見問題而且能輕鬆找到。
API 應 “自文件化”，方法、類和成員如果命名恰當，就好比於 API 自己給自己寫了文件。但是不論一個 API 有多棒，文件都是必不可少的。這也就是為何所有公開內容 —— 方法、類、域、引數 —— 都應該具備相應文件。API 使用者應該和 API 開發者一樣覺得 API 簡單明瞭。
