用原型代替PRD時,原型應該包含哪些內容

27 評論 50986 瀏覽 1527 收藏 9 分鐘

隨著互聯網節奏越來越快,傳統的需求文檔已經比較難適應市場的腳步,特別對于要求敏捷的團隊來說,冗余而細致入微的需求文檔已經成為包袱(這么長個文檔領導也不會看呀)。目前大多數團隊更喜愛直接使用原型來代替需求文檔,然而所謂的原型可不只是畫畫線框圖喲。

首頁,原型的使用者包括產品、UI、研發、測試等(商務呀,上級呀)。這么多人參考原型來工作,壓力不小哦,一旦表達不清,出現歧義,研發的結果的就會教會我們什么叫“偏差”,不僅可能會背離產品方向,還會影響節奏和效率。所以該有的還是還有,高保真低保真什么的事情況而定。

變更日志

原型不可能一步到位,相信大家深有體會,所以每次更改后再給項目成員時,別人不知道你改了哪些地方,這是件很頭疼的事。這種情況下,更新日志就顯得尤為重要了,大家一看日志就知道你改了哪些,直接鎖定目標,效率大大的提升。

945740-ed35a444565b14a5

更新日志 示例

版本說明

同上,只不過是每個迭代版本的更新說明。

945740-fb3cec2daf738f62

版本說明 示例

信息結構

產品都包含了哪些內容,層次結構怎么樣,它們是如何組織起來的。有了信息結構,項目成員可以直觀快速的知會這些信息,特別是剛接觸時。

945740-9a4323f0aea91b09

信息結構 示例

流程圖

包含業務流程、任務流程。業務流程是業務邏輯,包括前后臺邏輯、數據走向等,而任務流程則是用戶的操作、頁面反饋等更具象化。

945740-18131f7696dbcad0

流程圖 示例

有些還包含頁面流程,基于任務流程,描述用戶怎么從一個頁面跳到另一個頁面的邏輯,這樣就能清晰的理解頁面之間的聯系。

945740-a88c650e178a9d2b

頁面流程圖 示例(來自網絡)

交互說明

讓你的線框“動”起來。有些朋友喜歡用動態效果來代替說明,對于演示來說是必須的,但對于傳遞信息來說,則有諸多不便。且不說做動效需要的時間成本,瀏覽原型的人需要一個個操作才能看到全部效果,說不定還有疏忽遺漏的地方。圖文并茂的交互說明能讓項目成員快速清晰的掃描全部信息,某些不太好描述的動效,則可以采用交互說明+動效的方式表達。

945740-8c643c95b3051401

交互說明 示例

另外,全局的交互說明記得要提煉出來(代碼重用性^_^),如統一的頁面切換方式、統一的手勢、彈層模態等。

945740-40502dac83238bfb

全局交互說明 示例

其中“交互說明”部分是最直觀和細節的,也是研發會仔細琢磨的部分(也是大部分會跳過前面步驟直接進行畫圖(&交互)的部分),所有需要我們考慮清楚,表達清楚。因為按鈕不止一個狀態、文本域是有限制的、用戶操作不是完全可控的…

狀態

默認狀態:主要是默認(初始化)顯示的數據、文字、選項等。任何一個頁面、表單、按鈕、文本域等都會有默認狀態,這是需要我們注明的,否則研發人員難以準確單純的從原型上判斷出元素背后的邏輯。

常見狀態:頁面上一個模塊,它可能會有多種狀態,比如APP客戶端個人中心一般會有未登錄狀態、已登錄狀態,這些是需要我們展示清楚的,如果我們少寫了狀態,研發人員就會納悶xxx(登錄)之后(前)是什么樣的呢?

異常狀態:非正常情況下的樣式、文案、說明等,比如搜索無結果、加載失敗、網絡(定位)未開啟等等。異常狀態一般較容易被遺漏,最終導致產品體驗較差。畢竟用戶不是都在辦公室里把所有開關(權限)都打開才使用我們產品的。

限制

范圍:數據的取值范圍。比如輪播圖的個數、滑塊的范圍&刻度、文本域的長度等等…

極限值:數據的顯示限制。比如最多應該顯示多少字數,超出時如何顯示、每次請求數據的條數,不足時怎么辦超出時怎么辦等等…

操作

常見操作:正常操作時得到的反饋狀態。比如一個按鈕經過不同操作會出現不同狀態,鼠標進入、按下、點擊后。

特殊操作:一些極端情況下的操作,出現概率較小,還是要想好應對措施。比如我們在買保險時會有常用被保險人,選中某個其詳細信息會出現在申請表單中,如果在這時候修改了被選中人的信息,修改后的人,算被選中人還是新的被保險人呢?提交表單后是覆蓋愿被選中人信息還是新增一個被保險人呢?

面對可能出現復雜的情況,要和研發人員一起探討解決辦法,并把交互說明寫清楚。有時候研發人員想到的辦法可能更簡單實用。

誤操作:用戶操作錯誤的情況。這種情況采取的措施一般是提前預防錯誤、適當提示用戶、系統自動糾錯。比如庫存接近0時,選擇數量時就會提醒用戶庫存5件,如果用戶輸入超出5,則自動更正為5.

手勢操作:使用移動端產品時的操作方式。比如滑動、放大、搖晃等。

反饋

提示:用戶操作后,系統反饋給用戶的提示。

跳轉:點擊某個鏈接/按鈕后,頁面跳轉到的地方。網頁也表明是原頁面刷新還是新標簽頁打開,移動端要表明轉場方式(默認為全局)。

動畫:用戶操作后,系統通過動畫的方式反饋給用戶。動畫給人的感覺比較友好,趣味性較強,避免過于夸張。比如Clear用炫酷的手勢和動畫贏得了用戶的青睞。

除靜態頁面外,還需要考慮各種動態情況;除正常情況外,還需要考慮特殊和錯誤情況。

 

本文由 @陳正曦? 授權發布于人人都是產品經理?,未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 求示例文件,謝謝!
    yuuly@163.com

    來自北京 回復
    1. 請問你有這個源文件了嗎?

      回復
  2. 學習了。

    來自上海 回復
  3. 樓主,能不能提供的示例啊,文中提到的需要包含的內容都顯示在哪?
    本人小白,求救!

    來自北京 回復
  4. 好東西,謝謝分享 ??

    來自北京 回復
  5. 樓主,交互說明那張圖是用什么軟件畫出來的呀 ??

    來自北京 回復
    1. 就是用Axure畫的吧!

      來自北京 回復
  6. 后面幾點沒配圖?所有的細節都在頁面上羅列難免會有疏漏,文檔還是不能省啊。需要的時候可以看看,免得到后來自己都忘了 ?

    來自福建 回復
  7. 我現在都不寫PRD了,可是直接寫在原型上也有問題,老是細節部分想不到,特別是需求變更極快極多的情況下,又涉及到邏輯和框架的,再去調整就很麻煩了!

    來自廣東 回復
  8. 說實話,寫得好我贊同??墒怯袔讉€人能全部展示出來這些信息,做過的人都知道,很多時候有些交互語言描述不出來,就算你都描述出出來了,技術也未必會認真看。人都有主觀思維,技術認為你的意思未必是你的意思。

    來自北京 回復
  9. 不錯!

    來自福建 回復
  10. 感謝分享,寫得不錯。敏捷開發,快速迭代,傳統的多文字需求文檔的確過時了。無論開發人員或領導都沒有那么多時間或耐心去閱讀。

    來自湖南 回復
  11. 謝謝分享,寫的挺全面的,可是組織起來有點困難,不知道這么多得信息要怎么展示出來~

    來自天津 回復
  12. 后面寫的就有點隨意了

    來自安徽 回復
  13. 受教啦,謝謝分享 ??

    來自北京 回復
  14. 贊一個

    來自福建 回復
  15. 真正的干貨

    來自上海 回復
  16. 學習了~

    來自江蘇 回復
  17. 知道該怎么做啦,感謝分享 ??

    來自北京 回復
  18. 學習了

    來自北京 回復
  19. ?? niu!

    來自廣東 回復
    1. ??

      來自北京 回復
  20. 我用的就是這套

    來自北京 回復