作者：Experiencesolutions
譯者：尚文歡
原文地址：http://www.experiencesolutions.co.uk/blog/2008/09/15/the-10-most-common-reasons-for-poor-usability-part-1/
注：括號【】內的文字為譯者自己添加的內容

只有置身事外才能真正發現產品的可用性問題，很容易舉出可用性差的例子，但是通常情況下人們并不知道那些造成產品好用或者難用甚至令人憤怒的真正原因。當然，這并不是偶然，大多數優秀的產品都曾進行過深入的用戶體驗設計以及可用性測試。

下面是我們總結的導致可用性差的最常見原因

1. 過分關注產品功能與技術

在項目的一開始，很多項目負責人和利益相關人員都希望能夠利用最新的技術或開發大量的的功能，功能的開發與測試則受到高度重視，并且通常會有一個專門的項目小組負責，錯就錯在未能平衡這些功能與用戶真正的需求之間的關系，相反，用戶需求被扔到了大部分接口開發完成之后。

【沒有數據表明但聽過很多設計師抱怨，決策者往往將改善用戶體驗交給了視覺設計師或者是交互設計師進行最終界面的改善，這讓設計師們無從下手】

2. 設計師和工程師的“門戶之見”

脫離用戶的情況下，設計師和工程師除了自我經驗并沒有更多想法，僅從自我能力、理解和看法出發進行系統設計。他們常常會深入的做項目卻很少懷疑自己的決定，如果產品能夠按照他們預想的方式運作那就足夠了。

【這里可參考千鳥同學的文章：對設計和技術的誤解，順便提一下最近比較熱鬧的Doug Bowman辭職事件，在我理解中，G公司受到流量的影響，是一個數據決定設計的公司，而Apple則受到銷量的影響，是設計決定數據的公司，人各有志，而G公司也不會因為Doug的離開有所改變】

3. 沒人考慮過用戶真正需要使用的界面

開發人員很容易陷入項目的細節，并沉浸在如何使產品正常運作的復雜性上。有時候，一個團隊很容易做到集中精力于工作細節卻不能退一步從用戶的角度去質疑自己的設計，了解用戶真正的需求，了解用戶在什么情況下使用他們的產品，而這些很可能徹底改變設計的方向。

【工程師很容易為了一個細節問題和產品設計師較真，而如果這個設計師在沒有實權的情況下，很容易和工程師妥協，不論設計師說話的手段有多高，方向性問題上或許能夠說服設計師，針對某個細節，并且是設計師不熟悉的細節，產品很容易被工程師誤導而失去本意】

4. 最終拍板的人缺乏界面設計經驗

通常，我們會碰到一個能干并且善良的項目主管來為產品最終的界面與運作拍板，但大多數情況下并非如此，這個能夠拍板的人往往很少有用戶界面設計的經驗，并經常不經意間做出那些并不考是否會慮影響用戶體驗的決定。

【兩方面原因，設計師無法擔起重任時，項目經理不得不事必躬親，在雙方不信任的情況下自然會出現各種矛盾】

5. 過分關注數據（定量測量）

當一個網站完工后，你會聽到項目團隊在討論各種數據，獨立訪問的數據，注冊量，PV數據等等。不幸的是，產品或者網站的可用性卻沒那么容易度量。與此同時，項目團隊或許會意識到一堆被忘記的問題，或者是網站關鍵頁面的低PV，他們卻很少能夠理解用戶的操作方式，什么才是提高的可用性以解決問題的關鍵。

【數據只能代表過去，只是暫時的，而可用性則是一個長期的，見效慢的過程，做數據很快，而做口碑則需要積累】

6. 太多的決策者

當一個項目小組中出現太多的決策者或者是一個很大的團隊沒有清晰的項目領導或角色定義時，這個小組會收到太多相互沖突的關于產品應該如何設計的觀點，通常情況，這個小組會討論，視圖將接口轉化成他們自己“認為”的有利于項目的方式，一旦這種未經檢查的產品開發方式變成了妥協、投機和自我意識，項目小組將會很少乃至不會再去理智的檢查他們的想法，最終導致失去為用戶設計產品以滿足用戶需求這一目標。

【產品設計師、項目經理、首席工程師，如果這三者都意見不一，如何讓工人們做出一個意義明確的產品】

7. 定義不明確的項目目標

在每接觸一個新客戶的時候，我們總是驚訝的發現很少有項目有明確的目標。當項目沒有確定的目標，這種產品或是服務所呈現的是一種偶然的上升趨勢，隨著時間的推移，項目團隊失去了信心，而用戶則流失于那些并不匹配的特性和功能。平衡清晰的商業目標與清晰的用戶目標是提供給用戶一貫的好的體驗的重要方面。

【明確的目標也要適度，給予工程師與設計師一定的發揮空間，當然，前提是這個工程師和設計師愿意發揮，如果是那種不喜歡創造或者實力還達不到創新，最好是事無巨細交代清楚，否則不僅效率低下，做出來的結果也不好】

8. 沒有為提升用戶體驗提供激勵

極少團隊會在產品開發過程中為提升用戶體驗提供激勵，大部分時候，公司采取更為傳統或者是以指標（客戶滿意度、預算、交通、產出等）的方式來獎勵團隊。顯而易見的是，如果項目小組沒有在提升可用性過程中得到獎勵，他們將會將工作的重心放在那些可以讓他們得到關注和獎勵的方面。在項目的開始就以規范的基準建立可用性測試，這將在任何項目中為測量與激勵可用性提升提供一個很好的方式。

【這的確是一個問題，很少有公司會為提升用戶體驗而給工程師獎勵，工程師會認為這是設計師的工作而不會主動去思考，結果仍舊是雙反扯皮，妥協】

9. 他們只是沒有意識到可用性差而已

很多客戶告訴我們，他們已經知道其產品或者服務的問題出在哪，但他們還是很驚訝我們的報告中出現的那些他們并沒有關注過的可用性問題。除非你的確進行了規范的可用性測試，很難想像問題出在哪。顧客的意見，投訴和網站分析有時可以告訴你出現了問題，但很少能夠讓你深入了解問題在哪以及為什么會出現問題。這些問題只能通過觀察用戶如何使用產品與服務來發現，但很多團隊從未這樣做過。

【可用性測試的規范很多，去google搜索一下usability checklist就可以了】

10. 見樹不見林

我們都曾經歷過以為自己做出那種類似已經很好不能更好的決定的感覺，這在項目的全過程中都有可能發生，人們過于熟悉自己的產品或者服務之后，無法退一步去考慮全局，因為他們無法再從用戶的角度去看整個項目，最終一手導致了差可用性的出現。引入中立的、長期的建議機制是從客觀的角度去制定決策以及消除可用性問題至關重要的解決方式。

做一個好用的產品和服務是很難的，但消除差的可用性則可以從一開始建立目標就開始，貫徹整個項目周期。

【一葉障目，這不僅僅體現在小小的產品設計上，更能體現出一個人的資質，需要一個有遠見的leader，更需要一群有遠見的員工】