極客的可用性/來自客戶的反饋

讓我們回到 這個例子，一位不幸的男子在資料庫中刪除了列而不是行，從而丟失了 5000 個地址。

可用性工作資料庫確認刪除

導致此錯誤的一些因素包括

• 該使用者以前在這個資料庫中刪除過數百條記錄，每次程式都會將預設選項設定為刪除記錄。該使用者習慣於只點擊確定。
• 由於工作的例行性質，以及他週五下午加班的事實，該使用者的警覺性低於平時。
• 資料量太大，超出了程式的撤消緩衝區，因此無法撤消致命操作。

這些因素中沒有一個可能出現在可用性測試中，甚至可能不會出現在 beta 測試中。因此，這個錯誤不太可能在可用性測試中被發現。即使發現了，你可能也意識不到它的嚴重性，因為使用者不會感受到失去 5000 個地址的恐懼。找到這種錯誤的唯一方法是傾聽你從產品使用者那裡獲得的反饋。

事實上，使用者反饋是一個極好的資訊來源，對改進產品非常有用。不幸的是，大多數生產商未能利用此資源。他們只是認為使用者查詢是一種麻煩，並沒有以任何系統的方式使用它們來改進產品。近年來，這種情況實際上已經惡化，將使用者支援外包到遙遠的國家已成為一種普遍現象。有關使用者問題的資訊永遠不會到達開發人員手中。

實施一個處理客戶查詢的程式非常重要。所有使用者問題、建議、投訴和支援請求都應該被記錄下來並進行統計分析。如果幾個使用者遇到了相同的問題，那麼很可能是一個可用性問題。應該獎勵使用者報告問題，例如，發一封信說你正在解決這個問題，並在實施解決方案後提供免費補丁或更新。

這應該成為任何技術裝置生產商的質量控制組織的一部分。如果使用者裝置無法立即修復和更新，那麼你可以建立一個網頁，向所有使用者提供如何處理已知問題的相關資訊。對於軟體產品，你可以製作一個可下載的補丁。