6個步驟估算網站UX規劃所需專案時程(上)

在我剛入行的前幾年，工作上常會遇到的一個問題是不知道怎麼估算專案時程和範圍，原因是UX 設計師常常需要在整個專案需求都尚未明朗的時候就加入擔任規劃的角色，而且經常馬上被PM問的第一個問題就是「你要多少時間？」

工作幾年之後我漸漸發展出一個可以還算準確地估算範圍的方法，依循以下六個步驟，最後計算出的範圍和時間都不會差距太遠，也可以減少專案開始之後才發現有未考量到的情況，而導致需求擴張的情況(但客戶的需求大轉彎等狀況，不在此列)。

步驟一：定義應用場景

在這個階段，務必要求跟PM或業務一起出席需求說明會議，UX可以透過一般的需求訪談、利害關係人訪談，或是爭取多做使用者訪談，來定義初步的需求場景。
需求場景並無一定的寫法，你可以使用Use Case、User Story或是簡單的5W1H等格式，甚至只是簡單的一小段話，只要能描述出對方的需求和目標即可，例如，一個需求場景可能是：

「我們想要做一個產品保固期限查詢面網頁，客戶可以自行輸入產品的序號查到該產品的保固期限，藉此來減少電話客服的使用量。」

步驟二：以流程為中心的範圍估算

這個階段，我會把客戶的需求場景轉換為flow順一遍。如果有多個場景，就會有多條流程。這個階段的重點是把流程梳理一遍，把重要的節點和步驟標示出來，確認是否有遺漏的環節、是否會對其他現有相關頁面造成影響？這個階段也要確認必要的資料源是否可以串接。

例如，在「產品保固期限查詢頁面」的需求中，我們並不只單純考慮發生在查詢頁面上的互動，我們還必須考慮User要如何得知官網新增了這項服務? 我們應該讓它露出在哪些位置？如果查完對保固期限有疑問，應該如何引導他們使用FAQ或線上客服等低成本管道…等等。

同樣的，這沒有特定的寫法，我會視專案的需求複雜程度，使用一般的Flow chart(只包含主要的前台頁面)，或是Service Blueprint(標出前台、後台或其他資料源)，你也可以用SA常用的Activity diagram等圖表來呈現。

這個步驟完成就可以馬上和需求單位討論確認共識了，不需要等wireframe畫完才確認。

步驟三：以頁面為中心的範圍估算

關鍵的節點和步驟等流程大致底定之後，我會轉換成site map的形式再估算一次，原因是不管是要轉換成後續的wireframe、GUI或是前端要估算工作，都是會以頁數為基準。

下篇請看這裡 6個步驟估算UX規劃所需的專案時程 (下)