## 產品設計體會(十五)——PM、PD、UE與UI
這周從產品部門的角度出發,講一下我心目中的幾大主要任務和相應的職責區別,涉及產品經理、產品設計師、用戶體驗師、視覺設計師四個角色。一般來說,這個順序就是一個產品從規劃到最終成型的任務流方向,是一個從抽象到具體、商業到技術的過程。
PM:產品經理,俗稱老大(另一個PM項目經理在我們公司更像是從技術角度出發的職位)。一個產品,首先由PM來分析細分市場、目標客戶的訴求,規劃產品的賣點、殺手級應用,這個過程通常PD已經介入了,這個層面上,商業問題、業務邏輯的流暢是思考的焦點。
PD:直譯為產品設計師,也可能叫產品規劃師、需求分析師。PD側重于將一個個殺手級應用做功能級的設計,在這個模塊上,PD類似是一個小產品經理。比如要做進銷存,具體到庫存管理需要提供庫存警戒功能么?警戒數字是只有上限?下限?還是都有?警戒數字設置需要批量操作么?等等。技術團隊中的架構師(或者系統分析師,也可能叫項目經理、開發組長)會與PD緊密合作,這時候開始考慮技術可行性,性價比。
UE:字面為用戶體驗師,可能稱作交互設計師、界面設計師。UE負責產品和用戶交互方面的設計,這方面在技術部門的配合角色應該是前端工程師(web表現層)。通常UE拿到case的時候,要做什么功能已經決定了,PD與UE要充分溝通,UE必須要了解很多商業層面的內容,理解功能的商業價值。舉個例子,比如在商業目的是“注冊用戶數”的前提下,設計注冊流程是一頁搞定還是分幾個“下一步”,出錯提示是js彈出還是頁面即時判斷……
UI:英文直譯為用戶界面,可能也叫界面設計師、視覺設計師,很多小作坊簡稱美工,與UE的界限在很多時候是模糊的。到了UI層面,基本是界面的表現,是用戶第一眼看到的效果,比如配色、頁面結構、按鈕形狀、字體字號等等。
當然上面這個過程不是靜態的,一方面產品設計的流程是可以并必然要反復、迭代的,另一方面各個角色的分工有時候是模糊的,對上下游的業務也必須有所了解。
講了這么多,可能還是沒有一個感性的認識,有一個簡單的判斷方法,盯著產品部門某位員工的顯示器一天,看一下他的大部分時間屏幕上都是什么:
PPT的是PM,他在想這怎么跟高層確認產品戰略;
Word的是PD,他在寫文檔;
Dreamweaver的是UE,他在做網頁;
PhotoShop的是UI,他在做圖;
另:整天Project的是PM(項目經理);整天Excel的是財務。。。
- 前言
- (一)——變態吧,開始帖周報了
- (二)——數據分析
- (三)——性價比:做不做?
- (四)——需求管理
- (五)——有關流程
- (六)——再談流程
- (七)——需求探針
- (八)——產品與項目
- (九)——關于學習
- (十)——團隊合作
- (十一)——市場掃描
- (十二)——少而精
- (十三)——再說需求分析
- (十四)——做過的幾個項目
- (十五)——PM、PD、UE與UI
- (十六)——Feature List
- (十七)——PD的幾種文檔
- (十八)——概念設計
- (十九)——UPA年會的流水賬
- (二十)——有關改版
- (二二)——封閉開發
- (二三)——用戶研究
- (二五)——當交互設計遇到敏捷開發
- (二六)——PD就是出來賣的
- (二七)——大產品設計
- (二八)——細節之文案
- (二九)——產品設計的五個層次
- (三十)——“體會”導讀的思維導圖
- (三二)——零散的體會
- (三三)——用戶大會
- (三四)——土老板破冰必殺技
- (三五)——QA與測試
- (三六)——再理解“敏捷”
- (三七)——可用性測試
- (三八)——項目外包!=開發外包
- (三九)——CSDN專訪精編版
- (四十)——銷售渠道
- (四一)——用戶創意無限
- (四二)——又是零散體會
- (四三)——說說評審會
- (四四)——項目外包不適合“敏捷”?
- (四五)——外行眼中的技術分工
- (四六)——UML學習摘錄(上)
- (四七)——UML學習摘錄(下)
- (四八)——資源戰爭與BRD
- (四九)——產品市場化
- (五十)——終點:Matrix
- (五一)——敏捷的估計與規劃
- (五二)——MS Office使用心得
- (五三)——產品文檔與規范
- (五四)——PD招聘廣告詞
- (五五)——項目Kick Off
- (五六)——《需求工程》培訓記錄
- (五八)——《項目化管理》培訓記錄