UIUX｜如何從0到1，規劃一個後台管理系統（上）

(圖片來源：unsplash)

 ｜自我介紹

我是 Nia，目前任職於一間以接案為主要業務的軟體開發公司，職稱為 UX Designer，負責各類型專案（包含 App, Web, 管理系統開發等）前期產品資訊架構與使用者操作流程的規劃。 依據各專案所需，參與過程從協同 PM 與客戶進行需求訪談＆分析，繪製 wireframe 與客戶來回確認流程規格，銜接 UI Designer 完成視覺設計，並於開發實作中協助工程師正確理解產品的設計邏輯與流程。

 ｜主題契機

這幾年累積的專案橫跨各種領域，一開始還很菜的時候，面對 2C 產品都還有辦法從自身經驗，或其他同類競品中學(ㄇㄛˊ)習(ㄈㄤˇ)得到靈感；但一碰到 2B 產品時，除了自己經驗=0 之外，搜尋各大平台的學習資源也相對稀少，只能找尋一些介於 2B/2C 之間的產品使用經驗做為參考，粗淺地想像操作流程，同時還得不斷從客戶那裡挖掘一些專業知識，拼拼湊湊地把東西交出來。

時至今日，已規劃了不少客製的管理系統，包含 CMS 系統、會員管理系統、出缺勤系統、或是 ERP（報價/合約模組、銷售訂單模組、電子簽核模組、資料審核模組、請/採購模組、各類報表...）。雖然每次都是依據專案所需提供客製的規劃，但許多模組架構與規則大抵都是相同的，只是在某些細節上會依據產業不同或客戶特殊要求，而有或大或小的變動。

總之，進入正題，以下會分享我如何去規劃一個完整的後台管理系統的流程，希望有更多經驗交流的機會、或幫助有需要的人。

⬩⬩⬩

Stage 1：起手式 — 定義專案的目標

聽起來像是廢話的第一步，是要讓自己與團隊彼此的心裡有個底 —「有哪些產業知識需要特別去釐清」&「這個後台的規模大概在哪裡」。

➤  後台最基礎的概念

如果只是單純規劃一個網站的管理後台，其實不太需要額外的產業知識輔助，但你需要先知道什麼是 CMS（Content Management System, 內容管理系統），涉及所有類型後台最基礎的功能與概念。

用最簡單的方式解釋的話，可以從字面上直接解讀 — CMS 就是要「管理（某個地方）的內容」。「某個地方」經常是一個網站、APP或後台本人；「內容」可以是文字、圖片、影片、檔案...等（你想像在電腦世界裡會出現各種型態的東西）；「管理」則是使用者對內容執行的行為，包含建立、修改、儲存、檢索、刪除。

舉個例子，許多大眾在瀏覽的網站（我們稱為「前台」），都設有「最新消息」這類需要頻繁更新的頁面，但負責上稿的社群小編很可能不會寫程式，所以通常相對應會有一個管理該網站的管理系統存在（我們稱為「後台」），讓小編可以快速新增一個頁面，進行文字的編寫、圖片的編排，最後發佈並呈現在網站上，後續若有異動，小編也可以回去修改、刪除內容。

上述這些行為，其實與我們平常在 FB、IG 發布貼文無異，但管理後台追求的通常是能夠處理大量內容的效率，介面設計方向就會和 2C 產品有落差。2C 產品的流程，時常需要引導使用者 step by step 完成一個任務，每個任務的 loading 還不可以太重，以免造成中途放棄。而 2B 的後台，大多面相較專業的特定角色，會反覆操作相同的流程，在規劃就要著重「工作效率」— 能夠快速而精準的搜索資料、批次處理程序、統整並掌控全局。當然，這並不是定律，所有的規劃還是得考量使用者特徵與規模，對流程熟悉度與使用頻率等，提出適切的設計。

➤  產業知識

釐清產業知識靠的是經驗的累績跟不恥下問的精神。就目前我處理過的專案中，涉及額外產業知識輔助的包含電商平台、出缺勤系統、企業營運（生技產業、檢測產業、建築工程）。

以電商產業為例，它的後台系統相對容易理解，因為網購的行為流程一般人都經歷過，甚至還有不少身兼「賣家」的身份，而賣家管理自家賣場的那個系統介面，就是我某次專案的設計目標。不過，我們單就「買家」的面向去拆解，其實可以初步想像出後台至少有「商品管理模組（買家可以上、下架商品）」與「訂單管理模組（買家可以掌控每一筆顧客（我）購買的訂單）」。（如果有 CMS 的概念在前，這個雙向流程的關聯應該只是一塊蛋糕吧？）再從賣家的角度去思考的話，可能就會有更多需要控管的內容，如「商品庫存管理」、「訂單出貨管理」、「促銷折扣設定」、「金流設定」、「物流設定」、「匯出報表」等。

欸等等，是不是跳太快了啊，我又不是賣家，是要怎麼知道有這些功能模組？

第一，想辦法接觸目標使用者，或直接成為使用者。親朋好友先問一輪，除了有機會直接看到別人家的後台，也能夠透過聊天對話初步了解賣家生態。或是，現在很多平台審核賣家的門檻不高，註冊一下就可以使用管理後台，等於直接體驗，快速有效學習。

第二，不要放棄 Google 任何可用的資訊。剛好目前電商市場發展的非常完善，一堆教你成為各大平台賣家的文章、影片通通是養分（尤其是那種手把手教你操作畫面的部分），也順便把競品資料蒐集完一輪這樣。

最後，以上兩種都不管用的時候，就向你的客戶學習、請教。這種情況大多出現在知識門檻比較高的產業，例如：先前為建設公司規劃企業營運管理系統。首先，我不僅沒買過房子（就算想也無法即刻下單 💸 直接體驗流程 😭 ），更會不知道蓋一個建案需要經過哪些流程（當時還想著乾脆直接把我丟在建設公司跟著走一遍流程吧...可是人家建案才剛完工，完全錯過），所以我就當自己是一張白紙，帶著心中滿滿的疑問，透過後續無數次的訪談才進入狀況，這是後話。

➤  後台管理系統的規模

對於專案涉略的產業知識有一定的基礎之後，我就會根據列舉的功能模組（通常會有一份功能清單）、客戶初步提出的特殊需求、使用者角色區隔的種類/差異/數量等資訊，拿捏專案整體的複雜度、確認過去規劃經驗是否可供參考、估算溝通成本，最後回覆 PM 所需時程。

這裡對規模的「拿捏」完全是個人心中的尺標（=經驗），現在的我也僅能用過去的專案作為基準，參考相似的流程花了多久來回訪談確認，以估算規劃所需的時程。但如果是產業知識深又陌生的大型專案，其實是會在一開始就先切割功能模組，並區分開發階段，專案時程也就可能以年為單位計算，UX 規劃的部分也不會那麼緊繃（雖然長期的專案也隱藏著一些問題）。

落落長說到這裡，我們才算是有個明確的專案目標，但也只是協助 PM 完成專案部分的報價。 

⬩⬩⬩

Stage 2：使用者訪談

專案 kick off 後，通常前幾次的訪談，是要釐清整個後台範疇涉及的使用者有哪些，與系統循環運作的整體流程。

➤  釐清使用者角色

和 2C 產品一樣，我們還是得先定義專案的使用者是誰。

一般來說，使用者區隔越單純，整體複雜度會相對較低。例如在規劃出缺勤系統時，後台管理的目標使用者以公司的 HR 為主，負責處理員工、組織、休假規則、報表等的主要功能的設定，單一角色佔據 8 成以上流程的操作；而其他角色如老闆、主管級員工可能也會登入後台，但多以查詢、檢視資訊為主，使用頻率、涉及的範疇都低很多。在這樣的情況下，流程規劃會比較乾淨俐落，因為角色與角色之間的互動較少（＝較好處理）。

然而，專案目標是規劃企業內部營運系統的話，複雜度直接爆增 😭 。後台使用者大多會以企業的組織結構進行劃分，可能有部門、科別、處室、組別，以及需要額外劃分主管級的角色。理想狀況是，每個單位的業務區隔很清楚，工作流程也切割得很乾淨，但往往並非如此，組織或大或小總會有幾個特定員工，職務橫跨組別、部門，或是某個單位特別有份量，有權管控自己以外的業務，以及需要前段與後段流程連動的因應情境。

這些藏在訪談對話裡的微妙細節，都會影響到後續在規劃後台的權限設定、簽核流程的複雜度，甚或是功能模組的呈現。因此，了解該企業的組織構成，會是在初步訪談中一件很重要的事情，即便有些單位平時的主要業務並不在此系統中執行，仍擁有一定的影響力（常常是和錢錢相關的財務部門），並且在企業運作的過程中，每個單位環環相扣，其存在都有價值，這也是我們接著需要屏氣凝神接收的重要資訊。

_

➤  系統循環運作的流程

承接使用者的區隔，是我們要了解各個角色涉略的行為。

剛剛提到，若是角色單一的系統規劃，訪談時通常不超過 2 位使用者，就已經可以將系統整體的流程順過一遍，且流程在每個階段的銜接較不容易遺漏，因為都是由同一個角色完成，即便有 2~3 人分工，處理的內容會較為接近，能理解彼此負責的主要任務（畢竟有時候休假需要互相cover）。因此，就可以從他們平時的主要任務去切入了解，逐一彙整出整個系統，從初始設定到完成每個使用者任務的流程是什麼。

以出勤系統為例，我們可以從人事同仁平日的任務切入，如「掌握員工每日出勤狀況」、「處理人事異動」，或是定期在月初需「計算薪資」等，歸納與出勤相關的事務，這些是可以從訪談中獲得的資訊，然而要將這些任務轉化成在系統中實際的行為，就需要進一步的拆解。

拆解到最後，會發現剛剛的主要任務可以串成一個循環的流程。

到這邊其實已經把系統最主幹的流程擬出，雖然還有一些支線流程需要拆解，但已經可以清楚了解功能模組之間串連的關係。

實務上，我們不會這麼土法煉地只從單一任務，慢慢擴展到整個系統，而是多方條件與任務進行全局思考，並且解法也不會只有一個選項，但這個階段的原則就是要 — 確保每個大方向的需求被滿足時，所需資訊、流程沒有遺漏。舉例來說，出勤系統專案的最初，其實是先定調了「 打卡 APP」的流程，才接著把後台逐一規劃出來，但今天若改成使用門禁系統，前面拆解的任務哪裡又會不同呢？有興趣可以思考一下。

倘若是多角色的企業內部系統，訪談時最怕人多口雜，主持人需要很有意識地去控制討論內容不要在細節上鑽牛角尖，要記得最一開始的目的是要把每個角色之間，在系統上會如何互動與相關聯清楚理解，同時也是讓自己可以更融入使用者的氛圍中，絕對不要貪心地想著要在一次的訪談中，就蒐集到所有需求與釐清所有流程（這真的是我的悲痛），謀摳零。

而在拆解任務的方法上，就與上段描述無異，只是需要特別注意 — 第一，這個行為的操作者會是誰；第二，兩個角色不同操作者的相連任務、串接流程，要如何順暢地運行下去。用剛剛的出勤系統舉例來說，如果我們從訪談過中得知—該企業的職務分配是「由HR進行新進員工的建置」，但需要由「該員工的主管決定班別與打卡設定」，這個時候該怎麼處理呢？解方有百百種，但你會怎麼思考呢？

總之，在使用者訪談的階段，會有好一陣子資訊蒐集的過程，有時候資訊量太龐大就會跟接下來的階段交替進行，直到把整體規劃與客戶定調，才進入程式開發。（再次提醒一下，我們公司是接案為主，整個專案流程走 Waterfall 仍是最常見的模式）

本篇文章「如何從 0 到 1，規劃一個後台管理系統」上集，就先在此告一段落啦！（寫文章好累，瞬間對 Medium 各種大神Respect !!!）敬請期待下集，將會聊到「Stage 3：繪製資訊架構圖」以及還在難產中的各種內容，祝我好運！😅