PAGEPAGE1Hi~最近在對自己參與過的項目進行總結，希望可以和大家分享學習交流。輸出內容是檢視自己的方式，所以我就來吸取經驗了。通過研讀各位優秀作者的精品，我學習到了不少知識。此次，以實際工作中遇到的情況作為案例，我將從0至1的產品中抽取重點模塊進行分享。為了閱讀體驗，我將盡量簡化常規化的環節，本次采用AXURE梳理PRD——利用AXURE動態面板和內聯框架，制作文檔導航，提高瀏覽人員的閱讀效率。一、概述1.產品介紹2.文檔修訂記錄將重點模塊添加對應的跳轉鏈接，方便瀏覽人員迅速定位內容。版本號規則：小數點后為當前版本的小更新，小數點前為大版本更新。修訂屬性：新增、修改、刪除二、產品結構1.信息結構圖2.功能結構圖由于完整結構圖展開占很大的篇幅并且看不清楚，為了閱讀體驗，對結構圖部分收縮。完整版結構圖可在AXURE中查看。三、業務流程圖建議將流程圖統一整理至表格中，做成鏈接跳轉形式，實現快速查閱。為了順暢的需求閱讀體驗，將各自的流程圖放在之后的需求描述部分中展示。四、全局說明1.名詞術語說明2.權限彈窗3.時間距離規范3.1時間規范3.2距離規范4.異常情況4.1網絡異常手機網絡連接異常，小程序彈窗提示如下：4.2用戶狀態說明五、功能性需求說明良好的需求閱讀體驗需要保證閱讀過程是順暢的。在這部分，首先列出【需求清單】，總覽這次需求涉及的模塊及簡要信息。緊接著，按照【需求模塊】-【流程圖】-【原型頁面流轉】-【原型需求拆解】的敘述邏輯去完成各個模塊的需求說明。1.需求池&需求清單1.1需求管理池需求來源：產品、運營、BOSS等等需求類型：新增需求、需求調整、功能優化、BUG修復、UI優化系統：涉及到的系統及模塊需求說明：簡述需求優先級判斷：重要緊急、重要但不緊急、緊急但不重要、既不緊急也不重要（ps：我們要經常關注重要但不緊急的任務進度，避免重要緊急任務扎堆出現。）1.2需求清單對需求管理池評估篩選后，將需求模塊、對應功能、需求優先級、完成情況統一整理到表格中。同樣的，這里將模塊名稱做成鏈接格式，快速查閱對應的需求模塊。優先級規范：p1、p2……數字越小代表優先級越高。2.新用戶&首頁模塊2.1新用戶登錄流程圖2.2

新用戶登錄原型（點擊查看大圖）2.3首頁3.預約團課模塊3.1團課預約流程圖3.2

團課預約頁面流轉3.2

課程列表頁3.3

課程詳情頁3.4

預約課程頁4.預約私教模塊4.1私教預約流程圖4.2私教預約頁面流轉4.3私教列表頁4.4私教詳情頁4.5私教預約頁5購卡模塊5.1購卡流程圖5.2購卡頁面流程5.3購買儲值卡頁面6.我的模塊（個人中心）6.1個人頁面6.2修改資料6.3我的卡包6.4我的課程包6.5我的優惠券6.6富文本頁面六、非功能性需求非功能性需求，是比較容易忽視的部分，往往和性能、安全掛鉤，影響著產品的穩定性與安全性。以下僅僅是例子，具體方案需要根據業務情況和產品特性與相關人員深入溝通。1.性能需求響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時間。并發用戶數：同時承載正常使用系統功能的用戶數量。與性能相關的數據指標還有QPS（每秒響應請求數）、TPS（每秒處理的事務數）等。性能需求這部分僅僅是舉個例子，具體情況和數據方案，需要和相關人員深入溝通。2.可用性需求避免用戶高頻點擊無反饋的情況。為用戶提供反饋渠道。保持文案與組件的一致性。3.數據統計需求產品初期需要一定基礎的數據提供支持，因此，除了小程序官方數據統計平臺，再接入第三方統計平臺，統計以下事件的數據及路徑轉化率。七、思考總結1.內容細節流程圖和頁面流轉圖要整齊統一，實在太多信息，建議用子流程模塊和多頁面分述解決。見過很多像“蜘蛛網”一樣的圖，閱讀體驗比較糟糕。盡量讓用戶不用點開大圖就能看清內容，本篇部分頁面流轉圖和頁面需求也難免遇到這類問題。異常邏輯和toast彈窗等細節需要加強把控，本篇這部分還是有所欠缺。2.高保真or低保真？低保真線框圖：重點在于功能、結構、流程的梳理，利用簡單的框架和元素，省時省力；但細節相對高保真沒這么完善，可能會有一定的溝通成本。高保真：針對于高層領導及投資人等，進行產品概念演示，視覺效果好，細節相對完善；相當于是一個產品的demo，但修改成本較高。原型交互做的很酷炫，證明你對工具非常熟練。但如果為了做交互花費了大量的時間，就得考慮時間成本值不值得。如果能夠用簡單的注釋和跳轉，清晰表達交互邏輯，會不會省時省力一些？具體情況具體分析，比如，你做了很多交互，開發做漏了會說：“沒寫清楚啊，我怎么知道哪里可以點擊呢？”因此，我的習慣是做簡單的“交互邏輯+交互注釋”，盡量避免復雜且耗時耗力的交互。當然，重要核心的交互邏輯，繪制出來比文字說明更容易理解。這時候，如果有現成的組件就套用，如果沒有，就采用“圖+文字+口述”的方式表達清楚。3.WORD？AXURE？需求文檔用什么工具寫比較好？這是我見過比較多的產品話題討論之一——有用WORD的，有用AXURE的，還有用墨刀、石墨文檔等等……我曾經請教過兩位分別使用WORD和AXURE撰寫需求文檔的朋友，他們是這樣的看法：WORD選手：用word寫，形式更規范。結構大綱清晰，細節到位。洋洋灑灑幾十頁，滿足感杠杠滴。AXURE選手：用AXURE寫，圖+標注+交互，更直觀地表達產品需求，閱讀更順暢。預覽方便，支持上傳云端同步。WORD寫了也沒人有耐心看，這個世界很浮躁啊。我的看法：需求文檔是幫助傳達及溝通需求的工具，講究的是“可讀性”。所以，在選擇采用什么方式之前，需要和團隊溝通達成共識，即什么樣的方式能給到他們更好的閱讀體驗。我在實際工作中，