最近在看《Joel說軟件》，這傢伙插科打諢的講述風格着實讓我耳目一新，在愉悅中借鑑些可貴的經驗還是蠻享受的。
在書中有一節提到了對於原型的看法，Joel認爲原型不能搞得太複雜，稿紙原型是最好的方式。特別是界面的佈局、色調這些東西完全可以用鉛筆潦草的表示。當然Joel說得有一定的道理，但是這並不能適用於任何類型軟件的開發，就像Joel在書中提到的XP、RUP這些方法學不能適用於遊戲、嵌入式的開發一樣。
我認爲Joel所說的原型做法，適合用於產品的開發中。如果還要更詳細的限制一下這個產品的概念，那就是不要直接和客戶打交道。在這種情況下，原型只要做到讓開發人員明白頁面的大體佈局、整體風格以及業務流程的走向，就已經達到目的了。而使用稿紙原型則遠遠比花上幾個月的時間做出一個精美的GUI原型實惠方便的多。
但是對於直接面向客戶的項目，或者和客戶聯繫較緊密的行業產品，做一個漂亮的原型還是很重要的。而對於基於Web的企業應用，則要做一個漂亮的頁面原型。這個頁面原型不需要有任何後臺程序支持，業務邏輯可以用頁面間的跳轉、假設的數據簡單表示。
很明顯，這個頁面原型是有雙重意義的。首先它和上面的稿紙原型一樣，面向開發人員；另一面，它用於向客戶展示，是和客戶溝通的媒介。在項目或者產品還沒有成形之前，第二點尤爲重要。首先，它可以形象、具體的和客戶進一步溝通，以便把握客戶真實的需求；且它可以使客戶對你的項目或者產品充滿信心，給客戶服下定心丸。
由於頁面原型產生於整個工程的早期，這使得它往往與實現的結果有所出入甚至差別很大。這時該不該回過頭來同步原型（當然這個原型不是稿紙原型）呢？我認爲大多情況下，這是沒有必要的，尤其是對於風格上的修改。修改頁面原型是件費力的事情，而且很少有人會喜歡從事這方面的工作。你可以採用更靈活的方式來表達這種變化——就是Joel提到的稿紙原型，因爲處於開發階段時，就很少會有客戶參與進來（不知道有多少完全採用XP），即便還有客戶代表參與在面，想必他也不會對稿紙原型有何異議吧。
這時，有人會提出來：當交付的時候，客戶會大叫，系統實現的怎麼和當初給我們演示的不一樣呢！我認爲是溝通的問題，首先你在用頁面原型給客戶演示的時候，就要給客戶將明白，讓客戶不要誤解這就是最後要實現的樣子。當然如果碰上了難纏的客戶，那一切都難說了……
作爲原型——不管是塗鴉在稿紙上的，還是製作精美的網頁——當它們的使命完成後，就要儘早的拋棄掉。