每個產品團隊都會有自己的工作流程，無論這個工作流程是否最高效、是否體現最大價值，但是我認爲只要這個流程能夠爲實現工作目標提供過程的保障就可以算是好的流程。
對於流程本身而言，可以因團隊不同或工作任務不同而有差異。一個成熟度的產品團隊可以在保證工作質量的前提下輕鬆適應任務的變化，也就是說能夠依據不同的工作要求調整對應工作的流程。也只有這種團隊才能正真體現最大的價值，稱得上是一個敏捷的、能快速響應變化的團隊。
那麼，我們先來看看以前做產品設計時的團隊工作流程。我總結爲是一個相對normal的流程。大多時候，一個PM，一個美工，一兩個寫Html的工程師就足夠了。
如下圖所示：
工作流程包括：
Ø 當產品經理做好了產品的需求分析和功能實現批次計劃後，開始計劃產品迭代過程。
Ø PM做好產品的線框設計，交給前端工程師（Front-End）；
Ø 前端工程師開始依照產品經理的線框做HTML開發，同時要肩負一些交互設計工作，比如，導航，搜索，查詢，彈出頁面或層設計，menu等；
Ø 同時，美工開始依照線框，做頁面的視覺設計，比如，色彩，按鈕，logo，icon等；
Ø 當HTML和美工設計都ok了，就可以交給Javaer、PHPer等做前後臺整合了；
Ø 然後是產品的一系列測試，包括可用性測試，功能性測試，性能壓力測試，產品集成測試，發佈測試等。
然而，隨着產品精細化設計的要求，特別是web2.0的一些標準逐步引入到產品設計範疇。以注重用戶體驗，注重以人與系統的交互爲設計重點，崇尚簡約和適度的設計理念被提出來，並逐漸引領了產品設計的主流思想。
在新的產品設計過程中，爲了體現web2.0的UE設計元素，實現產品設計的工作精細化，我們逐步優化了新的產品標準工作流程，並定義了產品工作流程的標準輸出成果。
如下圖所示：
新的產品設計團隊標準工作流程被劃分爲兩個領域：
1、 產品功能設計領域；
2、 產品視覺交互設計領域；
這種劃分的意義在於把產品不再僅僅看作一個由代碼構成的系統，而更是一組由用戶行爲構成的服務集合。從系統角度來看設計更看重的是功能，而從服務角度來看設計更看重的是體驗，所以，我們在產品設計的過程中，一條線去關注產品的功能設計，一條線去關注產品的體驗設計。
只有兩個領域都做到了精緻，做到了極致，一個產品才稱得上是好產品，纔有機會幫助投資人獲得盈利的可能。
產品功能設計領域包括以下一些環節：
Ø 制定工作計劃
Ø 用戶需求調研
Ø 信息架構設計
Ø 原型製作
Ø 內部評審
Ø 出資方評審
產品視覺交互設計領域包括的環節是：
Ø 視覺風格調研
Ø 視覺設計
Ø 視覺內部評審
Ø 資方評審
Ø 裁圖及前端實現
從UE的五層要素設計思路來看，用戶需求調研過程是對應的Strategy和Scope層；產品功能分析過程對應了Structure層；交互呈現調研、原型製作對應了Skeleton層；視覺風格調研和設計對應了Surface層。信息架構設計則對應了Structure層的信息架構和Skeleton層的信息設計。
下面對每一個流程進行簡要的介紹和描述：
l 1制定工作計劃
主要參與角色是PM-產品經理；主要的標準成果物是《工作計劃》。
第一步非常重要，可以理解爲是產品路線圖上最爲關鍵的一個階段計劃。熟話說萬事開頭難，好的開頭是確保成功的第一步。一個成功的產品在其生命歷程上，會包括：
創意階段---設計階段---實現階段---運行階段---更新升級---消亡
這裏制定的工作計劃是設計階段的工作計劃，這個階段計劃的目標是把產品的創意變成可實現的產品設計語言，確保產品的創意和目標得以在實現過程中完美體現出來。
同樣，在計劃的過程中，PM也要考慮工作任務的特性，結合工作流程做出適應和改變。
我在制定工作計劃時使用的工具一般是MS的Project或者Excel，計劃內容要明確至少四大要素：
1、 任務：要完成的任務最好能做合理的細分，可以參考WBS的定義。
2、 時間：任務開始和結束時間；
3、 資源：投入到任務的資源，要責任到人；
4、 產出：標準的產出物是什麼，這是檢驗其工作成果的最好載體。
l 2用戶需求調研
主要參與角色是PM-產品經理；主要的標準成果物是《調研問卷》和《調研分析報告》。
對於有特定目標用戶的研發型產品，往往都需要PM在產品設計之初對用戶做詳盡的調研，調研的內容包括：
Ø 總體性調研
產品價值目標，用戶的業務目標，用戶的組織架構，與產品相關的流程，規章制度，出資人對於產品認定的成功標準等。
Ø 功能和非功能性調研
產品用戶角色，產品功能需求，用戶對於產品功能的需求優先級，產品內容需求，產品約束，運營需要，性能要求，其他特性等。
在進行調研的時候，調研問卷是必不可少的一份文檔。在準備調研問卷時，PM可以通過問卷明確調研的方向和把控範圍；被調研者可以瞭解調研重點，並準確的給予響應，明確提供有價值的信息範圍（深度和廣度等）。
需求調研完成後，PM要及時完成調研分析報告，並與用戶進行確認。
調研分析報告是將調研過程中形成結論的內容按照一定的邏輯格式規整成文後，方便用戶進行逐條確認。
調研分析報告一般着重體現五點內容：
1、 產品的戰略目標和價值體現
2、 產品的核心業務形態
3、 產品的功能分佈和描述
4、 產品的非功能需求（不包含交互和視覺部分內容，這部分將單獨調研）
5、 產品的內容需求（作爲信息架構設計的基礎）
如果調研報告能將上述的五方面內容說清楚了、說準確了，我們會認爲調研工作是成功的。
l 3產品功能分析
主要參與角色是PM-產品經理；主要的標準成果物是《產品需求文檔》，有個洋名字爲PRD。
產品需求文檔是對產品的需求分析後，以設計語言進行描述，將作爲開發階段的主要輸入物之一。
如果是通用型產品，在PRD的分析過程中還可以借鑑MRD。在這類項目中，PRD在產品項目中是一個承上啓下的作用，對上是基於MRD內容的深化和落地，對下是要把MRD中的內容設計語言化和技術化，向研發人員說明產品的功能特性和性能指標。
在這裏，我們拋開市場元素，只從產品本身的功能特性來看，我們約束PRD要體現以下的一些內容：
Ø 產品生命週期模型
Ø 實現進度安排規劃
Ø 產品技術路線
Ø 對產品feature詳細描述
Ø feature優先級
Ø 產品release計劃
Ø 用例（use cases）設計
Ø 產品部署設計
Ø 產品性能設計
至於產品的需求分析方法，可以參考我前面的文章《探討APP的分析過程》。
l 4信息架構設計
主要參與角色是PM-產品經理或IA-信息架構師；主要的標準成果物是《信息架構設計》。
產品的信息架構設計文檔主要包括：
Ø 信息架構策略
Ø 信息架構藍圖
Ø 內容映射
Ø 內容模型
Ø 原型（着重體現四大體系：導航，搜索，標籤和組織）
具體可以參考我前面的文章《信息架構的設計思路》。
這裏需要說明的是：特別對於互聯網產品而言，信息架構不是一個簡單的工作，不能把它作爲產品需求設計的一個附屬任務來完成，而是要將其作爲一個獨立的工作任務，安排有經驗的專家來負責把控。因爲，我見過很多因沒有重視產品的信息架構設計，而到後來不得不推翻重做的產品，這種勞命傷財的過程希望不要再發生了。
l 5原型製作
主要參與角色是PM-產品經理和UE交互設計師；主要的標準成果物是《低保真原型》和《高保真原型》。
很多產品經理都是十項全能，畫線框，畫原型，做分析，做設計…….但是真正檢驗一個產品經理的業務能力和設計素養的就是他做的prototype。
爲什麼這麼說？
因爲，軟件行業的產品經理，往往身上都揹負着產品創新和設計的重任，這種能力最好的體現方式就是通過原型來展現，一個有想法並能將想法快速展現出來的PM，具備成爲一個合格PM的基礎。
在不同的團隊，PM的工作略有不同。有的產品經理只畫線框，然後把線框交給UE，由UE完成prototype的製作，因爲在UE的工作中還包括了交互的設計。
有的產品經理則需要一把抓，從功能設計到交互設計全部搞定，當然這樣的產品經理雖然累，但綜合能力將會更爲突出一些。
再來說說線框和prototype的區別：
Ø 線框是靜態的；prototype可以是有交互能力的；
Ø 線框是思路；prototype是思路的具體實現；
Ø 線框包括靜態頁面和說明；prototype是頁面和行爲展現；
Ø 線框更多體現框架、組織、結構、功能劃分及佈局等；prototype更多體現：邏輯，細節，元素，整體，色彩，交互，內容等。
Prototype又分爲低保真和高保真兩種：
Ø 低保真原型反應頁面的框架邏輯，導航邏輯，交互邏輯，標籤邏輯，內容組織邏輯等。
Ø 而高保真原型在低保真原型的基礎上，還加入了信息內容，視覺元素，交互細節等。
兩種原型的用法也略有不同：
一般在產品團隊中，內部更看重的是低保證原型。因爲，在設計之初，最怕的是偏離設計方向而浪費資源，所以通過低保真原型可以快速的發現問題，通過不斷的迭代設計完善產品框架和主體構造。
一般在與外部進行產品工作成果說明和演示時，用高保真原型更好。因爲，sponsor或用戶更喜歡關注產品的實際模樣，因爲他們骨子裏是代表未來實際使用者的利益，如果他們覺得色彩不好，交互細節有問題，那麼他們會堅持要求團隊做出響應，直至他們滿意爲止，既然如此，我們最好將這個過程安排的越早越好，至少不要因爲他們的意見而導致後期的開發工作重複。
l 6內部評審
主要參與角色是Product Owner；主要的過程產物是《評審報告》。
在一個以自有產品銷售爲主的企業裏面，產品的研發和銷售往往是兩個體系。我們將產品的研發負責人稱爲PM，而將銷售的負責人稱爲Product Owner。
PO熟悉客戶，知道客戶爲何需要這個產品，也知道市場的很多方方面面，所以，他們參與產品的內部評審是非常有必要的。
在內部評審過程中，我們要做好評審報告的記錄。對於評審過程，我認爲有以下幾點要特別記錄：
1、 一致認同的問題。在會上就要給予明確的響應措施，誰負責響應，多長時間響應，誰來檢查等；
2、 不能落實的問題。在會上要形成跟進方案，誰來跟進，找誰獲取資源，爭取什麼時候獲得結論等；
3、 形成的結論。會議上形成了什麼結論，後續有何安排等，都需要詳細記錄。
4、 這份會議紀要將發送給誰，抄送給誰。
有時候，產品團隊和銷售團隊不總是一團和氣，一碰面總容易擦出火來。這是因爲，一旦爭論到產品的細節，產品團隊總認爲銷售方面不懂產品，不懂技術；而反過來，銷售團隊又會責備產品團隊不懂用戶，不懂需求，自以爲是。
說實話，這種情況不太好處理，但一個有經驗的產品經理如果會審時度勢，做出明智的決定，也許可以化解一些矛盾。
比如，
親自去再摸一次需求，而不是一味的火拼，甚至找到老闆來協調；
做出兩套方案，待與用戶參與的評審時，確定最終的需求；
如果明知自己是對的，則冷處理，將類似的問題全部掛起，並儘快整理一份書面澄清函，由PO提交用戶逐一回復。
l 7出資方評審
主要參與角色是Sponsor，Product Owner，PM等；主要的過程產物是《評審報告》。
內部研發型產品的sponsor一般是分管產品研發的副總或CTO，有時候CEO，銷售副總也會作爲干係人列席；交付型產品的sponsor一般是用戶方的業務負責人。
在這種級別的評審會議，PM要非常的細心準備好每個細節，熟話說：臺下十年功，臺上三分鐘。如果不能通過會議讓sponsor認爲出資是值得的，那麼團隊的日子將非常難過，對整個team的信心將是沉重的打擊。
所以，在準備過程中，我認爲有以下一些要點是特別要注意的：
1、要有P3組合。PPT+Prototype+Plan。
Ø Ppt着重介紹產品的主要設計細節，核心技術方向，產品亮點，有必要還需要包括用戶調研的數據分析成果，外部的可靠來源數據依據等。
Ø Prototype主要展現產品的外觀模樣，主要展現的是功能性，交互性，以及視覺性。
Ø Plan主要展現，截至目前階段產品研發的過程到了哪個環節，一共花費了投資人多少錢，成本是否在可控範圍內，後續還要投入多少資源等等。
2、要有問題應答表。
Ø PM要準備好sponsor可能會問道的一些問題，並做好準確、真實的答覆準備，以隨時響應sponsor的提問。
Ø 如果PM不能cover所有的方面，就一定要做好分工，不同的人準備回答不同的問題。
3、要準備現場的一些記錄工作。
Ø 安排特定人做現場的錄音或記錄工作。
會議中，一般會形成一些重要結論，比如：目前的工作是否正常，是否可以繼續到下一個階段；是否需要做出修改和調整；是否要停止下來，等待其他條件滿足後再繼續。
不管怎樣，PM要做好各種應對的準備，隨時與各方面做好溝通和傳遞。
l 8交互呈現調研
主要參與角色是視覺設計師和交互設計師；標準成果物是《交互呈現調研報告》。
在交互呈現調研過程，主要是明確用戶羣體的特性，包括瞭解其使用習慣，特殊偏好，在用產品操作過程的友好或缺陷之處等等。
在調研過程中，我們常常將會用到一些可重用的資源來作爲調研的輔助，比如：
1、 框架體系；
2、 設計模式；
3、 組件；
這些可以被用來作爲調研的資源，爲我們快速的理解用戶的實際需要有很大的幫助。因爲在調研過程中，有很多時候用戶會告訴你，他們看過的某某網站，某某產品的某些表現形式很好，可以借鑑。但是，哪些表現元素是真正可以被借鑑的，哪些是不適合被借鑑的，都沒有明確下來，包括如何借鑑，如何和用戶的實際需求結合起來，都只是一些非常空洞和概念的想法而已。
所以，我們會用到一些被我們沉澱和積累的資源來作爲調研過程中的案例標準來展現和承載探討。
Ø 框架體系
框架體系指產品依據展現業務的不同而設計的有着內在聯繫的各種頁面展現框架集合。舉個例子，一個購物網站有註冊框架，支付框架，購物流程框架，商品展現框架。同時，爲了支撐購物的良好體驗，一般還會有商品的論壇框架，評價框架，搜索框架，比較框架等等。
那麼，如果是個着重於信息的管理產品呢，則有信息發佈框架，信息聚合展示框架，信息搜索框架，欄目展現框架，詳細信息頁框架等等。
如果我們能過將這些框架示例按照一定的邏輯組織和整理起來，在調研過程中，依據用戶的不同需求，有針對的展現相類似的框架示例，那麼就可以方便直觀的基於示例進行探討，明確用戶的意圖，形成調研結論。
Ø 設計模式
設計模式是一種常見問題的常用解決方案。
比如，用戶忘記了密碼怎麼辦，那麼我們可以提供一個密碼找回模式，這個模式是通過輸入註冊的郵箱地址後，我們將用戶的密碼發到該郵箱。相應的，還有登錄模式，各種搜索模式，分頁模式，日期輸入模式，圖片切換模式，評論模式，留言模式……
有很多企業都建立了自己的模式資源庫，也就是將各種設計模式的文檔經過整理後，分類保存，在網上或企業內部進行公開。
比如，雅虎的設計模式庫：http://developer.yahoo.com/ypatterns/。
Ø 組件
組件是頁面最通用的組成元素，比如，文本，鏈接，按鈕，複選框，圖片等。一般模式可以在不同產品中通用，然而組件卻往往只適用於特定的產品，因爲，組件是確定了展現形式的成品，可以直接被使用。
組件資源庫和模式資源庫一樣，可以採用很多方式來管理和收集，比如wiki的方式。也有很多公共的資源提供網站，比如，http://www.webdesign.org/，上面就有很多最新的組件資源
l 9視覺風格調研
主要參與角色是視覺設計師和交互設計師；標準成果物是《視覺風格調研報告》。
視覺風格調研工作在交互呈現調研的基礎上，調研產品的實際用戶羣體的熟知的文化理念，以及現有在用產品的生命原色，產品隱喻，所在地方的政治約束，社會元素等衆多因素，爲後期設計適合本產品的特有視覺風格提供依據。
調研過程中要關注的一些要點包括：
Ø 企業CI
Ø 企業內部的視覺設計規範
Ø 現有系統的視覺設計
Ø 企業文化
Ø 用戶羣體特性
Ø 操作使用環境
Ø 操作使用習慣
有時候，用戶會要求你去改變現有產品的視覺設計，那麼還需要調研清楚，他們爲什麼要改變，原來的視覺有什麼不足之處。
l 10視覺設計
主要參與角色是視覺設計師；標準成果物是《頁面效果圖》，《視覺設計規範初稿》。
在視覺調研完成後，VI進入設計階段。在設計之初，PM、UE首先要與VI確定工作內容和計劃。
比如，
Ø 哪些頁面要做效果，這些頁面的確定稿分別在何時會提供給VI。
Ø 哪些組件會被使用到，有多少種組件需要做效果，這些組件何時會確定提供給VI。
除了頁面的效果圖，還要形成視覺設計規範的初稿，在這份規範中，要形成視覺設計的各種標準。比如，
Ø 頁面柵格系統
Ø 視線流
Ø 框架佈局的大小
Ø 各個元素的大小，色彩，對齊
Ø 各種留白
Ø 交互defalt樣式，鼠標劃過樣式，點擊樣式
Ø 文字規範，字體，大小
Ø 圖片樣式，大小，格式，顯示處理等
在這個階段VI的成果只能稱爲視覺設計規範的初稿，這是因爲只有在得到sponsor評審確認後，設計的標準才能最終確定下來，成爲後續工作的基線和準則。
l 13裁圖及前端實現
主要參與角色是前端工程師，F.E；標準成果物是《靜態頁面》，《視覺設計規範》。
前端工程師的最主要工作分爲兩個部分：
1、 切圖。
2、 編寫頁面JS和CSS等實現腳本。
下面是一個前端工程師交給PM的成果目錄結構：
後續工作將交給PHPer，Javaer完成前後臺的渲染。
到此，整個產品設計工作將完成階段性任務，後續則是產品開發工程師實現代碼，產品測試工程師完成測試和集成，最終發佈；產品進入運營階段。
本文參考了：
《WebAnatomy:Interaction Design Frameworks that Work》
By Robert Hoekman,jr. Jared Spool
本文轉至：http://blog.csdn.net/linco_zhang/article/details/6948019