知乎@MoonMonster的回答：

加班中，為換腦子翻翻墳。

要不要長文呢？…… 算了，還是以一些圖片代替吧，大部分都是在07~08年間在之前公司建設(shè)團隊時的產(chǎn)物。

UE Team 內(nèi)部工作流程（圖1），指導(dǎo)性的流程，實際操作中會有偏差，如任務(wù)緊急有些環(huán)節(jié)及review就會被跳過，大體是這樣一個流程。圖1

UE Team 外部工作流程（圖 2），簡陋版（復(fù)雜版估計看不懂了），表達出大體的意思，各方之間的職責(zé)及工作范圍。需求方要提供詳細的需求文檔（request doc），需求有變更需要被記錄（change request doc）、接受需求后進入內(nèi)部流程并交付產(chǎn)出物給開發(fā)團隊（一堆doc，視覺都需要文檔化），開發(fā)團隊依據(jù)設(shè)計文檔交付版本，QA部依據(jù)設(shè)計文檔進行測試 并反饋bug，UE繼續(xù)跟進，然后無限循環(huán)……. -_-‘圖2

產(chǎn)品Workflow文檔（圖3 只列出流程圖的一小角），這玩意除了我和開發(fā)其它人都不敢看，傷神！當(dāng)初畫得這么復(fù)雜也是有點報復(fù)心理 -_-‘ 。交互人員請多畫畫workflow能幫你理清邏輯，但別像下圖這樣。圖3

產(chǎn)品spec文檔（圖 4），用來殺腦細胞的，為這頭發(fā)白了不少！下圖是老的制作方法，完全手寫，后期就與原型一并產(chǎn)出了。詳細到界面上每個元素的具體定義及行為描 述，Diagram圖的編號需要與上面的Workflow內(nèi)的編號一致，方便開發(fā)人員查找！有些同行說沒用、沒人看，但我的體會是寫個一年半載，整體設(shè)計 能力將提升一個level，workflow文檔和spec文檔也可以考驗一個人的細膩程度，現(xiàn)在的基本功也是那時候練下來的。圖4

Spec文檔細分（圖5），上面這個是大spec文檔，還包含一些其它部分的文檔。像之前我們的產(chǎn)品進行設(shè)計時是一個通用性的產(chǎn)品，當(dāng)需要針對不同的客戶進行訂制化時，又將產(chǎn)生相應(yīng)的Site Modification文檔 。圖5

產(chǎn)品原型（圖 6），早些年做原型時基本以PPT進行產(chǎn)出，review時方便進行展示，后來也用Axure（算是國內(nèi)較早一批使用Axure的用戶吧），由于前期流程 比較扎實，review環(huán)節(jié)也比較多，我們制作原型時往往會產(chǎn)出高保真原型。另外，我們使用Axure制作原型除了看重它的交互性之外更重要的是它能方便 導(dǎo)出spec文檔。ps.現(xiàn)在已經(jīng)較少用到了。圖6

工作資料目錄（圖 7 科技樹要完整 ^_^ ），做完一堆工作，產(chǎn)出N份文檔，需要有一個邏輯清晰的目錄管理，方便以后工作。下圖僅列出產(chǎn)品目錄，三個層級：產(chǎn)品名稱 》 文檔分類 》 具體目錄。 簡單、明了、命名清楚（相關(guān)人員只要看到文檔名就知道是哪個產(chǎn)品的哪份文檔以及版本情況，下面介紹）
圖7

文檔命名規(guī)范（圖8），這個是有大用處的東西！交付物從不同的設(shè)計人員手中產(chǎn)出，以文檔的形式進行存放，并且需要給不同部門、不同人員進行閱覽， 命名統(tǒng)一后管理方便、溝通一致。圖8


-_- 這… 沒想又成長文了！
羅列到這吧，除了上述這些，還有許多雜七雜八的文檔。

目前，市面上用戶體驗人員越來越多，設(shè)計師也越來越多，但… 對于流程、規(guī)范、交付物、都沒有太多介紹，不知道上面羅列的對各位有木有幫助，各個公司都有各個公司的玩法，算是一個補充吧。

UX / UE / UCD / UED / PED … 我都浮云了！ 設(shè)計而已嘛，繼續(xù)加班 ……

本文原作者為知乎@MoonMonster

本文由人人都是產(chǎn)品經(jīng)理@邊緣整理自知乎問答，轉(zhuǎn)載請注明并保存本文鏈接！