如何使用 Axure 寫 App 產品需求文件 ( 1 )
或許也可以看做是產品經理血淚史 (？)
先定義用戶使用場景與資訊架構
首先，我以用戶使用場景為核心畫出這張圖，大概反覆改了 3 天左右吧。根據開發資源與（被壓的）上線日期，我將功能分為主要功能及次要的功能。考量到這是一個全新的 App 專案，且開發團隊大都是新進員工，沒有太多公司的背景知識，所以資訊需要寫得詳細點，把頁面裡要呈現的內容細節也寫上。
產出功能地圖
接著，為了在有限的時程內完成上線，讓需求單位理解產品前期階段可能會被捨棄的開發項目，我會把功能地圖畫出來，讓營銷團隊、營運團隊、老闆，可以清楚第一次上架時 App 有什麼功能，這在教育訓練時也很有幫助。若跟另一個平台有差異，建議可以標示出來更好，例如官網有修改密碼功能，App 沒有修改密碼功能。
確認需求文件對象
初期，我用 Axure 畫原型給 UI 設計師，用 Word 寫文件給工程師，才寫完第一個需求文件檔案，如下圖，工程師表示看不懂（哭）。
同時間，設計師在設計畫面時，因為我的原型圖上沒有留下類似 Word 文件中的情境描述，所以某些情境 UI 設計師沒有設計，事後工程師提醒設計師後才加上，來回也浪費了一些時間。
而我本來是打算 UI 畫完圖後，我會把圖片插入 Word 文件裡，工程師就看得懂了。可是事情可沒有這麼美好….。由於我們敏捷開發的團隊是包含設計師及工程師的，每個開發週期都是一起執行的，UI 的設計及工程師對情境的邏輯開發也應該要做整體考量。
認知到這件事有點嚴重後，我改變了作法，索性就放棄 Word，嘗試用 Axure 寫搜尋功能的需求，如下圖。
如此一來，設計師與工程師共同看同一份文件，大家也會看原型文件時討論互動效果怎麼做，點下去要不要有按壓效果，過場時的動畫，從左邊滑出來下一個畫面，在中間跳出提示等等。
結語
回想起我有 1 年沒有用 Word 寫需求文件了，卻在半年內上架了 2 個 App，1年內經歷了 10 次產品迭代。所以，如果能清楚傳達產品需求，誰說一定要用 Word 寫產品需求文件呢。
