- 數據產品經理高效學習手冊:產品設計、技術常識與機器學習
- 張威
- 2690字
- 2020-04-22 12:13:09
1.4 產品原型及需求文檔
產品經理從用戶需求出發,依據產品設計邏輯和流程將用戶需求轉化為產品原型和需求文檔后,研發人員才能夠根據產品原型和需求文檔開始研發工作。所以,產品原型和需求文檔既是產品設計流程的結果,又是產品研發流程的開始。
1.4.1 產品原型
原型圖,也被稱為線框圖,是產品經理將用戶需求轉化為產品解決方案的重要載體,是產品經理與研發人員進行溝通的重要工具。根據原型圖與真實頁面的仿真程度,可以把原型圖分為高保真、低保真兩類;根據原型組件交互描述的詳細程度,可以把原型圖分為高精度、中精度、低精度三類原型圖。
(1)兩類保真度原型圖。
高保真原型圖在布局和畫面上盡可能還原了真實的頁面狀況,能夠很好地體現出真實效果,用戶體驗較好,但是實現成本較高,需要花費大量的精力和時間處理,適用于產品方案已經確定的階段。低保真原型圖布局和畫面的仿真程度較低,有時甚至使用筆來簡單勾畫出草圖,方便討論和修改,適用于產品方案構思的初期。
(2)三類精度原型圖
除了按照原型圖對真實頁面的仿真程度進行分類,還可以按照原型圖交互細節描述詳細程度進行分類,分為高精度、中精度和低精度原型圖。
高精度原型圖:高精度原型圖詳細展示原型中各組件的操作細節和交互細節,往往使用大量圖文說明來描述產品細節和設計意圖。
低精度原型圖:低精度原型圖使用頁面流程圖等簡易方式,快速展示主要操作邏輯和流程,集中力量展示關鍵組件的展示邏輯。
中精度原型圖:中精度原型圖介于高精度原型圖和低精度原型圖之間,各個組件的操作交互細節描述的詳細程度也介于兩者之間。一般而言,典型的中精度原型圖包括頁面布局、導航欄、關鍵組件、文案說明等內容。
(3)兩種分類的區別和聯系
高保真、低保真原型圖和高、中、低精度原型圖既有聯系又有區別。高保真和低保真原型圖是以原型圖對真實頁面的仿真程度進行劃分的,高、中、低精度原型圖是以原型圖組件操作交互描述詳細程度進行劃分的,兩者的劃分標準不一致,這是兩者的區別;但是實踐中,一般高保真原型圖對于組件操作交互的描述也會特別詳細,而低保真原型圖為了滿足快速交流的需求,仿真程度較低,同時組件交互描述也往往較為粗略,所以高保真原型圖往往也是高精度原型圖。
1.4.2 需求文檔
產品設計是一個將用戶需求由抽象概念轉化為具象化產品的過程,經常需要借助文字或圖像進行展現,這就是產品需求文檔(Product Requirement Document,PRD)。PRD主要是給設計、研發等相關人員閱讀的文檔,目的是告訴這部分人員產品頁面內容、交互規則和輸出結果等詳細信息,像是一份詳細的產品功能需求說明書。
1.PRD概述
PRD是產品經理用來跟技術開發人員和其他相關人員進行溝通的輔助文本工具,由產品經理負責撰寫。這里有兩點需要注意。
第一,它是文本工具。這也就是說,相對于口頭溝通,PDR能夠使溝通過程和溝通意見落在紙上,同時也為后期溝通提供了文字記錄,便于查詢。
第二,它是輔助溝通的工具。PRD不是用來劃分責任歸屬的,而是用來輔助溝通的。大量的溝通還是要通過產品經理和技術開發人員口頭交流來完成,PRD只是把溝通的關鍵性結果做一個留檔和備份,便于后期隨時查詢使用。
一般說來,一份完整的PRD至少包括3個部分:需求描述、功能描述和變更記錄。
2.需求描述
需求描述是告訴技術開發人員和相關人員“為什么要設計開發這個功能”,是產品存在的基礎和前提。很多產品會越設計越復雜、越設計越臃腫,就是因為產品經理設計添加產品功能時并沒有嚴肅認真思考每個功能的需求情況,經常靈光一現隨意增加產品功能。產品需求根據對象的側重不同可以區分為:業務需求和用戶需求。
業務需求:業務需要表達的是組織或客戶高層次的目標。業務需求側重描述組織為什么要開發該款產品或者希望通過這款產品達到什么目標,它通常表達的是項目投資者、產品購買客戶等的需求。
用戶需求:用戶需求是指產品的功能滿足了用戶某個場景下的使用需求,解決了用戶的某個問題。這主要是從用戶角度來定義和闡述的需求,描述了用戶能使用系統來做些什么。例如,用戶需要對產品的全球銷售情況有一個直觀和宏觀的印象,這就需要給用戶提供一個可視化界面,直觀地展示產品全球銷售的關鍵信息點。
3.功能描述
功能描述規定了開發人員需要在產品中實現的軟件功能,用戶可以使用這些功能來滿足其業務需求。功能描述既可以從人和系統的旁觀者角度來描述,也可以從產品角度來描述。前者叫用例描述,后者叫功能點描述。實踐中,功能點描述多采用在Axure原型圖旁邊注釋的方式,而用例描述更多采用PRD方式來詳細論述。
無論是用例描述還是功能點描述,其最終目的都是希望研發人員能夠快速清晰地理解產品功能需求。所以,一般包括以下內容。
交互規則:交互規則是指使得產品元素狀態發生改變的規則和規范,既包括用戶交互規則,也包括元素狀態自動變化的規則。例如,用戶操作產品頁面上各種交互元素和組件(篩選按鈕、滑動條)使得產品狀態發生改變;或者系統自動設定了元素狀態變化規則,如電商平臺自動設定了打折時效期,一旦過了該段時間,商品價格自動復原等。
數據規則:數據規則主要是指數據產品展現層與數據庫進行數據交互的規則。例如,用戶通過注冊頁面輸入信息并存儲在數據庫中,那么就需要指明注冊頁面包括的字段、每個字段的類型及長度等內容。
4.變更日志
變更日志的編寫并不復雜,但是一些產品經理常常因為怕麻煩而忽略了,這往往給產品研發帶來不小的隱患。
產品需求變動其實是很正常的事情,但是如果需求變動沒有及時記錄,那么可能會出現這樣的情況:產品經理想表達的是A,結果表達成了B,技術開發人員聽到的是B,理解的內容卻是C,最后因為客觀限制把產品做成了D。如果及時把需求變動記錄在PRD上,那么技術開發人員和產品經理溝通就不僅限于當時口頭溝通的“一瞬間”,而是有了可以進一步細致討論的基礎和材料,使得雙向細致的溝通成為可能。
另外,如果產品需求變動不及時記錄,一段時間后可能會因為遺忘導致各種問題。現實中,很多時候產品需求發生了變化,產品經理即時與技術開發人員進行了溝通,但是忘記將變化結論記錄在PRD中。一段時間后,產品經理或者技術開發人員可能就遺忘了這個變化,導致最后上線產品跟預期效果不一致。
最后,產品原型不可能一步到位。凡是有實踐經驗的人都應該深有體會,每次產品原型進行更改后,如果不及時記錄更改的地方,技術開發人員肯定是“頭大加火大”。因為他們完全不知道你修改了哪些地方。這些情況下,及時更新日志就顯得很重要了。有了更新日志,大家一看日志就知道產品經理改了哪些地方,進而直接鎖定修改目標,大大提升研發效率和開發進度。
因此,一個合格產品經理一定要養成及時記錄變更日志的良好習慣,也要對變更日志給予足夠的重視。
- 我們都是數據控:用大數據改變商業、生活和思維方式
- 同步:秩序如何從混沌中涌現
- 數據浪潮
- 企業數字化創新引擎:企業級PaaS平臺HZERO
- Unity 5.x Game AI Programming Cookbook
- 算法競賽入門經典:習題與解答
- Creating Mobile Apps with Sencha Touch 2
- Ceph源碼分析
- 中國數字流域
- 企業級數據與AI項目成功之道
- 辦公應用與計算思維案例教程
- 探索新型智庫發展之路:藍迪國際智庫報告·2015(下冊)
- Instant Autodesk AutoCAD 2014 Customization with .NET
- Oracle數據庫管理、開發與實踐
- 算法設計與分析