起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識16種簡單方法讓需求文檔更清晰更專業
需求文檔作為整個項目中最重要的內容，直接影響整個項目開發的質量。產品經理的重點在需求文檔的功能邏輯、取值邏輯、交互邏輯等描述上，還有就是關注PRD的可讀性。PRD是你給到團隊中的最重要的文檔，團隊成員都看著PRD來干活。能夠準確、快速、清晰的表達出PRD內容，也有很多注意點。
一、使用合適的需求文檔類型
1. Word文檔
通過Word進行需求描述，對外提供 Word 或PDF 格式。
容易留存，也比較正規，在閱讀上以文字為主。
文檔中包含了文字+原型圖，使用「原型圖片+文檔內文字說明」的方式進行描述。
對于沒有原型的需求文檔。
比如接口需求，偏后端邏輯的需求。
只需要通過文檔進行描述即可，直接使用word就行。
2. 原型一體化需求文檔
在原型里將需求文檔中各個內容全部包含，然后將原型通過在線鏈接、或者是打包成html 提供出去。
在畫原型的時候，同步寫上功能描述。
具體選擇哪種類型？
——首先看公司要求。
像我之前有公司要求，必須用word，就算是有大量原型的，也只能把頁面原型畫好，然后再復制到word里，在word寫需求內容。
如果公司 / 團隊沒有要求，具體采用的方式可以看不同的需求類型：
如果涉及到畫原型，且原型頁面較多的：
——建議使用Axure原型一體化需求文檔。
如果只有偏后端需求的，邏輯相關的需求。
比如說是接口需求、算法需求，并不涉及到前端需求的。
—— 建議直接使用 word 寫。
如果是做的大項目，同時有功能需求，又有接口需求、算法需求的。
—— 建議都在原型中寫需求，使用Axure原型一體化需求文檔
我之前做新項目時，Axure文檔用于描述功能，然后提供了word文檔，重點說接口邏輯。
后來用例評審的時候，測試說不知道word版接口需求，之后我就統一寫在Axure里了。
在這篇文章里，我們重點說下「原型一體化需求文檔」中的注意點。
目的很簡單：提高易讀性，提高信息傳達效率。
二、頁面文件夾層級劃分合理
在Axure中可以添加頁面文件夾與頁面（page），一個合理的頁面劃分可以很大的提高可讀性。
以下 Axure 中的頁面稱為Page，為避免與原型的頁面造成誤解。
我覺得不錯的劃分方法有：
1. 按照菜單層級劃分
如下圖，這是一個后臺的需求文檔，我們可以將一級菜單劃分成文件夾、將二級菜單作為page。
文件夾名稱、Page名稱都使用菜單名稱。
2. 按照功能點大小劃分
當功能點的頁面太大時，我們可以新增一個Page進行說明。
如下圖，「機構管理」是個表格，有「新增」與「編輯」兩個功能。
點擊「新增」時，會彈出一個彈窗，但是彈窗里的內容太多，在「機構管理」中添加描述時，內容會很多。
所以就可以再建一個Page，單獨對「新增」「編輯」進行說明。
在「機構管理」寫到「新增機構」這個功能時，則引導去另外一個頁面進行查看具體說明。
如下圖：
但是并不是要每個功能點都新建Page。
當一個頁面中的功能描述太多、某個功能點的描述有很多時，這時可以單獨建一個Page進行說明。
目的是劃分出多個Axure Page，避免一個頁面中內容過多，影響閱讀。
3. 按照Tab頁、步驟條中每個頁面劃分
比如使用了步驟條組件，我們可以把步驟條的每一步對應新建出一個Page，對每一步單獨進行說明。
對于Tab頁也是，把每個Tab頁都新建對應的Page。
二、原型與描述的排版
我們先從原型與功能描述的布局看，我了解到的有3種，推薦的是第1種：
1. 左圖右文（推薦）
示例圖如下：
這種布局方式是我最建議的方式。
左邊放原型，右邊放描述內容。
通過編號進行左右對應，可以快速找到對應的說明。
在一屏內容中可以顯示出原型與描述，且功能點位置與功能描述的位置有映射關系。
功能點從上到下編號，功能點描述從上到下依次描述，可很容易找到對應位置。
這種布局也會有一個問題，就是當右側功能描述內容太多時，功能點與功能描述的位置會離得比較遠。
極端例子：第1個編號的功能點寫了很多，超過了一屏，然后在寫之后的功能描述時，需要滑動頁面。在看的時候也是，再查看第2點之后的描述時需要不停的上下滑動頁面，來找到原型與描述。
2. 上圖下文
示例：
在上邊放原型圖，下邊放描述。在很多交互稿中會使用這種方式。
不過這種方式有個最明顯的問題：
功能點與描述內容離的太遠，眼睛需要上下移動去查看。
如果在一屏內能顯示出全部內容，還會好點。當高度超過一屏后，則需要進行上下滑動頁面去查看，很費勁。
3. 左右布局
如下圖：
原型在中間，左右放描述。
這種視覺流很亂，根據編號來回找。
這種對于PC端大尺寸頁面更不適用，需要來回左右滑動。
三、功能序號標注
先畫出原型圖，在原型中標注「序號」，然后在右側按照相同的序號進行功能需求描述。
這是一種很方便的方式。
1）標注順序：一般按照從左到右，從上到下的順序。
2）標注哪些點：需要進行功能說明的功能點，但是并不意味著每一個點都要進行標注。
一般按照從大到小，按照模塊化的方式進行序號標注。
以下方的表單頁面為例：
當原型畫出后，在頁面上標個序號 「 1 」，對頁面進行下簡介。
一般說明頁面是什么，使用角色是誰、權限是什么等等，對整個頁面進行說明。
然后繼續標注「返回」，對「返回」進行說明。
然后接著對下方的「患者信息」進行標注。
可以看到「患者信息」里有很多字段，我不建議對每個字段進行說明。
可以直接對「患者信息」整個模塊進行標注，然后對每個字段進行說明。
（現在看其實上邊的需求描述還是不全，比如漏了小數點位數說明，文本輸入框內能不能輸入表情emoji符號等等）
當頁面內出現彈窗時，在右邊展示出彈窗原型，接著對彈窗里的內容進行說明。
單獨對彈窗里功能點進行標注，然后在下方繼續對需求進行說明。
對于彈窗里的內容，我一般從「1」開始重新編號，不把彈窗里的序號和其他頁面夾雜在一起。
當存在功能點遺漏，或者要添加新的功能點說明時，這時候會涉及到功能點標注序號的修改。
比如一個頁面中的序號標注 1 – 10，這時發現中間少了個標注。
可以采用新增一個 「11 」，然后對「11 」再進行說明，不用嚴格按照順序標注的方式。
四、利用連接線
使用連接線連接功能點與功能描述。比如下邊的例子。
我不建議這種方式，首先我們已經有了序號，可以找到對應關系。
另外使用連接線，會產生多余的工作量，需要去調整線條，不讓線條遮擋內容……
我認為是沒有必要使用連接線連接功能點與描述。
不過使用連接線來連接頁面，這種方式很好。
但是只針對移動端頁面，PC端并不適用。
看個例子：
在下邊的頁面中，我將全部頁面平鋪在了一個Page里。
當涉及到頁面跳轉、彈出層時，可以使用連接線，連接功能點與頁面，用于表達頁面流程。
在使用連接線時要注意，不要讓連接線遮擋內容，連接線也不要交叉。
五、功能描述注意點
功能描述是需求文檔中很重要的部分，對于功能描述有幾點我們可以注意：
1. 重點內容重點突出
可以使用一個突出的顏色，比如標紅、標黃。
功能描述很多時，看的人很容易忽略。
因為大家看文字都是掃過去，不會每個字每個字的去看。
我吃過這個虧，有次驗收的時候返現最重要的功能沒實現，研發測試說沒看到，我一看需求文檔上寫了，然后研發加班搞得。
無論寫什么文檔，重點內容都要重點突出。
2. 有必要添加示例
文字說明都會有一定的片面理解。
對于比較復雜的內容我們可以添加示例說明：
3. 采用多分段，多分行，加序號的方式
當文字較多時，分行分段是很有用的方式。
添加序號也能更易閱讀。
4. 用好標點符號
如：點擊「確認」按鈕，跳轉至【XXX頁面】。
將特殊的名稱、動作通過符號框住，可以更清晰的表達。
5. 結合Axure的特性，添加文字鏈接
當需要閱讀者進入另一個Page查看時，可以通過「添加文字鏈接」交互，點擊文字鏈接快速進入對應Page。
6. 內容變更時保留記錄
當描述需要修改時，可以保留原內容，然后添加刪除線，并寫上修改后的內容，寫上修改時間。
如果你直接刪除，接著寫修改后的內容，你可能會忘了改之前的邏輯。
7. 對于變量值，使用特殊符號標記下
對于會變化的值，我一般使用用兩個百分號。
如下方的「科室名稱」，會根據不同的選擇展示不同的名稱，所以我就通過‘%科室名稱%’進行表示，然后單獨說明，并舉例說明。
8. 用表格描述也挺好
除了使用文字，功能描述時還可以使用表格的方式。
比如表單頁字段說明，當內容很多時，可以直接使用表格進行說明。
9. 寫上頁面名稱、功能點名稱
對于每個頁面、每個功能點，可以單獨展示出名稱，這樣便于找到頁面。
如果頁面重要，也可以說明下頁面是什么，干什么的。
六、不建議使用的方式
1. 不要嵌套mockup
這種很不建議，只能展示出首屏內容，當頁面多長時，還要添加上下滑動，手機殼也沒有任何用。
在純演示交互時沒問題，但是在PRD中，不要用。
2. 盡量不要把 功能序號 和 動效 混在一塊
舉個例子：
比如：畫原型使用動態面板，做了個切換Tab的動效。
并且在動態面板里的每個State（面板頁面）里的原型上添加了序號標注。
想把動效和功能描述都展示出來。
如果你這樣做，你需要在面板頁面里標上序號，再退出動態面板，然后再繼續寫功能描述。
這樣非常費時間，而且這個時間很沒有必要，不要多給自己找事。
操作的越多，出錯的概率就越大。
可以直接把Tab頁的每個頁面平鋪出來，直接進行標注序號、功能描述即可。
不要迷戀動態交互。
3. 不要使用看起來很炫酷的Axure需求文檔模板
對于需求文檔，只要你說明白，讓看的人能看明白，你能最快的完成需求文檔輸出就行了。
有些原型需求文檔模板，提供了很多動態交互，可以在模板里寫很多內容。
這個也沒有意義，你寫內容的時候很費事，看的人也麻煩。
就直接規規矩矩的使用Axure文件夾、Page放不同的內容就可以了。
七、總結
我們從原型一體化需求文檔中包含的內容做了說明，來提供PRD的易讀性。
還有其它點：
把Page底色設置成護眼的顏色、調整功能描述文字的字間距、行間距等。
還有文字顏色，我一直使用的Antdesign組件庫中的刺眼玫紅，我也想打算改個柔和的顏色。
產品經理要考慮用戶體驗，需求文檔是產品經理輸出的最核心的產品，所以這個產品的用戶體驗我們也要好好優化。
本文由人人都是產品經理作者【王大鹿】，微信公眾號：【產品大鹿】，原創/授權 發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
干爹公眾號文件都有rp源文件我愛你
更多產品落地干貨，都在公眾號：產品大鹿
寫的好棒??！
牛啊牛啊 作者大大有沒有推薦組件
都在公眾號：產品大鹿，里邊有
突然發現 去年關注過你