做一個互聯網產品設計者，編寫Use Case是日常工作的一個重要內容，也是重要的技巧。
回想起來自己當年從市場部轉入到產品部，編寫UC也是從0開始，最初就是拿著別人寫的東西，然后按照自己的思路去設計新產品。剛好今天因為工作的關系，又再跟同事說如何寫好UC，順便這里總結一下。
先發一個UC的常用模板：
————————–
用例名稱
最新更新日期：

負責人：

用例描述：

用戶界面設計：

用例場景：

用戶：
前置條件：
主流程：
后置條件：
擴展流程：
輸入項詳列：
輸出項詳列：
關聯ＵＣ

補充規約：
遺留問題和可能的解決方案：

————————–

作為產品設計師，開始做一個新產品設計，一開始的時候，通常是在腦子里面的一堆想法，idea或者是跟需求方討論出來的一些業務規則等等，最終要變成可以實施的項目，需要產品設計師去梳理，規范化需求，并最終形成需求文檔，UC是其中最典型的文檔產出物了。

我的建議是：

1、原則上流程圖，特別是業務流程圖是最先開始要拿出來的，在流程圖中要確保各個業務流程是完整的，而且是效率最高的。這個需要比較多時間的討論和細化。
2、將業務流程拆分成為一些典型的用戶交互模塊。比如：用戶管理模款、帳戶管理模塊等
3、將每一個模塊劃分成為典型的用例組合，比如：用戶注冊、用戶信息修改等等。
所以在具體開始寫UC的時候，我的建議是：

1、不要一個UC寫完整了再寫一個，建議是先通盤寫出所有UC的名稱（其實名稱一定程度上已經定義好了UC的主要工作目標了，比如：用戶注冊、注冊用戶信息修改、帳戶信息檢索等）。等于是寫文章的一個提綱，主要的章節都有了。然后再看一遍，對照自己腦子里面的業務流程，看看是否有遺漏的。

2、寫完成UC的描述，我的常用格式是：通過本UC….， 比如“通過本UC，用戶可以完成支付寶用戶的注冊。” UC 描述基本上已經明確定義了該UC的范圍，大小。在往下寫之前，對該UC應該完成的主要功能，以及會遇到的所有分支、輸入輸出應該有明確的定義。UC的撰寫過程只是將上述的內容進行細化和規范化，變成其他人可以閱讀使用的東西。特別提醒一點：UC是給別人看的，而不是你自己看的。

3、下面說說正式寫UC正文的時候，我個人覺得特別要注意的地方：

正確的定義UC的用戶和前置條件，將會有效的改善UC的流程復雜性。比如：淘寶要做一個專門為淘寶賣家準備的產品。淘寶賣家第一次進入該產品，需要確認一個服務條款。怎么定義用戶和前置條件？常見的會有：
用戶已經登錄
用戶為淘寶賣家
用戶尚未確認最新版本的服務條款

根據上面的業務是為淘寶賣家做準備而言，上面的用戶定義貌似沒有問題，但是在實際產品設計中中會遇到一個問題：怎么判斷用戶是淘寶賣家？用什么條件？看，麻煩來了，所以，我的建議是，把上面的第二條去掉。會有問題嗎？當然具體還是要看業務，我只是舉例子，說：用戶的定義將很大程度上影響流程的復雜性。

4、主流程一定是你希望的流程，你認為用戶最順利操作你的產品的流程，那么它就是主流程。很多Pd在寫UC的時候。主流程無比復雜，里面加入無數的判斷，就是因為這一點上沒有明確。我自己的感覺是，往往一個UC，主流程可能很短，而分支流程會比主流程多，而且復雜。
Kimi注：未完，待續

原文：http://www.kimihome.net/blog/?p=701