每個產品團隊都會有自己的工作流程，無論這個工作流程是否最高效、是否體現最大價值，但是我認為只要這個流程能夠為實現工作目標提供過程的保障就可以算是好的流程。

對于流程本身而言，可以因團隊不同或工作任務不同而有差異。一個成熟度的產品團隊可以在保證工作質量的前提下輕松適應任務的變化，也就是說能夠依據不同的工作要求調整對應工作的流程。也只有這種團隊才能正真體現最大的價值，稱得上是一個敏捷的、能快速響應變化的團隊。

那么，我們先來看看以前做產品設計時的團隊工作流程。我總結為是一個相對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

總結

以上是生活随笔為你收集整理的标准的产品设计工作流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。