《Getting Real》這本書有點意思，是37 signals團隊的作品，作者以簡潔有力的風格，闡釋了如何打造一個簡單但卻真正解決用戶需求的產品。
1、不妨假裝在資源很少，人力不夠的情況下，去考慮需求，做出來的產品，沒有多余的，浪費的東西。

<i>要做到這點其實真的很難，經常思考你的產品上有沒有多余的東西，在能解決用戶問題的前提下，如果有，為啥不去掉，減少代碼量，降低耦合度。這點就跟日本的設計一樣，他們因為資源缺乏，所以設計出來的作品從來就沒有多余和浪費的東西，讓人看著很自然。</i>

2、創造，不是對每個需求說Yes,而是對每個需求說No，除了那些真正至關重要的需求。

<i>創造是提煉精油，不是做膨化食品。</i>

3、產品的大框架，根，要固定，對部分局部細節，可以保持彈性，不要定死方案，一來可能造成隱形負擔，二來限制了用戶探索產品的樂趣和空間。

4、用戶告訴你應該做A功能，然后你可以反問他：“你提到的這個，我們考慮過，那你有沒有想過，我們為什么不做？”

5、真實的產品導致真實的行動。這才是你走向真理之路。問題是在使用產品的過程中發現和驗證的，所以最重要的事是盡快出一個真實的產品出來。那些虛擬的模型，簡單的文字描述，都是虛的。

6、辦實事，能促進達成共識。用事實說話，實踐是檢驗真理的唯一標準。當一群不一樣的人開始嘗試尋找和諧共鳴的時候...如果他們是一建立一個全方位的真實的產品那么他們的意見總會趨于一致。當然，如果他們只是打打草稿或是生出一些點子的話是很難達成共識的。因此，當你真正開始做一個實在的產品時，共識就比較容易達成。

<i>實踐是檢驗真理的唯一標準，不要把時間浪費在爭論概念上。</i>

7、如果你知道過后總是要重來一遍，你就不需追求一開始就達完美。這種明了不管如何你總是得過后重新審視一些問題的理念，能引發你先把產品想法推出去看看是否可行的激情。

<i>認清現實吧，這也是很多產品在某個階段，都要重構的根由。做產品的過程也要為過去的趕著上線等“偷懶”償還“債務”。</i>

8、設置選項也是邪惡的因為他們使軟件變得冗余。更多的選項就需要更多的編程代碼。而且你還要花額外的時間在測試和設計上。還有很多選項排序和顯示界面等你可能從來沒見過的東西。這意味著隱藏的軟件瑕疵：破碎的布局，凌亂的表格，奇奇怪怪的頁面排序問題等等。在一些小處細節上，你需要幫客戶拿主意，是的，你有可能下了一個不太好的決斷。沒什么大不了。如果事情發生了，人們會抱怨，會讓你知道。照樣，你可以做調整。

<i>設置選項就是隱藏在界面爭奪戰中敗下陣來的功能和元素，然后好久才能被主人看到一次。只是當設置中的內容越來越多時，設置也就喪失了原本的意義。</i>

9、事實證明，加設置首選項是有代價的。當然，有些首選項也有重要的作用 — 并且可能是關鍵的頁面職能。但每提供一個選項都有不菲的代價，你應當仔細考量其價值。很多的用戶和開發者都沒能理解這個道理，最終付出很大成本，寶貴的資 本只帶來一點點的價值...我發現，如果你是信奉要靠設計優秀默認功能而不是懶惰地去添加設置首選項的人，那么自然而然地你的總體UI（用戶界面）會走上 正確的道路。

10、當我聽說有人對自己的點子很具保護性時覺得很可笑。（那些在告訴我一些簡單的概念之前希望我簽定保密協定的人。）對我而言，如果不去執行的話點子是一無用處的。它們只是倍數。執行才是價值萬金的。
理由:
糟糕的點子 = -1
脆弱的點子 = 1
普通的點子 = 5
好點子 = 10
偉大的點子 = 15
超閃亮的點子 = 20
沒有執行 = $1
柔弱的執行 = $1000
普通的執行 = $10,000
好的執行 = $100,000
偉大的執行 = $1,000,000
超強的執行 = $10,000,000

如果要成就一番事業，你必須將二者相乘。
最閃亮的點子，如果沒有執行，最多值$20。如果它乘以優秀的執行，那么就值$20,000,000。
那就是為什么我不愛聽他人的點子。只有當看到它被確實執行下去了我才有興趣。

11、為了讓事情做好，人們需要不被打擾的時間，特別是對開發們來說。

<i>從自己工作經歷來說，不要頻繁找開發，否則他們沒法干活，而且這也是自己不專業的表現，把問題整理好，能自己解決的就自己解決，爭取一次解決問題。開發又不是你的女朋友。</i>

12、不要會議：開會前想清楚你真的需要會議嗎？會議經常出現在概念不夠清楚的時候。不要求助于會議，試著簡化概念，于是你可以快速的討論它，通過電子郵件，即時通訊或者Campfire。目標就是避免會議。**你避免花費在會議上的每一分鐘是你真正做事情的每一分鐘。有太多的會議了。放棄那些沒有意義的和沒有效果的會議。只有當需要討論重要的商務議題的時候或者你需要建議，贊同或者一致意見的時候才召開會議。

<i>要想清楚會議是為了什么而開，少拉一些人進來，有人來開會純粹是因為坐電腦前有點無聊了想換個環境透透氣。</i>

13、在你確實地必須 開會（這必須是一個少見的事情）的時候 , 堅持這些簡單的原則：設定一個30分鐘的計時器。當它響的時候，會議結束。句號。
邀請盡可能少的人。
沒有明確議程的時候不要開會。

14、增加人員帶來了減少的回報。最有趣的原因之一就是增加的交流通道的數量。兩個人只需要相互溝通；只有一條簡單的交流途徑。三個人有三條交流途徑；4個人有6條。事實上，交流途徑的增長是指數級的……很快，備忘錄和會議匯占據整個工作時間。解決方法是明顯的：把團隊分解成小的，自治的和獨立的小單位以減少這些交流途徑，減少個體之間的依賴，鼓勵一專多能。

15、尋找和慶祝小的勝利：每天發行點什么軟件開發中最重要的就是激勵。激勵是局部的 -- 如果你沒有被你正在做的事所激勵， 機會就沒有應有的那么好。 實際上，很有可能變得更糟糕。
冗長，滯后的發布周期是激勵的殺手。 這使得慶祝活動之間間隔太長的時間。 另一方面， 可以慶祝的迅速勝利是極大的激勵動因。 如果你讓冗長的發布周期壓碎迅速的勝利，就殺死了激勵。 并且這樣也會殺死你的產品。
所以， 如果你的發布周期是在一個月以內， 拿出每周一天（或者沒2周拿出一天）對取得的小勝利進行慶祝。 并捫心自問： “我們可以在4個小時內發布些什么？” ， 然后去實現它。 這可以是
一個新的簡單特性
一個對現有特性的小改進
為了減低支持負擔，重寫一下幫助信息
去除那些并不需要的表格項

當你發現這些 4小時的迅速勝利時， 你將發現慶祝的理由。 這樣鼓舞了士氣， 增強了激勵 并且 再次肯定了團隊正在向著正確的方向前進。

<i>用戰果，鼓舞你的將士們。——尼古拉斯.納博納.小鳥將軍。</i>

16、給延期的軟件開發項目添加人手只會更加拖延進度。

17、如果你在琢磨從幾個人選中挑出哪一個來填補空缺，選文字功底好的那位。無論他是設計師、程序員、市場人員、銷售人員還是其他，寫作技巧都很有用。簡潔高效的寫作和文字編輯能力可以帶來簡潔高效的代碼、設計、郵件、即時信息以及更多。

18、先設計最重要的：頁面賴以生存的是其核心。舉例來說，如果你正在設計顯示博客文章的頁面，那么核心就是博客文章本身。不是在邊欄里的文章分類，不是頂部的頁頭，不是底部的評論提交表單，而是實際的博客文章單元。沒有博客文章單元，這就不是一個博客文章頁。只有當這個單元完成之后你才能開始考慮頁面中次重要的元素。次重要的元素完成之后，你再轉戰第三重要的元素，以此類推。這就是震中設計。

震中設計規避了傳統中 “先搭建框架，再填充內容”的方式。在那種方式里，人們先建立好頁面布局，然后把導航條包含進去，然后插入有關銷售推廣方面的東西，到最后才把核心功能——頁面的實際意義所在用來填充剩下的空間。這是本末倒置的做法。
震中設計讓你從一開始就關注于真正重要的部分。先做必需要的，再做其他的。結果是給用戶一個更友好、重點清晰的界面。并且，這樣可以讓你馬上和設計、開發人員展開對話而不是等到頁面所有部分都各就各位之后。

19、對于每一個界面，你需要考慮可能出現的三種情況：常規一切運行正常的話，人們看到的是一個充滿內容的界面。

<i>場景勝過一致性：說到底，一致性只是一種未經驗證的執念。動作是使用 按鈕 還是用 鏈接 來實現 ？ 這取決于那個動作。 一個日歷視圖是應該使用列表方式還是表格方式實現？ 這取決于 它要用在哪里 并且 要顯示多長的時間。 全局的導航鏈接是否需要出現在每個頁面上 ？ 是否每個地方都需要一個全局的搜索條 ？ 是否在每一頁上需要一個完全相同的頁腳？ 答案是“這取決于應用環境” 。這就是應用環境比一致性重要的原因。 如果你的設計在那種狀況下有意義， 不一致也沒有什么大不了的。 只給人們重要的。 給他們所需要的，并且去掉其不需要的。 比保持一致性更好的是保持正確。</i>

一致性不是必不可少的。 很多年來， 學習用戶界面和用戶交互的學生都這樣被教導，界面中的一致性是界面設計中的核心守則之一。也許這在軟件中成立，但是在Web上，這不對。 Web上真正重要的是，在每個獨立頁面，用戶是否能夠快速、簡單地前進到流程中的下一個步驟。在 “好的創新” （Creative Good）, 我們把這叫做“聰明的不一致” ： 確保流程的每個頁面都給用戶提供他在流程中的那個位置所真正需要的東西。 只因為了和網站的其它部分保持一致，加入多余的導航因素，是很愚蠢的。
初始人們第一次使用這個應用，在加入內容前的界面。

忽略初始界面的階段是你會犯的最大錯誤之一。初始界面是應用留給人們的第一印象，永遠不會有第二次這樣的機會……這個么，你應該知道。然而，產品在初始狀態下是沒有內容的。當新人注冊，他們將從初始界面開始。就像是一個博客，用戶需要自己去充實它。而在用戶輸入文章內容、鏈接、評論、日期、邊欄的信息或其它數據前，整體外觀無法成形。不幸的是，用戶會在初始界面時決定產品是否值得一用——在這個內容和信息最少的階段來判斷產品的適用性。如果你設計的初始界面有缺陷，人們就不知道缺少些什么，因為他們感覺什么都沒有。錯誤有錯誤發生時，人們看到的界面。這是一種保護性設計，必不可少。

20、能用一個按鈕做兩件事，就不要用兩個按鈕做兩件事，一個是節省空間，另外一個還是為了不讓用戶跳來跳去。放大來看，不要讓用戶在這個界面做了一件事，然后又要跳到另一個界面去做另一件事，拒絕分離的界面。

21、更少的代碼：產品設計上，要比競爭對手做的更少，而不是更多。做的更少達到同樣的目標，才能體現你的實力。
你或許認為代碼量加倍軟件復雜性也相應加倍，但實際上，每增加一些代碼，軟件的復雜性就隨之指數式增長。 代碼的每一點增加，每一點改動，每一個相依性，每一個前指性（Preference) 都有著聯動效應。輕率地增加代碼，不用多久，你就會造出一個可怕的大稀泥巴。打造軟件最重要也是最鮮為人知的規則：復雜性和大小不成線性比例…… 2000行的程序比1000行的程序要用多于兩倍的開發時間。對付復雜性的辦法就是更少的代碼。更少的軟件意味著更少的特征（features），更少的代碼和更少的浪費。

關鍵在于將每一個困難的問題（要求很多的代碼）重新描述成一個簡單的問題（要求少得多的代碼）。你解決的問題也許不是和原先百分之百一樣的問題，那也沒關系。用20%的努力解決原先問題的80%就是一個很大的勝利。原先的問題幾乎從來就沒有糟糕到值得花5倍的精力去解決。

更少的軟件意味著撇開水晶球。處理今天面對的問題而不是預測未來的問題。為什么？對明天的恐懼常常是毫無結果的。不要讓幻想的問題把你拖住。從一開始，我們就將產品的設計基于更少軟件的概念。只要可能，我們就將問題簡單化。我們發現，對簡單問題的解決方案不僅更容易實施和支持，也更容易理解和使用。這都是我們用來區別于競爭對手的做法的組成部分。我們造的產品要做更少，而不是做更多。

鼓勵程序員提出反建議你想聽到："你建議的方法要花12小時，但我這樣做只需1小時，它不做x，但它做y。"讓軟件推你回來。告訴程序員用他們認為最好的方法去戰斗。還有，尋找可以避免編寫更多軟件的途徑。用屏幕文字的方式建議用戶繞道而行，從而避免對于軟件模型的更改。比如，建議用戶上載指定尺寸的圖片，而不是在服務器端作圖像處理。

沒有任何代碼比沒有代碼更靈活
好軟件設計的"秘密"不在于知道在代碼里放什么，而在于知道代碼里不放什么！這在于辨認出硬點和軟點在哪里，還知道哪里該留下空間而不是試圖塞進更多的設計。PM最重要的能力就是簡單，其次是在簡單的基礎上，實現自然的體驗。好的PM不是能做很多需求，而是能不做很多需求。好設計的前提是知道不設計什么，這樣才能專注在最重要的事情上。

22、
界面將成為功能文檔的替代物。 在紙上簡單快速地畫些草圖。 然后把它寫成html代碼。 界面設計是每個人都會認同的共同基礎，這不同于，大段的文字可以有不同的理解。人人都使用同樣的屏幕界面時， 混亂不見了。在你開始擔心后臺代碼之前，要建立一個人人都可以看得見的，使用的，點擊訪問的，并且可以“感受到的” 界面。 一定要盡量把自己置于客戶體驗之前。

<i>(1)對PRD來說，盡量少用文字，如果必不可少，則盡可能精簡，因為一段文字甚至一句話，開發設計和你有可能就有不同的理解，這也是為什么一千個讀者有一千個哈姆雷特的原因，文字就是有這個特性，不同人容易有不同的理解，并且不能直達重點。因此，需求文檔其實也沒多大用。</i>

<i>(2)另外一點，PRD不要過多關注實現方法，而是應該專注在目標和需求上，因為這些才是你可以確認的，可以準確傳播給開發設計和運營的。其他的細節只會浪費你的時間，并且沒有多大卵用。**避免寫功能規格定義是一個好的開始,但不要僅只于此；要處處避免過分的寫文檔工作。除非有個文件確實要演變成現實, 否則別寫它。****建造出來,別寫出來。如果你需要解釋什么,先建造一個原型而不是寫一份冗長的文檔。實際的界面或原型是你正在構建一個真正的產品的很好說明。另一方面,一紙文檔,只能說明它們終將被丟入垃圾桶。</i>

23、寫故事,別寫細節。如果你發現你確實需要來解釋一個新的特征或概念,寫一個簡短的故事說明之. 別陷入技術或設計的細節,只講一個短故事. 象你在正常的交談時和一個人講話的方式一樣。
它并不需要成為一個短文。只要象記流水賬似說明發生什么事。如果拿出你正在開發的屏幕作背景，來簡述這個故事,那就更好了。
堅持經驗,而不是越來越拘于細節。考慮戰略,而不是戰術。一旦你開始建立的你的那部分應用，戰術自然就會適得其所。現在你只是要想出一個故事,發起討論,然后使你步入正軌。

24、填入真實的文字而不是測試用的胡亂用語，真實的體驗產品。 虛擬文本意味著你不會看到當真實信息錄入后出現的不可避免的改變。這意味著你不會知道在你的站點填寫表格時會是什么樣子。 虛擬文字是隔在你和現實之間的面紗。

25、確立你產品的氣質和個性，是有趣的，還是嚴肅的，保持這種個性，這將在你設計界面，運營產品時幫你定位。

26、做付費產品時，將你的產品或服務拆分成多個小塊，免費送給用戶，吸引他們來使用你的產品，從而引導他們去使用你的其他產品。設想一下在你的每個專輯中拿出一首單曲作為免費獎勵，讓全世界下載 --- 就像電影的預告片 --- 就像送往電臺的最熱單曲---使得人們想去買你的音樂。不要擔心這首曲子被盜版。 讓人們去演奏， 去拷貝 ， 去共享 ，去分發。要有信心，一旦全世界都聽過，他們會付錢買更多。

27、作者提到了開博客或論壇，發教學帖子，給用戶傳播知識這類推廣方法，是一個不錯的方法，因為教育一般是比較溫和的，相比于那些商業營銷推廣。在解決用戶問題的同時，還能引導用戶去使用你的產品。

28、給用戶特色食品：給產品加一些特色有趣的特性，不管是從運營上，還是從技術上，能夠形成一個較好的傳播點。掌握使用最新時髦技術的花邊噱頭，是一種有效且廉價的方式來引起轟動效應。如果你正在使用了一些新的或引入矚目的技術，一定要繼續使用并且把它在特殊興趣社區中大肆宣傳。

29、找到你的用戶在哪，去找到他們在哪討論、贊揚、嘲諷你的產品，然后和他們互動，詢問他們是否愿意成為你產品的熱心用戶，最后還要做一件事：把積極正面的用戶評價，抓到產品官網上，放一個專門頁面來展示他們，利用真實用戶的評價來幫你推廣。

30、做用戶型產品，PM肯定要活躍在一線，傾聽用戶真實的聲音。

31、不要把發布出去的東西，叫做測試版，要給用戶信心，即便它就是一個不完整的版本，測試版只是內部測試時使用的。

32、產品逐漸變成熟，不意味著產品就要變得臃腫復雜。你并不需要成為一個外太空鋼筆，要上下顛倒地書寫。 有時成為一支鉛筆就挺好。 你不需要是一把瑞士軍刀。你可以作一把螺絲刀。 你不需要做一個潛水表，在5000米下還安全工作，假如你的客戶是陸地愛好者，只想知道現在幾點了。