如何以用例驅動設計,寫出更高質量的PRD?
在評審階段,我們常常會因為一些疏忽的紕漏,導致需要變更需求,繼而耽誤進度。為了避免這種情況,該怎么做呢?作者推薦了一個方法——用例驅動設計法,幫助你掌握科學的設計方法,做到不漏細節。
產品設計中,難免會遇到這樣一些問題:
- 業務邏輯不全,沒考慮到分支流程、異常流程;
- 交互細節沒考慮到,部分場景的處理方式缺失;
- 關鍵業務規則缺失,未定義邊界值。
這些問題如果在評審中經常出現,很容易被研發測試吐槽,如果是在開發中出現,可能會通過變更需求來彌補,可能還會影響開發工期。
要避免這些問題,需要有一套科學的設計方法。刀哥給大家推薦一個方法,可以有效解決這些問題,我把它叫做用例驅動設計法,以用例驅動設計,保證業務、交互、規則都能考慮到,不遺漏關鍵細節。
01 什么是用例?
用例是對參與者通過系統達成目標過程的描述。
用例是UML里面的標準術語,也可以理解為功能模塊,用例是參與者和系統的交互過程,是第三方視角,而功能是系統視角,可以從這個角度來加以區分。
一個完整的用例,包含用例名稱、參與者、前置條件、后置條件、主流程、備選流程、業務規則,這幾個部分。
用例名稱:用例名稱是一個動賓結構,如新增用戶、修改用戶、刪除用戶。用例也有層級結構,比如管理用戶是一級用例,而新增、修改、刪除,為二級用例。
參與者:是指執行這個用例的角色。
前置條件:要執行這個用例,需要具備的權限、狀態等。
后置條件:執行完用例后,系統如何處理,比如增加一條數據、刪除一條數據、變更狀態等。
主流程:用戶達成目標的正常流程,分為參與者和系統。
備選流程:包含異常路程和分支流程,這部分是在梳理需求時,最容易被遺漏的。
業務規則:系統根據具體的規則來執行處理,這些規則,需要在用例的描述清楚,業務規則也是容易遺漏的點。
02 用例的其他部分
按照傳統的UML規則,用例里是不包含界面交互的,用例更多的是表達邏輯,關心用例的更多的是后端研發,這是狹義的用例。
我把用例涉及到的界面也放在用例里,我把它叫做廣義的用例,廣義的用例包含業務邏輯、字段規則和界面交互。
業務邏輯主要包含流程和規則,字段規則主要包含系統的輸入和輸出,界面交互是對頁面、控件的交互描述。
這樣一個廣義的用例,就可以把需求描述得很清楚,不遺漏關鍵細節。每個單獨的用例,可以作為設計、研發、驗收的單位。
03 如何以用例驅動設計?
以用例驅動設計,可以分為以下幾個步驟:
1. 梳理所有的用例
一個大的用例,可以分成更多的二級用例,二級用例又可以拆為三級用例,以每個具體的三級用例,作為產品設計的最小單位。
2. 寫用例
前面已經說過,用例包含名稱、參與者、前后置條件等要素。寫用例之前,可以先不用動手畫原型,也可以畫了一些簡單的原型再寫用例,具體根據自己的偏好。
以下是一個完整用例的模板。
這種是標準的用例協作方式,實際工作中,不一定要按照這種模板寫,也可以用流程圖+文字描述的方式書寫。比如在Axure里面寫PRD,內容形式要求并沒有那么高,甚至不用畫流程圖,直接文字描述也可以。流程圖的作用,是幫助我們可視化業務邏輯,使設計更全面,不遺漏細節。
3. 設計交互界面
在做界面之前,可以先做一些競品調研,分析競品的界面及交互,然后再開始動手,在分析競品的時候,也可以看看別人的業務邏輯及規則,看自己的設計是否有考慮到。
比如,做驗證碼登錄這個模塊,可以分析國內幾家用戶量比較大的產品,看他們是怎么設計的。
以下是京東APP驗證碼登錄的交互界面。
第一步,輸入手機號。
第二步,輸入驗證碼。
通過對京東登錄模塊的分析,也可以試出他們的一些業務規則,比如:
- 驗證碼有效期為1分鐘;
- 同一手機號當日獲取次數最多為5次;
以上這些界面交互和業務規則,都可以作為我們設計的參考。
電商平臺的用戶量比較大,會考慮到很多用戶場景,對于這種通用的模塊,參考大廠的做法,是比較保險的。
在分析完后,我們再來做自己的設計,就可以做到很全面了。
寫在最后
以用例驅動設計,可以全面的考慮業務邏輯、界面交互,不遺漏關鍵細節,以這種思路寫出的PRD,質量會更高。
寫出高質量的PRD,是產品經理的基本功,PRD質量高,才可以花更多的時間去思考產品規劃、產品迭代、產品運營等,進階高級產品經理。
自己梳理用例的時候,把正常流程、異常流程、分支流程,都考慮到,具體做交互設計的時候,可以去參考大廠的設計方案,按照這個思路設計,產品應該不會太差。
專欄作家
刀哥,微信公眾號:刀哥說,人人都是產品經理專欄作家。7年產品老司機,現任某互聯網公司高級產品專家,有豐富的金融項目經驗,豐富的實操經驗,擅于輸出接地氣的實用干貨,幫助成千上萬的產品經理晉升成長。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
作為測試,很喜歡看到一個比較完善的prd文檔,自己平時在看公司產品的prd文檔時,不知道看哪些重點,總覺得他們的文檔差什么,但又說不上來,現在知道了,其實他們很多時候只寫一個大概的業務流程和簡單業務規則,是有遺漏很多細節的規則限制,遺漏的部分就是字段規則和交互上的。
時隔一個多月看又有新的收獲
刀哥,有空能分享一下prd文檔嘛,感謝
豁然開朗,學到了!