PRD產品需求文件-第8堂【B2B2C產品經理PM的8堂必修課】
- LeonLin
- 2024年1月17日
- 讀畢需時 5 分鐘

目標
知道B端產品3種常見頁面的原型圖繪製方法
知道如何避開原型圖繪製5大誤區
了解如何提升原型圖的交互體驗,更符合用戶操作習慣
掌握PRD文件6要素,交付優質PRD
一、如何畫好B端產品原型圖
1-1 什麼是原型圖
作用:產品可視化(簡單的框架圖、形象表達頁面的排版)
目標人群:部門領導、交互設計、UI設計、研發、測試
為什麼B端產品經理一定要自己畫原型圖?:
B端系統龐大複雜,必須深入瞭解用戶需求和用戶操作習慣
B端產品細節錯綜複雜,在原型圖繪製過程中可以再次深入思考
先確認後開發,可以用原型圖和用戶確認產品設計合理性
交互設計師一般不在一線,需給草圖以闡述設計關鍵點
原型模板相對固定,團隊可能沒有UIUX,因此是PM的必備技能
B端產品經理需要畫高還原(高保真)的原型圖嗎?
低保真(低還原)原型圖:線框圖
僅呈現最終產品的部分視覺屬性。例如:元素的形狀、基本視覺層次。一班不具備交互效果。
高保真(高還原)原型圖:精細化圖
逼真細緻的設計,所有介面元素、間距和圖形與最終的相仿。原型在交互層面非常逼真。
1-2 如何畫好原型圖?
積累原型圖素材庫
開源組件庫:參考/下載前端使用的框架和組件庫(如:Element, ivew, Ant等)
自製組件庫:將自己常用的規範整理成標準組件庫(如:佈局、按鈕、表單、空間、彈窗、預警等)
熟練掌握方法
建立目錄:根據結構圖,在Axure中建立模組文件夾、功能頁面,調整從屬關係。將結構圖的層級關係轉換成原型目錄從屬關係,並清晰命名
畫出佈局:用線框圖畫分每個區塊要顯示的內容。將頁面中字段進行分類分組,在頁面上畫出顯示區塊。
列舉字段:在每個區塊裡把所有要顯示的字段排版,案字段屬性(長短、數據類型等)和規範調整佈局
B端產品常見頁面原型的繪製方法
列表頁、新增頁、詳情頁(B端產品百分之80都是由這三類型頁面組成)
列表頁:5大區域,有Menu選單欄、頁面導航區、篩選搜尋區、操作區、列表區、操作欄
新增頁:3大區域,包含共用資訊、分組資訊、操作欄
詳情頁:資訊回傳、操作欄
1-3 避開原型圖繪製的5個誤區
誤區1:頁面龐大,表述不清晰
(X)多頁面都畫在一個圖裡,頁面較大,容易表述不清晰、遺漏
(O)一個介面一張圖,如:列表頁、詳情頁,包含大彈窗,都是一張圖
誤區2:資訊顯示不完整
(X)區分不出是頁面還是彈窗;按鈕觸發交互遺漏
(O)資訊顯示完整,頁面和彈窗樣式區分明顯,所有觸發都有效果圖
誤區3:擷取現有系統頁面圖做修改
(X)擷取現有系統頁面圖,在截圖檔案上做增刪
(O)用組件庫裡的組件繪製,後期修改方便
誤區4:排版交互形勢不統一
(X)同系統內部的頁面排版、交互形式不統一
(O) 有原型圖規範標準,不同產品經理在繪製時須遵守統一標準
誤區5:必填字段無標示
(X)必甜滋段沒有提示標示,資訊層次不清晰
(O)必填字段加星號、紅色文字,盡量放在頁首等重要位置,次要資訊可摺疊收起來
1-4 繪製好的B端產品原型圖,提升用戶體驗
第一步:表述出要實現的功能
第二步:讓功能更好用+易用
1-4-1 什麼是用戶體驗?
「人們對於針對使用或期望使用的產品、系統或者服務的認知印象和回應」。通俗來說,就是「這個東西好不好用,用起來方不方便」。用戶體驗≠交互+介面美觀度。而是符合用戶的操作習慣,能降低學習成本,提升業務效率。
1-4-2 提升用戶體驗三方面(業務、交互、視覺)
業務層
流程越短越好:盡可能縮短步驟,減少點集合頁面跳轉次數。如點餐時,點一個套餐要多5步,那多人點餐人可能就會造成排隊時間延長。舉例如下圖。
整合功能場景:這個功能由誰、在什麼場景下操作,以及可能會遇到什麼問題、需要整合哪些功能提升效率。如:將分享菜單一點的功能加入菜單。
有效指導異常:遇到問題或操作困難時給出快速跳轉連結和幫助指南
交互層
少跳轉:頁面跳轉會讓用戶感覺操作有卡頓感,可以改成彈窗,減少跳出感,會覺得流程短了,好用了。
少彈窗:頁面上的資訊分區塊直接呈現,如果內頁面上的資訊分區塊直接呈現,如果內容較多,可將高頻率且重點的內容直接放在外面,以便查找。
快捷操作:將同樣/相近的業務操作聚集在一起,並提供快速的按鈕,如批量操作/全選操作
視覺層
資訊清晰:不僅是指資訊結構的曾是,還包括頁面的內容,讓用戶一眼就能看到上面寫了什麼,有什麼功能,在B端產品內,清晰是最高指導原則
資訊緊湊:B端的資訊較多,因此需要壓縮空間,緊湊排版,盡可能使一頁的資訊量最大化,減少頁面的上下滾動與彈窗顯示。
少用圖標:圖標越少越好,用文字表示,除了常用按鈕,或垃圾桶這種大家都能看懂的Icon,不要自己設計圖標,增加學習跟反應成本。
貼近現實:盡可能採用客戶現有表單的樣式,降低學習成本
1-5 小結
二、如何撰寫優質PRD
Product Requirement Document 產品需求文件,指導團隊(專案、開發、測試、設計、UIUX實現產品)。
2-1 為什麼你的PRD總是完美避開重點?
沒有從全局到局部的過程,團隊成員難以瞭解掌握功能
只有圖,沒有規則說明,研發沒有辦法寫程式碼邏輯
規則說明過於簡單,團隊內部理解不一致
沒有用研發的語言表述,無法有效直接指導開發
原型圖和業務規則對照不起來
文件書寫隨便,重點隱藏在中多次要資訊中,開發時會遺漏
缺少文件版本管理,團隊成員拿到的版本不一致
2-2 寫好優質PRD的6要素
一、修訂紀錄
在開發過程中,變更功能點時,紀錄:變更時間、內容、頁面連結和變更原因等,團隊成員可以更快速找到變更點,也有利於PM復盤
修訂紀錄 | |||||
修改時間 | 功能模塊 | 修改內容 | 原型連接 | 修改原因 | 修改人 |
2024/1/11 | 創建原型 |
二、專案介紹
(*需要注意:一定要從大(專案)到小(功能)的來龍去脈闡釋清楚)
目標用戶:指功能實際使用人。最好具體到某個職位上,比如:外場服務生、櫃檯
場景描述:描述目標用戶在什麼場景下進行什麼行為。可以用一具體的例子來描述
需求/痛點描述:描述目標『用戶』在『場景』下操作時遇到什『問題』
可解決方案:簡單描述解決方案,若有多方案列上優缺點,標註這次選擇的方案
三、功能框架
流程圖:功能流程圖,描述系統中功能實現流程
結構圖:產品功能框架,描述產品設計架構體系
四、全局說明
重要規則:
名詞含義:明確定義名詞指代的具體事務和規則。比如對新用戶的定義
重要業務規則:提煉出來重點說明,讓團隊成員明確產品最根本的邏輯規則,避免實現時有大偏差
通用規則:
一些組建和交互規則是全局通用的,濃縮提煉出來已減少重複說明
五、原型圖
每個頁面具體呈現的內容和樣式
六、業務規則
功能規則
功能點:功能點名稱及業務總體規則的說明
字段說明:可用表格列出每個字段名稱、是否必填、數據類型、可選項、默認值、輸入/輸出、數據來源、備註等
異常校驗:可用表格顯示異常校驗項、提示內容、提示方式等,表格裡面順序也是校驗的優先級
字段規則表格 | |||||||
字段名稱 | 數據類型 | 可選項 | 默認值 | 輸入/輸出 | 是否必填 | 數據來源 | 備註 |
規則校驗表格 | ||
異常情況 | 提示內容 | 提示方式 |
交互規則:介面跟用戶的互動規則,如:點擊按鈕時,會跳轉OO頁面 / 出現彈窗 / 提示OO,Hover(滑鼠移動)時,有什麼效果;異常時報錯資訊格式
2-3 PRD的交付形式
軟體版本(Axure, Figma, 墨刀)
文字版本(Word, 公司Wiki, Notion)
封面
目錄
修訂紀錄
概述(目標用戶、背景)
功能需求概述(功能列表、流程圖、結構圖)
功能需求詳細說明(全局規則、分端講解功能、原型圖、業務規則)
時間圖
團隊分工
三、總結
Part1:原型圖設計 | Part2:PRD撰寫 | |
---|---|---|
核心工作 | 繪製體驗好的流程圖 | 交付優質PRD |
工作方法 | 1. 建立目錄 2. 畫出排版佈局 3. 列出字段 | 1. 修訂目錄 2. 專案介紹 3. 功能框架 4. 全局說明 5. 原型圖 6. 業務規則 |
工作產出 | 頁面原型圖 | 1. 文字版 2. 軟體版 |
檢測指標 | 1. 頁面完整 2. 統一規範 3. 貼和用戶 | 1. 結構清晰 2. 說明詳盡 3. 可毒性強 |
Commenti