如何寫出詳細且易于閱讀的PRD?
PRD對于產(chǎn)品人員而言,就像開發(fā)文檔對于開發(fā)人員、測試用例之于測試人員。但PRD又有些不一樣,產(chǎn)品的PRD需要給業(yè)務(wù)人員、內(nèi)部產(chǎn)品人員、開發(fā)人員、測試人員閱讀。所以PRD不僅要詳細,同時還要對開發(fā)、測試等非產(chǎn)品崗的人員友好,讓他們便于閱讀。
相信很多剛走上工作崗位或者想要從事產(chǎn)品工作的產(chǎn)品新人做的第一件事就是上網(wǎng)搜索“什么事PRD”或者“如何寫好PRD”。當(dāng)我開始學(xué)習(xí)寫PRD的時候,我也在網(wǎng)上找優(yōu)秀的案例,搜出來的優(yōu)秀PRD案例大多模塊豐富,介紹詳細。
看著產(chǎn)品用戶角色描述、產(chǎn)品總體架構(gòu)、業(yè)務(wù)流程圖、產(chǎn)品功能需求等模塊,剛覺得似懂非懂,又發(fā)現(xiàn)每一個小東西下面又有很多分類。例如:流程圖還分為業(yè)務(wù)流程圖、任務(wù)流程圖和頁面流程圖。產(chǎn)品功能需求還分為產(chǎn)品性能需求、測試環(huán)境需求、安全性需求等等。
如果產(chǎn)品新人接到原型任務(wù)時,想要按照這些格式,摩拳擦掌地寫PRD,你會發(fā)現(xiàn),如果真有按照模板來寫,PRD的內(nèi)容少有10來頁,多的有幾十上百頁。這樣的PRD作為文檔留存固然詳細,但是當(dāng)項目時間緊任務(wù)重、或者小功能需要快速迭代的時候,開發(fā)、測試沒有時間也沒有耐心去看這樣一個詳細的文檔。他們只會認真看原型和批注的部分。當(dāng)然認不認真可能還另當(dāng)別論。
對于產(chǎn)品人員來說,我們的期望開發(fā)能夠認真閱讀PRD的原型、批注部分,了解頁面和邏輯,開發(fā)出來的產(chǎn)品能夠達到我們預(yù)想的效果;同時期望測試在了解PRD原型和邏輯的基礎(chǔ)上能夠了解功能的變化,是全新的功能還是復(fù)用以前的邏輯,順利進行測試。
此外,產(chǎn)品把PRD寫的詳細且易于閱讀,有一個非常直觀的好處:在項目進行時,開發(fā)、測試來找你詢問的次數(shù)越少,在開發(fā)的過程中,PRD在后期的改動越少,整個項目進行的會更順利。
如果PRD沒有寫詳細,在項目開發(fā)的時候,不斷地會有開發(fā)和測試來找你確認問題,問題越來越多,修改PRD的概率也會越大。在項目的過程中修改PRD,很容易“牽一發(fā)而動全身”。開發(fā)可能要重新梳理邏輯,測試也需要修改用例。
所以產(chǎn)品人員在寫PRD時,要記住兩個要點:
- 盡可能寫詳細 ;
- 易于開發(fā)、測試人員閱讀
批注要事無巨細
很多產(chǎn)品一開始在寫批注時很容易想當(dāng)然,覺得這個功能的邏輯這么明顯,開發(fā)測試人員肯定知道。這個業(yè)務(wù)這么清楚,開發(fā)測試人員肯定會比我清楚的。這個按鈕這么通用,開發(fā)測試人員肯定一看就知道是干嘛的;這個邏輯在前面的頁面已經(jīng)寫過了,可以不用再贅述了…..
這是因為產(chǎn)品人員陷入了一個誤區(qū):以產(chǎn)品的角度來看這份PRD。你是產(chǎn)品,你構(gòu)想出來的方案,你當(dāng)然是熟悉業(yè)務(wù)和功能的,也知道上下頁面邏輯的關(guān)聯(lián)。所以在寫PRD的時候,會覺得很多東西都是顯而易見的。
但是開發(fā)、測試人員沒有參與用戶的調(diào)研和需求的討論,也沒有參與方案的產(chǎn)出。所以他們不知道新增的業(yè)務(wù)流程和功能按鈕的用處。而且有可能你設(shè)計的頁面是分別有幾個開發(fā)來開發(fā)的,頁面1和頁面2的某個邏輯相同,你在頁面1寫了邏輯,但是頁面2是由別的開發(fā)負責(zé)的。
所以不能想當(dāng)然,而是應(yīng)該把每一個頁面的邏輯都當(dāng)成獨立的頁面,將這個頁面存在的邏輯和細節(jié)都清晰地羅列出來。
對于把PRD寫詳細這一點,我總結(jié)出一個重點“用測試思維寫PRD”。
這個觀點是我從測試用例和測試工作上反推出來的。測試人員在寫測試用例的時候,會對PRD進行非常詳細的解構(gòu)。大到業(yè)務(wù)的邏輯,小到一個按鈕的各種特殊情況,都是他們需要進行測試的。產(chǎn)品可以借鑒這個思維來寫PRD。
1. 閱讀測試用例
新手產(chǎn)品可以向測試要一份測試用例,仔細研讀??纯礈y試用例中的分析。這樣在寫PRD的時候,也能夠大概清楚測試會關(guān)注哪些細節(jié)。你寫的PRD也就越對測試的胃口。到時候測試找你確認的問題越少。
如果拿到了測試用例,可以先關(guān)注一下“測試前提”,這可以和批注中的前置條件進行對應(yīng)。而“驗證場景”是測試對頁面的樣式、內(nèi)容的展示、功能的檢查、校驗。而“預(yù)期”則是批注里產(chǎn)品想要實現(xiàn)的效果,這部分也是產(chǎn)品應(yīng)該在批注里詳細描述的內(nèi)容。
2. 寫批注的時候,考慮到各種情況
寫PRD的時候,如果對上下游業(yè)務(wù)不是特別熟悉,很容易會遺漏細節(jié)。所以在寫PRD時,要沉下心來,多問問自己:如果出現(xiàn)XX情況那怎么辦呢?
例如我們現(xiàn)在每天都要用的掃碼支付的功能,可能現(xiàn)在看來就是掏出手機,對著二維碼掃個碼。但是需要考慮很多特殊情況。例如:如果用戶手機沒有網(wǎng)絡(luò)或者網(wǎng)絡(luò)不好的情況下,怎么顯示;二維碼不是收款碼掃碼后怎么顯示;如果支付寶掃了微信的收款碼應(yīng)該怎么顯示;用戶默認的支付賬戶是哪個;如果用戶默認賬戶里的余額不足怎么提示……
一些功能可能看起來簡單,但其實里面會有復(fù)雜邏輯,所以產(chǎn)品在確定了主要方案后,需要多思考一些特殊情況,然后在PRD里進行備注。這樣不至于測試來問你的時候,你措手不及,發(fā)現(xiàn)自己的方案有很多漏洞。
3. 思考內(nèi)容“從哪兒來,到哪兒去”
這種情況大多出現(xiàn)在B端產(chǎn)品的移動端設(shè)計中,需要考慮兩端信息的對應(yīng)性。在設(shè)計移動端時,一些展示的內(nèi)容,很有可能是從系統(tǒng)中調(diào)用過來的。所以在寫批注是,要備注清楚這個字段是調(diào)用的當(dāng)前系統(tǒng)的哪個模塊的哪個字段。
而在移動端提交的內(nèi)容,則要考慮這個東西到哪里去。也要備注清楚這個內(nèi)容填完后生成的記錄會展示在當(dāng)前系統(tǒng)的哪個模塊哪張報表。
PRD要易于閱讀
PRD除了在內(nèi)容上要符合閱讀者的預(yù)期,在樣式上也要做到頁面整齊,便于閱讀。
1. 流程圖和用例
在PRD中提供流程圖和用例,能夠幫助開發(fā)、測試人員盡快地熟悉業(yè)務(wù)流程、用戶角色和核心功能。
process on上的流程圖案例
process on上的用例圖案例除了流程圖和用例,如果時間允許,還需要提供功能列表。這樣的話,在熟悉大致業(yè)務(wù)和核心功能基礎(chǔ)上,開發(fā)和測試還能進一步了解詳細功能。測試用例在往期的文章里提過,看這里產(chǎn)品新人第一次負責(zé)項目應(yīng)該怎么做?
2. 言簡意賅、語言規(guī)范
在寫PRD的批注時,盡量語言規(guī)范,避免口語化。簡潔明了的描述能夠給讀者一個好的閱讀體驗。尤其是項目頁面較多的時候,復(fù)雜的頁面,再加上口語化、冗余的文字描述,開發(fā)、測試人員閱讀起來會比較費勁。
在PRD里,可以用多種形式來進行表達。例如:遇到一些比較復(fù)雜的功能,涉及到狀態(tài)變化,描述起來文字較多,難以理解。這個時候就很適合用一張把表格來展示狀態(tài)的變化。
3. 頁面展示具有強關(guān)聯(lián)性
由于頁面之間可能會存在交互的聯(lián)系,所以頁面擺放時,最好是根據(jù)順序進行擺放。這樣的話,開發(fā)和測試也能更好地理解頁面與頁面之間的關(guān)系。同時,批注也最好也頁面緊挨在一起。這樣的話,在看的時候,能夠同時看到原型和備注。
所以從PRD展示角度來看,墨刀會是比較友好的工具。使用墨刀的話,原型和批注可以展示在同一個頁面。而使用Axure,如果畫的是大幅的網(wǎng)頁頁面,在預(yù)覽狀態(tài)的時,無法同時看到原型和批注。這樣的話,閱讀體驗就不是很好。很容易發(fā)生開發(fā)嫌麻煩只看原型、或者甚至找不到批注的的情況。
總結(jié)
如果沒有經(jīng)歷過幾次項目,一開始寫出來的PRD,會比較簡單。開發(fā)、測試會輪番地來向你確認問題。在這個過程,會懊悔自己有很多細節(jié)在一開始沒有想清楚。當(dāng)然會有優(yōu)秀的人能夠一開始就思考得特別詳細。那我們這些不夠優(yōu)秀的人,要在一次一次的項目中總結(jié)問題,不斷改進。同時要和團隊的開發(fā)、測試不斷磨合,綜合考慮他們的想法。
最好的PRD永遠會是下一份PRD。當(dāng)然不想寫出完美的PRD的產(chǎn)品不是好產(chǎn)品。
#專欄作家#
異彩,微信公眾號:一只蝸牛慢慢跑,人人都是產(chǎn)品經(jīng)理專欄作家。從事房產(chǎn)管理系統(tǒng)的產(chǎn)品工作,關(guān)注To C產(chǎn)品的交互設(shè)計、運營、結(jié)構(gòu)設(shè)計和商業(yè)模式。在成為一名優(yōu)秀的產(chǎn)品人的路上努力前行。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Unsplash,基于CC0協(xié)議。
感覺每一句都是在說我 句句扎心
啊~我們打算加一個頁面,周一上線(今天是周五)!
老板說:時間還是很充足的嘛。產(chǎn)品周五通個宵把方案做出來。開發(fā)周末加班通宵做出來,測試周末晚上通個宵測試,周一就順利上線啦。
加個頁面,簡單
還是要看看增加的頁面里面的項目復(fù)雜度 ??
原型圖加清晰的注釋,把技術(shù)聚在一起,口述一遍,完事。
小公司,當(dāng)真沒人看這玩意。直接問來的比較快
真實
真實
現(xiàn)在流行敏捷