1 兩類成功的人: 理解技術的商業人員 其成功依賴於所用資訊的品質和複雜性
理解商業的技術人員 企業家型的工程師
2 在決定創造某個軟體產品之前，經過簡單而適當的設計，編寫有很好互動性的產品
3 電腦可以告訴我們一個事實，但卻不能提醒我們，它可以精確地引導我們，
卻不能引導我們去我們想去的地方4 軟體產品有兩類描述： 建立非常完整而詳細的，實際產品的描述 描述終端使用者看到產品時的描述5 功能有負面因素，這些和正面因素一樣，他們引起的最大設計問題是，每個出於善意的，
也許是不常用的功能，使常用功能模糊起來6 寫壞軟體比寫軟體更昂貴（現在好多流氓軟體。。。。）
7 讓程式員長期寫錯誤的東西，其代價比他們什麼都不寫還要高。
8 消費者的忠誠 我期望在百幕大有周六的假日，但我並不需要它，如果我有膽結石，我需要手術，
但它並不是我期望的，從短期看，一個人可以受到需求的強烈影響，但從長期來看，
一個人期望的東西有更大，更深刻的效果，當他期望某些東西時，他回忠誠於它，
當一個消費者期望一個產品或者一個品牌時，他的忠誠是商業中最強大的一股力量。
當你為客戶提供了他們最期盼的產品時，你的競爭這實際上就快要失敗了。沒有消費者長期品牌忠誠度，你的公司相對於競爭者來說都是極其脆弱的。
9 高技術領域有三種根本的品質 實際能力 技術人員必須回答的問題，我們能幹什麼，哪些東西有可能幹成 生存能力 商業人員的貢獻 什麼是能養活我們的東西，我們能賣什麼 期望能力 設計人員提供的能力 ，他們必須回答 什麼是令人期望的東西？
人們究竟想要什麼。 什麼是可能的（技術），什麼是存活的（商業），什麼是期望的（設計）。 設計成功的產品：產品生產出來效能良好 進入銷售領域賣得很火 ，帶來利潤 成為人們真正需要的東西 首先決定什麼是客戶期望的東西，然後工程師去建造它，商業人員去銷售它，這是最明智的方法
10 為快樂而設計
假如你要設計一種款式的汽車來滿足三種人的需要：帶孩子的媽媽，木匠，年輕的總裁。能設計出來嗎？？
能，有人要嗎？？沒有！沒有，因為這一定是一輛愚笨的汽車。唯一的辦法是為媽媽造一輛帶後門的小客車
，為木匠造一輛皮卡，為年輕的總裁設計一輛跑車。
這就是角色設計，軟體開發怎麼為角色設計呢？？精確描述我們的使用者以及使用者希望達到的目標目標的範圍越大，迷失方向的可能性就越大縮小目標，提高目標人群內的滿意度。被愉悅的使用者是極其寶貴的財產。
對產品滿意度搞的使用者是極其寶貴的財產。給角色取名字是成功定義角色的重要組成部分一個完整定義的使用者角色是互動設計中非常有效工具過分簡單的市場模型無助於解決問題根據使用者的工作性質和責任，使用者的特點去建立角色
如果你打算設計基於軟體，使使用者滿意的產品，你必須相對精確地瞭解那些使用者是誰，這就是角色扮演的人物，下一步是儘可能設計功能強大的產品，為此，你必須更多瞭解使用者。
11 為效能而設計（面向目標的設計）
認清目標導向和電腦軟體設計的人性化設計。
研究表明：人對電腦的反應與人對其他人的反應是一樣的。 角色決定著需要達到的目標，而目標則反映出角色的意義。 目標是我們完成任務的緣由。 好的互動設計的實質是進行互動作用的設計，這種互動使得使用者能達到他們的實際目標，而並與他們的個人 目標不衝突。
任務不是目標 ，
任務將隨技術的變化而變化，但目標卻具有相當穩定的。令人愉快的性質 ，比如你從公司到家，可以打車，也可以坐公交，
任務是打車或者公交，目標是回家。
目標是穩定的事物，任務是瞬變的現象，這就是為什麼針對任務的設計不總能適合目標，而針對目標的設計總能適應任務的道理。 從事任務導向設計的程式員 用任務代替目標來進行設計是造成無效互動與挫敗的主要原因之一。
目標導向的設計 個人目標： 不感到被愚弄
不製造錯誤
做適量的工作
令人著迷(或者至少不要太令人討厭)
兩個方面(個人工作量的減少，還有就是個人權益是否受到損害) 公司目標： 提高我們的利潤
擴大我們的市場分額
擊敗我們的競爭者
僱用更多的人
提供更多的產品或者服務
公司目標與個人目標的平衡 實際目標： 避免會議 處理客戶的需求
記錄客戶的訂單
建立可以量化的工作模型 虛假目標 這些都只是實現目標的手段，本身並不是目的的，目標才是最終的目的 省錢 減少鍵擊 運行於IE 易學
保護資料完整 加快資料錄入
提高程式的執行效率 使用最佳的技術和功能 增加圖形的美觀 維護跨平台的一致性
12 為人而設計 模組是對使用軟體產品的角色為達到某個目標而進行的簡潔的描述 日常使用型模組
最有用和最重要的，這裡的基本動作都是使用者要完成的，而且是最頻繁完成的動作
日常使用的模組需要最強的互動支援，新使用者必須能很快掌握它，使用者大量使用，
使用者變得很有經驗，他們將要求定製日常使用的互動，這樣它將更合乎個人的工作作風。 必需使用型 必須完成的動作，但卻不是頻繁完成的動作，比如清理資料庫和請求例外操作
任何使用者都情願使用程式提供的方式去工作，不要求定製化，互動要求很低。 邊緣情況的摸組 在產品設計階段經常簡要設計，但程式不能省去這些工作。
邊緣情況的處理能力的編碼是成功或者失敗，關係到日常使用和必需使用的產品的成功或者失敗。
