作為互聯網公司的PM(產品經理)，我們需要面對眾多部門，因為自己就是項鏈里的那根線。需要書寫各種文檔，最常見的就是PRD(產品需求文檔)，當然根據重量級和時間等多因素，可以提交不同類別的，例如DRD(設計需求文檔)和ERD(工程需求文檔)。嘿嘿，DRD和ERD是我自己發明的。更多小的ECR級別項目中，文檔大家寫的都很自由。

今天晚上在跟工程師討論中，得到了一些啟發，摘錄部分。

給工程師看的文檔

1 工程師喜歡看結構化文檔，不喜歡看描述性文檔。

描述性文檔也要給工程師看，并且最好親口說，因為這對理解產品策略和發展方向有幫助，工程師可以幫助PM彌補沒考慮到的地方

2 工程師喜歡流程圖甚于Mockup，而Mockup是給領導給Marketing等成員看最合適；

并不絕對，初級工程師反倒喜歡mockup，而高級工程師經驗多了兩者沒區別

3 Mockup是畫大餅，產生食欲，爭取資源和獲得理解的方式。“有照片的菜單永遠比只列菜名的菜單受歡迎”，這是馬總說過的；

Mockup務必不要過于精細，否則累的是PM，領導和其他團隊會一開始就進入細節盤問階段，不利于表述產品目的和大的功能模塊

4 工程師更喜歡菜譜，而且是西式菜譜。做一道菜需要幾分鐘，幾滴色拉油，烤爐溫度和時間，需要哪些工序，前后順序和量化歸納。

這個并不絕對，聰明的工程師不喜歡菜譜，不喜歡純粹編碼。有些時候不妨像做中國菜一樣，給對方發揮余地。只是碰上好搭檔的概率不多，更多情況下菜譜更保險

5 軟件工程是西方的泊來物，標準化文檔非常重要。很多老外PM希望達到一種境界，進行完詳盡的分析和文檔后，開發人員按部就班就行了。中國人做菜喜歡個性發揮，油鹽醬醋通常都需要自己拿捏，菜譜上多“少許、半勺、少量”等描述性詞語。有時候PM也希望工程師這樣做菜，我們想吃甜味，但放多少克糖是需要廚師自己揣摩。

6 自己揣摩有利有弊，好處是PM省心，壞處是項目不可控。如果從風險角度考慮，軟件工程中的過程改進及文檔管理是受歡迎的。

給界面設計師看的文檔

除了工程師，那么UI設計師的DRD(設計需求文檔)又該怎樣拿捏？

MS Office的Visio在PM中比較受歡迎，對于那種沒有FW和PS操作經驗的PM來說就更重要了。當然你也可以使用Word，但Word在畫框圖方面可視為不專業，對于入門級PM或者輕量級設計框圖也適用。

對Word下了這么個定論，非常慚愧。工具是死的，人是活的，高級PM也能做到拈花折枝即可殺人的境界。

根據我的經驗，如果項目一旦正式啟動，PM最好不要采用Photoshop或者Fireworks等軟件自己來做設計。那樣會讓自己陷入細節，總想著跟UED去PK設計技巧，做了自己不該做的事。因為Visio已經將模塊做成控件，所以自己不需要拉框線，做精細的按鈕。

對于界面設計，除了正常的界面文案外，其他輔助性文字盡量使用一整塊的灰塊表示，PM不要陷入按鈕和字體設計中。PM的眼睛應該像眺望遠方一樣，看到的只是起伏的群山輪廓，至于山上長的樹是什么顏色，相信UED。

倘若PM有空余時間，而且項目并非公司會投入UE資源去做的，還處于idea階段。那么自己不妨用PS或FW做些精細設計。畢竟在立項前，PPT中配上能看上的圖，會增色很多，也更有說服力。讓每個人頭腦中不會出現1000個想象的產品，可以統一起來。至于精細到多細，要自己把握，這很花費時間的。一個半成品的Demo專業UED也需要2－3個工作日，拿業余時間設計是不可能精細到那種地步。如果非要有個衡量標準，那就是圖層盡量控制在100個以內，不要使用需鼠標貝賽爾曲線效果，少用染色效果，不用濾鏡。

給UED的設計稿，參考紙媒在版排前的草圖，那種黑白框線，文字用灰色細條代替。有空我再思考總結如何具體把握。如下圖：

最簡單的線框圖

多個頁面的線框圖

某個具體頁面線框圖

名詞解釋：

RD：Research and Development,在這里是指研發人員，就是公司的工程師

Mockup：圖樣，原型圖，在這里的意思是初始設計圖

UED：User Experience Designer ，用戶體驗設計。