設計真正偉大的使用者介面沒有什麼偉大的奧秘可言，做到保持簡單易用就可以。
『保持簡單易用』意味著不要讓使用者分心。恰恰相反，好的ui讓使用者達成目標。結果如何？你的培訓和維護費用降低，並獲得更開心、滿足和高效率的使用者。
當你面對乙個全新的介面設計時，別忘了這些原則。
編輯手記：kyle將在紐約舉行的web設計趨勢上繼續**使用者介面設計的內容。
1. 了解你的使用者
「關注使用者：如果在關注競爭對手還是使用者之間選擇，答案總是後者。工作總是首先從使用者開始。」——jeff bezos
了解使用者，因為使用者的目標就是你的目標。試著重述使用者，了解他們的技能水平和體驗，以及什麼是他們需要的。找出使用者偏好什麼樣的介面，並觀察他們在介面中如何操作。不要迷戀於追逐設計趨勢的更新，或是不斷新增新的功能。首要的任務是關注你的使用者，這樣才能創造出乙個能讓使用者達成目標的介面。
2. 重視模型
使用者的大部分時間都消耗在介面中，而不是他們自身上（facebook，myspace，blogger，美國銀行，學校/大學，新聞**，等等）。我們無需畫蛇添足，使用者在你正在創造的介面中看到的正是那些（已有的）介面已經解決的同樣問題。利用已成慣例的ui模型，你將使使用者感覺像在家中一樣熟悉。
cotweet在郵件應用中運用了廣為人知的ui模型。
3. 保持一致性
「使用者期望越多的被正確驗證，使用者就越覺得系統在自己掌控之中，從而也就更喜愛它（系統）。」——jakob nielson
使用者需要一致性。他們需要知道一旦他們學會做某項操作，那麼下次也同樣可行。語言、布局和設計是需要保持一致性的幾個介面元素。一致性的介面可以讓使用者對於如何操作有更好的理解，從而提公升效率。
4. 運用視覺等級
「設計師可以從混亂中找到統一；他們可以通過組織操控文字、從而清晰地傳達設計意圖。」—— jeffery veen，web設計藝術家和研究者
設計時，要讓使用者把注意力放在最重要的地方。每乙個元素的尺寸、顏色還有位置，它們為理解介面共同指明了道路。清晰的層級關係將對降低外觀的複雜性起到重要作用（甚至當行為本身也同樣複雜的時候）。
5. 提供反饋
介面要始終保持和使用者的溝通，不管是當他/她們的行為對錯與否。隨時提示使用者的行為：狀態更改、出現錯誤或者異常資訊。視覺提示或是簡單文字提醒都能告訴使用者，他/她的行為是否能夠達到預期的結果。
bantamlive在介面中為大多數行為提供了一種嵌入式的載入提示。
6. （對使用者）寬容
無論你的設計有多麼的清晰明了，使用者都會犯錯。你的ui應當允許並寬容的對待使用者的錯誤。要為使用者提供可以撤銷行為的方式，並且對五花八門的輸入資料盡量寬容（沒人願意只是因為填錯了生日的格式而重頭再來）。同樣，如果使用者的行為引起了乙個錯誤，在恰當的時機運用資訊顯示什麼行為是錯誤的，並確保他/她明白如何防止這種錯誤的再次發生。
如何利用簡單的驗證碼提高註冊率一文中講述了乙個絕佳的例子。
7. 鼓勵使用者
一旦使用者對介面有了經驗之後,要獎勵他/她們，使之進價。把複雜任務分解為若干簡單步驟將會更顯繁複和讓人精力分散。提供更多的抽象方式——如鍵盤
快捷鍵——完成任務，這樣會讓你的設計變得簡潔易用。
8. 融入使用者的語言
「如果你對每個畫素、每個圖示、每個字型都考慮再三，那麼你同樣需要斟酌每個詞語。」 —— getting real
所有的介面或多或少都有文字在其上。讓文稿盡量口語化，而不是華美辭藻的堆砌。為行為提供清晰、簡明的標籤，保持簡樸的文字敘述。使用者對此將會很讚賞，因為他們不再是聽命於他人的官腔——他們聽到的是如朋友般甚至自己說話的表述方式。
9. 保持簡潔
「乙個現代的悖論就是：創造複雜的介面很簡單，因為複雜到必須簡化它們」—— pär almqvist
正所謂：大音希聲、大象無形。最上乘的設計中，你看不到華而不實的ui修飾，或是用不到的設計元素。換而是，其必須的元素一定是簡潔且有意義的。當你想著是否要再介面上加乙個心功能或是元素的時候，問問自己，「使用者真的需要這些嗎？」或者是「為什麼使用者想要這個小巧的動態圖示？」。你是否只是因為出於自我喜好而新增這些元素？記住，永遠不要在ui設計中給自己出風頭。
10. 不斷向前
爺爺：如果每次失敗我都放棄的話，那麼我將永遠不會發明耐火褲！【這時褲子燒光了，露出了**】
爺爺：接縫處還在改良中……
軟體介面設計和易用性基本原則
一 審美上令人愉悅 通過一下的圖形設計原則製造感染力 1，在介面元素之間提供有意義的對比 2，建立分組 3，對其介面元素和分組 4，提供 3d外觀 二 清晰準確 易理解的語言文字 1，可視元素 2，功能 3，比喻 4，詞，文字 三 多一些相容 1，使用者 2，工作和內容 3，老產品 4，採用使用者視...
設計模式基本原則
設計模式基本原則 開 閉 原則 open closed principle，或者ocp 原文 software entities should be open for extension,but closed for modification.解釋 乙個軟體實體應當對擴充套件開放，對修改關閉。黎克特...
設計模式基本原則
1 單一職責原則 類的職責要單一 不要將太多的職責放到同乙個類當中去。eg 資料結構職責類和演算法行為都放在乙個類。我們應該把資料結構和行為分開。2 開閉原則 乙個軟體實體應該對擴充套件開放，對修改關閉。可變性封裝 3 黎克特制代換原則 可以接受基類物件的地方必然要可以接受子類的物件。4 依賴倒轉原...