你有沒有過這樣的經歷——辛辛苦苦寫了半天的文檔， 結果開發一眼沒看，做需求的時候又把文檔裡的內容問了一遍？如果你也有這樣的經歷，那麼在APP原型上寫需求，或許能幫你解決這個問題。
為什麼要把需求直接寫在原型上？
- 沒有開發願意看臃雜的需求文檔，包括直接寫在原型上的。
- 便捷高效
- 方便版本迭代
如何在APP原型上寫需求？
首先將APP經常需要寫需求的對象羅列出來，並分析其屬性，精煉出書寫字段模板。直接上圖：
以下是本人認為APP常遇到需要“寫需求的點”：
- 功能的邏輯
- 功能的規則
- 按鈕
- 文本框
- 文本標籤
- 特殊面板
- 版本的迭代
（上圖中並沒有對“面板”的介紹，因為面板寫作方式跟按鈕類似，但面板中的元件比按鈕要複雜，所以本人將其單獨列出）
本人將就以上幾類“對象”如何和諧地寫在原型上做詳細說明。在此之前，需要介紹一下Axure的“說明”功能。
Axure9.0版本說明功能更加豐富、美觀，展示上更加顯眼。它允許我們提前設置好說明字段，我們寫需求的時候可以跟著標籤文案思考，減少漏寫需求。見下圖：
大家可以根據需求添加，這個是我常使用的字段集。
1. 文本框
文本框主要用途是鍵入內容，常用的書寫字段有以下3種：
（1）基本說明
- 字段類型：文本
- 長度規則：11位；超過xx位省略處理
- 是否必填：是
- 校驗規則：為空校驗、有效性校驗
（2）交互說明
- 點擊獲取光標，調取鍵盤、顯示清除圖標；
- 失去光標，收回鍵盤，隱藏清除圖標等
（3）特殊情況
- 獲取光標時調用什麼鍵盤類型、向上推動頁面方便鍵入
- 文本框是否記錄上次使用的號碼
2. 按鈕
本人定義的按鈕——可以點擊的單個對象（複雜的面板可放在面部一欄撰寫）：按鈕、鏈接文字、圖標等。按鈕主要是和用戶產生交互的，若只展示文案，請採用標籤文本撰寫。
按鈕的交互結果會有很多形式，常見的有以下幾種：
- 頁面跳轉
- xx對象被選中
- xx文本改變
- 彈出彈框
- 彈出toast氣泡
- 操作完成發送短信、推送、通知等
故此，按鈕需求書寫，本人總結的書寫需求的字段如下：
- 狀態說明：詳細列舉按鈕可能的變化：按鈕文案、顏色、可點擊性變化等。這裡請不要寫入任何交互需求
- 交互說明：詳細列舉各狀態（未登錄時、非會員用戶等）下，點擊按鈕的交互，以及對應的結果（成功、失敗、跳轉頁面等）。
- 操作提醒：列舉各種操作結果對應的toast提示語
- 特殊說明：對特殊信息、規則進行補充。比如“上文提到的新用戶定義“、”計算公式“等
- 通知：操作完成後如果觸發短信通知、或者推送消息，可在此標籤下數撰寫。該點是產品們常常遺漏的點
3. 文本標籤
文本標籤作用是展示信息。由於用戶身份、狀態的改變或者按鈕交互，會導致標籤的文本改變，有的甚至是樣式的改變。
故此，本人總結的書寫需求字段如下
- 長度規則：字數限制、x行顯示多餘省略等
- 狀態說明：文本標籤在不同條件下可以呈現不同的狀態
- 特殊說明：根據實際情況補充細節，沒有的話則無需註明
4. 面板
關於面板，我們最熟知的就是”動態面板“，本人定義的面板是APP頁面的某一版塊，通常包含很多元素。面板通常是在繪製頁面完成後已經顯現出來——繪製原型的時候已經對各個版塊命名了。常見的面板有兩類：
列表：例如”人人都是產品經理APP“——學院面板裡分類的各個版塊（免費課程、熱門課程）。
功能區：隨著用戶身份、時間段等因素的不同，整塊內容都會發生變化。例如：支付寶——福滿全球。
面板不但可以只是展示使用，還可以作為一個對象，進行各種各樣的交互：點擊、滑動。故此，本人寫作時，把面板與按鈕分出來單獨書寫，開發閱讀起來會更直觀。書寫字段有以下幾種：
- 展示規則：
- 交互說明：
- 操作提醒：
- 特殊說明：
（它跟按鈕的書寫字段類似，跟按鈕區分出來，是因為有時面板的展示規則書寫會比按鈕的複雜；很多時候，我們需要把面板的不同狀態都給畫出來，給開發查看，而按鈕不需要。）
5，如何在一個頁面上展示多個不同的面板？
大家都知道使用Axure的動態面板，但是該怎麼展現出來呢，本人字設計了一個需求撰寫表格，方便應對這種情況：
Axure上的交互動作可以設置多種不同的情形，開發需要查看時，可點擊查看不同的狀態；避免我們在一個頁面複製多個圖片，使文檔變得複雜。
6. 如何便捷地進行版本迭代？
當前版本的需求高亮顯示，往期的需求變化繼續保留，色塊置灰。
7. 功能邏輯和功能規則
功能邏輯很多時候不需要使用到流程圖，功能邏輯多數情況可以通過頁面層級展示出來。功能邏輯非同業務邏輯。本人建議
在規劃功能點的時候一定要畫功能邏輯圖，避免設計功能時有遺漏，在書寫需求的時候，可以根據複雜程度選擇是否展示（一般不需要）。功能邏輯由於跟頁面跳轉掛鉤，請學好Axure基本交互，這個是產品經理的基本要求。本人會再出一期在Axure使用中基礎但是很便捷的技巧合集。
功能規則可在該功能頁面——需求撰寫表格裡分條列述，這些都是規劃功能時需要考慮周全的，在寫需求的時候沒什麼好說的。
需求書寫位置要求
針對上面提到的7個點，請制定自己的書寫習慣：是寫在需求列表上，還是寫在“說明”彈框裡。定下來後，需求評審的時候跟開發介紹查看需求的規則，整個文檔請嚴格按照規則書寫，避免開發一臉懵逼。由於彈框相對於表格比較隱蔽，本人將複雜的“需要寫需求的點”放在表格裡，如下：
- 需求表格裡：面板、按鈕、規則、其他（一次性展示的功能模塊：彈框）
- 說明彈框裡：文本標籤、文本輸入框
其它補充
把需求寫完整和清晰，是每個產品經理的職責，不單單是把需求寫出來了而已。想到哪寫到哪，經常會遺漏，而且維護起來自己都找不到在哪。
1. 建議將自己在項目中經常忘記、被開發吐槽的點列舉出來。
本人的需求表格第一行就是常忘記的點，先把它錄入進去，設置好常用的參數，遇到特殊情況可直接進行修改，沒有特殊情況，可直接按照預設需求進行開發。
2. 將常用的模塊或者交互規則寫在全局說明裡。
比如手機文本框的基本參數和交互、獲取驗證碼按鈕的狀態說明 交互說明 等。
3. 保證大的前提不變的情況下，請根據實際情況調整。
寫作的目的是為了讓需求簡單易懂、美觀，文檔搞得越複雜，開發心情越糟糕，在適當的時間點和合適的位置列出需求說明，可以讓開發同學不那麼煩躁。
這些只是一些個人總結，如果照搬照抄可能會讓你的需求寫起來四不像。
最後，還是希望能幫到你！
本文由 @最多隻能7個字 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
