如何以用例驅動設計,寫出更高質量的PRD?

語言: CN / TW / HK

在評審階段,我們常常會因為一些疏忽的紕漏,導致需要變更需求,繼而耽誤進度。為了避免這種情況,該怎麼做呢?作者推薦了一個方法——用例驅動設計法,幫助你掌握科學的設計方法,做到不漏細節。

產品設計中,難免會遇到這樣一些問題:

  • 業務邏輯不全,沒考慮到分支流程、異常流程;
  • 互動細節沒考慮到,部分場景的處理方式缺失;
  • 關鍵業務規則缺失,未定義邊界值。

這些問題如果在評審中經常出現,很容易被研發測試吐槽,如果是在開發中出現,可能會通過變更需求來彌補,可能還會影響開發工期。

要避免這些問題,需要有一套科學的設計方法。刀哥給大家推薦一個方法,可以有效解決這些問題,我把它叫做用例驅動設計法,以用例驅動設計,保證業務、互動、規則都能考慮到,不遺漏關鍵細節。

01 什麼是用例?

用例是對參與者通過系統達成目標過程的描述。

用例是UML裡面的標準術語,也可以理解為功能模組,用例是參與者和系統的互動過程,是第三方視角,而功能是系統視角,可以從這個角度來加以區分。

一個完整的用例,包含用例名稱、參與者、前置條件、後置條件、主流程、備選流程、業務規則,這幾個部分。

用例名稱:用例名稱是一個動賓結構,如新增使用者、修改使用者、刪除使用者。用例也有層級結構,比如管理使用者是一級用例,而新增、修改、刪除,為二級用例。

參與者:是指執行這個用例的角色。

前置條件:要執行這個用例,需要具備的許可權、狀態等。

後置條件:執行完用例後,系統如何處理,比如增加一條資料、刪除一條資料、變更狀態等。

主流程:使用者達成目標的正常流程,分為參與者和系統。

備選流程:包含異常路程和分支流程,這部分是在梳理需求時,最容易被遺漏的。

業務規則:系統根據具體的規則來執行處理,這些規則,需要在用例的描述清楚,業務規則也是容易遺漏的點。

02 用例的其他部分

按照傳統的UML規則,用例裡是不包含介面互動的,用例更多的是表達邏輯,關心用例的更多的是後端研發,這是狹義的用例。

我把用例涉及到的介面也放在用例裡,我把它叫做廣義的用例,廣義的用例包含業務邏輯、欄位規則和介面互動。

業務邏輯主要包含流程和規則,欄位規則主要包含系統的輸入和輸出,介面互動是對頁面、控制元件的互動描述。

這樣一個廣義的用例,就可以把需求描述得很清楚,不遺漏關鍵細節。每個單獨的用例,可以作為設計、研發、驗收的單位。

03 如何以用例驅動設計?

以用例驅動設計,可以分為以下幾個步驟:

1. 梳理所有的用例

一個大的用例,可以分成更多的二級用例,二級用例又可以拆為三級用例,以每個具體的三級用例,作為產品設計的最小單位。

2. 寫用例

前面已經說過,用例包含名稱、參與者、前後置條件等要素。寫用例之前,可以先不用動手畫原型,也可以畫了一些簡單的原型再寫用例,具體根據自己的偏好。

以下是一個完整用例的模板。

這種是標準的用例協作方式,實際工作中,不一定要按照這種模板寫,也可以用流程圖+文字描述的方式書寫。比如在Axure裡面寫PRD,內容形式要求並沒有那麼高,甚至不用畫流程圖,直接文字描述也可以。流程圖的作用,是幫助我們視覺化業務邏輯,使設計更全面,不遺漏細節。

3. 設計互動介面

在做介面之前,可以先做一些競品調研,分析競品的介面及互動,然後再開始動手,在分析競品的時候,也可以看看別人的業務邏輯及規則,看自己的設計是否有考慮到。

比如,做驗證碼登入這個模組,可以分析國內幾家使用者量比較大的產品,看他們是怎麼設計的。

以下是京東APP驗證碼登入的互動介面。

第一步,輸入手機號。

第二步,輸入驗證碼。

通過對京東登入模組的分析,也可以試出他們的一些業務規則,比如:

  • 驗證碼有效期為1分鐘;
  • 同一手機號當日獲取次數最多為5次;

以上這些介面互動和業務規則,都可以作為我們設計的參考。

電商平臺的使用者量比較大,會考慮到很多使用者場景,對於這種通用的模組,參考大廠的做法,是比較保險的。

在分析完後,我們再來做自己的設計,就可以做到很全面了。

寫在最後

以用例驅動設計,可以全面的考慮業務邏輯、介面互動,不遺漏關鍵細節,以這種思路寫出的PRD,質量會更高。

寫出高質量的PRD,是產品經理的基本功,PRD質量高,才可以花更多的時間去思考產品規劃、產品迭代、產品運營等,進階高階產品經理。

自己梳理用例的時候,把正常流程、異常流程、分支流程,都考慮到,具體做互動設計的時候,可以去參考大廠的設計方案,按照這個思路設計,產品應該不會太差。

專欄作家

刀哥,微信公眾號:刀哥說,人人都是產品經理專欄作家。7年產品老司機,現任某網際網路公司高階產品專家,有豐富的金融專案經驗,豐富的實操經驗,擅於輸出接地氣的實用乾貨,幫助成千上萬的產品經理晉升成長。

本文原創釋出於人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基於 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

給作者打賞,鼓勵TA抓緊創作!