總覽
專案名稱：首頁改版
時程：2024–2026 年（我離職時尚未完成）
職務：專案負責人、首席設計師、UX 設計師及 UI 概念設計師（直至 2026 年離開專案為止）
簡介
在正式營業後的三年內，不管是對內還是對外，我們都發現了許多問題，並明顯意識到現有版本已無法滿足用戶與業務需求。透過日常專案工作，設計團隊一直持續搜集並整理這些問題。 其中最嚴重的問題之一，是載入首頁所需的 API 呼叫次數過多，這直接影響使用者進入首頁時會有漫長的等待時間。而在2024 年，有用戶反映因首頁畫面空白，且等候時間超過五分鐘，對他們權益造成重大影響，這起事件促使CEO與通路處提高此次改版專案的優先層級。 決策通過後，由我負責，以Project owner和Lead Designer的身分，帶領專案從內部研究階段一路推進至跨職能會議。
規劃與執行
經與高階管理層（C-level）及其他利害關係人討論後，我們正式啟動了改版專案，先初步規劃了所需資源與資料，並明確定義下列步驟：
- 研究
- 問題定義
- 設計概念提案
- 可行性評估與執行
*本案例研究聚焦於專案的「研究」到「設計概念提案」階段。在我離開該專案時，可行性評估與執行階段仍在進行中。
1. 研究
經過設計團隊內部討論後，我們選擇了三個研究方向：
- 使用者數據（用以驗證不確定的假設）
- 內部工作坊（用以了解各團隊的優先事項）
- 競爭分析（銀行與金融應用程式）
用戶數據
發現
這些數據直接的挑戰了我們原先的假設——使用者必須大量滑動螢幕才能找到目標並開始任務。實際上，大多數 LINE Bank 使用者擁有的帳戶不超過三個。我們還發現，使用者在嘗試過幾種路徑後，已習慣點擊底部的卡片，這帶出了另一個議題：即使已知有更好的使用流程，我們是否仍應保留這種舊的使用習慣？
內部工作坊
我準備了四個問題，藉此讓大家在場內有更深入的討論：
- 您在使用LINE Bank服務時遇到的三個痛點。
- 您在工作上，因為LINE Bank現有服務造成影響的三個痛點。
- 除了LINE Bank服務外，還有哪些您喜歡的銀行APP？原因為何？
- 若您是此次改版專案的負責人，您會加入哪些需求？
發現
這個活動，引出不同團隊對此專案所期待的目標有所不同這項事實：用戶方希望加快載入速度、業務團隊則希望提升產品能見度，而工程團隊則期望減少 API 依賴。我們利用這些矛盾點，為下一階段定義了設計核心議題。
競品分析
我們針對金融科技較為成熟的國家（包括南韓、英國和香港）的銀行服務進行了拆解和分析，最後也萃取一些特色功能整理成完整報告。
發現
- 為解決薪轉戶綁定的問題，南韓和英國都提供了更大的彈性，允許在單一銀行服務內同步並管理多個銀行帳戶。例如，即使使用者在 B 銀行開立帳戶，也能透過 A 銀行進行轉帳及管理，這大大幫助了用戶，可以快速透過單一APP管理所有財務，然而受限於台灣的法規與市場環境，即使在研究過程中理解此方案的潛在價值，但同時也清楚看到金融科技的廣度極大受限於法律限制。
- 顯示/隱藏餘額對台灣用戶而言是一項重要且常見的功能，因為許多人在公共場合使用銀行產品時，會優先注意保護自己的財務隱私。然而，在南韓及其他某些國家，這項功能在銀行應用程式中並未被普遍提供，藉此可以看出地區文化上對財務隱私的看法。
- 在台灣，許多用戶會以薪轉戶作為主要往來銀行，但這通常是由台灣公司方決定，這意味著用戶未必會選擇使用者體驗最佳或最便利的銀行，而是順應公司選擇，這引出了一個關鍵議題：我們該如何打破這種既定行為，找到其他方法吸引更多用戶？
2. 問題定義
經過研究後，我們將焦點集中於一個核心問題：
我們該如何重新設計銀行應用程式的首頁，讓使用者能更快速地掌握自身財務狀況並執行重要操作，與此同時，也需確保所有功能在符合商業與法規限制下，也不會產生可行性問題？
基於這個大問題，我們從三個角度拆分：
- 使用者：協助使用者快速查閱財務狀況，並高效完成重要任務。
- 業務：平衡不同的業務策略與目標。
- 系統（重點）：減少 API 呼叫次數並提升系統效率。
3. 設計概念提案
根據研究結果與內部需求，我們意識到要平衡使用者、利害關係人、系統及管理層的需求將是一項艱鉅的挑戰。為了探索不同的可能性，我與另一位設計師合作提出了幾個不同設計概念。
方案 A（最終決議）：以分頁呈現每個產品
**優點：對使用者而言，**此結構能讓所有產品一目瞭然，並可透過單次點擊進入產品頁面以查看資產狀態。對企業而言，每個產品皆可擁有專屬的分頁版位，並採用獨立的設計呈現。對系統而言，當使用者進入某個分頁時，僅需載入相關的產品資料一次，可大幅降低需要呼叫的系統數量。
**風險：**設計較為複雜，因每個分頁和產品都需要和各部門進行單獨協調，此外，由於各團隊都認為自家產品對用戶和公司而言是首要優先內容，因此難以決定分頁的排序。
方案 B：顯示所有產品資訊和資產在單一頁面
**優點：**使用者可先關注其總資產餘額，並透過自訂產品排序來查看最常使用產品的狀態。
**風險：**企業展示產品的空間將受到限制。從系統角度來看，由於單一頁面將包含大量資訊與資產資料，我們需要另一種解決方案來避免一次性載入所有資料。
方案 C：僅顯示資產在單一頁面
**優點：**此方案能直接滿足用戶在銀行服務中查看資產的主要需求，同時也能大幅減少需要透過 API 呼叫的資料量，這是最以使用者為中心的解決方案。
**風險：**在用戶持有資產之前，產品在首頁上的能見度為0，此外，系統在顯示畫面前，需先識別每位用戶持有的資產。
最終方向
為推動專案進展，我們向高階管理層（C 級）利害關係人簡報了這些概念設計，並就各方案的優點與風險達成共識。經討論後，我們選擇了方案 A，因為它既能達成所有三項目標，又能將風險控制在可管理範圍內。
*基於保密協議，我無法分享此後階段的設計方案或詳細資訊。
更多內容
我之於專案
雖然在我離開專案時，尚未正式上線，但我已完成了幾項工作並獲得成果：
- 使產品、業務、工程及領導團隊圍繞共同的問題定義，並針對三大方向及優先程度達成具體共識：使用者存取權限、業務可視性與系統效率。
- 將討論焦點從單純增加內容，轉向平衡使用者需求、商業目標與系統限制。
- 確立「概念 A」作為下一階段的首選設計方向。
- 為開發與資料團隊定義了未來的追蹤藍圖。
後續驗證
我預先規劃了下列指標與研究方向，在專案上線後進行評估：
- 首頁載入時間與 API 呼叫次數
- 帳戶操作的任務完成率
- 使用者是否能理解新的資訊層級結構
- 業務團隊是否能輕鬆維護新的內容架構
- 元件庫能否支援未來產品擴展
在整個專案過程中，我們持續討論了這些數據指標，也已規劃在開發期間，資料與工程團隊將同步準備了相關的追蹤機制，以便團隊能在上線後進行。
收穫
以下經驗反映了我在過程中所獲得的啟發。
- 在此專案中，使用者、業務團隊、工程團隊及高層管理階層對於「更佳的首頁」應具備的樣貌難以達成共識，我清楚體會到，與利害關係人的共識建立過程，需更早地被加以安排，此並非設計前的獨立步驟——而是設計工作本身的一部分。
- 在負責其中一個最重要且最顯眼的畫面時，我很快便意識到這其中伴隨著取捨與待解決問題，我也學到，協助利害關係人他們找到利益點、釐清優先順序，對於整個專案的進行是至關重要的。
- 即使已有既定的設計語言和元件庫，仍有許多時刻需要決定是否需進行擴充或是否增加新元件，若遇其他專案正在並行進行時，這些決策尤其困難，任何一次選擇，皆可能在數月或數年後產生長遠的影響。