不想被程序懟?我總結(jié)了產(chǎn)品文檔80%易犯的邏輯遺漏問題

7 評論 9851 瀏覽 94 收藏 7 分鐘

編輯導語:產(chǎn)品經(jīng)理的日常就是懟開發(fā)以及被開發(fā)懟,那么,如何才能避免這種情況、順利進行評審呢?本文作者總結(jié)了一份產(chǎn)品文檔中80%容易犯的邏輯遺漏問題。如果你能很好地解決這些問題,那在文檔邏輯的撰寫上就能夠解決不少問題。

“你這個產(chǎn)品設計有好多邏輯bug,你想清楚了再開評審啊~”當你被技術一頓懟后,你痛下決心,下次一定要讓自己把所有可能的邏輯點全部考慮清楚。結(jié)果到了下次,又是一頓懟…

面對這種問題到底該如何解決?如何才能更好規(guī)避邏輯上的遺漏?

其實這個問題非常容易解決,在你生活中做產(chǎn)品設計邏輯思考時,很多問題的遺漏都是有規(guī)律的,只要找到這些規(guī)律,80%以上的邏輯問題都能解決。今日我們主要就講講邏輯梳理中的——數(shù)據(jù)篇,以下總結(jié)全部來源我個人的經(jīng)驗總結(jié)。

特別說明:此處的數(shù)據(jù)并不僅僅指單一數(shù)據(jù),也包括整個頁面全部數(shù)據(jù)提交時候的判斷。

一、數(shù)據(jù)增刪改查的邏輯整理

1. 新增數(shù)據(jù)

  • 新增的數(shù)據(jù)與過往數(shù)據(jù)是否重復:比如設計電商商品管理后臺時,若用戶新增了一個與之前新增商品完全一致的產(chǎn)品,系統(tǒng)要如何處理?涉及到數(shù)據(jù)新增這是基本的邏輯問題,一定要添加說明。
  • 新增的數(shù)據(jù)是否存在上限與下限:比如當你作為電商產(chǎn)品涉及添加收貨地址時,用戶可以無限添加嗎?這里就要思考你數(shù)據(jù)的上限,而下限會在特定的一些產(chǎn)品里出現(xiàn)。
  • 新增的數(shù)據(jù)是否不符合格式:新增的數(shù)據(jù)需要符合每一個字段的基本規(guī)定,比如簡單的登錄注冊流程,若是手機號不符合字段格式,就會彈出基本的提示。

2. 刪除數(shù)據(jù)

不要想當然以為刪除一個數(shù)據(jù)是很簡單的事情,其實也涉及到以下兩個很關鍵的邏輯判斷:

  1. 刪除時是否需要相關提示:就像我們之前講過兩個原則——防錯原則和協(xié)助記憶原則,這兩個原則就是對該邏輯漏洞最好的答案;
  2. 刪除時其他頁面有無正在使用該數(shù)據(jù):這一點是非常重要,初級產(chǎn)品經(jīng)理在進行產(chǎn)品設計時,經(jīng)常會遺忘。尤其是B端產(chǎn)品,此類問題更是經(jīng)常涉及。

簡單舉例來說:餐飲SAAS后臺產(chǎn)品經(jīng)理決定刪除某個菜品數(shù)據(jù),那么就要考慮可能該產(chǎn)品在同時段已經(jīng)被客戶下單,這個時候數(shù)據(jù)如何處理?

——不要簡單的進行刪除。

3. 更改數(shù)據(jù)

數(shù)據(jù)往往涉及到修改,面對修改時,我們又會發(fā)生什么樣的邏輯遺漏呢?

  1. 改成的數(shù)據(jù)是否與歷史數(shù)據(jù)重復:修改完成的數(shù)據(jù)與過往某一條數(shù)據(jù)一模一樣,這個時候如何處理?
  2. 改后的數(shù)據(jù)是否出現(xiàn)不符合格式:修改后的數(shù)據(jù)是否符合字段規(guī)定標準,若不符合如何提示?

4. 查找數(shù)據(jù)

1)如果沒有該數(shù)據(jù)時,如何進行提示?

用戶在搜索查找的場景里,若沒有該數(shù)據(jù)信息,如何展示?

一般列表類的非常場景,做好相應提示處理–其次,有些產(chǎn)品可能也需要做一個引導。比如菜品搜索下沒有任何菜品,就可以添加一個【添加菜品】按鈕,將用戶快速引導到我們的添加功能,這也符號產(chǎn)品的靈活高效原則。

2)如果查出的數(shù)據(jù)超出限制,如何顯示?

數(shù)據(jù)庫有該數(shù)據(jù)100條,這個時候如何顯示,顯示排序的規(guī)則又是什么樣的?

一般列表類顯示,都是分頁加載方式。

二、數(shù)據(jù)的使用、顯示、刷新、排序

1. 使用數(shù)據(jù)時

1)若存在多個用戶同時使用時,是否會發(fā)生沖突?

比如用戶購買商品時,什么時候要校驗庫存。因為多個用戶購買時,就很容易發(fā)生某個人下單后,其他人購買時庫存為0。

2)若單一用戶使用數(shù)據(jù)時,停留時間過長時數(shù)據(jù)如何反饋?

簡單比如說,你在京東購買商品不支付,跳轉(zhuǎn)到待支付頁面,然后你在該頁面停留了24小時以上,超過了待支付的期限,這個時候你再進行操作,頁面如何反饋?

2. 顯示數(shù)據(jù)時

  • 無數(shù)據(jù)的顯示:如列表頁,當沒有數(shù)據(jù)的時候要如何處理?這個在面對數(shù)據(jù)時是基本的提示操作;
  • 數(shù)據(jù)極大極小化顯示:比如抖音的消息提醒,如果1000條消息,怎么顯示?這個時候一般是99+,而微信也采用了“···”。

3. 刷新

  • 數(shù)據(jù)頁面是否需要刷新:若需要刷新,采用哪一種刷新方式?
  • 是否要做到實時刷新:該數(shù)據(jù)是否需要實時刷新?

4. 數(shù)據(jù)的排序

排序:如果有數(shù)據(jù)如何進行排序;如果數(shù)據(jù)相同,按照什么優(yōu)先級進行排序。

這就是關于數(shù)據(jù)遇到的一些邏輯問題,當你能夠很好地解決這些問題,對于自己在文檔邏輯撰寫上就能夠解決不少問題。

 

本文由@梁漩智 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 整理的不錯,加油繼續(xù)!

    來自浙江 回復
  2. 其實很多都是數(shù)據(jù)庫知識。認真學習一下數(shù)據(jù)庫,其實還好。這些都不是什么大問題,開發(fā)指出來,產(chǎn)品改一改。
    產(chǎn)品根源的設計就容易導致數(shù)據(jù)邏輯的混亂,曾經(jīng)我改了好久。
    對于后端來講,最重要的就是數(shù)據(jù)庫和SQL增刪改查。

    來自浙江 回復
  3. 除了數(shù)據(jù)篇,還有其他的嗎

    來自四川 回復
  4. 哈哈,我就是做餐飲的。上個月天天被懟,就是因為文章內(nèi)這些

    來自浙江 回復
    1. 以后他們就慢慢沒機會了~

      來自北京 回復
  5. 同作者感同身受,猶記得以往也犯過同樣的錯誤,支持作者分享這些有用的經(jīng)驗。

    來自廣東 回復
    1. 好的呢~

      來自北京 回復