如果你是在開發消費類軟體，那你必須要知道，你和你的普通使用者對計算機的理解方式截然不同。當你開始給軟體做技術支援時，你可能會對這種天壤之別感到震驚。
這並不是說你的使用者都是傻瓜，只是因為他們沒有像你一樣在計算機上花費大量的時間。下面是通過我的排座軟體中的千上萬個技術問題所總結得到的經驗：
1. 拷貝和貼上
從我收到的大量技術支援郵件中可以清楚看出，使用者經常重新輸入我用郵件發給他們的序列號，其原因似乎是他們並不知道如何（或者說他們能夠）拷貝和貼上文字。千真萬確！你可以在軟體手冊中關於序列號的地方說明如何拷貝和貼上來緩解這種問題（這樣不僅快捷，而且可以避免一些易混淆的字元，比如 “0”和“o”）。
2. Web應用程式和本地應用程式的差異
許多使用web應用的使用者並不理解他們需要下載並且安裝桌面軟體的新版本才能使用一些新的功能。你可以通過自動更新的程式來避免這一問題，不過一點你出錯了那結果會相當悲劇。
3. 資料儲存
許多使用者不理解他們的資料是如何儲存的，也不知道存在哪裡，甚至不知道資料居然是和應用程式分離的。他們無法理解一些資料是存在他們的本地硬碟中，而另外一些居然是存在“雲”中的。他們不能理解檔案、資料庫和登錄檔的差別。那麼當他們在一臺新機器上安裝桌面應用程式的時候，他們可能會對對無法訪問在以前那臺機器上建立的文件感到驚奇。因此在你的FAQ中加上關於如何從一臺機器遷移到另外一臺的說明還是有價值的。
4. 你所用的術語
使用你的使用者不能理解的術語常常會讓使用者非常惱火。比如說，非技術人員完全無法理解什麼是“對話方塊（dialog）”，跟別說“模態對話方塊（modal dialog）”了。你可以稱之為“視窗（window）“。
5. 右鍵
有些使用者沒有發現（或許沒有想過去嘗試）點選滑鼠右鍵。因此你不要把任何功能僅僅放在右鍵選單中或者其他不容易被發現的地方。
6. 並行
一些應用程式能夠處理並行訪問（比如客戶端-伺服器應用程式和web應用程式），而另外一些則不能（比如大多數桌面應用程式）。但是許多使用者以為所有的軟體在被多個使用者同時使用的時候都是安全的。如果你的軟體不能實現這一點，可能你需要在你的宣傳冊上說明這一點從而避免使用者產生錯誤的預期。
7. 什麼樣的修改可以恢復
技術人員可以非常開心地使用一些軟體並觀察發生哪些事情。他們通常不會擔心“嘗試”一些東西，因為他們能夠通過“撤銷（undo）”、版本控制或者備份來恢復大部分呢的修改，通常他們也能判斷一個操作是否不可恢復。非技術人員不會如此自信，因此不會用同樣的方式來嘗試一些事情。實際上有些人看上去可能會覺得一個錯誤的移動操作可能導致電腦炸的火光四射。因此通常儘量只做他們理解的傳統操作（比如在Windows上他們用Microsoft Office和Outlook），對於複雜的任務需要提供詳細的教程。
8. 何時需備份
每隔幾天我就會從某人那裡收到郵件說由於一個大的硬體故障他所有的資料都丟失了，而且沒有在獨立的裝置上進行備份。有時候這是因為他們甚至沒有意識到資料是儲存在他們自己的計算機上。你可以在你的文件或者軟體中提醒他們需要備份，不過這樣沒什麼區別。歷史證明這是絕大多數人不得不學習的教訓（包括技術人員）。提醒備份並不會傷害任何人，而且如果你在事情發生之後指出這一點的話還有助於化解使用者的憤怒。
9. 他們本該看文件
人們使用你的軟體是因為他們有事情要做。不管你是否喜歡，你心愛的軟體只是到達終點的手段而已。雖然有些使用者可能會讀文件，但是大多數人都認為這是在浪費他們寶貴的時間。實際上，從我收到的客戶郵件來中可以看到一個不容置疑的事實：有的使用者甚至沒有看一句解釋問題的錯誤訊息提示。這表明你需要寫一份清晰和精確的文件，但是你同時需要帶著一個假設來開發你的軟體：大多數使用者不會去讀它。這就是為什麼我們需要可用性測試（Usability Testing）。
10. 鍵盤和椅子之間的問題
缺乏技能的使用者常常並沒有認識到他們有多麼缺乏技能。這樣他們可能會因為他們自己所犯的錯誤來指責你的軟體。在這種問題上只能儘可能地禮貌。如果顯而易見客戶並沒有足夠的技能來使用軟體，那麼你應當禮貌地建議“顯然他們的需求並非理想的”，同時向他們提供無條件退款。然而如果很多人提出了相同的問題，那麼你需要修改你的產品來更貼近你的使用者（改變使用者來適應你的軟體當然是好的，但不幸的是，對於大多數人來說，這並不可行）。
後話
你有沒有遇到類似的問題呢？如果有，請在微博或評論中分享。
Via：SuccessfulSoftware（英文） Aladdina（中文）