乙個「簡單」和「複雜」的例子
在我和開發人員溝通乙個專案需求的時候，他們頻頻慨嘆mockup的設計所考慮情況之細緻，很多程式要實現的預判和「非基礎功能點」讓開發人員望而卻步不情願去實現。相比較設計師為了讓使用者避免出錯而絞盡腦汁去設想和考慮，開發人員更傾向於直接給到乙個只能容許的操作行為，其他非法請求全部報錯：「程式是嚴謹的，他錯，我報錯，以不變應萬變。簡單一點不好嗎？」程式設計師們甚至笑言：「考慮他們的體驗那麼多，我們開發的體驗真不好，please，咱們能不能不要把事情搞那麼複雜」。
在這個例子裡，程式設計師看來，對於使用者在和系統互動的過程中可能出現的各種情況均予以考慮，找尋使用者理解起來最明確、操作最簡單的、使用者犯錯最少的設計是缺少效率且浪費時間的。設計師這樣做，是在將簡單的事情複雜化。ok，現在就有這樣乙個問題，什麼是「錯誤」？每當程式要處理錯誤的請求，是否是使用者真的在「犯錯」？
我在某一天使用了乙個**的相簿功能時，遇到了這樣的情況（如下圖）:
「普通上傳」是當前的選中狀態，而上傳「取消」的button也是同樣的樣式。因為選中狀態具有「肯定、確定」的潛在暗示，這樣消極操作和積極操作的狀態完全混淆了，使用者在上傳過程中很容易出現錯點「取消」button當作確定完成上傳任務的誤操作。
如果真的發生了這樣的情況（應該不在少數，像我就發生了在本地好不容易選擇好的誤點了很像「確認」功能的「取消」而做無用功的情況），是的，使用者犯錯了，但是責任難道在使用者嗎？「本來我不會犯錯，是你的設計使我犯錯，或起碼增加了我犯錯的機率。」類似這樣的錯誤，系統可能會報錯，也可能不會；但真正應該檢討的卻是系統本身，即： 使用者對介面的理解和本身的系統意圖出現誤差，系統設計的歧義等固有缺陷導致使用者出錯。讓使用者頻繁碰壁、產生挫折感的設計，其原因不是使用者的愚蠢、而是設計的愚蠢。
關於「錯誤」一詞解釋的第二點主要針對使用者對系統的行為層來說，即：使用者在人機介面互動過程中的誤操作，系統未能通過更好的設計減少和避免使用者的誤操作帶來的損失。
還是以「上傳**」為例（如下圖）:
乙個模態的警示框，赫然告訴你，你想在這裡上傳相片，根本不該使用除了ie之外的瀏覽器！除了事先不打算通知你之外，同時也沒的商量，因為我沒有給你提供別的替代性方案和其他選擇。
可以想象,使用者想要使用這個上傳相片的功能，之前已經需要經歷過許多步驟，比如要開啟自己相簿存放的線上位址、要成功登入進入管理後台、要尋找到上傳相片的功能模組等等，已經付出了相當一部分的操作成本。但是系統卻很殘酷的讓使用者的所有工作都白做了，不僅如此，還很野蠻的方式告訴使用者：你從一開始就錯了！在這個情況下,使用者對系統的理解並不存在誤差，但還是在互動過程中產生了嚴重的挫折感。但是，這真的是使用者的錯誤和需要承擔的責任嗎？我認為不是：「嚴格說來，我不是犯錯，我只是不清楚我能做什麼、以及應該怎麼做的規則。」
由以上兩方面的案例，我想已經可以初步回答程式設計師同學的問題了：「是的，簡單總是好的，但是在互動過程中，事件永遠是複雜的，所可能發生的情況的可能性永遠是那麼多的，不是你為他考慮的多，讓他簡單；就是他自己試驗和受挫的經歷更多，更複雜，體驗更差」。
關於容錯設計的三個境界：
1、保證不是我們自己的錯：遮蔽會引起歧義的設計、本身不合理的設計，不讓使用者因為系統的設計缺陷而導致犯錯。
2、把簡單留給使用者，把複雜留給自己：通過系統的優良設計約束和指引使用者的操作，把出現錯誤的可能降到最低。
3、減小錯誤的代價，幫助使用者做對：當使用者還是犯了錯誤，通過設計引導使用者走向正確的方向。
對互動設計師而言，第一條是本應遵守的設計底線，二三兩條是設計時可供遵循的設計指南。其中的第三條，關於出現錯誤後如何幫助和引導使用者做對，尚軒同學接下來會專門撰文**這個問題，此處暫不贅述，下面主要就第二條談一些看法:
這是gmail的郵件處理區。
上圖表示當沒有選擇任何一封郵件的時候，操作項被置灰，不可點選。這樣在有效避免了誤操作的同時，也展示和預告了當符合操作要求時，「更多操作」內提供的全部功能的內容。
下圖則是已有選擇郵件的時候，操作項全部啟用為可用狀態時的情況。對比上一張圖未啟用的狀態，可以注意到除了啟用與否的狀態差別，還有其中的 「加註星標」功能在初始啟用狀態下是只有加註而隱藏了刪除功能的、充分考慮了加註和刪除功能的互斥性而予以隱藏。
通過使用者的使用狀態，通過有選擇性的設定功能項啟用、待啟用的狀態，以及功能項展示、隱藏的狀態，是有效避免使用者誤操作的常用手段。這個考慮細心周到的設計在很大程度上預防了使用者可能發生的操作失誤。
這是msn的登入介面。
當游標定位於密碼輸入區時，如果此時鍵盤的大寫鎖被不小心開啟了，介面會提示使用者此時處於caps lock處於啟用的狀態，很可能會出現密碼輸入的錯誤。
這樣處理比使用者輸入完成點選提交之後再提示使用者出了什麼問題要來的友好和有效很多；比只是一味的批評使用者 「你錯了」從頭至尾完全不告訴使用者出了什麼狀況的介面要友好太多。
當使用者的乙個行為很可能會引發預見性的錯誤，越早提示使用者，並給出可行性的建議，錯誤越容易被接受和改正，使用者的損失也就越小。
flickr的**上傳頁面。
對於使用者在這個頁面需要做什麼、可以做什麼有清晰的劃分，對現在需要進行的、當前所處的操作階段予以高亮顯示，吸引人進行操作；對於還未進行到的操作階段也預先做了乙個介紹，很清晰的介紹了完整的任務流程。
讓使用者知道在乙個流程之中，自己已經完成了什麼，將要做什麼，還有什麼沒有做和應該怎樣做，才能使任務成功，是避免使用者出錯的很積極的乙個應對方式。
讓我們摒棄作為設計師的中高階使用者視角，深入挖掘使用者行為習慣和心智模型，真正從使用者的角度去分析使用上可能會出現問題，通過系統的設計去盡量避免錯誤的發生——「把簡單留給使用者、把複雜留給自己」。about face3.0 第25章「錯誤、警告和確認」中講到一條重要的設計原則：讓錯誤成為不可能。很美好。以此與各位設計同仁共勉之。
互動設計實用指南系列 0 我們眼中的互動設計
互動設計 interaction design,縮寫 ixd 或者 iad 是定義 設計人造系統的行為的設計領域。人造物，即人工製成物品，例如，軟體 移動裝置 人造環境 服務 可佩帶裝置以及系統的組織結構。互動設計在於定義人造物的行為方式 the interaction 即人工製品在特定場景下的反應...
互動設計實用指南系列 8 深廣度平衡
圖1從右側這家店的櫥窗裡，我們能迅速分清哪些是租房資訊哪些是售房資訊。因為店家很貼心的將房產資訊進行歸類，並且在視覺上做了一些劃分，讓我們對資訊能一目了然。借這個小案例引出我們今天要分享的話題 深廣度平衡。其實 深廣度 本身並不是乙個單一的概念。在 的資訊架構中，有一種組織結構叫做樹形結構 首頁視為...
互動設計實用指南系列 6 標籤明晰 有效
說簡單一點，我們就是要為 的資訊做分類，並為它們起乙個通俗易懂的名字。這其實是任何人都可以做的一件事情，所以在導航設計流程中，它的重要性也常常被忽略。在設計產品時，常會聽到這樣的話 這個欄目該叫什麼名字？恩。先別管吧，把更重要的工作做了再說。然而，站在使用者的角度，導航標籤代表的是整個 的內容 產品...