最讓人吃驚的是，使用高保真原型可以大大縮短產品上市時間。沒錯，我知道這聽起來不可思議，但只要我稍稍解釋傳統軟體開發的情況，你就能理解了。因為傳統的產品說明文件起不到應有的作用（不完整、含糊不清，特別是未經測試）， 而且幾乎沒有確定關鍵細節，也不解決實際困難，必須等到開發階段這些問題才能得到解決。這導致專案要麼被迫反覆調整 （產品說明文件不斷變更，造成專案延期、士氣低落），要麼開發人員只能憑空猜測，交付的產品一團糟，使用者不得不等待下一個版本或多個補丁釋出後才能使用。無論哪種情況，產品上市的時間都將推遲。 所以我建議大家嘗試高保真原型，與其花幾個星期撰寫冗長的Word 文件，既沒人讀，也無法測試，還不如和設計師一起建立產品原型。把產品原型拿給團隊檢查，交給目標使用者測試。也許要反覆修改多次才能確定原型，但現在修改總比開發幾個月做出糟糕的產品強。等產品原型確定後，用它代替產品說明文件交付開發，看看會有什麼結果。 範例高保真原型和產品說明文件的範例請參考 http://www.svpg.com/examples。
第19章使用者體驗設計與實現 User Experience Design vs. Implementation 先定義使用者體驗再動手開發在軟體開發過程中，有很多工作可以同時進行。比如，我一直認為需求調研和產品設計（使用者體驗設計）是互相影響的， 應該同步展開。我不喜歡老式的瀑布式開發模型，產品經理先完成需求調研，然後交給互動設計師設計。業界已經認識到這是一種陳舊的產品開發思路。 此外，多數軟體開發團隊已經嚐到了開發與測試交叉進行的甜頭，我認為這是巨大的進步。以前的做法是開發人員先編寫程式碼，全部完成後再交給測試人員測試，不但耗費時間，而且可靠性差。 儘管如此，有些工作不能同步展開。許多團隊把使用者體驗設計和軟體開發放在一起進行，這是行不通的。原因如下。
第19 章使用者體驗設計與實現| 119 1. 與軟體開發團隊合作的人要記住一點：一旦產品進入開發階段，再修改設計思路是非常困難的，而且越往後修改的成本越高。因為開發團隊必須根據確定的使用者需求和產品定義設計軟體架構，然後進行開發。前期架構決策極大地制約著後期的開發工作，事後修改軟體架構， 無異於推翻重來。另外，從心理上說，事後修改設計會打擊開發人員的鬥志，引發消極的心態。隨著時間一分一秒過去，返工和波動會增加團隊的壓力。儘管敏捷方法提倡不斷修改和完善，但並非所有的修改都受歡迎。 2. 使用者體驗設計要保證產品同時具備可用性和價值，任務很重。為了拿出既可用又具有價值的設計，必須儘早、反覆地驗證設計思路。有些人覺得可以等到每個迭代週期結束再觀察設計思路是否合適，甚至等到產品公開測試時再收集使用者反饋，這樣低效的驗證方法肯定是行不通的。優秀的使用者體驗設計師一兩天內要嘗試幾十個點子，哪怕只是 2~4周的選代週期都會慢得讓人無法忍受。 3. 我認為驗證設計思路必須使用高保真原型。有人說，迭代結果和公開測試的產品可以當做原型。拋開要等很長時間不談，這些開發中的產品與產品原型有很大的區別，不能混用。為了驗證各種設計思路，產品原型應該可以隨意修改，完成其任務後應該被丟棄。而開發中的
120 | 啟示錄：打造使用者喜愛的產品產品應該以固定的原型為基礎。 4. 儘管產品開發可以分成多次迭代（這樣做可以降低風險，提高質量，便於產品整合），使用者體驗設計卻不能拆分。設計師必須全面地、連貫地看待使用者體驗，考慮以往使用者的使用習慣。讓使用者放棄不可用的軟體很容易，要他們放棄使用習慣卻很難。 5. 使用者體驗設計不一定是最費時間的工作（像軟體開發一樣，所需時間取決於具體的方法、特定的產品需求，以及從業者的技能和經驗），但至少需要一兩週時間。 如果產品設計和開發同步展開，那麼多半會出現這樣的情況：一方面，開發人員等著設計師的設計結果無事可做；另一方面，設計師飽受壓力，要在幾天內完成原本需要幾周完成的工作。為了應付差事，設計師只好不情願地拿出倉促完成的設計交給開發人員。開發人員一邊開發，設計師一邊修改設計。 等設計師最終完成設計，為時已晚，開發人員會說：“等下一輪再修改吧。”但下一輪又有下一輪的重點。設計師對產品不滿意，使用者更不會喜歡這個結果。 如果我遇到這種情況，肯定會辭職，到一家看重使用者體驗的公司去謀職。 還好，這個問題不難解決，關鍵是確定先後順序。雖然需