一份靠譜的PRD文檔,需要注重哪些細節?
只有通過原型推敲,才能夠不放過任何一個細節,做出好的產品。
PRD文檔很見產品經理的基本功。好的PRD文檔開發人員閱讀起來如沐清風,手腳麻利,干活利索。延期?不存在的!
一份考慮不夠周全的PRD文檔,讓開發人員二丈摸不到頭腦,在需求評審會上,悄然醞釀著撕逼大戰。或者是,產品經理善于挖坑,需求評審會上居然過了,在實際開發過程中才發現問題,嚴重時候可能需要返工,浪費人力物力財力。
細節考慮不清楚,測試同學也無法發現潛在的問題,可能導致產品缺陷。
不靠譜!
為了不翻車,在寫完PRD的時候,對于每個用例,都應該仔細去考慮下面的細節內容。
前置條件
是否需要用戶登陸?
在操作前是否有什么必要條件?如使用定位功能必須開啟GPS。
數據
1、數據展示
數據來自哪里?
沒有數據時候展示什么?(很多產品直接就是空白的,用戶不明白的還以為是自己網絡不好加載不出來。)
最多展示多少數據?
超過容器的部分怎么辦?
數據加載失敗怎么處理?
計量單位是否統一?(如內容發布時間,是顯示具體時間還是如“1天內”這樣的表述?)
2、數據輸入
數據類型是什么?
是否必填?
長度是否有限制?
是否校驗唯一性?(如用戶名,是否唯一?)
有無特殊說明?(如密碼以星號展示)
是否有默認值?
刷新數據是否還在?
3、數據加載
加載數據的方式?(手動加載還是滾動自動加載?)
加載中的樣式?
加載失敗如何處理?
如果無數據可加載如何展示?
一次加載多少數據?
4、排序問題
排序的規則?
排序更新的頻率?
是否有影響排序的因子?
是否有置頂?
5、數據緩存
哪些數據可以緩存?
緩存更新的規則?
緩存刪除的規則?
組件操作
組件可點擊的區域大???(有些產品的關閉按鈕點擊區域很小,用戶很難操作。)
是否可以拖動?
是否可點擊?
有無特殊交互效果?(得到焦點時、失去焦點時等)
交互自查
彈窗樣式?
頁面切換樣式?
提示樣式?(成功提示、失敗提示、異常提示)
操作反饋(點擊、滑動、縮放等等)
操作
操作是否可以撤回?(如回滾功能,回收站功能)
關鍵操作之前是否需要給予提示/警告?(如刪除操作)
是否需要為某些操作添加特殊說明(如后臺產品,有些操作并不是所有用戶都了解的,有必要給出特殊文字說明)
操作如果異常/失敗/強制中斷,如何處理?是否有備份?
操作中是否允許中斷?
以上基本覆蓋了大部分的容易遺漏的細節,根據產品的不同,還有可能出現不一樣的異常狀況,都需要被考慮到。如我曾經為數據工程師設計的一款數據標注的產品,就有一個情況,就是工程師在標注數據的時候,有可能會離開位置去做一些其他的事情。而這個產品在交互上就需要給予工程師一個數據標注的進度位置展示,否則工程師一回頭就忘了自己標注到哪里了。這些都需要根據場景來實際考慮。所以我一直在說高保真原型的重要性。只有通過原型推敲,才能夠不放過任何一個細節,做出好的產品。
作者:躚塵,互聯網產品經理(微信公眾號:躚塵),獨立音樂人(網易云音樂:躚塵),歡迎交流。
本文由 @躚塵 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Pexels,基于 CC0 協議
寫得蠻好的。但是如果寫這么詳細,PRD文檔未免太臃腫了,我看了很多文檔也沒見寫這么詳細的。。。?怎么解決這個問題?
diaozhatian!!!…
感謝樓主,收下了。
之前看過一本書叫《清單革命》,把一些容易忘記的條目記錄下來,到時候核對一下清單即可,減少大腦記憶壓力。
感覺更像ue的方案
666666
你這個是做交互,與做產品設計沒任何關系。
哪有那么多公司需要UE
挺全面的,可以再根據自己思路再整理一份
一圖抵千文,之前一直想歸納的東西因為懶沒有去歸納,大神干貨很干,打印收藏了,謝謝哈。
真的很詳細,都把平時一些問題梳理進去了 干貨收了
就喜歡這種干貨,可操作性非常強 ??
666666 ??
贊
干貨一定收藏
好文章,。贊一個。就是評論為什么這么少呢?
難得一見的干貨,謝謝
嗯,跟實際工作中使用的差不多,不過每次寫的時候總會遺漏點東西,現在有一個系統的梳理,以后對著寫就不會遺漏了。已收藏!
感謝梳理,已收藏