專案背景

這個專案是一個地方政府的單一陳情系統. 首先特別要說明的是這個專案算是公司的策略性專案, 在銷售階段以及風險評估階段就已知道這個專案風險很高, 虧本機率也高, 加上資源不足, 還有技術上的問題要克服. 但是當初因為有客戶關係以及其他因素的考量, 所以最後還是選擇接案. 我認為以後應該不太會再有這樣的思維了.

這個單一陳情系統, 主要是提供民眾可以即時做陳情, 投訴及檢舉等問題回報, 整合照片及地理資訊讓案件處理人員快速辨識問題, 使用自動分案技術來加速案件處理, 整合及保留案件及處理資訊以供未來分析決策使用.  系統包括受理子系統, 公務子系統, 以及報表. 系統提供 Web 以及 App介面, 並介接機關員工資料庫, 公文系統, E-Mail, 簡訊及派工系統等.

這個系統是該地方首長的重要競選政見之一, 在經費部分動用了預備金, 而非使用一般計畫性專案的預算, 因此這個系統備受關注.  這個系統因為提供民眾使用, 因此系統好不好用以及畫面美觀與否都非常直接, 因此在專案初期即將 UI/UX 以及視覺設計考慮進來, 前端 UI Designer一開始就加入專案.

專案進行

這個專案的 SA 和 PA/SD 都十分稱職, PA對專案掌握度高, 對成員的工作分配及能力訓練都做得很好.  系統架構設計清楚易懂, 切得乾淨, 專案成員的團隊精神很好, 例如週末加班全員都到齊,  SA 也常常在半夜還在測系統, 還有一位 SA車禍受傷, 還抱傷來趕專案工作. 大多數專案成員對於 PM, SA 和 SD也都持相當肯定的態度, 比較多的抱怨是畫面修改太多次造成重工.

前端設計過程

為了要讓 UI Designer更了解客戶需求, 因此一開始就請 UI Designer參與需求訪談, 並請 UI Designer提出構想, 和客戶討論及確認.  客戶除了承辦單位參與需求訪談之外, 還有一位國王的人馬加入指導.  這位指導對於 UI Designer 的構想, 經常提出主觀性的批評, 而且對於某些已經和承辦單位達成的共識, 也以不夠美觀的理由予以否決, 但又沒講出真正想要的設計是什麼, 甚至提出請專案團隊將 UI 設計整個外包的要求.  最後只好一方面請出講師級的資深 UI  Designer, 以專業的角度和客戶分享當代世界設計的趨勢, 來取得客戶對於專案團隊在UI設計專業能力方面的信任, 然後針對客戶喜歡的風格提出幾版設計構想.  另一方面 PM 則和客戶主管商量, 請首長在主管會議中就這幾版設計構想拍板定案.  這段時間也因為畫面多次修改造成程式不少重工, 因此整個設計也退回到以 WireFrame 來確認每一個頁面的結構, 內容和功能, 而且在向客戶提出方案之前, 專案團隊內部一定先討論過, 然後才在客戶的專案會議中展示和溝通, 並在會議中取得共識以及得到客戶主管的同意.

回顧

如果重新再來一次, PM 認為他會堅持採取先設計 WireFrame的作法, 然後在內部先更確實的討論之後, 例如要跟工程師討論一個設計需要程式方面多少 Efforts 之類的, 然後再去跟客戶確認.  因為頁面結構及內容確定後, 工程師就可以進行程式開發, 設計風格部分, 還可以慢慢和客戶溝通確認, 只要頁面內容不變, 程式可以不太需要修改.  另外, 在預算可能的範圍內, 進行使用者調查, 也就是對真正會使用這個系統的民眾(真正的End-user) 做意見調查, 因為一個系統只有民眾真正願意使用, 才不會變成蚊子館.

省思與建議

現在的系統開發, 無論是 Web 或App, 免不了都要做前端的 UI設計, 而前端的UI設計又會影響到程式設計, 因此 UI 設計應該要儘早定案, 個人認為UI 設計可能必須和需求階段並行或是當成需求階段的一部分.

UI 設計也有自己的流程, 因此和客戶訪談之後就請 UI Designer提出構想和客戶討論及確認, 可能不是一個好的方式. 比較理想的方式可能還是照著一般UI 設計的流程.

UI Designer 是否需要參與客戶的訪談, 基本上PM要自行判斷, 重要的是 UI Designer 是否能了解掌握客戶的需求與系統的功能.

後記

這篇是根據 PMO (公司內叫 OQMO) 成員 James 的分享以及專案 AAR 改寫而成, 並儘可能根據實際狀況, 希望能提供日後類似專案參考.