第十一章 言語

第一節 功能規格書沒有任何的功能

不要撰寫功能規格文檔
這類藍圖性質的文檔通常對最終成品毫無幫助，原因如下：

功能規格都是幻想
他們不反映實際情況。一個應用，在開發、設計、使用前都是不真實的。功能規格只是一些紙上的文字而已。

功能規格都是關于妥協的
它只是為了讓人有參與感并感覺快樂，措辭溫和，用處不大。對于艱難抉擇，暴露公開等關鍵問題，它也從不涉及。

功能規格只能產生達成一致的幻覺
一群人對某段文字達成一致并不是真正的共識。每個人閱讀相同的文字有可能產生不同的理解。之后不可避免地會產生如下言論：“等等，這不是我當初所設想的。”“額，我們當時不是這么描述它的。”“我們當時已經達成一致了，你都簽字了。”你一定很熟悉這些套路。

功能規格逼迫你在信息量最少的時候做出一些最重要的決策
在你開始一個項目之前，你對其知之甚少。你做的越多，用的越多，你就了解地越深。這才是你應該做出決策的時刻——當你獲得足夠的信息時。

功能規格會導致功能過載
在規格書上增加點什么是沒有成本的。你可以為了取悅某人就隨意增加功能。最終你是為這些項目列表而設計，不是為用戶設計。結果是，你的網站嚴重過載，因為屏幕的頂部有 30 個導航標簽.

功能規格無法讓你進化、改變
一個功能被終止。即使在開發過程中，你發現這是個錯誤的決定，你也必須堅持下去。一旦開始創建，任何事情都會改變，而規格書無法應對這個現實。

那么該用什么來替代規格書呢？用一頁紙描述你的 App 要做什么。用簡明的語言，快速執行。如果一頁無法完整描述，那么就太復雜了。這個過程的耗時不應超過一天。

之后開始搭建界面——用界面來代替功能規格。快速畫出一些簡單的草圖。然后將其轉變為 HTML 。文字會導致不同的理解，界面能夠成為每個人達成一致的基礎。

當每個人都使用同一界面時，困惑就消除了。在你開始關心后端代碼前，搭建一個人人都可以觀看、點擊、感受的界面。

忘記死板的規格書。他們讓你過早地作出重要決策。繞開規格書，你就能保持靈活。

無用的規格書

一份規格書幾乎是無用的。我從未見過一份規格書能在全面和精確上取得平衡。

而我見過很多基于規格書創建出來的糟糕產品。這是最糟糕的一種編寫軟件的方法，因為這意味這軟件是基于理論編寫，而不是事實。

—— Linus Torvalds, Linux 創建者 （from Linux: Linus 關于規格書的看法）

與阻礙做斗爭

有些人堅持在開始設計之前就確認大量的需求文檔，我認為這些人是真正的阻礙，他們會拖慢過程的進展（這些人往往對設計和創新思考沒有任何貢獻）。

我們最好的成果都是基于腦子里的幾個概念，他們是關于網站改進，快速原型，或對設計做出些許改變，之后用真實的數據搭建一個原型。在對原型進行一番探討后，我們通常能獲得一個良好運轉的項目，也通常都有個好結果。

—— Mark Gallagher, 公司內網開發者, (from Signal vs. Noise)

第二節 不要制造死文檔###

拋棄無用的文書
避免功能規格書是一個好的開始，但別就此停住。應該在任何地方都避免過量的文書。除非一個文檔能變成實體，否則不要生成它。

搭建，而不是書寫。如果需要解釋什么，嘗試做出原型，而不是一堆冗長的文檔。一個真正的界面或原型能夠逐步成為真正的產品，而一頁紙，最終只會進入垃圾箱。

這里有一個例子：如果一個線框圖注定無法成為實際的設計，那就不要做它了，除非這個線框圖最終要轉變為真正的設計。

脫離于產品的文檔是沒有價值的。你所做的一切都應該能夠最終轉化為實物。如果一個文檔在實現之前就停止了，它就死了。

沒人會讀它

我數不清在開發團隊周圍有多少無聊的、未讀的，蓋滿灰塵的產品規格書和商業需求文檔。我們只是寫代碼，討論問題，進行用戶測試。我曾經和這樣的開發者共事過，他們花費數小時的時間撰寫冗長、詳細的郵件，或者編碼標準文檔，而這些最終都無人閱讀。

網絡應用的前進不依賴大量的文檔。軟件開發是一個持續改進、迭代的過程，包括了交互，快速決策，以及前進路上的那些無法預測的問題。所有這些都不能，也不應該被紙張所捕獲。

不要浪費時間撰寫這些美好的幻象，沒人會看的。如果你給產品足夠的成長空間，它將變成一個與設想完全不同的產品，你要接受這個事實。

—— Gina Trapani, 網絡開發者/ Lifehacker (生產力和軟件指南) 編輯

第三節 告訴我一個簡潔的故事

描繪故事，而非細節
如果你發現需要用語言描述一個功能或概念，嘗試寫一個簡短的故事。不要陷入設計或技術的細節，只需一個簡潔的故事。用正常的人類語言來描述，就像一個普通的對話。

它不必是一篇論文。只要描述事件發生的流程。如果能通過你正在開發的用戶界面來描述這個故事，那就更好。

重要的是體驗，不是細節。考慮戰略，不是戰術。戰術會在你開始搭建具體的組件時落實。現在你只需要一個能開始對話的故事，引導你走上正確的路徑。

第四節 使用真實的語言

插入真正的文字，而不是 lorem ipsum
Lorem ipsum dolor 是設計師的好朋友。無意義的文字能夠幫助人們理解設計。但無意義的文字同樣有危險。

它將基于文本的內容簡化為一個視覺設計元素，而不是文字應該呈現的：一段需要閱讀或進入的有價值的信息。你不知道放入一段可閱讀的內容后會發生什么變化，這意味著你不知道你的網站填充內容后的樣子。它在你和現實之間蒙上了一層紗。

你需要一段真實的拷貝來知曉這個字段應該有多長
你需要一段真實的拷貝來知曉表格會如何拉伸或收縮
你需要一段真實的拷貝來知曉你的 App 看起來是什么樣的

盡可能使用真實的相關的文字。如果你的網站或應用需要數據輸入，輸入真實的數據。盡量進行真實的輸入，而不是從別處粘貼一段文字。如果是名字，輸入一個真實的名字。如果是一個城市，輸入一個真實的城市。如果是密碼，需要輸入兩次，那么就輸入兩次。

當然，隨機輸入一些無意義的文字要方便許多。但這是不真實的。這不是你的用戶會做的事。用戶在使用的時候不會有捷徑。當你復制粘貼的時候，你不會知道真實的輸入感覺是什么。

做用戶會做的事，這樣你能更好地理解他們，也就能搭建出更好的界面。

假文垃圾

沒有了想象出實際內容的想象力，一個設計依據就消失了。意義被模糊了，因為他只是一段文本。可理解性遭到了妥協，因為沒人意識到這段文字實際上是用來閱讀的。機會也丟失了，因為你用來代替真實內容的假文垃圾無法提供這種機會。文本會變得很小，因為它不是用來閱讀的，我們或許創建許多可愛的空格。

—— Tom Smith, 設計師/開發者 (from 我討厭假文和假文使用者)

第五節 將產品人格化

你的產品人格類型是什么
把你的產品想象成一個人。你希望他成為什么樣的人？禮貌？堅定？寬容？嚴格？風趣？冷酷？嚴肅？放松？你想成為一個偏執狂還是值得信賴的人？一個百事通？還是一個謙虛可愛的人？

一旦做出決定，在產品的搭建過程中，始終記住這些人格特征。利用他們來指導文案寫作，用戶界面，功能設置。每當你做出改變，問問自己，這個改變是否符合 App 的人格特征。

你的產品是有發言權的，它每天 24 小時都在與你的客戶交談。