PRD是一個產(chǎn)品經(jīng)理硬實力最好的背書。在項目周期中，理論上只有需求階段由產(chǎn)品經(jīng)理全權(quán)負(fù)責(zé)，此時受到的外部干擾最少。輸出的PRD直觀體現(xiàn)產(chǎn)品經(jīng)理對產(chǎn)品從宏觀到細(xì)節(jié)的思考結(jié)論，體現(xiàn)硬實力。

一、怎么理解PRD

產(chǎn)品需求文檔，即Product Requirement Document，是產(chǎn)品經(jīng)理能力基礎(chǔ)中的基礎(chǔ)。

是從產(chǎn)品規(guī)劃到產(chǎn)品設(shè)計階段的里程碑式綜合產(chǎn)出物。

1. PRD對產(chǎn)品經(jīng)理的意義

PRD是一個產(chǎn)品經(jīng)理硬實力最好的背書。在項目周期中，理論上只有需求階段由產(chǎn)品經(jīng)理全權(quán)負(fù)責(zé)，此時受到的外部干擾最少。輸出的PRD直觀體現(xiàn)產(chǎn)品經(jīng)理對產(chǎn)品從宏觀到細(xì)節(jié)的思考結(jié)論，體現(xiàn)硬實力。

在其他階段充斥著大量的溝通、協(xié)調(diào)、權(quán)衡、妥協(xié)，軟實力彌補(bǔ)硬實力的情況；即人際關(guān)系做得比業(yè)績好，也是一些人的工作方式。還有一些項目走不到需求階段，在PPT匯報和Demo演示后戛然而止

閱讀一本書就是在與作者對話，閱讀PRD就是與產(chǎn)品經(jīng)理對話。

好的PRD，可以提升溝通效率，降低返工風(fēng)險，讓開發(fā)在需求評審階段可以準(zhǔn)確的評估工期，確保項目的穩(wěn)定進(jìn)展。并且可以在出現(xiàn)爭議時做為憑證快速定位問題，在新人加入時做為教材幫助其快速了解項目內(nèi)容

好的PRD，可以建立良好的職場形象，積累職場人品。想不如說、說不如寫。寫的清楚，就是真的想明白了。輸出好的需求文檔，可以在開發(fā)心中建立起靠譜的形象，獲得信任；有了信任，在后續(xù)的溝通協(xié)同中會更加順暢。

對于產(chǎn)品經(jīng)理來說，PRD同樣是自己的產(chǎn)品，它的用戶就是在項目過程中將其做為依據(jù)的UI、開發(fā)、測試、運(yùn)營等。

需求評審就是PRD這個產(chǎn)品發(fā)布的過程，不要把用戶的反饋認(rèn)為是理所應(yīng)當(dāng)，不要覺得自己有機(jī)會和用戶解釋。

需求評審不僅是為大家宣講一遍需求，更是要達(dá)成共識，就算當(dāng)下大家無法完整的記住所有內(nèi)容，在以后的項目周期中也可以在PRD中找到衍生問題的答案。

PRD也可以過濾產(chǎn)品經(jīng)理在溝通上的優(yōu)勢或劣勢，更加直觀的審視每一個需求的價值和合理性。

PRD是產(chǎn)品經(jīng)理最好的背書，產(chǎn)品的成功與否，是受內(nèi)外部無數(shù)影響因素控制，無法直觀驗證產(chǎn)品經(jīng)理本身的能力和價值。PRD是完全把控在產(chǎn)品經(jīng)理手中的，它的質(zhì)量可以直接體現(xiàn)出撰寫它的產(chǎn)品經(jīng)理的能力和態(tài)度。

你可能會因為一些案例誤會，喬布斯、馬化騰、張小龍、俞軍都有產(chǎn)品經(jīng)理的title，他們就不用寫PRD。那是因為產(chǎn)品經(jīng)理的定義很廣，公司需要他們產(chǎn)出的價值不同。

雖然名義上都是產(chǎn)品經(jīng)理，其實根本不是一個工種，而且產(chǎn)品經(jīng)理往往只是大佬眾多title中的一個。

我們通常討論的產(chǎn)品經(jīng)理，都是有執(zhí)行層面的工作產(chǎn)出任務(wù)的。你可能會受到一些觀點(diǎn)影響，覺得不要過于糾結(jié)交互，不要停留在功能思維，要有策略思維有業(yè)務(wù)思維。

那是因為做好基礎(chǔ)是提升的前提，PRD寫的好，不一定是好的產(chǎn)品經(jīng)理，PRD寫的不好，一定不是好的產(chǎn)品經(jīng)理。

除非你有自己獨(dú)特的發(fā)展路線，不然絕大部分產(chǎn)品經(jīng)理都要反復(fù)經(jīng)歷這個樸實無華的階段，有人覺得枯燥，我覺得很有意思。

2. 一些現(xiàn)狀

越基礎(chǔ)的東西，越容易被有意無意的忽略。如果說整個互聯(lián)網(wǎng)行業(yè)的勢能是從產(chǎn)品到增長，那么產(chǎn)品經(jīng)理個人成長的趨勢便是從執(zhí)行到規(guī)劃、從局部到整體、從微觀到宏觀、從具象到抽象。

從產(chǎn)品到增長的前提是，產(chǎn)品層面已經(jīng)達(dá)到一定標(biāo)準(zhǔn)，打好了基礎(chǔ)，可以承接住增長帶來的流量的留存和轉(zhuǎn)化。產(chǎn)品的基礎(chǔ)包含了順暢的流程體驗、穩(wěn)定的系統(tǒng)運(yùn)行、業(yè)務(wù)的完整閉環(huán)、完善的服務(wù)體系等等。

資本越來越冷靜，中小企業(yè)就越來越急功近利。很多時候產(chǎn)品的功能層面還沒打磨到可以面向大量用戶的情況下，便早早寄希望于推廣營銷帶來增長。這是行業(yè)里長期聚焦于巨頭產(chǎn)品、明星產(chǎn)品討論帶來的幸存者偏差。

因為單純的產(chǎn)品功能層面已經(jīng)很難有獨(dú)特的競爭力了，所以人們在討論成功產(chǎn)品的時候，往往更加關(guān)注產(chǎn)品基礎(chǔ)之上的其他成功因素。

容易讓人忽略，產(chǎn)品打下的良好基礎(chǔ)是成功的核心原因之一，讓人誤以為自己公司的產(chǎn)品與成功產(chǎn)品的差距僅僅是對外宣講的成功方法論里的因素。

產(chǎn)品經(jīng)理的個人發(fā)展同樣如此，需求文檔是基本功，很多人不屑練習(xí)基本功。

在看行業(yè)大佬分享的時候，他們鮮有提及自己在做執(zhí)行工作的時候?qū)唧w功能的思考，因為這樣的話題太基礎(chǔ)太枯燥，不夠有噱頭，不夠吸引人，不能滿足分享發(fā)起者的利益述求。這也導(dǎo)致很多人追逐大佬的思維方式，忽略了實操的重要性。

基本功沒有練好，就開始憧憬像大佬一樣闡述自己的產(chǎn)品哲學(xué)，發(fā)表對行業(yè)的看法，指導(dǎo)公司的戰(zhàn)略規(guī)劃。

收集干貨和方法論指點(diǎn)江山很容易，忍受寂寞反復(fù)深入思考細(xì)節(jié)很難；混圈子參加峰會結(jié)交大佬很爽，梳理業(yè)務(wù)協(xié)調(diào)資源權(quán)衡決策很痛苦；只能停留在思想層面的創(chuàng)意沒什么價值，能把創(chuàng)意的框架填充完整執(zhí)行落地才有價值。

我之前經(jīng)常寫一些看上去很牛逼的文章，比如《為什么亞馬遜沒有在中國風(fēng)生水起》、《亞馬遜為什么還不把Pinterest拿下》、《來往真正的對手不是微信，而是旺旺》、《騰訊缺什么？缺一個馬云！》。

每每寫完之后，總有一種“朕終于把奏折批完了”的感覺?？珊髞碛l(fā)發(fā)現(xiàn)，這不過是自己的意淫：自己壓根就沒有后宮佳麗三千，憑什么扶著一把老腰更是說直不起來。

寫得多了，也搞清楚了：這些文章對于任何一個文藝青年來說，都是極其簡單的套路。

寫得多了，也覺得無聊了。

畢竟，這些文章無非就是：找準(zhǔn)看客意淫點(diǎn)：騰訊阿里百度，馬化騰馬云李彥宏；

堆砌大量數(shù)據(jù)：不要在乎有沒有用，數(shù)據(jù)給人的直覺是客觀靠譜；

寫的足夠長：質(zhì)不重要，量唬死人；

偶爾插入黑幕：管他真假。

如果自己是一個媒體人，專門是寫文章的，那倒也罷了，畢竟是工作使然。但如果自己壓根不是搞媒體的，寫這些文章又有何意義！

正如我經(jīng)?？吹接腥藛栴愃朴谶@樣的問題：

“陸奇不在了百度還能活下去嗎”

“騰訊是不是真的沒有夢想”

“為什么海底撈服務(wù)這么好”

“區(qū)塊鏈怎么投資”

“羅永浩算一個合格的產(chǎn)品經(jīng)理嗎”

….

不知道您看了這些提問是怎樣的，我個人現(xiàn)在一看到這些提問都忍不住在懷疑：這些提問的人肯定是隱藏平臺下面的各位大佬的馬甲，比如比爾蓋茨、巴菲特、扎克伯格、馬化騰、馬云、周鴻祎之類的。我拼命的想著如何回答，眼睛都紅了三圈，硬是沒有找到合適的回答口徑，就此也失去了被這些大佬青睞的機(jī)會。

想來，著實可惜。

久而久之，我也想通了：畢竟，咱不過是個普通人罷了，還是做好手頭上的事情，最好。

那么怎樣才能做好手頭上的事情呢？

我想最重要的其實就是基本功。

楊俊《瞧不起的基本功，筑不起的摩天樓》

3. 認(rèn)知門檻

PRD寫的糾結(jié)的原因主要有以下幾點(diǎn)：

（1）方法論不適合

我們可以輕而易舉的搜索到上百篇教你怎么寫PRD的教程，也可以找到很多模板參考學(xué)習(xí)。

但是在現(xiàn)實環(huán)境里，如果公司在需求評審階段有詳細(xì)甚至嚴(yán)苛的流程規(guī)范，那么先按照要求執(zhí)行總是沒錯的。因為從上而下的推動相對容易，大家都建立起了相關(guān)的意識，流程的完善通常也對應(yīng)著分工的細(xì)致，讓你更容易聚焦和專注。

容易出現(xiàn)問題的情況往往是看了很多完善的理想化的教程，在應(yīng)用的時候想達(dá)到“完美”甚至影響了“完成”。

在摸索中，你不知道你辛辛苦苦肝出來的東西，被應(yīng)用了多少，被浪費(fèi)了多少。

一些人只看到了某某團(tuán)隊做成了什么，卻不考慮某某團(tuán)隊有多少人投入了多少成本協(xié)調(diào)了多少成本，你能不能對標(biāo)得上。如果把這件事情放在明面上討論，不免讓人覺得在找借口，其實這是再正常不過的SWOT。思考，然后選擇。

而小龍評審微信的功能有一個習(xí)慣：不看原型圖，不看設(shè)計稿，也不看Demo，要體驗前后臺代碼開發(fā)好后的產(chǎn)品。這就意味著：如果一個功能在給到用戶之前有過n個方案，則前后端開發(fā)人員已經(jīng)開發(fā)過n個版本的代碼。如果你從事互聯(lián)網(wǎng)行業(yè)，特別是在創(chuàng)業(yè)公司，你肯定會知道：這是極大的資源浪費(fèi)，并且對開發(fā)速度和質(zhì)量要求都非常高，還很考驗開發(fā)團(tuán)隊對產(chǎn)品經(jīng)理的信心和耐心——他們只會認(rèn)為這個什么都不懂的產(chǎn)品經(jīng)理整天在瞎改。

但是微信團(tuán)隊做到了，經(jīng)常是昨天半夜開產(chǎn)品會，想出了一個方案，今天半夜就能體驗這個新方案，并且把它否掉了。

——陸樹燊 《微信創(chuàng)始團(tuán)隊成員：解讀微信團(tuán)隊的實驗室文化》

PS. 所以有些創(chuàng)業(yè)團(tuán)隊想找我去跟他們分享微信團(tuán)隊的工作方法，我就跟他們說，微信的做法是學(xué)不來的——如果像微信團(tuán)隊一樣去折騰開發(fā)人員，大概你們的產(chǎn)品經(jīng)理活不到版本發(fā)布……

（2）公司不重視

一個項目順暢運(yùn)行，一定是有人在發(fā)揮作用的，但是很容易被人覺得是理所應(yīng)當(dāng)。

就像上文提到的，因為產(chǎn)品層面同質(zhì)化嚴(yán)重缺乏獨(dú)特競爭力，在復(fù)盤成功案例時鮮被提及。這也導(dǎo)致了公司覺得把產(chǎn)品層面的基礎(chǔ)打好很容易，很多業(yè)務(wù)討論都是預(yù)設(shè)在產(chǎn)品層面已經(jīng)完善的前提下，缺乏耐心和投入，這種態(tài)度自上而下的影響產(chǎn)品經(jīng)理。

同理，公司也很少會把撰寫PRD的能力做為考核指標(biāo)和內(nèi)部培訓(xùn)內(nèi)容。

（3）試錯成本低

一個自覺的產(chǎn)品經(jīng)理，會自我驅(qū)動的三省吾身見賢思齊，只要不是方向偏的離譜，基本功至少不會太差。而PRD寫的不好又不自覺的產(chǎn)品經(jīng)理，往往是因為沒有為此付出代價，才會一直不發(fā)覺不重視這個問題。

在面試時，因為企業(yè)考察的顆粒度以及公司機(jī)密等原因，很少有機(jī)會可以直觀全面的考察到面試者撰寫PRD的能力。在需求評審時，因為開發(fā)小哥哥們的寬容或敷衍，很多被遺漏的需求細(xì)節(jié)在開發(fā)階段才通過口頭溝通補(bǔ)充。

“PRD，騙RD”。這也造成了一個現(xiàn)象，產(chǎn)品經(jīng)理被人調(diào)侃什么都不會（PRD試錯成本低），用PPT做產(chǎn)品（公司更重視PPT）。

對于公司，良好的產(chǎn)品基礎(chǔ)；對于個人，扎實的基本功；和學(xué)歷一樣，擁有的人才配說它不重要，其實它很重要。

對于公司，可以對外宣揚(yáng)的成功方法論；對于個人，可以對外輸出的個人影響力。都是海面之上的冰山，是可以被人看到的部分。

千萬不要忽略了海面之下還存在著更加龐大復(fù)雜的部分，這才是冰山可以露出海面被人看到的原因。

二、PRD到底怎么寫

1. 工具

工具只是工具，沒有絕對的標(biāo)準(zhǔn)、只要適合就好。

在我的實踐中，用Axure原型+注釋的方式撰寫，導(dǎo)出HTML或發(fā)布到Axshare或通過藍(lán)湖上傳的方式傳達(dá)，效率最高效果最好。

Axure之于產(chǎn)品經(jīng)理就像PhotoShop之于設(shè)計師，經(jīng)典的雖然看起來沒那么酷炫，但是它代表著易用性、拓展性、普適性。

• 易用性：可以找到大量教程，降低門檻快速上手；
• 拓展性：可以獲取大量素材，積累提升輸出質(zhì)量；
• 普適性：可以兼容各種系統(tǒng)，提升工作協(xié)同效率。

有人用墨刀做花里胡哨的交互，文字描述寥寥，結(jié)果連異常流程都覆蓋不了。

有人用word寫長篇大論，結(jié)果開發(fā)根本不看，還要問你每個頁面怎么跳轉(zhuǎn)。

有人用sketch，不配合專屬插件的話，很容易畫成沒有結(jié)構(gòu)性的頁面流程圖。而且是否具備普適性，取決于周圍與你配合的人。

工具本身沒有問題，有問題一定是工具人的問題。

為了讓你的PRD的用戶使用效果更好，汲取意見是很重要的。有的時候不要埋怨開發(fā)為什么不認(rèn)真看，去問問他們喜歡看什么樣的，適當(dāng)調(diào)整達(dá)成統(tǒng)一。

Tower、禪道、tapd等團(tuán)隊協(xié)同工具，會導(dǎo)致一部分人習(xí)慣把產(chǎn)品的結(jié)構(gòu)通過協(xié)同工具中的單個需求建立父子關(guān)系連接，在每個子需求中上傳需求圖片+文字描述。

這種方式更適合優(yōu)化已有功能，功能可以在小范圍內(nèi)實現(xiàn)閉環(huán)，但是容易使人忽略細(xì)節(jié)的調(diào)整對全局的影響。

產(chǎn)品經(jīng)理應(yīng)該把控Axure源文件的顆粒度，哪些版本/模塊在一個源文件里更新，從哪個版本/模塊新建文檔維護(hù)；文檔或文件夾之間盡量去重、解耦。在原有文件上新增或調(diào)整的部分，更顯眼的做出標(biāo)注，讓人可以一眼看出變動的部分。

在Axure里搭建當(dāng)前版本/模塊最完整的產(chǎn)品結(jié)構(gòu)，并且及時更新。要明確一個認(rèn)知，協(xié)同工具是給UI、開發(fā)、測試、運(yùn)營看的，目的是讓他們看起來方便，可以針對單個需求設(shè)置執(zhí)行人員、排期、添加bug記錄等，核心價值是項目管理。

而不是為了產(chǎn)品經(jīng)理維護(hù)需求文檔方便，所以在需求的撰寫和管理時，不要依賴協(xié)同工具。在追溯需求問題的時候，要能做到在Axure文件里便能找到記錄，而不是去翻協(xié)同工具里的需求記錄。

2. 拆解

用兩個類比幫助你更好理解我要表達(dá)的觀點(diǎn)：

• 項目>PRD；
• 產(chǎn)品>首頁；
• 工作>簡歷。

在項目流程中撰寫PRD，和在產(chǎn)品設(shè)計中設(shè)計首頁、在工作經(jīng)歷中梳理簡歷的感覺類似。它們都不是獨(dú)立存在的，都與之前的各個環(huán)節(jié)有著千絲萬縷的聯(lián)系。

誠然后者需要技巧，但是如果不是建立在前者價值的基礎(chǔ)上，將言之無物無的放矢。所以梳理PRD怎么寫，無法脫離于項目流程單獨(dú)思考，需要帶入流程。

再來看這張圖：

項目的流程大同小異，在做好需求評審前的各個環(huán)節(jié)之后，你自然會積累從抽象逐漸到具體的一系列文檔內(nèi)容。此時將它們進(jìn)行整理，做匯總提煉，補(bǔ)充顆粒度更細(xì)的內(nèi)容即可。

一順百順一損俱損。從項目的維度拆解PRD的組成后，可以發(fā)現(xiàn)，前面的每一個環(huán)節(jié)做的越完善，在撰寫PRD的時候越能降本增效。

在撰寫PRD出現(xiàn)問題時，也可以追本溯源根據(jù)內(nèi)容部分找到對應(yīng)的環(huán)節(jié)，定位問題從而找到解決方案。

所以PRD到底怎么寫，如果你把問題定位在“怎么寫PRD”這個顆粒度，你能找到的大部分內(nèi)容大致是一下3種：

1. 模板+簡要的講解；
2. 從各種角度切入，或重新解讀或填充某部分的細(xì)節(jié)；
3. 長篇幅的系列文章。

多看第三種，更有可能通過結(jié)論找到思考路徑。

但是這些都是被動的做法，你只能去碰，找到能給你啟發(fā)適合你應(yīng)用的內(nèi)容的概率。

主動的做法是，拆解→定位→聚焦

3. 具體內(nèi)容

為了實操性，我不會放一個看起來高大上的需求文檔模板，面面俱到，導(dǎo)致參照的時候要素過多無法聚焦。

以下的內(nèi)容可能存在爭議，重點(diǎn)是你要獨(dú)立思考，想想什么樣的才是最適合你的。

我寫這些的適用場景不是你興致勃勃的想要學(xué)習(xí)提升，而是：

• 在你看了那么多關(guān)于需求文檔的干貨以后，還是無法把其中所謂的知識點(diǎn)應(yīng)用到實際工作中；
• 在你被PRD困擾而你又想繼續(xù)做產(chǎn)品經(jīng)理的前提下，如何打造一個PRD的MVP，先確保項目順利進(jìn)展，再查缺補(bǔ)漏逐步迭代優(yōu)化；
• 在你面對著錯綜復(fù)雜的需求來源，產(chǎn)品路線不夠聚焦，團(tuán)隊排期緊張的情況下，如何快速把抽象的需求轉(zhuǎn)化為具象的可落地內(nèi)容；
• 在你看到了問題也想到了解決方案，但是無法翻譯成達(dá)到開發(fā)可以執(zhí)行的標(biāo)準(zhǔn)時，如何通過SOP建立結(jié)構(gòu)化思維提升輸出穩(wěn)定性。

如果把它當(dāng)成職場向內(nèi)容看，可能違和感會小一些。

產(chǎn)品規(guī)劃和PRD的撰寫，都要知道哪些部分承載核心價值，不要妄圖通過堆積功能/內(nèi)容來增加滿足用戶的可能性。

（1）必備內(nèi)容

這里的必備內(nèi)容已經(jīng)是降低過要求的，是real必備，有了這些內(nèi)容才能起碼確保你思考的足夠完善，表達(dá)的足夠清晰。

a. 業(yè)務(wù)流程

通過流程圖展示，泳道圖也是流程圖的一種，更加強(qiáng)調(diào)分工，比普通流程圖多了一個劃分維度。根據(jù)描述角度的側(cè)重，這個維度可以是角色（患者/醫(yī)生）or終端（用戶端/醫(yī)生端/管理后臺）or場景（就診前/就診中/就診后）。

業(yè)務(wù)流程至少要說明的內(nèi)容：

• 涉及哪些角色
• 任務(wù)如何劃分
• 角色如何協(xié)作
• 數(shù)據(jù)如何流轉(zhuǎn)
• 是否存在分支
• 異常如何處理
• 校驗?zāi)男┮?guī)則
• 產(chǎn)出哪些文檔

b. 角色說明

角色名稱、角色定義、角色權(quán)限（數(shù)據(jù)權(quán)限、操作權(quán)限）。

如果產(chǎn)品的業(yè)務(wù)屬性沒有那么強(qiáng)，角色比較單一，至少要說明游客和注冊用戶的權(quán)限區(qū)分。

在相關(guān)功能設(shè)計時，注意區(qū)分不同權(quán)限的對應(yīng)狀態(tài)樣式，無權(quán)限的分支流程。

簡單權(quán)限劃分：

復(fù)雜權(quán)限劃分：

如果功能權(quán)限顆粒度過細(xì)，比如常見的后臺產(chǎn)品，在角色說明表格之外要做更多補(bǔ)充。

此類場景下權(quán)限管理有必要做為一個功能模塊來規(guī)劃，劃分好功能權(quán)限，預(yù)設(shè)角色（用戶分組），明確角色定義，配置好角色對應(yīng)的權(quán)限模板。

c. 功能流程

功能流程表達(dá)的是，業(yè)務(wù)流程中的內(nèi)容，是如何通過人機(jī)交互實現(xiàn)的。

根據(jù)具體功能劃分適合的顆粒度，標(biāo)準(zhǔn)是解耦、形成閉環(huán)。

如果分支流程比較復(fù)雜，可以在對應(yīng)位置標(biāo)注，再把閉環(huán)的分支流程作為一個單獨(dú)的功能流程圖展示。如：注冊/登錄流程，可以根據(jù)獨(dú)立閉環(huán)的子功能劃分為：登錄、注冊、找回密碼等，通過三個流程圖展示。

注意不要把產(chǎn)品結(jié)構(gòu)和功能流程混在一起。一個功能流程中只完成一個任務(wù)，有兩種結(jié)果：成功or失敗。

常用的元素只有四種：

• 圓角矩形：開始、結(jié)束；
• 矩形：非判斷的所有流程節(jié)點(diǎn)，操作動作、交互效果、中間狀態(tài)等；
• 菱形：邏輯判斷、數(shù)據(jù)校驗；
• 單箭頭連接線：表達(dá)流轉(zhuǎn)方向。

d. 原型+功能詳述

一份交互自查表，搞定一切，整體＆流程：

內(nèi)容＆狀態(tài)＆顯示：

反饋＆通知：

文本＆控件：

常見類型：

繪制原型＆添加注釋的過程，是想好再動手；越簡單的邏輯或越快速的思考可以使想和做的節(jié)點(diǎn)趨于一致，甚至手跟不上腦子。抽絲剝繭厘清邏輯條理清晰的記錄下來，是很有快感的事情。

交互自查表里的內(nèi)容相對全面，根據(jù)你的使用習(xí)慣和不同控件的側(cè)重點(diǎn)來進(jìn)行思考和注釋。比如列表，重點(diǎn)注釋列表的（篩選）初始狀態(tài)，排序規(guī)則，列表項組成及數(shù)據(jù)來源。

如果數(shù)據(jù)來源有需要用戶自定義編輯的部分，則要權(quán)衡編輯的規(guī)則（如極限值）和列表中的展示規(guī)則（如極限值）。比如表單，重點(diǎn)是區(qū)分初始、瀏覽、編輯等狀態(tài)；編輯狀態(tài)下的引導(dǎo)、校驗、提醒，中途退出的數(shù)據(jù)是否緩存。

要考慮數(shù)據(jù)流轉(zhuǎn)對其他流程的影響，業(yè)務(wù)思維影響產(chǎn)品設(shè)計，產(chǎn)品設(shè)計影響交互規(guī)則。如個人資料提交之后不涉及其他業(yè)務(wù)流程，則提交后立即生效，并且可以反復(fù)修改。如認(rèn)證資料提交后需要專門人員進(jìn)行審核，審核結(jié)果的不同導(dǎo)致后續(xù)流程不同。則提交后不會立即生效（這時需要提供更多的進(jìn)度提醒讓用戶安心），可根據(jù)業(yè)務(wù)特性和審核人力成本來權(quán)衡修改限制。

這是一個先乘后除、先加后減的過程。寫得夠多以后，你自然會找到一個自己更舒服而且團(tuán)隊更接受的方式。

至于你要用標(biāo)注點(diǎn)、要連線、還是建立表格來寫這些東西，不重要；重要的是統(tǒng)一、清晰。

（2）常見內(nèi)容

常見內(nèi)容是意思的在PRD里展示出這部分，會使PRD更加完善。如果沒有這些內(nèi)容，也不會直接影響到項目進(jìn)展；但是不代表產(chǎn)品經(jīng)理可以不思考不輸出這些內(nèi)容。

這些內(nèi)容就算在PRD里沒有展示，也要確保已經(jīng)思考清楚并且在其他地方有所記錄。

a. 需求分析：需求背景＆需求價值

在PRD之外，可以通過需求模板、需求池等方式記錄。

PRD的用戶是UI、開發(fā)、測試、運(yùn)營等團(tuán)隊成員，有的人對產(chǎn)品有自己的思考樂于討論，想要在執(zhí)行之外獲得成就感；有的人不想?yún)⑴c討論，只想直接知道結(jié)論，知道需要執(zhí)行什么內(nèi)容。根據(jù)你的用戶特點(diǎn)，來決定這部分內(nèi)容溝通的深度。

需求評審時絕大部分時候要說，但是并不絕對。如果有人想知道，一定要解釋清楚。

避免信息差，劃分客觀事實和基于對客觀事實的調(diào)研觀察得出的主觀結(jié)論。

雙方的溝通要在信息同步的前提上，不要在評審人員提出質(zhì)疑的時候才拋出一個他不知道的客觀信息來反駁。表達(dá)的越全面越能幫助評審人員發(fā)現(xiàn)問題引起討論，降低評審人員的思考門檻，進(jìn)行引導(dǎo)。無論需求大小，就算只是調(diào)整一個簡單交互，表單里加一個字段，都有與之對應(yīng)的需求背景＆需求分析。

如果被質(zhì)疑的時候，你只能說出“老板要這么做”的話，說明你在需求調(diào)研和需求分析階段偷了懶，沒有負(fù)起責(zé)任，這也容易因為對需求理解不到位造成返工。做功能只是手段、不是目的。

想想銷售對你說“客戶就要這樣的”時候你心里的萬馬奔騰，不要只做一個傳話的人，不要變成自己討厭的人。

b. 版本記錄和修訂日志

在PRD之外，可以通過區(qū)分多個源文件命名備注，表單記錄。

其實性價比最高最穩(wěn)妥的方式還是在PRD里直接記錄，每次順手完成，成本遠(yuǎn)遠(yuǎn)小于事后追溯。

修訂日志類似需求池，修訂日志中的內(nèi)容會更加具象，非科學(xué)推導(dǎo)的結(jié)論也會更多。

自己的原因-需要重構(gòu)場景

需求挖掘沒有到位，沒有問出有效問題引導(dǎo)、沒有找到關(guān)鍵的業(yè)務(wù)干系人、業(yè)務(wù)流程存在疏漏。這時要補(bǔ)充前面遺漏的內(nèi)容，對現(xiàn)有解決方案進(jìn)行優(yōu)化。

對需求分析階段重點(diǎn)復(fù)盤，規(guī)避類似錯誤。

非科學(xué)推導(dǎo)-需要重構(gòu)交互

需求方提出的其他解決方案 “老板要這么做、“客戶要這么做”。在兩種方案都能滿足的前提下，就要進(jìn)行博弈。

衡量兩種方案的成本差異、實現(xiàn)效果、對方是否容易溝通、這件事是不是整個項目中我最需要堅持的等等。如修改字段文案，成本幾乎可以忽略不計，在文案沒有敏感詞、沒有歧義的情況下基本就可以滿足需求方的要求；把撕逼的機(jī)會留給守護(hù)核心功能流程上。

修改的內(nèi)容越多，涉及的內(nèi)容越復(fù)雜成本差異越高，修訂日志要記錄完整的概括內(nèi)容，記錄清楚受到新方案影響的全部功能＆邏輯。

這里也存在一些不合理需求的可能，因為當(dāng)前結(jié)論不是根據(jù)需求分析科學(xué)推導(dǎo)的，所以要重點(diǎn)記錄背景；以免以后無法找到得出當(dāng)前結(jié)論的原因。

c. 產(chǎn)品結(jié)構(gòu)圖=功能結(jié)構(gòu)圖+信息架結(jié)構(gòu)圖

不管是架構(gòu)還是結(jié)構(gòu)，都是一個意思。

功能＆信息兩者間沒有清晰的邊界，功能中承載著信息，信息在功能間流轉(zhuǎn)。

功能結(jié)構(gòu)圖：脫離頁面，以功能模塊劃分。功能模塊代表一個閉環(huán)的流程，用來展示功能層級和組成；最小顆粒度在產(chǎn)品中即對應(yīng)觸發(fā)邏輯的控件/熱區(qū)，如支付按鈕；是產(chǎn)品的骨架。

信息結(jié)構(gòu)圖：脫離頁面，以信息分類劃分。信息分類代表一個獨(dú)立的數(shù)據(jù)表，信息代表一個獨(dú)立的字段或固定參數(shù)；最小顆粒度在產(chǎn)品中即對應(yīng)頁面中的一個元素，如文章標(biāo)題；是產(chǎn)品的血肉。

根據(jù)產(chǎn)品設(shè)計時的思路逐漸清晰而逐漸完善，顆粒度越細(xì)，功能和信息越糾纏不清，沒有必要刻意區(qū)分。

畫一個產(chǎn)品結(jié)構(gòu)圖即可滿足日常需要：產(chǎn)品結(jié)構(gòu)圖=功能結(jié)構(gòu)圖+信息結(jié)構(gòu)圖。

產(chǎn)品結(jié)構(gòu)圖通過頁面劃分，是簡易版的原型，將功能和信息關(guān)聯(lián)到頁面中，幫助我們直觀的理解產(chǎn)品最終將呈現(xiàn)的樣子。

如有其他目的，也可以根據(jù)你的目的來決定表達(dá)方式。

團(tuán)隊分工or按功能模塊報價

功能結(jié)構(gòu)圖，如搜索在首頁＆列表等頁面都會出現(xiàn)，分工時需要通過功能維度把搜索單獨(dú)提出來由專人負(fù)責(zé)or單獨(dú)收費(fèi)。

協(xié)助開發(fā)建立數(shù)據(jù)庫or協(xié)助用戶批量導(dǎo)入數(shù)據(jù)

信息結(jié)構(gòu)圖，列出所有的字段。需要做數(shù)據(jù)采集的場景，用excel或在線文檔羅列字段，做好數(shù)據(jù)有效性（減少自定義，能選則選）。

工具只推薦一個：XMind

d. 頁面流程圖

介于功能流程和原型之間的，通過展示頁面核心元素及觸發(fā)跳轉(zhuǎn)動作的流程圖。主要用于體驗頁面跳轉(zhuǎn)的合理性。

可以適當(dāng)加些校驗規(guī)則的說明和異常流程，沒有必要做得過于細(xì)致，這只是過渡階段，輔助思考的一種方式，最終都是要落實到具體的原型+注釋上的。

千萬不要把詳細(xì)的原型+注釋做成一頁鋪開的“頁面流程”，PRD要通過頁面結(jié)構(gòu)（目錄）實現(xiàn)結(jié)構(gòu)性，方便查看的人理解層級關(guān)系。

如果把我們工作中輸出的文檔當(dāng)做一個產(chǎn)品的話，那么文檔的讀者就是用戶，很多產(chǎn)品經(jīng)理或交互設(shè)計師使用Axure或其他工具做的原型，可讀性遠(yuǎn)不如程序員寫的代碼。我們來看看下圖，很多產(chǎn)品經(jīng)理或交互設(shè)計師的文檔就像這樣，我之前就有同事會輸出這種文檔。我們現(xiàn)在招聘看到的很多人的作品也是這種類型的文檔。（與文檔內(nèi)容無關(guān)，不需要看清楚內(nèi)容，所以圖片已做模糊處理）

厲害吧？酷炫吧？我能夠在一張圖上面駕馭這么復(fù)雜的邏輯和流程，看看我多么專業(yè)。我只能呵呵一句，互聯(lián)網(wǎng)這個處處考慮用戶，連你工作的上下游都是你文檔的用戶的行業(yè)，真是不太適合你。

這種毫無模塊化思路的文檔，會造成團(tuán)隊溝通上的困難，文檔難以維護(hù)，工作無法交接，而且會導(dǎo)致在做產(chǎn)品設(shè)計時思路混亂，漏洞百出。

如果你招聘時收到了這樣的作品文檔，請慎重。

模塊化的設(shè)計思路，如果你是一個邏輯性強(qiáng)且在乎讀者體驗的人，那么你自己工作中完全有可能摸索出來模塊化設(shè)計思路。

ArvinNing《模塊化設(shè)計思路：好的原型文檔應(yīng)該注意什么？》

e. 功能清單

介于產(chǎn)品結(jié)構(gòu)和原型+注釋之間的內(nèi)容；通常用于給項目團(tuán)隊以外的人（老板、客戶、銷售、寫軟著等）展示，減少專業(yè)術(shù)語，用戶視角描述產(chǎn)品各個功能模塊實現(xiàn)的目標(biāo)或效果。

f. 數(shù)據(jù)統(tǒng)計

• 統(tǒng)計哪些數(shù)據(jù)
• 如何定義
• 如何計算
• 如何埋點(diǎn)

運(yùn)營活動需求必備相關(guān)數(shù)據(jù)指標(biāo)采集需求。

常規(guī)功能根據(jù)公司的數(shù)據(jù)體系完善程度、數(shù)據(jù)采集方式（埋點(diǎn)or全埋點(diǎn)/無埋點(diǎn)/可視化事件監(jiān)測）、功能特性等情況酌情撰寫。

數(shù)據(jù)體系完善程度：是否自動實現(xiàn)埋點(diǎn)，不需要額外說明。

功能特性：該功能是否需要數(shù)據(jù)指標(biāo)驗證解決方案的有效性，是否需要通過數(shù)據(jù)指標(biāo)尋找優(yōu)化點(diǎn)＆增長點(diǎn)。

g. 測試用例

想強(qiáng)調(diào)的核心流程，可以通過測試用例的格式再翻譯一遍，在功能描述基礎(chǔ)上進(jìn)一步窮舉和完善。

通過項目協(xié)同工具記錄bug，標(biāo)灰的內(nèi)容可以通過系統(tǒng)自動記錄。

h. 產(chǎn)品形態(tài)

整個產(chǎn)品的運(yùn)作邏輯，重點(diǎn)展示用戶角色、信息、渠道之間的流轉(zhuǎn)關(guān)系。

i. 用戶故事地圖＆用戶體驗地圖

故事地圖側(cè)重將用戶任務(wù)拆分，對應(yīng)到功能的顆粒度。

將用戶畫像，行為與功能進(jìn)行串聯(lián)，有助于在PRD中講清楚用戶如何通過產(chǎn)品滿足需求解決痛點(diǎn)。

體驗地圖在故事地圖基礎(chǔ)上，更側(cè)重情緒曲線、痛點(diǎn)，有助于尋找機(jī)會點(diǎn)優(yōu)化用戶體驗，通常在產(chǎn)品設(shè)計時使用，同樣可以作為設(shè)計依據(jù)在PRD中說明。

j. 未來規(guī)劃

想做的東西太多，需要通過版本迭代把握節(jié)奏，產(chǎn)品經(jīng)理至少要領(lǐng)先研發(fā)團(tuán)隊1~2個版本。也存在因為時間原因，臨時開發(fā)折中方案的情況，提前說明這個功能未來會規(guī)劃成什么樣子要達(dá)到什么效果，讓研發(fā)心里有數(shù)，為系統(tǒng)靈活性和拓展性做指導(dǎo)。

4. 特殊需求文檔

正如上文所說，需求文檔與需求階段的各個環(huán)節(jié)有著千絲萬縷的聯(lián)系。策略產(chǎn)品＆數(shù)據(jù)產(chǎn)品與功能產(chǎn)品有著截然不同的流程，因此需求文檔的內(nèi)容存在差異。

策略PRD：

DRD（Data Requirement Document 數(shù)據(jù)需求文檔）：

三、一些提升輸出質(zhì)量的tips

1. 學(xué)會“偷懶”

（1）結(jié)合系統(tǒng)特性，善用標(biāo)準(zhǔn)控件

如Android設(shè)計規(guī)范、 iOS設(shè)計規(guī)格、小程序設(shè)計規(guī)范、AntDesign(后臺UI框架)、G2Demos(數(shù)據(jù)可視化)。

設(shè)計規(guī)范和UI框架中的控件已經(jīng)十分成熟，熟悉并合理利用，減少需求撰寫成本，減少邏輯漏洞風(fēng)險。也有利于降低開發(fā)理解門檻和減少重復(fù)造輪子的情況。

（2）建立/積累自己的元件庫

降低撰寫需求和團(tuán)隊溝通的邊際成本，確保一致性。

2. 學(xué)會配合

專業(yè)的事交給專業(yè)的人。需求階段，產(chǎn)品經(jīng)理獨(dú)當(dāng)一面，遵循木桶理論，確保其中每個環(huán)節(jié)都不掉鏈子。

其他階段，產(chǎn)品經(jīng)理協(xié)調(diào)調(diào)度，遵循長板理論，確保其中每個職能都有發(fā)揮空間。

（1）設(shè)計＆交互

a. 豐富的顏色

不要給UI造成干擾，把視覺部分的發(fā)揮空間留出來，同時也避免花里胡哨的文檔內(nèi)容讓人看了辣眼睛。有想法可以提前溝通，不要喧賓奪主。

常用顏色如下即可：

不同灰度的黑：結(jié)合字體類型（粗細(xì)）＆字號區(qū)分信息展示權(quán)重。

紅色（強(qiáng)調(diào)色）：標(biāo)注價格、刪除等需要強(qiáng)調(diào)的內(nèi)容。

藍(lán)色（主題色）：你習(xí)慣的主題色，用于區(qū)分主操作/輔助操作、選中/未選中等。

b. 酷炫的交互

浪費(fèi)時間，而且容易出現(xiàn)觸發(fā)不完全導(dǎo)致理解偏差。

如果沒有交互設(shè)計師，在交互部分也要給UI留出話語權(quán)共同討論達(dá)成一致。UI設(shè)計是對軟件的人機(jī)交互、操作邏輯、界面美觀的整體設(shè)計，只做美工的是GUI。

同樣是經(jīng)常被人吐槽從業(yè)門檻低能力良莠不齊的兩個工種，就不要互相為難了，共同交流學(xué)習(xí)進(jìn)步吧。

產(chǎn)品經(jīng)理在視覺上需要重點(diǎn)關(guān)注的主要有兩點(diǎn)：

• “一勞永逸”的契合產(chǎn)品定位＆目標(biāo)用戶的配色方案；
• “標(biāo)準(zhǔn)套路”的視覺展示權(quán)重。

（2）技術(shù)

非功能性需求

把這些東西復(fù)制粘貼出來看起來很厲害，其實在PRD里往往只能成為正確的廢話，相信你的開發(fā)和測試，不要班門弄斧浪費(fèi)時間。

性能需求：速度、容量、并發(fā)性、實時性；

質(zhì)量需求：可靠性、可用性、可維護(hù)性、安全性、可移植性，還有接口、約束等。

（3）運(yùn)營

運(yùn)營建議

不要越俎代庖，首先你的建議不一定有效，話說的越抽象越宏觀就越正確，但是也越?jīng)]用。其次如果你的建議詳細(xì)完善具備可行性，還要運(yùn)管干什么，不要讓人家產(chǎn)生抗拒心理排除掉本來可行的思路。如果你的團(tuán)隊需要你參與或者你對此感興趣，可以討論，不要主導(dǎo)，還嫌鍋不夠大么。

當(dāng)然了，合理分工高效配合是一個理想的狀態(tài)，真實情況里還是會有團(tuán)隊存在職能缺失或短板的情況，還會有很多邊界模糊的灰色區(qū)域，產(chǎn)品經(jīng)理應(yīng)該多做聯(lián)系和推動，負(fù)起責(zé)任，但是前提是把本職工作先做好。

3. 建立標(biāo)準(zhǔn)

（1）全局標(biāo)準(zhǔn)統(tǒng)一

a. 交互邏輯統(tǒng)一

對于用戶，降低認(rèn)知成本和操作成本。

對于團(tuán)隊，減少溝通成本和提升開發(fā)效率。

b. 文案風(fēng)格統(tǒng)一

一切產(chǎn)品文案從產(chǎn)品定位出發(fā)，一個產(chǎn)品不會同時存在多個定位，所以文案風(fēng)格要統(tǒng)一。

c. 功能命名統(tǒng)一

• 新增、添加、新建
• 編輯、修改
• 確定、確認(rèn)

（2）傳達(dá)內(nèi)容清晰

a. 模塊/頁面層級

很多時候產(chǎn)品的設(shè)計并不是嚴(yán)格按照層級對應(yīng)的，會導(dǎo)致繪制產(chǎn)品結(jié)構(gòu)或功能模塊關(guān)聯(lián)時感覺別扭。

下面我嘗試描述一下并分享下我的方法，找到自己的方式處理即可，不要被完美主義束縛。

頁面同時存在單復(fù)數(shù)元素

通過英語語法中的單復(fù)數(shù)來理解，單數(shù)就是1，復(fù)數(shù)就是2~∞，兩者對應(yīng)至少兩套交互邏輯。把移動端頁面轉(zhuǎn)換為后臺樣式，可以更加直觀的查看層級，區(qū)別在于突出了字段。

在頁面元素同時存在單復(fù)數(shù)的情況時，提煉出其背后的字段，將復(fù)數(shù)元素歸類，會使層級更清晰。

頁面的不同狀態(tài)/導(dǎo)航（界面）

顆粒度到界面?！卷撁妗亢汀窘缑妗康姆Q呼與表達(dá)習(xí)慣沒有關(guān)系，平時溝通若無歧義則不必刻意深究，在寫PRD時需要注意。

廣義的『界面』指所有能夠完成人機(jī)交流任務(wù)的元素組合，比如一個表單或者一系列按鈕組合。因為這個定義太寬泛，因此很難達(dá)成共識。狹義的『界面』就是指能夠完成一個任務(wù)，并且在感官上位于一個面板的元素組合。比如一個網(wǎng)頁，一個窗體，一個對話框，一個『PoP彈層』，甚至一個網(wǎng)頁（窗體）的不同狀態(tài)都可以視為不同的界面。

——Hozin法師《交互水深 01 | 從區(qū)分 [ 頁面 ] 和 [ 界面 ] 開始吧》

這是一個深奧的話題，點(diǎn)到即止，比如【訂單詳情頁】是一個頁面，【訂單詳情頁>待支付】是一個界面。

在做產(chǎn)品設(shè)計輸出需求文檔時，應(yīng)該以【界面】為單位，這樣可以最大化的細(xì)化用戶任務(wù)顆粒度，充分考慮清楚需求內(nèi)容，方便團(tuán)隊其他成員更清晰的理解需求評估工作量；也更方便復(fù)用和統(tǒng)一形式，降低設(shè)計/開發(fā)成本和用戶學(xué)習(xí)成本。

找到導(dǎo)致差異的最核心的維度，以該維度劃分。

導(dǎo)航

導(dǎo)航對應(yīng)同一功能模塊的不同信息分類，常見于內(nèi)容＆商品分類，在對應(yīng)的列表中，界面標(biāo)題使用分類名稱。其結(jié)構(gòu)本質(zhì)是，功能模塊相同，均為文章列表、界面命名為分類信息。

此時我選擇以功能維度劃分，不同分類對應(yīng)的界面，其實是一個功能模塊。

導(dǎo)航對應(yīng)不同功能模塊

每個導(dǎo)航對應(yīng)不同的界面布局，甚至存在多級導(dǎo)航，其結(jié)構(gòu)本質(zhì)是，在一個頁面中存在多個功能模塊。

此時我選擇以功能模塊劃分，不同導(dǎo)航對應(yīng)的界面，是多個功能模塊。

狀態(tài)

兩種情況殊途同歸，不同狀態(tài)的訂單詳情頁，每個狀態(tài)對應(yīng)不同的字段和操作，根據(jù)狀態(tài)劃分。

訂單列表，同時存在導(dǎo)航＆狀態(tài)，導(dǎo)航又與訂單狀態(tài)有關(guān)，此時選擇最小顆粒度的維度，即訂單狀態(tài)。因為導(dǎo)航中有全部，有時【已取消】＆【已退款】狀態(tài)會歸納到【售后】tab，一些中間態(tài)會被歸納到【進(jìn)行中】tab。

在拆解清楚的基礎(chǔ)上，可以再選擇通過導(dǎo)航tab歸納說明。這是在描述清楚全部狀態(tài)的訂單詳情頁后，再描述訂單列表的導(dǎo)航分類需求。

如訂單詳情的不同狀態(tài)，表單的預(yù)覽＆編輯狀態(tài)，可以在一個Axure頁面中布局，大部分元素是相同的，沒必要反復(fù)說明；同時可以直觀感受不同狀態(tài)間的差異以及流轉(zhuǎn)過程。

功能模塊沒有首頁，默認(rèn)展示其中一個子頁面

線上效果：

第一次點(diǎn)擊一級菜單，展開該模塊二級菜單，頁面無跳轉(zhuǎn)。點(diǎn)擊二級菜單，頁面跳轉(zhuǎn)。

PRD效果：

不需要模擬出線上效果中的第二步，點(diǎn)擊一級菜單，直接跳轉(zhuǎn)至該模塊的第一個子頁面即可。

PRD目錄結(jié)構(gòu)：

如果嚴(yán)格按照頁面層級，可能要展示這樣的效果，把一級菜單融入二級菜單，導(dǎo)致信息辨識度降低。

把一級菜單提出并強(qiáng)調(diào)，導(dǎo)致查看的操作成本增加。

使用如下方式，既確保信息辨識度又不會增加操作成本。

b. 邏輯權(quán)重

根據(jù)復(fù)雜程度，選擇文字或流程圖描述。

c. 展示權(quán)重

• 黑白灰+主題色+強(qiáng)調(diào)色；
• 字體類型（粗細(xì)）+字號。

d. Mockup

在某些場景下，基于各種原因，要把頁面元素在一屏內(nèi)展示完全，可以利用Mockup輔助布局，同時直觀強(qiáng)調(diào)給其他人。還有一些長頁面，產(chǎn)品和UI在繪制的時候都習(xí)慣將菜單欄/底部工具欄放在最下面。如有必要，可以通過Mockup+動態(tài)面板更好的模擬用戶視角的實際效果。

一些沉浸式體驗的設(shè)計，也可以用此方式更清晰的說明觸發(fā)條件（頁面滑動多少區(qū)域，導(dǎo)航欄/菜單欄/工具欄隱藏）。

e. 簡潔準(zhǔn)確的文字描述

簡潔準(zhǔn)確是相對的概念，除了考慮團(tuán)隊成員的認(rèn)知程度以外，也要嘗試建立標(biāo)準(zhǔn)推動普及。

f. 圖文并茂

層級關(guān)系、交互邏輯、狀態(tài)樣式等，都可以通過圖文更清晰的描述，減少只有文字的情況，這符合人類的本性。

為什么中國人喜歡紋英文，外國人喜歡紋漢字。因為對非母語的感知更接近圖案而不是文字，人天生喜歡圖案勝過文字。

g. 注意名詞使用

• 組件＆控件
• 頁面＆界面

h. 注意錯別字

• 登錄＆登陸
• 帳號＆賬號

（3）布局結(jié)構(gòu)

a. 圖文布局

頁面元素與注釋對應(yīng)清晰，最好在元素邊上就是注釋，可通過標(biāo)注點(diǎn)建立目錄/表格或連線使對應(yīng)關(guān)系更好理解。不要為了頁面簡潔把注釋隱藏起來，需要再點(diǎn)擊一次才能查看。

b. 文字排版

避免大段文字，多分行。通過字體類型（粗細(xì)）和字號區(qū)分出信息層級和描述重點(diǎn)。

4. 形成風(fēng)格

為你的PRD注入靈魂，從照著寫誰都能寫出來的內(nèi)容，到寫出只有你能寫出來的內(nèi)容。

（1）一次性搞定命名＆文案

搞定的意思包含對靜態(tài)數(shù)據(jù)的文案決策＆動態(tài)數(shù)據(jù)的規(guī)則決策。

a. 界面命名

顆粒度到界面，用戶分群，要分別站在PRD用戶和產(chǎn)品用戶的視角傳達(dá)信息。

b. 動作命名（按鈕文案）

如果命名比較通俗易懂，如【購買】和【立即購買】不會出現(xiàn)歧義，可以不做區(qū)分。

如果命名比較有特點(diǎn)，需要額外說明。如K12的產(chǎn)品啟動頁按鈕叫【開始學(xué)習(xí)】，沒人能篤定的確認(rèn)【開始學(xué)習(xí)】是跳轉(zhuǎn)到首頁還是其他流程的快捷方式。

c. 導(dǎo)航文案

根據(jù)業(yè)務(wù)的不同特性，對文案的專業(yè)性、調(diào)性的要求程度不同，文案和對業(yè)務(wù)的理解與產(chǎn)品設(shè)計思路關(guān)聯(lián)緊密，如藥品分類。

d. 引導(dǎo)/提示文案

在傳達(dá)清晰的基礎(chǔ)上貼合業(yè)務(wù)特性、產(chǎn)品定位、用戶群體。

（2）結(jié)果導(dǎo)向，不拘泥于形式

如在頁面元素中的標(biāo)注方式：真實數(shù)據(jù)+數(shù)據(jù)來源+展示規(guī)則.

用真實數(shù)據(jù)做示例，預(yù)覽真實用戶視角，規(guī)則與效果直觀建立關(guān)聯(lián)。降低理解門檻，有助于在文字描述之外補(bǔ)全細(xì)節(jié)。

5. 多學(xué)多看多想

世界線收束，著重推薦一下交互類書籍。

（1）Hozin法師的交互書單

【模式篇】

1. 金字塔原理思考、表達(dá)和解決問題的邏輯
2. 網(wǎng)站交互設(shè)計模式
3. 界面設(shè)計模式_第2版
4. 網(wǎng)站設(shè)計解構(gòu) 有效的交互設(shè)計框架和模式
5. 勝于言傳：網(wǎng)站內(nèi)容制勝寶典
6. Web表單設(shè)計 創(chuàng)建高可用性的網(wǎng)頁表單
7. 社交網(wǎng)站界面設(shè)計
8. 搜索模式
9. 標(biāo)簽 標(biāo)記系統(tǒng)設(shè)計實踐
10. Web信息架構(gòu)：設(shè)計大型網(wǎng)站
11. 移動應(yīng)用UI設(shè)計模式 第2版

【設(shè)計原則篇】

1. 簡單法則
2. 通用設(shè)計法則
3. 秩序之美 網(wǎng)頁中的網(wǎng)格設(shè)計
4. 認(rèn)知心理學(xué) （第7版）
5. 贏在用戶：WEB人物角色創(chuàng)建和應(yīng)用實踐指南
6. 圖解力跟頂級設(shè)計師學(xué)作信息圖
7. 信息可視化 交互設(shè)計
8. 微交互 細(xì)節(jié)設(shè)計成就卓越產(chǎn)品
9. Landing Page優(yōu)化權(quán)威指南
10. 設(shè)計敗道 來自著名用戶體驗案例的教訓(xùn)

【流程方法篇】

1. 用戶體驗與可用性測試
2. COMMUNICATING DESIGN
3. UCD火花集
4. 絕密原型檔案 看看專業(yè)產(chǎn)品經(jīng)理的原型是什么樣
5. UX權(quán)威指南
6. 精益設(shè)計 設(shè)計團(tuán)隊如何改善用戶體驗
7. 重塑用戶體驗 卓越設(shè)計實踐指南
8. 交互設(shè)計：設(shè)計思維與實踐
9. DESIGN FOR THE FUTURE METRO 風(fēng)格解讀及設(shè)計指導(dǎo)
10. 和諧界面：交互設(shè)計基礎(chǔ)
11. 用戶體驗面面觀：方法、工具與實踐

這里一并貼出法師的看書建議：

1. 推薦書籍，都是必看必讀必學(xué)已經(jīng)幫助大家排除了很多不靠譜的資料，請精讀；
2. 一定要按照推薦順序閱讀學(xué)習(xí)，初中數(shù)學(xué)尚未畢業(yè)，讀起《微積分》必定一臉茫然；
3. 不必寫讀書筆記，如果沒有獨(dú)特觀點(diǎn)，請不要寫出來，鸚鵡學(xué)舌，見過太多。

（2）看原型的網(wǎng)站

• 人人都是產(chǎn)品經(jīng)理
• AxureCn>原型案例
• AxureUX>付費(fèi)作品＆免費(fèi)作品
• xiaopiu>精選廣場
• 墨刀>討論區(qū)>原型分享
• 產(chǎn)品大牛>廣場

 

本文由 @紫原新之助 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議