做一個互聯(lián)網(wǎng)產(chǎn)品設(shè)計者，編寫Use Case是日常工作的一個重要內(nèi)容，也是重要的技巧。
回想起來自己當(dāng)年從市場部轉(zhuǎn)入到產(chǎn)品部，編寫UC也是從0開始，最初就是拿著別人寫的東西，然后按照自己的思路去設(shè)計新產(chǎn)品。剛好今天因為工作的關(guān)系，又再跟同事說如何寫好UC，順便這里總結(jié)一下。
先發(fā)一個UC的常用模板：
————————–
用例名稱
最新更新日期：
負(fù)責(zé)人：
用例描述：
用戶界面設(shè)計：
用例場景：
用戶：
前置條件：
主流程：
后置條件：
擴展流程：
輸入項詳列：
輸出項詳列：
關(guān)聯(lián)ＵＣ
補充規(guī)約：
遺留問題和可能的解決方案：
————————–
作為產(chǎn)品設(shè)計師，開始做一個新產(chǎn)品設(shè)計，一開始的時候，通常是在腦子里面的一堆想法，idea或者是跟需求方討論出來的一些業(yè)務(wù)規(guī)則等等，最終要變成可以實施的項目，需要產(chǎn)品設(shè)計師去梳理，規(guī)范化需求，并最終形成需求文檔，UC是其中最典型的文檔產(chǎn)出物了。
我的建議是：
1、原則上流程圖，特別是業(yè)務(wù)流程圖是最先開始要拿出來的，在流程圖中要確保各個業(yè)務(wù)流程是完整的，而且是效率最高的。這個需要比較多時間的討論和細(xì)化。
2、將業(yè)務(wù)流程拆分成為一些典型的用戶交互模塊。比如：用戶管理�？�、帳戶管理模塊等
3、將每一個模塊劃分成為典型的用例組合，比如：用戶注冊、用戶信息修改等等。
所以在具體開始寫UC的時候，我的建議是：
1、不要一個UC寫完整了再寫一個，建議是先通盤寫出所有UC的名稱（其實名稱一定程度上已經(jīng)定義好了UC的主要工作目標(biāo)了，比如：用戶注冊、注冊用戶信息修改、帳戶信息檢索等）。等于是寫文章的一個提綱，主要的章節(jié)都有了。然后再看一遍，對照自己腦子里面的業(yè)務(wù)流程，看看是否有遺漏的。
2、寫完成UC的描述，我的常用格式是：通過本UC….， 比如“通過本UC，用戶可以完成支付寶用戶的注冊�！� UC 描述基本上已經(jīng)明確定義了該UC的范圍，大小。在往下寫之前，對該UC應(yīng)該完成的主要功能，以及會遇到的所有分支、輸入輸出應(yīng)該有明確的定義。UC的撰寫過程只是將上述的內(nèi)容進行細(xì)化和規(guī)范化，變成其他人可以閱讀使用的東西。特別提醒一點：UC是給別人看的，而不是你自己看的。
3、下面說說正式寫UC正文的時候，我個人覺得特別要注意的地方：
正確的定義UC的用戶和前置條件，將會有效的改善UC的流程復(fù)雜性。比如：淘寶要做一個專門為淘寶賣家準(zhǔn)備的產(chǎn)品。淘寶賣家第一次進入該產(chǎn)品，需要確認(rèn)一個服務(wù)條款。怎么定義用戶和前置條件？常見的會有：
用戶已經(jīng)登錄
用戶為淘寶賣家
用戶尚未確認(rèn)最新版本的服務(wù)條款
根據(jù)上面的業(yè)務(wù)是為淘寶賣家做準(zhǔn)備而言，上面的用戶定義貌似沒有問題，但是在實際產(chǎn)品設(shè)計中中會遇到一個問題：怎么判斷用戶是淘寶賣家？用什么條件？看，麻煩來了，所以，我的建議是，把上面的第二條去掉。會有問題嗎？當(dāng)然具體還是要看業(yè)務(wù)，我只是舉例子，說：用戶的定義將很大程度上影響流程的復(fù)雜性。
4、主流程一定是你希望的流程，你認(rèn)為用戶最順利操作你的產(chǎn)品的流程，那么它就是主流程。很多Pd在寫UC的時候。主流程無比復(fù)雜，里面加入無數(shù)的判斷，就是因為這一點上沒有明確。我自己的感覺是，往往一個UC，主流程可能很短，而分支流程會比主流程多，而且復(fù)雜。
Kimi注：未完，待續(xù)
粵公網(wǎng)安備 44010402000282號