如何寫好PRD?站在用戶角度是關鍵

9 評論 19263 瀏覽 187 收藏 9 分鐘

常常有人問我怎么寫prd,在深受市面上流行的功能需求模板“殘害”之后,我現在一般不會向別人推薦任何所謂的“模板”。

需求文檔是產品需求的表達方式,而其中需要描述什么內容取決于產品經理想要描述什么,即產品經理的需求。如果產品經理的需求是明確的,而且產品經理腦中有物,那么需求文檔自然而然就出來了。最可怕的是產品經理自己都不知道自己要描述的是什么內容,這個時候即使有模板,寫出來的東西也是一團糟。

互聯網產品以用戶為中心,所以prd也應該站在用戶的角度來描述,如果不知道自己要寫什么,在寫文檔之前產品經理可以先問問自己以下4個問題:

  1. 用戶需求是什么?
  2. 通過產品,用戶能得到什么?
  3. 如何滿足不同用戶的使用場景?
  4. 產品應該做什么?

這四個問題凝聚了End2End思想的核心,站在用戶的角度給需求,在Jesse James Garrett的《用戶體驗要素》一書中,被分別稱為范圍層(問題1,2),結構層(問題3),框架層(問題4)的用戶體驗。

一、用戶的需求是什么?

按照需求出生的先后排序,需求分別是:

  1. 用戶需求
  2. 功能需求

即先有用戶需求,才有功能需求。此文開頭已經提過,筆者曾受功能需求模板誤導,所以下文中僅描述用戶需求。舉個例子,用戶希望買到物美廉價的商品,那么對于用戶而言,用戶需求其實就是以下幾點:

265765-fb9e97b8fbf7f990

如果是B2C平臺,還得考慮到B端用戶的需求,那么用戶需求列表就是:

265765-c5ff5bb7f3995ce3

二、用戶可以得到什么?

這個問題,其實也是思考產品的有用性,即產品這么做對用戶能產生的價值。

在上面這個B2C電子商務平臺的例子中,B端用戶通過在系統中發布商品,供C端用戶購買,可以給B端用戶帶來收益,加入了優惠券之后,B端用戶在系統中發放優惠券,系統通過優惠券可以刺激C端用戶消費,此時B端用戶給C端用戶提供了折扣,拉動消費后C端用戶會給B端用戶帶來更多的收益,圖形化后的表達為:

265765-7097e9b0b250cff2

更精確地,上圖可稱為用戶價值鏈。

三、如何滿足不同用戶的使用場景?

滿足不同用戶的使用場景,又稱作用戶場景分析。

接著上面的例子,在用戶的兩個需求中又包含了不同的場景,其中商品需求的場景包括瀏覽、下單和付款,優惠券需求的場景包含了獲取和使用,于是用戶場景(use case)主要表現為:

265765-db9aee303aad2b6b

發布商品是對B端用戶而言。

瀏覽商品這個場景中,不同的用戶有不同的使用場景。一部分用戶是有目的的,他們知道自己想要的東西叫什么名字,可能只是想知道在這個產品中該商品的價格,所以產品需要提供搜索功能來應對這種用戶場景。然而大部分用戶都是無目的瀏覽,為了滿足這種用戶的需求,只需將商品羅列出來就好。電商平臺常見的分類展現、價格范圍等等功能都是為了滿足介于有目的和無目的之間的用戶場景,分析方法類似,此處不再展開描述。

瀏覽商品之后是下單,有的用戶習慣把看起來覺得還不錯的商品全部放在一起,先比較比較,再決定是不是要購買,有的用戶屬于沖動消費或者消費目的明確,這些用戶通??吹揭粋€商品覺得還不錯,就直接下單了。所以下單這個場景,又有兩個用戶場景,一個是添加到購物車再下單,一個是直接下單。

最后是付款,付款的方式有多種,有的用戶喜歡用支付寶,有的喜歡用微信,有的喜歡用銀聯等等。這些場景都是現實存在的,但是產品經理需要過濾哪些場景是頻繁的場景,哪些是不頻繁的。比如,如果這個B2C平臺是建立在微信上的,那么用戶用支付寶和銀聯付款的場景就顯得很弱,如果是淘寶或者天貓,毋庸置疑,支付寶一定是頻繁場景,如果是獨立的電商平臺,那么可能以上幾種場景都需考慮在內,甚至還需要再多加入幾個支付場景。

優惠券為大家所知,獲取的途徑通常有兩種,一種是系統發放,一種是主動領取。

通過以上描述,不難得出以下用戶場景分析圖:

265765-68180c0a00715f2c

四、產品應該做什么?

描述產品應該做什么的過程,是prd最核心的部分,也是研發人員最關心的部分。因為只有研發人員看了到產品應該做什么,他們才知道自己應該怎么做。

互聯網產品重交互,所以用戶與系統之間的互動是最好的描述方式。在測試中有一種方法被稱為黑盒測試,用在這里,再合適不過。簡單地說,就是用戶輸入什么,系統輸出什么,即:

265765-3e56947c4de63d5a

左邊一列描述用戶的動作,一行僅與用戶的一個動作關聯,右邊一列描述對于用戶的這個動作,系統做出什么樣的反應,包括達到什么頁面,展示什么信息或者跳轉到哪個頁面。

結合我們的例子,由于這個例子中有“兩個”用戶,我們的C端用戶和B端用戶,所以表格需要做一點小改造:

265765-c7f5a12c93f9ebb0

以其中B端用戶發布商品和C端用戶搜索商品為例,展開描述,可得到如下用戶事件流(user story):

265765-e658378ff7d77ab5

將其他場景拓展開之后,prd文檔基本完成。在此基礎上,不管系統應對的用戶多么的復雜,都可以自如地化繁為簡。

#專欄作家#

康小胖,人人都是產品經理專欄作家,產品經理。專注專注O2O電子商務,堅決擁護用講故事的思維做產品,關注電子商務及移動互聯網,愛好圓珠筆涂鴉。

本文系作者獨家授權發布,未經本站許可,不得轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. M-PRD

    來自湖南 回復
  2. 這個不應該是PRD的思維邏輯啊,定義為MRD的思維邏輯還差不多。

    來自北京 回復
  3. 【此文章不會給PM有所幫助!反而會造成困擾?。?!】prd給開發,給設計看的,圍繞用戶寫,程序員怎么辦?分析用戶是寫prd之前的事情,分析用戶需求等等。萬不可和prd混為一壇。

    來自北京 回復
  4. 文章寫的不錯。但很不認可這個標題。
    我們思考的過程、策劃的過程,肯定要更多的從用戶出發。但現在是寫prd,是給程序員看的,我們更應該去符合程序員的思路和代碼結構去寫。

    來自江蘇 回復
    1. 我也是這么覺得的!

      來自江蘇 回復
    2. 其實呢,如果最后一步寫得夠詳細,把流程細節都描述清楚,開發基本已經能看懂了,這種做法的好處,是讓研發不僅能知道要做什么,還能知道為什么要這么做。團隊合作的風格因人而異啦~ ??

      來自廣東 回復
    3. 那是不是應該是MRD該做的事情?

      來自廣東 回復
    4. 產品是給用戶用的,prd的用戶是程序員,prd指導程序員開發出用戶使用的產品,有點繞啊,那pm寫prd是一件什么事兒

      來自湖北 回復