需求文檔作為整個項目中最重要的內(nèi)容，直接影響整個項目開發(fā)的質量。產(chǎn)品經(jīng)理的重點在需求文檔的功能邏輯、取值邏輯、交互邏輯等描述上，還有就是關注PRD的可讀性。PRD是你給到團隊中的最重要的文檔，團隊成員都看著PRD來干活。能夠準確、快速、清晰的表達出PRD內(nèi)容，也有很多注意點。

一、使用合適的需求文檔類型

1. Word文檔

通過Word進行需求描述，對外提供 Word 或PDF 格式。

容易留存，也比較正規(guī)，在閱讀上以文字為主。

文檔中包含了文字+原型圖，使用「原型圖片+文檔內(nèi)文字說明」的方式進行描述。

對于沒有原型的需求文檔。

比如接口需求，偏后端邏輯的需求。

只需要通過文檔進行描述即可，直接使用word就行。

2. 原型一體化需求文檔

在原型里將需求文檔中各個內(nèi)容全部包含，然后將原型通過在線鏈接、或者是打包成html 提供出去。

在畫原型的時候，同步寫上功能描述。

具體選擇哪種類型？

——首先看公司要求。

像我之前有公司要求，必須用word，就算是有大量原型的，也只能把頁面原型畫好，然后再復制到word里，在word寫需求內(nèi)容。

如果公司 / 團隊沒有要求，具體采用的方式可以看不同的需求類型：

如果涉及到畫原型，且原型頁面較多的：

——建議使用Axure原型一體化需求文檔。

如果只有偏后端需求的，邏輯相關的需求。

比如說是接口需求、算法需求，并不涉及到前端需求的。

—— 建議直接使用 word 寫。

如果是做的大項目，同時有功能需求，又有接口需求、算法需求的。

—— 建議都在原型中寫需求，使用Axure原型一體化需求文檔

我之前做新項目時，Axure文檔用于描述功能，然后提供了word文檔，重點說接口邏輯。

后來用例評審的時候，測試說不知道word版接口需求，之后我就統(tǒng)一寫在Axure里了。

在這篇文章里，我們重點說下「原型一體化需求文檔」中的注意點。

目的很簡單：提高易讀性，提高信息傳達效率。

二、頁面文件夾層級劃分合理

在Axure中可以添加頁面文件夾與頁面（page），一個合理的頁面劃分可以很大的提高可讀性。

以下 Axure 中的頁面稱為Page，為避免與原型的頁面造成誤解。

我覺得不錯的劃分方法有：

1. 按照菜單層級劃分

如下圖，這是一個后臺的需求文檔，我們可以將一級菜單劃分成文件夾、將二級菜單作為page。

文件夾名稱、Page名稱都使用菜單名稱。

2. 按照功能點大小劃分

當功能點的頁面太大時，我們可以新增一個Page進行說明。

如下圖，「機構管理」是個表格，有「新增」與「編輯」兩個功能。

點擊「新增」時，會彈出一個彈窗，但是彈窗里的內(nèi)容太多，在「機構管理」中添加描述時，內(nèi)容會很多。

所以就可以再建一個Page，單獨對「新增」「編輯」進行說明。

在「機構管理」寫到「新增機構」這個功能時，則引導去另外一個頁面進行查看具體說明。

如下圖：

但是并不是要每個功能點都新建Page。

當一個頁面中的功能描述太多、某個功能點的描述有很多時，這時可以單獨建一個Page進行說明。

目的是劃分出多個Axure Page，避免一個頁面中內(nèi)容過多，影響閱讀。

3. 按照Tab頁、步驟條中每個頁面劃分

比如使用了步驟條組件，我們可以把步驟條的每一步對應新建出一個Page，對每一步單獨進行說明。

對于Tab頁也是，把每個Tab頁都新建對應的Page。

二、原型與描述的排版

我們先從原型與功能描述的布局看，我了解到的有3種，推薦的是第1種：

1. 左圖右文（推薦）

示例圖如下：

這種布局方式是我最建議的方式。

左邊放原型，右邊放描述內(nèi)容。

通過編號進行左右對應，可以快速找到對應的說明。

在一屏內(nèi)容中可以顯示出原型與描述，且功能點位置與功能描述的位置有映射關系。

功能點從上到下編號，功能點描述從上到下依次描述，可很容易找到對應位置。

這種布局也會有一個問題，就是當右側功能描述內(nèi)容太多時，功能點與功能描述的位置會離得比較遠。

極端例子：第1個編號的功能點寫了很多，超過了一屏，然后在寫之后的功能描述時，需要滑動頁面。在看的時候也是，再查看第2點之后的描述時需要不停的上下滑動頁面，來找到原型與描述。

2. 上圖下文

示例：

在上邊放原型圖，下邊放描述。在很多交互稿中會使用這種方式。

不過這種方式有個最明顯的問題：

功能點與描述內(nèi)容離的太遠，眼睛需要上下移動去查看。

如果在一屏內(nèi)能顯示出全部內(nèi)容，還會好點。當高度超過一屏后，則需要進行上下滑動頁面去查看，很費勁。

3. 左右布局

如下圖：

原型在中間，左右放描述。

這種視覺流很亂，根據(jù)編號來回找。

這種對于PC端大尺寸頁面更不適用，需要來回左右滑動。

三、功能序號標注

先畫出原型圖，在原型中標注「序號」，然后在右側按照相同的序號進行功能需求描述。

這是一種很方便的方式。

1）標注順序：一般按照從左到右，從上到下的順序。

2）標注哪些點：需要進行功能說明的功能點，但是并不意味著每一個點都要進行標注。

一般按照從大到小，按照模塊化的方式進行序號標注。

以下方的表單頁面為例：

當原型畫出后，在頁面上標個序號 「 1 」，對頁面進行下簡介。

一般說明頁面是什么，使用角色是誰、權限是什么等等，對整個頁面進行說明。

然后繼續(xù)標注「返回」，對「返回」進行說明。

然后接著對下方的「患者信息」進行標注。

可以看到「患者信息」里有很多字段，我不建議對每個字段進行說明。

可以直接對「患者信息」整個模塊進行標注，然后對每個字段進行說明。

（現(xiàn)在看其實上邊的需求描述還是不全，比如漏了小數(shù)點位數(shù)說明，文本輸入框內(nèi)能不能輸入表情emoji符號等等）

當頁面內(nèi)出現(xiàn)彈窗時，在右邊展示出彈窗原型，接著對彈窗里的內(nèi)容進行說明。

單獨對彈窗里功能點進行標注，然后在下方繼續(xù)對需求進行說明。

對于彈窗里的內(nèi)容，我一般從「1」開始重新編號，不把彈窗里的序號和其他頁面夾雜在一起。

當存在功能點遺漏，或者要添加新的功能點說明時，這時候會涉及到功能點標注序號的修改。

比如一個頁面中的序號標注 1 – 10，這時發(fā)現(xiàn)中間少了個標注。

可以采用新增一個 「11 」，然后對「11 」再進行說明，不用嚴格按照順序標注的方式。

四、利用連接線

使用連接線連接功能點與功能描述。比如下邊的例子。

我不建議這種方式，首先我們已經(jīng)有了序號，可以找到對應關系。

另外使用連接線，會產(chǎn)生多余的工作量，需要去調整線條，不讓線條遮擋內(nèi)容……

我認為是沒有必要使用連接線連接功能點與描述。

不過使用連接線來連接頁面，這種方式很好。

但是只針對移動端頁面，PC端并不適用。

看個例子：

在下邊的頁面中，我將全部頁面平鋪在了一個Page里。

當涉及到頁面跳轉、彈出層時，可以使用連接線，連接功能點與頁面，用于表達頁面流程。

在使用連接線時要注意，不要讓連接線遮擋內(nèi)容，連接線也不要交叉。

五、功能描述注意點

功能描述是需求文檔中很重要的部分，對于功能描述有幾點我們可以注意：

1. 重點內(nèi)容重點突出

可以使用一個突出的顏色，比如標紅、標黃。

功能描述很多時，看的人很容易忽略。

因為大家看文字都是掃過去，不會每個字每個字的去看。

我吃過這個虧，有次驗收的時候返現(xiàn)最重要的功能沒實現(xiàn)，研發(fā)測試說沒看到，我一看需求文檔上寫了，然后研發(fā)加班搞得。

無論寫什么文檔，重點內(nèi)容都要重點突出。

2. 有必要添加示例

文字說明都會有一定的片面理解。

對于比較復雜的內(nèi)容我們可以添加示例說明：

3. 采用多分段，多分行，加序號的方式

當文字較多時，分行分段是很有用的方式。

添加序號也能更易閱讀。

4. 用好標點符號

如：點擊「確認」按鈕，跳轉至【XXX頁面】。

將特殊的名稱、動作通過符號框住，可以更清晰的表達。

5. 結合Axure的特性，添加文字鏈接

當需要閱讀者進入另一個Page查看時，可以通過「添加文字鏈接」交互，點擊文字鏈接快速進入對應Page。

6. 內(nèi)容變更時保留記錄

當描述需要修改時，可以保留原內(nèi)容，然后添加刪除線，并寫上修改后的內(nèi)容，寫上修改時間。

如果你直接刪除，接著寫修改后的內(nèi)容，你可能會忘了改之前的邏輯。

7. 對于變量值，使用特殊符號標記下

對于會變化的值，我一般使用用兩個百分號。

如下方的「科室名稱」，會根據(jù)不同的選擇展示不同的名稱，所以我就通過‘%科室名稱%’進行表示，然后單獨說明，并舉例說明。

8. 用表格描述也挺好

除了使用文字，功能描述時還可以使用表格的方式。

比如表單頁字段說明，當內(nèi)容很多時，可以直接使用表格進行說明。

9. 寫上頁面名稱、功能點名稱

對于每個頁面、每個功能點，可以單獨展示出名稱，這樣便于找到頁面。

如果頁面重要，也可以說明下頁面是什么，干什么的。

六、不建議使用的方式

1. 不要嵌套mockup

這種很不建議，只能展示出首屏內(nèi)容，當頁面多長時，還要添加上下滑動，手機殼也沒有任何用。

在純演示交互時沒問題，但是在PRD中，不要用。

2. 盡量不要把 功能序號 和 動效 混在一塊

舉個例子：

比如：畫原型使用動態(tài)面板，做了個切換Tab的動效。

并且在動態(tài)面板里的每個State（面板頁面）里的原型上添加了序號標注。

想把動效和功能描述都展示出來。

如果你這樣做，你需要在面板頁面里標上序號，再退出動態(tài)面板，然后再繼續(xù)寫功能描述。

這樣非常費時間，而且這個時間很沒有必要，不要多給自己找事。

操作的越多，出錯的概率就越大。

可以直接把Tab頁的每個頁面平鋪出來，直接進行標注序號、功能描述即可。

不要迷戀動態(tài)交互。

3. 不要使用看起來很炫酷的Axure需求文檔模板

對于需求文檔，只要你說明白，讓看的人能看明白，你能最快的完成需求文檔輸出就行了。

有些原型需求文檔模板，提供了很多動態(tài)交互，可以在模板里寫很多內(nèi)容。

這個也沒有意義，你寫內(nèi)容的時候很費事，看的人也麻煩。

就直接規(guī)規(guī)矩矩的使用Axure文件夾、Page放不同的內(nèi)容就可以了。

七、總結

我們從原型一體化需求文檔中包含的內(nèi)容做了說明，來提供PRD的易讀性。

還有其它點：

把Page底色設置成護眼的顏色、調整功能描述文字的字間距、行間距等。

還有文字顏色，我一直使用的Antdesign組件庫中的刺眼玫紅，我也想打算改個柔和的顏色。

產(chǎn)品經(jīng)理要考慮用戶體驗，需求文檔是產(chǎn)品經(jīng)理輸出的最核心的產(chǎn)品，所以這個產(chǎn)品的用戶體驗我們也要好好優(yōu)化。