上篇請看這裡 6個步驟估算UX規劃所需的專案時程 (上)
步驟四：加入狀態的考量
製作不同狀態的工時經常會被忽略，原因是較缺乏經驗的專案負責人會用理想狀態去估算整個專案的規模，最常出現的對話就是：
PM：「這個新功能很簡單，我們只要加一頁就好了」
我：「欸我覺得不只喔，這個功能加上A狀態、B狀態還有什麼什麼的情況就變成 4頁了」
一個頁面會有各種狀態，加上這個頁面本身的複雜程度，對設計和開發單位來說，「1個狀態就是0.5~2頁+的工」。在這個步驟最好一邊做一邊密切和SA或開發團隊確認，也可能會發生必須去修改步驟二flow的狀況。
常見的狀態通常有：
- 理想狀態：就是最理想狀況下的頁面內容
- 局部狀態(半成品狀態)：有累積進度、或是可以暫存草稿等功能的畫面較容易遇到這種狀態。
- 空狀態：無資料狀態，可能是初始的狀態，或是User將資料手動清空之後看到的狀態。
- 錯誤狀態：各種發生錯誤的狀態，例如搜尋沒有資料、API沒有回應、Session過期等。
- 等待狀態：在某些情況下，頁面上可能會有User的action做完之後，系統無法馬上告知完成的情況，最基本的像是Loading狀態，或像是一些需要人工審核的流程等等。
- 倒退狀態：在一些具有步驟性的流程、或是可以「反悔」的狀況下，也需要考慮倒退狀況的處置，例如，如果想按上一頁回去修改之前的表單怎麼辦？User在購物點數入帳的隔天做了退換貨怎麼辦? 等等。
做完這個步驟，你會發現，實際要製作的頁面可能並非想像中的4、5頁，而是20、30頁，最後畫出來的Wireframe畫面數也會非常接近這個步驟估出來的數字。
步驟五：估算時間 (修改Wireframe以2次為準)
估算完範圍之後，就進到估算時間的部分了，以網頁而言，我產出第一版包含線框、流程和註解的文件，1個頁面平均會抓0.5~1個工作天，有些頁面結構是可以共用的，我會將之計為0.5頁；但也有些頁面複雜度特別高、互動特別多，可能一邊做還必須找參考資料或是和同事討論，因此會用超過1天的時間來規劃。每個專案情況或是每間公司的分工不同，這個時間僅能做為參考。
估完產出第一版的時間，再加上2次修改的時間(總共產出3版)、以及因應潛在風險因素所需的緩衝時間，就是我最後交付的UX規劃時程。
如果前面幾個步驟都有確實地做好，那麼除了因為prototype test而導致頁面修改、或是對方需求大轉彎等狀況之外，通常不會需要多次來回修改wireframe就可以確認完畢，預先談定修改次數也有助於減少無止盡需求變動修改的狀況。因此我通常會以調整1–2次的時間去估算時程。調整一版，大約抓2–3個完整工作天，當然，這也是依照專案複雜度而定。
在這個階段，我也會考量PM所提出的時程來談定交付成品的詳細程度，若時程被壓縮得很緊(這也經常發生)，那麼我可能會說第一個版本我只交付理想狀態，其他狀態後補，或是建議將非主要任務流程的功能捨棄、或拆成不同階段來開發等等。
將原本應該一整份交付的頁面依主要功能拆開，分階段交付，好讓設計可以平行開工，也是一個對應壓縮時程的方法。
步驟六：加入其他風險因素
即時前三個步驟都好好地確實作完了，還是可能會有一些風險因素導致時間估不準，例如，無法馬上確認第三方的資料源或API能提供什麼內容、需求單位說某個功能要回去和老闆討論然後一直沒回覆你等等。因此可以抓一點緩衝時間，也要將這些風險在一開始時就和專案負責人說明清楚。
因為風險因素而多抓的緩衝時間並無標準可言，如果你覺得這些不確定因素很可能大大影響你的流程規劃，最好的做法還是談定「等確定才能開工」(當然你還是可以先做一些準備)，畢竟，沒有道理其他人可以說「我不知道、我不確定」，但是你卻必須產出所有詳細的規格，對吧？
交付專案時程
整個6步驟所需的時間，視專案規模、複雜度、和需求與開發團隊溝通討論的頻率與效率而定，可以是3天~一個月以上。
完成以上的步驟之後，通常就能給出交付第1、2、3個版本的時程了、談定交付的範圍與完成度、也溝通了潛在的風險，而且不會相差太遠，因為通常你也已經在這幾個步驟中，大致想好規劃要怎麼做了。
如果有什麼想法，歡迎留言討論喔!
