top of page
  • 作家相片LeonLin

PRD產品需求文件-第8堂【B2B2C產品經理PM的8堂必修課】




目標

  1. 知道B端產品3種常見頁面的原型圖繪製方法

  2. 知道如何避開原型圖繪製5大誤區

  3. 了解如何提升原型圖的交互體驗,更符合用戶操作習慣

  4. 掌握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 提升用戶體驗三方面(業務、交互、視覺)


業務層

  1. 流程越短越好:盡可能縮短步驟,減少點集合頁面跳轉次數。如點餐時,點一個套餐要多5步,那多人點餐人可能就會造成排隊時間延長。舉例如下圖。

  2. 整合功能場景:這個功能由誰、在什麼場景下操作,以及可能會遇到什麼問題、需要整合哪些功能提升效率。如:將分享菜單一點的功能加入菜單。

  3. 有效指導異常:遇到問題或操作困難時給出快速跳轉連結和幫助指南


交互層

  1. 少跳轉:頁面跳轉會讓用戶感覺操作有卡頓感,可以改成彈窗,減少跳出感,會覺得流程短了,好用了。

  2. 少彈窗:頁面上的資訊分區塊直接呈現,如果內頁面上的資訊分區塊直接呈現,如果內容較多,可將高頻率且重點的內容直接放在外面,以便查找。

  3. 快捷操作:將同樣/相近的業務操作聚集在一起,並提供快速的按鈕,如批量操作/全選操作

視覺層

  1. 資訊清晰:不僅是指資訊結構的曾是,還包括頁面的內容,讓用戶一眼就能看到上面寫了什麼,有什麼功能,在B端產品內,清晰是最高指導原則

  2. 資訊緊湊:B端的資訊較多,因此需要壓縮空間,緊湊排版,盡可能使一頁的資訊量最大化,減少頁面的上下滾動與彈窗顯示。

  3. 少用圖標:圖標越少越好,用文字表示,除了常用按鈕,或垃圾桶這種大家都能看懂的Icon,不要自己設計圖標,增加學習跟反應成本。

  4. 貼近現實:盡可能採用客戶現有表單的樣式,降低學習成本





1-5 小結


 

二、如何撰寫優質PRD

Product Requirement Document 產品需求文件,指導團隊(專案、開發、測試、設計、UIUX實現產品)。



2-1 為什麼你的PRD總是完美避開重點?


  1. 沒有從全局到局部的過程,團隊成員難以瞭解掌握功能

  2. 只有圖,沒有規則說明,研發沒有辦法寫程式碼邏輯

  3. 規則說明過於簡單,團隊內部理解不一致

  4. 沒有用研發的語言表述,無法有效直接指導開發

  5. 原型圖和業務規則對照不起來

  6. 文件書寫隨便,重點隱藏在中多次要資訊中,開發時會遺漏

  7. 缺少文件版本管理,團隊成員拿到的版本不一致

2-2 寫好優質PRD的6要素


一、修訂紀錄

  • 在開發過程中,變更功能點時,紀錄:變更時間、內容、頁面連結和變更原因等,團隊成員可以更快速找到變更點,也有利於PM復盤

修訂紀錄






修改時間

功能模塊

修改內容

原型連接

修改原因

修改人

2024/1/11


創建原型




二、專案介紹

(*需要注意:一定要從大(專案)到小(功能)的來龍去脈闡釋清楚)


  • 目標用戶:指功能實際使用人。最好具體到某個職位上,比如:外場服務生、櫃檯

  • 場景描述:描述目標用戶在什麼場景下進行什麼行為。可以用一具體的例子來描述

  • 需求/痛點描述:描述目標『用戶』在『場景』下操作時遇到什『問題』

  • 可解決方案:簡單描述解決方案,若有多方案列上優缺點,標註這次選擇的方案

三、功能框架

  • 流程圖:功能流程圖,描述系統中功能實現流程

  • 結構圖:產品功能框架,描述產品設計架構體系

四、全局說明

  • 重要規則:

  • 名詞含義:明確定義名詞指代的具體事務和規則。比如對新用戶的定義

  • 重要業務規則:提煉出來重點說明,讓團隊成員明確產品最根本的邏輯規則,避免實現時有大偏差

  • 通用規則:

  • 一些組建和交互規則是全局通用的,濃縮提煉出來已減少重複說明

五、原型圖

  • 每個頁面具體呈現的內容和樣式

六、業務規則

  • 功能規則

  • 功能點:功能點名稱及業務總體規則的說明

  • 字段說明:可用表格列出每個字段名稱、是否必填、數據類型、可選項、默認值、輸入/輸出、數據來源、備註等

  • 異常校驗:可用表格顯示異常校驗項、提示內容、提示方式等,表格裡面順序也是校驗的優先級

字段規則表格








字段名稱

數據類型

可選項

默認值

輸入/輸出

是否必填

數據來源

備註









規則校驗表格



異常情況

提示內容

提示方式





  • 交互規則:介面跟用戶的互動規則,如:點擊按鈕時,會跳轉OO頁面 / 出現彈窗 / 提示OO,Hover(滑鼠移動)時,有什麼效果;異常時報錯資訊格式


2-3 PRD的交付形式

  1. 軟體版本(Axure, Figma, 墨刀)

  2. 文字版本(Word, 公司Wiki, Notion)

    1. 封面

    2. 目錄

    3. 修訂紀錄

    4. 概述(目標用戶、背景)

    5. 功能需求概述(功能列表、流程圖、結構圖)

    6. 功能需求詳細說明(全局規則、分端講解功能、原型圖、業務規則)

    7. 時間圖

    8. 團隊分工



三、總結


Part1:原型圖設計

Part2:PRD撰寫

核心工作

繪製體驗好的流程圖

交付優質PRD

工作方法

1. 建立目錄


2. 畫出排版佈局


3. 列出字段

1. 修訂目錄


2. 專案介紹


3. 功能框架


4. 全局說明


5. 原型圖


6. 業務規則

工作產出

頁面原型圖

1. 文字版


2. 軟體版

檢測指標

1. 頁面完整


2. 統一規範


3. 貼和用戶

1. 結構清晰


2. 說明詳盡


3. 可毒性強


Comments


bottom of page