文檔編寫有助於產品的概念形成、設計、創造和性能衡量。但是，編寫文檔的目的不應單單是為了產品維護。畢竟書面上的東西再多也沒法跟真正的產品體驗相提並論。
正如簡約用戶體驗倡導者Jeff Gothelf在Smashing Magazine的一篇文章中所介紹，在用戶體驗方面單純用作未來參考的詳細交付成果基本上從製作完成起就已經沒用了。在當今這個崇尚簡約、靈活的時代，用戶體驗的關鍵應該是產品的核心，而不是整體交付成果。不論你選擇簡單的還是詳細的流程，關鍵是要保證文檔能夠幫助設計向前推進(而不能只是一個滯後的指標)。
下面是產品設計開發文檔編制、各個元素及階段的概覽。不同公司的產品開發和文檔編制過程各有不同(例如Spotify，但是下面的很多交付成果在一定程度上是大多數公司所通用的。
我們所選擇的方法都是自認為最好用的方法，你可以根據自身情況自行選擇。
各自關係
在產品設計文檔編制方面，理論和實踐是完全不同的兩碼事。我們都知道用戶中心設計的基本原則。我們也都能從紛雜的方法中認出各種不同的研究方法、原型製作階段以及文檔編制技巧的整體流程。但是，你還是會經常問自己這個問題：在實踐中到底怎麼操作?
簡單來說，就是要讓文檔與設計流程形成互補，而不是簡單作為設計流程的補充。在深入探討之前，我們先從宏觀上快速看一下產品設計開發期間的文檔編制工作。在下方，我們從實踐的角度介紹了設計文檔編制的各個步驟之間的聯繫：
1. 在產品定義的初始階段，你需要和所有必要的相關人員就產品以及項目的開展方式進行一次頭腦風暴。頭腦風暴可能帶來一套啟動計劃、一個精簡的框架和一系列比較早期的概念圖以及模型。
2. 下面開始調研，在這一階段，你的團隊需要對所有假設進行完善，並填補空白的內容。根據產品複雜性、時間安排、現有知識程度等各種因素的不同，這一階段可能會有所差異。但是，從整體上說，開展競爭性市場分析並執行客戶調查是有益無害的。如果你有現成的產品，審查分析技術、啟發式方法、內容、產品背景和用戶測試等也會很有幫助。
3. 在分析階段，截止目前所收集到的產品營銷數據可以為用戶特性、體驗地圖和要求文檔(例如按優先級排序的功能電子表和用戶任務矩陣等)提供基礎。在這一時點，產品定義、產品優先級和產品計劃都已經經過界定並做好成為更正式的設計交付成果的準備。在這一期間也可能連續產出草圖和流程圖。
4. 這一階段的成果將導向使用場景、概念圖和模型，進而進入設計階段。常見的文檔類型包括草圖、線框圖、原型、任務流程圖和設計規格等。例如，調研和分析階段所得到的競爭分析和用戶特性將應用到模型、概念圖和使用場景中。反過來，這些內容又將影響到線框圖、故事板和詳細模型等中間或高級交付成果。有些公司會把調研、分析和設計階段視為一個大的流程。
5. 在執行階段，需要把代碼和設計資源組合打造成符合設計規格的產品。
6. 在實際產品發布時，還需要依靠支持記錄、bug報告及其他分析技巧繼續通過後續的版本迭代和升級推動產品的完善。在後續的生產模式下，需要以分析和報告的形式繼續不斷地生成並監控各類數據以確保成功的延續。
7. 最後，生產環境下通過性能指數表和分析技術進行不斷的測量與迭代可以保證實現連續不斷以數據為驅動的產品改善。
指導原則
現在你們已經看到了各個階段之間的聯繫，下面我們來看看哪些原則有助於推動產品在各個階段內前進。我們將說明如何運用產品衝刺方法讓流程隨著時間推進不斷向前，而不是停留在初始的定義階段。
和軟體領域內以靈活為核心的同類概念相似，設計衝刺是指在1-3周的時間內集中精力解決具體產品和設計問題。據3Pillar的用戶體驗領導人Alok Jain所稱，設計衝刺的三大關鍵要素是協作、減少交接摩擦和團隊精力的集中。簡單地說，你的設計文檔應該集合各方的工作成果，而且必須始終以用戶為核心。由於你需要快速執行各個階段，所以應當保持衝力、儘量減少浪費。更重要的是，你要著手處理小問題，以便保證能進行更加深入的探索和更高的風險承擔能力。
下面詳細地說明如何在你了解產品、涉及產品、發布和完善產品時運用這一思維。
1.了解產品
在構建產品之前，你需要了解其存在的背景。相關人員、公司和用戶為什麼關心你的創意能否向前推進?
根據Smashing Magazine所介紹，你所要開展的活動應當能夠滿足商業需求和用戶需求，還需要通過最佳的設計解決方案同時滿足這兩方這裡的關鍵是「活動」，因為儘管商業模式藍圖和簡約化藍圖之類的文檔都很重要，你還需要給其他相關人員提供動力，否則就是在花大價錢請一幫昂貴的人員閒聊眾所周知的話題。這些活動應當高效並能夠促成協作：
· 相關人員訪談——使用模板，可以讓每個團隊成員訪談3個相關人員。產品會給客戶帶來什麼感覺?他們應該怎麼操作?通過記錄相關人員腦中認為的客戶的思考、感覺、操作方式，你就可以設定出用來進行可用性測試和用戶分析的基準。
· 要求工作坊——讓相關人員聚集到一起討論項目計劃、然後探討概念如何融入產品以及技術要求。你可以拿出一個空的商業模式藍圖或簡約化藍圖，與你的團隊一起進行填寫。
· 速8——拿起馬克筆讓所有人在5分鐘內草擬8個不同產品或功能創意。讓每個人給每個創意打分，然後你就能看出整體的趨勢和偏好情況。這一活動實際上是《Google Ventures再設計流程》中的第2步。
在打完基礎後，你就可以邀請大量用戶進行訪談和測試以便獲得實際環境的數據進行調研分析。UXPin 的 CEOMarcin Treder的做法是在確認了問題和工作範圍後深入開展客戶開發和可用性測試。在UXPin還只是紙上的原型創建工具時，Marcin和用戶體驗界的明星Brandon Schauer、Luke Wroblewski、Indi Young等人共同對50多次用戶訪談和面對面可用性測試進行了詳細記錄。隨後，產品團隊使用所記錄下的內容制訂了用戶特性、寫了幾十套用戶背景故事並最終規劃出了產品要求。
Amazon所使用的「倒推」方法中的第一步是構想出成品內部新聞發布會的場景。這一方法有助於從客戶角度進行倒推，而不是將客戶局限到一個創意當中。通過對發布後進行反覆迭代修改直到完善，其產品團隊會立刻進行可信性檢查並編寫基準文檔以便後期設計開發使用。
2.設計產品
一旦你有了產品使用目的的基本概念，下面的主要目標就是構建原型。不管你的團隊是願意用餐巾紙隨便畫畫還是喜歡創建高保真或低保真度的線框圖，最後的成果都應當具有功能性。這一階段的獨特性在於，對於大部分交付成果來說，文檔就是設計本身。
Twitter的設計經理Cennydd Bowles表示，產品團隊應當提前調研兩個迭代，提前設計一個迭代並對之前的版本迭代進行審查,如果你想要保持靈活性，他建議直接打造低保真原型，讓「交互凌駕於流程之上」。如果你更傾向於注重細節，同時不失靈活，可以先從概念圖或草圖著手，然後迭代低保真線框圖，最後打造高保真原型。不管你使用哪種方法，一定要和相關人員及用戶進行測試。
如果預算和時間允許，你還可以畫出體驗圖來強調產品在哪些方面能滿足或不能滿足用戶需求，並做出任務模型表現用戶為達到各自目標所需要執行的各項活動。雖然這些內容不屬於設計的組成部分，但是考慮到你還需要了解自己的產品在人們腦中和市場上的定位，因此也不無裨益。有趣的是，Yelp會編寫包含常用代碼的風格指南作為設計階段的補充，從而讓文檔能夠真正的融入產品。
在UXPin，我們的流程是先使用細記號筆和網格紙組織小組進行草圖繪製，然後遴選出幾個線框圖，之後逐步添加細節直到達到高保真模型。如果需要進行用戶測試，我們會把模型打造成高保真原型。如果要發布重要功能，我們還會進行廣泛的用戶測試，讓原型的用戶滿意率達到70比30。
3.構建及發布產品
在開始集中進行技術工種時，一定要編制文檔幫助你獲得全局概念。具體的要求可以隨著產品的精細化而改變，但是文檔一定要能夠幫助你了解產品進入公眾時的優先事項。
RedStamp的用戶體驗經理Kristofer Layon的觀點是，你可以將產品要求和技術規格文檔以路線圖的形式進行視覺呈現。產品路線圖可以展現用戶故事，幫助你對功能主次進行排序，從而滿足用戶需求。有的時候，還可以在路線圖中加入特定的日期，讓它起到時間軸的作用。路線圖的好處在於它能夠幫助你分清優先次序，對產品要求和技術規格所確定的構建方法進行補充。在確定功能時，你可以使用Kano模型以3個類別對功能進行評估：
· 基本屬性——產品工作所必需。例如，筆記本的基本屬性是要有鍵盤和屏幕。
· 性能屬性——可以作為KPI用來與不同產品進行比較。例如，筆記本的CPU速度和硬碟容量是優劣的關鍵，人們一般傾向於速度快、容量大的電腦。
· 加分屬性——根據顧客偏好不同的主管屬性。例如，Macbook Air的超薄和光滑觸感。有些用戶會覺得這些是好賣點，但有的人不注重這些。
根據這個模型以1-5分給功能評分，然後把功能放到優先級矩陣中，可以幫助你初步形成產品路線圖的輪廓。Apple的做法是使用其《路線規則》和《Apple新產品流程》作為產品路線圖，並在其中規定職責、創造階段以及從概念形成到發布期間的重大裡程碑。事實上，Apple的《路線規則》受到了極高的重視，如果偏離路線會被立刻解職(在公司文件中明確說明)。
4.優化產品
在構建(及最終發布)產品時，文檔還需要注重於定義和跟蹤產品銷售情況及其他KIP。畢竟，如果不知道要優化哪些指標，也就無從談起優化產品。
LaunchClinic的創始人Dave Daniels的建議是，寫下發布目標(例如30天內下載量達到30000)，然後確認你是否有正確的工具來記錄進度。使用指標工具和bug報告軟體可以讓你建立起可以重複使用的報告，以便在產品發布前幾周以及後期進行跟蹤記錄。在客戶方面，你還可以對用戶進行分類，然後給他們發客戶調查問卷，評估進行迭代的內容和時機。
Spotify的迭代階段時產品開發中最長的一個階段。其產品團隊使用當前的指標和優先級矩陣(可能是在設計階段創建的)對以超出「局部最大值」程度對部分產品進行改善所需的工作量，與能夠帶來的好處進行比較權衡。如果他們覺得付出這些工作量是值得的，就會返回到定義階段重新修訂產品，以達到「全局最大值」。
主觀環境下的客觀流程
在產品設計文檔方面，沒有終極捷徑。幾乎所有使用我們產品的公司都會或多或少的使用我們上面介紹到的技巧。雖然產品開發和用戶體驗設計是一項高度主觀的工作，但你的流程和文檔不一定要很主觀。畢竟，產品的最終目標就是獲得收入，這一點沒什麼主觀可言。
不論你選擇簡單文檔還是詳細文檔，其目的都一樣，那就是把你的思維過程體現到書面上，讓你的團隊能夠進行互動和反映。文檔應當是產品的指南針，而不是一成不變的死規定。我們前面討論過的一些階段可能會以略微不同的順序展開或平行展開，但不論順序如何，它們都是為你提供靈感的方式。請你盡取所需，讓你的文檔隨著產品共同前行。（http://discover.ichezone.com）