starrow
為跨子公司的組織管理設計數位基礎建設，從組織圖架構到易用性驗證，建立可擴展的協作框架。
亮點 1
跨子公司組織圖的架構設計
將集團多子公司、一人多身份的複雜組織關係，從資訊架構梳理到圖像化呈現，在手機 App 上實現可互動查找的組織圖，成為整個產品串接 OKR 與協作功能的連接軸心。
複雜度在哪
集團底下多個子公司各自組織架構獨立，但業務上有跨部門協作需求，高層也需要掌握整體樣貌。組織圖不只是單純的單位層級資訊頁面，而是整個產品的連接軸心，OKR、對話、任務都掛載在這個結構之上。複雜度在於同一個人可能在同一集團下擁有多種身份，尤其是首長級主管，可能同時在多個子公司有角色。
0→1 的架構釐清
我從資訊架構梳理著手，釐清集團→公司→部門的層級關係、跨組織串聯方式、一人多身份的呈現邏輯，同步與開發持續交流確認技術可行性。產品在高層決策下採用「員工自建組織」而非系統自動匯入，希望透過建立與串接的過程，讓員工主動認知自己在組織中的位置與關係。這個前提也讓資訊架構的設計更需要考慮引導性與建立流程是否直覺，因為用戶必須從零開始把組織搭起來。
圖像化的技術挑戰
方向確認後，真正的挑戰是怎麼在手機 App 上實現可互動的圖像化組織圖。集團底下組織資料量大，一次載入全部會拖垮效能。最終跟開發對齊後採用分層載入——以用戶當前的單位角色為中心，只撈平級及上下級資訊，不一次載入全部，在「用戶能看到足夠的上下文」與「不拖垮效能」之間取得平衡。同時將顆粒度做到比官方組織圖更細，呈現到執行層人員，讓跨部門協作在日常層級就能發生。
亮點 2
易用性測試：從發起到推動優化
主導 9 人易用性測試，以 User Journey 收整 48 個問題、分為 7 大類，推動約 60% 問題優化；測試結果同時成為團隊評估產品品質與後續開發方向的客觀依據，並在近百人部門月會上分享。
發起動機
Phase 1 完成後正值開發團隊調整的評估節點，我主導規劃易用性測試，一方面驗證產品是否符合核心用戶預期，另一方面用實際使用證據釐清既有產品問題，讓後續團隊調整與迭代方向有客觀依據，而不是只依賴內部主觀判斷。測試的規劃與執行都由我負責。
測試方式
測試針對 starrow 的核心 TA——企業中高階主管與秘書，共邀請 9 位受測者（7 位主管、2 位秘書）。流程分為四大段：註冊與自由探索 → 組織圖 5 個任務 → OKR 5 個任務 → 總訪談。每個任務都設定一個情境搭配一個任務，讓受測者在接近真實的脈絡下操作。
問題收整
收整方式是繪製 User Journey，以便利貼收集測試流程中用戶實際反應，並用顏色區分主管與秘書身份。將問題歸為用戶預期、功能/文案理解、功能入口、操作回饋、介面呈現、空值狀態引導、輔助說明七類，共 48 個問題。
怎麼優化
案例一｜組織功能入口不直覺
用戶反應以頭像當作組織相關功能的入口不直覺，甚至完全找不到，只能透過首頁 CTA 進入。優化方向：將組織功能移至 footer bar 的「功能」裡，切換 tab 時就能看到；同時修改首頁 CTA 文案，改為在用戶尚未建立組織時引導建立、擁有組織後才消失，避免誤導用戶。（v1.0 已優化）
案例二｜組織資訊架構不清楚，列表式無法區分層級
初版列表式 UI 無法清楚傳達組織層級，團隊原先已有疑慮，易用性測試進一步驗證用戶確實會混淆部門與人員，甚至將兩種呈現誤認為異常。開發團隊調整後，我重新與工程確認圖像化方案的可行性，最後拆分為「部門詳情」與「組織圖」兩種視圖，分別解決單一單位資訊閱讀與整體層級理解。（v1.0 已優化）
案例三｜OKR 建立流程中儲存時機與用戶預期不同
OKR 並非我主要負責的功能模組，但易用性測試涵蓋產品的完整核心流程，因此驗證範圍並不侷限於我負責的組織功能。測試中發現，用戶在建立 OKR 時切換 tab，會因缺乏明確回饋而不確定資料是否已儲存。後續改以「上一步／下一步」的步驟引導取代單純自動儲存，降低操作過程中的不確定感。（v1.1 已優化）
整體優化成果
48 個問題中已解決 29 個，約 60% 優化率。其餘四成包含對未來功能的想像與較低優先級的易用性問題，已排入後續迭代規劃。成果曾在近百人的部門月會上分享。
其他貢獻
標記功能（Tag）
讓主管透過標記快速掌握專案全貌並對照 OKR 達標狀況，完成概念發想與 wireframe 階段即因專案 pending 中止。
成效
starrow 目前仍為 pending 狀態，因此沒有上線後的量化數據，但已有兩項具體成果：
- 專案階段成果獲集團高層肯定，並被主動詢問後續重啟時程；專案最終因策略調整 pending，而非因產品或設計品質終止。
- 易用性測試共發現 48 個問題、60% 完成優化，成果於近百人部門月會分享，並建立團隊以結構化方法驗證設計的先例。
Retrospective
MVP 思維的教訓
這個專案最大的學習是初期規劃太大包，沒有朝 MVP 收斂。如果重來，會更早把功能範圍砍到最小可驗證的程度，先跑起來再長。
Ownership 工作模式的養成
這個專案的分工方式讓每位設計師獨立 own 一個功能模塊——不只是負責介面，而是從功能規格的定義開始，到架構梳理、設計決策、開發對齊、測試驗證，整條鏈都在自己手上。功能規格不是 PM 給的，是設計師自己根據產品目標和用戶需求定義出來的。
這種工作方式讓我養成了一個習慣：不只想「這個模塊怎麼設計」，而是想「這個模塊在整個產品裡扮演什麼角色、有什麼發展可能性、如果目標改變了，這個模塊該怎麼跟著調整」。這是設計師和純執行角色之間最關鍵的差異，也是我認為在 AI 時代設計師最需要守住的能力邊界。