只有置身事外才能真正發現產品的可用性題目，很輕易舉出可用性差的例子，但是通常情況下人們并不知道那些造成產品好用或者難用甚至令人憤怒的真正原因。當然，這并不是偶然，大多數優秀的產品都曾進行過深進的用戶體驗設計以及可用性測試。
下面是我們總結的導致可用性差的最常見原因
1. 過分關注產品功能與技術
在項目的一開始，很多項目負責人和利益相關職員都?？茨軌蚶米钚碌募夹g或開發大量的的功能，功能的開發與測試則受到高度重視，并且通常會有一個專門的項目小組負責，錯就錯在未能平衡這些功能與用戶真正的需求之間的關系，相反，用戶需求被扔到了大部分接口開發完成之后。
【沒有數據表明但聽過很多設計師抱怨，決策者往往將改善用戶體驗交給了視覺設計師或者是交互設計師進行終極界面的改善，這讓設計師們無從下手】
2. 設計師和工程師的“門戶之見”
脫離用戶的情況下，設計師和工程師除了自我經驗并沒有更多想法，僅從自我能力、理解和看法出發進行系統設計。他們經常會深進的做項目卻很少懷疑自己的決定，假如產品能夠按照他們預想的方式運作那就足夠了。
3. 沒人考慮過用戶真正需要使用的界面
開發職員很輕易陷進項目的細節，并沉醉在如何使產品正常運作的復雜性上。有時候，一個團隊很輕易做到集中精力于工作細節卻不能退一步從用戶的角度往質疑自己的設計，了解用戶真正的需求，了解用戶在什么情況下使用他們的產品，而這些很可能徹底改變設計的方向。
4. 終極拍板的人缺乏網站界面設計經驗
通常，我們會碰到一個能干并且善良的項目主管來為產品終極的界面與運作拍板，但大多數情況下并非如此，這個能夠拍板的人往往很少有用戶網站界面設計的經驗，并經常不經意間做出那些并不考是否會慮影響用戶體驗的決定。
5. 過分關注數據（定量丈量）
當一個網站完工后，你會聽到項目團隊在討論各種數據寧波化妝，獨立訪問的數據，注冊量，PV數據等等。不幸的是，產品或者網站的可用性卻沒那么輕易度量。與此同時，項目團隊或許會意識到一堆被忘記的題目，或者是網站關鍵頁面的低PV，他們卻很少能夠理解用戶的操縱方式，什么才是進步的可用性以解決題目的關鍵。
6. 太多的決策者
當一個項目小組中出現太多的決策者或者是一個很大的團隊沒有清楚的項目領導或角色定義時，這個小組會收到太多相互沖突的關于產品應該如何設計的觀點，通常情況，這個小組會討論，視圖將接口轉化成他們自己“以為”的有利于項目的方式，一旦這種未經檢查的產品開發方式變成了妥協、投機和自我意識，項目小組將會很少乃至不會再往理智的檢查他們的想法，終極導致失往為用戶設計產品以滿足用戶需求這一目標。
7. 定義不明確的項目目標
在每接觸一個新客戶的時候，我們總是驚奇的發現很少有項目有明確的目標。當項目沒有確定的目標，這種產品或是服務所呈現的是一種偶然的上升趨勢，隨著時間的推移，項目團隊失往了信心，而用戶則流失于那些并不匹配的特性和功能。平衡清楚的貿易目標與清楚的用戶目標是提供給用戶一貫的好的體驗的重要方面。
8. 沒有為提升用戶體驗提供激勵
極少團隊會在產品開發過程中為提升用戶體驗提供激勵，大部分時候，公司采取更為傳統或者是以指標（客戶滿足度、預算、交通、產出等）的方式來獎勵團隊。顯而易見的是，假如項目小組沒有在提升可用性過程中得到獎勵，他們將會將工作的重心放在那些可以讓他們得到關注和獎勵的方面。在項目的開始就以規范的基準建立可用性測試，這將在任何項目中為丈量與激勵可用性提升提供一個很好的方式。
9. 他們只是沒有意識到可用性差而已
很多客戶告訴我們，他們已經知道其產品或者服務的題目出在哪，但他們還是很驚奇我們的報告中出現的那些他們并沒有關注過的可用性題目。除非你的確進行了規范的可用性測試，很難想像題目出在哪。顧客的意見，投訴和網站分析有時可以告訴你出現了題目，但很少能夠讓你深進了解題目在哪以及為什么會出現題目。這些題目只能通過觀察用戶如何使用產品與服務來發現，但很多團隊從未這樣做過。
10. 見樹不見林
我們都曾經歷過以為自己做出那種類似已經很好不能更好的決定的感覺，這在項目的全過程中都有可能發生，人們過于熟悉自己的產品或者服務之后，無法退一步往考慮全局，由于他們無法再從用戶的角度往看整個項目，終極一手導致了差可用性的出現。引進中立的、長期的建議機制是從客觀的角度往制定決策以及消除可用性題目至關重要的解決方式。
