盤點PRD中易遺漏的三類非正面需求

小程序這么火爆,作為產品經理,還不了解小程序如何設計?4周在線學習,搶占職場優勢。了解一下>>

PRD除了描述產品的正面需求,即要什么之外,還要描述產品的非正面需求,即我不要什么,或預防什么。

筆者將非正面需求歸為三類:排除項、異常項、默認項。

一、需求的排除項

在PMBOX中,項目排除項是項目范圍說明書中的一部分。同樣,需求排除項, 也是需求范圍說明的一部分。

交代需求排除項,不僅要告訴開發人員,哪些是不需要的功能、哪些不是目標場景或目標用戶,而且要交代哪些觸發操作不被允許。

1. 哪些是不需要的功能

比如,GIF圖是很常見的圖片形式,但是「微信」規定,發布的圖片不支持GIF格式。

又比如,更換游戲用戶頭像是個很常見的功能,但是「王者榮耀」就不支持(直接)更換頭像。

這些是產品克制的體現、邊緣性需求,或者說是功能邊界,當然也可以簡單歸屬為產品的個性化玩法。

作為產品經理,一方面需要基于產品定位,主動設置這樣的功能空缺,好像書法“飛白”,讓產品更加立體和獨特;

另一方面,某些時候受限于資源(比如開發人員不足),只能實現部分優先級高的需求,這時候也要被動地劃分出階段性的需求邊界,待日后做增量迭代。

不管上述那種動機導致的“非需求”,產品經理都要明確地將這些不需要的功能點,作為需求的一部分呈現在PRD中,以便團隊步調一致,避免思維定勢導致實現錯誤。

2. 哪些觸發事件不被允許

舉個例子,我們通常說點擊按鈕打開新頁面,指的是「單擊事件」。但是有時候代碼不做排除的話,就會將雙擊事件當做兩次單擊事件進行執行。

于是出現雙擊之后打開兩次頁面。那么用戶在新頁面操作完,返回的時候就需要返回兩次。如下圖演示了雙擊「搜索」和雙擊作者「頭像」時分別按兩次單機處理的畫面。

當然這與開發的細致程度和經驗也有關系。但作為產品經理,可以事先跟團隊約定:

  • PRD中不提雙擊的,則一律將該控件的雙擊事件都定義為無效。
  • 只在需要雙擊的時候才定義雙擊事件。比如抖音,雙擊視頻畫面則為點贊,單擊則切換【播放/暫?!?。

3. 哪些不是目標場景或目標用戶

比如業務規定,主播在直播間獲得打賞的虛擬物品,可以對應領取指定的實物商品。那么假設,某主播積攢了上百個同一虛擬禮物,并且要同時全部領取。

但是實物庫存不夠,主播以“平臺不守信用”為理由投訴平臺,該怎么辦?

辦法很多。要么就規定每次只能領取n個(n在試運營階段確定);要么發現庫存不足的時候,提前發出延遲供應的免責聲明;要么就通過客服下線解決(比如兌換同價值商品或現金)。

總之,在這件事上,不把這種場景作為產品設計的考慮對象。即不為其開發對應的產品功能,也不考慮其他辦法解決該問題帶來的不良的用戶體驗。

因為根據邊際效益,或者說產品定位來說,這種場景下的這號人就是排除項。既不是我們鼓勵的現象,也不是能為產品帶來價值收益的場景,同時花費精力只能讓產品失去重心。

產品經理在對待類似這種情況時,要判斷出這是不是我們的目標用戶和場景。如果不是,需在方案評審時或者在需求背景描述時候加以解釋,并果斷轉換解決方案。

二、需求的異常項

異常,主要包括目標App本身的異常、手機系統環境引發目標App的異常,和周邊平行應用引發目標App的異常。

1. App本身設計的異常

舉個例子,電梯中打開App,到達初始頁面【首頁】,界面顯示在加載。我們知道,這是網速問題。

這時候點擊【我的】菜單,想看草稿箱。但是發現無法打開【我的】。退出重啟,依然如此。

【我的】是本地文件,不依賴網速,卻為啥也打不開呢?

其實是因為代碼這樣定義的:打開App,要做一次初始頁面的加載,沒加載好,就不會允許其他操作。

這就導致了無需加載的【我的】頁面,雖然不依賴網速,但是因為依賴網速的【首頁】沒完加載,所以“殃及池魚”,【我的】也打不開了。

因此,作為產品經理,對于這種初次加載App的規制,就要做一個最長加載時間的設置。比如,若2s仍舊加載不出來,則切換到無網情況下的機制展示(無網絡情況下可以查看頁面)。

2. 外部環境導致的異常

以系統的定位功能為例,正常情況下,若定位系統開啟,那么打開App,定位功能就會為App提供當前位置,并展示在頁面。

但是若手機定位不開啟,那么APP的位置就無法獲取。

這時候就需要產品經理考慮,在這種手機GPS異常(系統設置帶來的異常)情況下,位置顯示什么?比如是顯示空、還是圖標。

同樣,如果手機未聯網,或者網絡不通暢導致的加載失敗 ,就該提示“加載失敗,稍后再試”。

如果App檢測到斷網了,或者網速不好,就該更準確地提示“網絡不佳”。

3. 平行應用影響導致的App異常

比如,當手機開啟藍牙,并且被另一個手機連上的時候,就會在手機頂部展示一行狀態:1個連接。

這時候實際手機界面被這一行擠壓了。

遇到全屏播放的界面,就會出現下圖這樣:頂部Tab頁簽下移,視頻畫面不居中,底部菜單下移。

App是否有考慮過這種情況下的界面兼容呢?如果沒考慮,那么就會出現這一合理場景下的異常bug。

又比如,一個語音聊天應用,當按住home鍵切出去的時候、來電話的時候、當用戶執行其他應用的時候等,該怎么規定呢?

作為產品經理,拋磚引玉一個方案例子:

a.【語音聊天】時 home鍵切出來,不影響聊的功能。

b.【語音聊天】時 不管是否切出去,若來電話(電話未掛斷的情況下) 則雙方屏蔽語音,但不掛斷。同時給對方toast提示:對方忙碌,馬上就好!

c.語音聊天時 切出去,看視頻、聽歌曲、打開其他應用(如微信)進行視頻等,都不影響語音聊天。(是否影響到效果,玩家自行處理)。

三、默認值設置

1. 默認頭像

這就像是統一制服一樣,不能因為這個孩子沒準備衣服你就讓他裸著出場。所以要確定一個這樣的圖。

這個頭像可以是灰色底圖,比如花椒的就是。也可以定制帶產品元素的,比如映客的。

2. 默認昵稱

好處就是萬一用戶懶得寫,也不至于空蕩蕩的。

產品經理設計一個昵稱庫,隨機給用戶分配昵稱,有時候還有意想不到的驚喜感。

個性簽名也是同樣的道理。

3.?默認提示

在無數據的頁面,比如【好友列表】,如果不告訴用戶這里確實沒數據的話,用戶可能會懷疑是不是App故障導致的呢。

所以產品經理一般都會給予一個默認的全局通用的提示,比如“暫時無數據哦”。

4. 默認封面

比如相冊, 在網速不好的時候,加載不出來,那么怎么辦呢?黑洞洞的不好看,所以也需要產品經理確認一個默認的封面或者數據背景圖。

這樣大家一看就明白了,哦,是沒加載出來啊。

5. 其他默認項

默認項總體上就是通用規范范疇的。遠不止列舉的這幾項。產品經理應事先就做全局設計,確保默認項一致、通用,且不遺漏。

總結

一個產品可以拆解梳理出一份PRD;但是反過來,提供這份PRD給開發,卻往往不能逆向地輸出同一個產品(假設UI一樣)。

這就是bug的誕生,和測試的必要性。

因此在確認PRD的時候,就像素描,不僅要高光區,還需要陰影區。

產品經理在說完正向的要什么之后,還要說清楚不要什么、異常情況下怎么辦,以及默認怎么辦。只有將細節說完備,才有可能讓需求完整落地。

 

作者:唧唧歪歪PM;公眾號:唧唧歪歪PM(ID:jjyypm)

本文由 @唧唧歪歪PM 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 我一口氣看完了你所有文章

    回復
    1. 肺活量鯨人

      回復
  2. 請問這三項是不是屬于非功能需求里面的?

    回復
  3. 但是項目的需求分析是漸進明細的。不可能一次性的做到事無巨細后再進行開發。

    回復
  4. 學習了

    回復
北京赛车投注