跳到主要內容區塊

政府網站營運交流平台-中文

網路趨勢與社群應用分享

獨立設計工作室的UX怎麼跟UI合作

UIUX相關的社群常常討論UIUX的職責以及如何分工的話題。

先前提到,許多台灣的UIUX工作者經常陷入「UX工作上常見的多重角色困境」,要不就是「設計僅一位」,要不就是「PM為什麼要會做設計」的困境。

我的觀點是,UI、UX的分工是「被發明」出來的工作流程,不應該有教科書式的規章來定義「正確的團隊配置」,但應該要有共識,如果我們要解決什麼問題(例如搞不懂產品方向),就需要有對應技能的人(例如需要用戶訪談、需要數據分析、需要工程技術的實現)。

舉我們家UIUX設計工作室為例,主要角色是UI、UX各一位,我們常以外部合作角色參與客戶的專案開發,下面跟各位分享我們的UI設計師與UX設計師如何分工。

圖一、釐清利害關係人
UX與UI工作接力的流程

專案啟動初期,合作方式談妥之後,我們的 UX 會開始與客戶一起工作,此時 UX 會進行的工作項目是專案前期企劃的準備...

圖二、專案前期的準備
專案前期的準備時,UX已經開始投入大量的時間參與

釐清利害關係人

包括客戶的團隊內部關係是如何溝通工作流程、客戶上面的老闆對於專案的期待、客戶的上下游供應鏈有哪些合作廠商可能影響或參與專案、客戶面對的市場環境。
產出:商業模式分析、心智圖分析
白話文:向上管理你所有的老闆、陪公子練劍。

專案規模與風險分析

專案一定有時程、預算的範圍,但每個人對於規模的認知不同,每個利害關係人對於風險的評估方式也不同,在這個階段要盡可能調查大家腦袋中對於專案的共同想像。
產出:需求訪談、旅程地圖、數據分析
白話文:不要相信任何人嘴上說的「很簡單」,你腦非我腦。

需求情境定義

在利害關係人共同認知需要解決的問題情境中,跟PM或Product Owner 一起定義出專案資源有能力解決的範圍。一個最終需要達成的目標(例如購物成功),可能有多個情境要服務(例如不同族群選擇超商取貨跟信用卡交易就造成金物流情境不同),所以情境之間的複雜度與矛盾衝突會大幅提昇專案困難度。
產出:角色誌Persona、服務流程圖
白話文:老闆你要認清現實,沒有一種流程可以服務「所有人」。

通常跟著客戶的PM或PO一起搞定上面三步驟之後,對於其他專案的開發成員來說,才會準備召開「專案啟動會議」,宣布專案目標以及討論解決方案,此時團隊的所有成員理論上在上述三步驟中都被騷擾過,進行程度不一的需求訪談、情境討論等。

圖三、資訊架構以及wireframe是連結設計師與工程師的工作藍圖
資訊架構以及wireframe是連結設計師與工程師的工作藍圖

接下來階段通常是以Scrum的方式每週或每兩週提交進度,我們家的UX會繼續…

提出資訊架構

把服務流程落實在功能規劃與介面規劃上,UX在此階段反覆的逼問RD或UI,我們有哪些可行的解決方案可以拿來搞定目標與情境。
產出:功能規格文件、Sitemap、局部流程的Low-fi prototype(俗稱低保真)
白話文:讓大家一起畫押出解決方案比較有參與感,不要靠PM拍腦袋

產出設計藍圖

也就是俗稱的 wireframe,我們家是UX在畫 wireframe,因為從頭到尾 UX 參與了需求確認跟情境定義的過程,此時 UX 的腦袋裡塞滿了大量關於專案的認知細節,如果交接給別人畫,一定會漏東漏西。
產出:UI Flow、wireframe

延伸1:線框圖(Wireframe)標註的識別規劃小技巧
延伸2:繪製線框圖(Wireframe)的視覺處理小技巧

到這邊,會交由 UI 接棒,我們家的 UI 會繼續…

圖四、UI設計師將概念、想像落實成為最終產品的真實樣貌
UI設計師將概念、想像落實成為最終產品的真實樣貌

產品識別規劃

確認客戶是不是有自己的品牌設計資源,產品想表達的形象是什麼?但我們家不幫客戶設計品牌識別,而是依據客戶的品牌識別建立後續專案可以用上的設計資源。
產出:UI kit

介面設計

UI 看著 wireframe 會重新檢視或討論介面中的資訊量、流程,並且依據不同裝置的特性再提出介面設計上的解決方案。我們在此階段判斷是否要修改 wireframe 的依據是:
☛ wireframe 原本要解決的情境問題,是否有更好的解決方案?
☛ 新的解決方案,會不會影響技術規格?(因為RD會先檢視 wireframe 來判斷系統的複雜度)
產出:mockup、展示整體流程的hi-fi prototype(俗稱高保真)

切版出圖

如果是網頁,我們家 UI 同時也是資深的網頁設計師,會撰寫 html / css 完成 RWD網頁,以及基本的 JS特效,APP 產品的話就是撰寫介面註解以及切出所有的icon 素材等等。

同場加映:數據分析

UX會再接手,協助客戶規劃數據上的事件追蹤佈點,我們會從 GA 分析回饋的行為數據,跟客戶一起討論產品所預設的情境規劃是否符合行為轉換的想像?並且提出持續改善的建議。(或者更多的質化研究、用戶訪談)

以上工作流程是我們這些年來摸索出的合作方式,開發團隊規模在10人左右也差不多適用,但對於 UX 與 UI 的合作信任度以及專業要求都高。

但話又說回來,一個缺乏互信的開發團隊,也不是一個好的工作環境,再好的工作流程都沒輒。

希望這篇我們家的分工流程能幫助你認識不同工作環境的合作方式,也希望能多了解不同UIUX工作者你們的分工方式,歡迎寫信或留言給我!

 

王彥博 / Soking

從產品設計師,多年新創公司、社群以及媒體經驗,提供數位產品設計的顧問服務以及 UX 教育工作坊。 個人 UX BLOG 獸群之心:https://medium.com/@soking

原文出處Medium;政府網站營運交流平台授權轉載