CASE STUDY · MODE PLANNING JAPAN · きらぽん JOB
用數據找出卡關的地方，讓求職者與園方直接對話
以 GA 與 Clarity 觀察使用行為，優化日本幼教求職平台的求職者與企業介面，並透過外部人資的易用性測試驗證設計。
Web
求職平台
數據驅動
日本
ROLE
UI/UX 設計師
上線前品質把關、上線後介面優化
TIMELINE
2019.04 – 2020.04
TEAM
市場分析人員、PM、外部工程師
PRODUCT
日本幼教求職網站
手機版求職者端＋電腦版企業端
01 / BACKGROUND
背景
日本的幼教人才招募長期仰賴人力仲介。政府為了解決托兒所候補名額不足（待機兒童）的問題，與民間企業大量增設托兒所，導致幼教老師嚴重短缺；托兒所為了招到人，只能支付高額的仲介費。
02 / OVERVIEW
總覽
Kirapon JOB（きらぽん JOB）是 Mode Planning Japan 的新業務：一個讓幼教老師（保育士）和托兒所直接媒合的求職平台。我加入時平台已有部分架構，我先確認上線內容與設計品質，讓網站如期上線；上線後和市場分析人員合作，以數據找出問題，完成求職者端（To C）與企業端（To B）兩次優化。
2019.04 – 2019.10
確認上線內容與品質，並針對企業端進行易用性測試
2019.10 – 2020.04
完成求職者端與企業端兩次優化，之後因新冠疫情暫緩
03 / PROBLEM
問題
商業問題
平台要取代仲介，前提是求職者和托兒所真的會使用站內的互動功能：企業主動發出邀約，求職者願意查看並回應。
USER · TO C
企業發出的邀約（詢問意願）使用率很低。
USER · TO B
人資確認求職者資料時，需要在多個區塊間來回切換，常常漏看資訊，回覆效率很低。
CONSTRAINT
企業端預算有限，無法大規模改版；求職者年齡層為 20 到 50 歲，數位習慣差異大。
PROBLEM TO SOLVE
如何讓求職者看見企業的邀約，也讓企業能有效率地回覆求職者？
04 / RESEARCH
研究
DESK RESEARCH · 幼教老師找工作時重視什麼
15,358
東京都調查的在職與潛在幼教老師
35.7%
有效回收率
INSIGHT
幼教老師選擇職場時最重視通勤距離，因此首頁提供依區域、車站、通勤路線搜尋職缺的功能。
SURVEY · 選擇職場時重視的項目（複選）
超過七成的幼教老師，最重視「離家近」
勤務地（離家近等）
72.5%
職場人際關係
60.3%
薪資高
46.4%
工作價值感
46.4%
工時、輪班有彈性
44.7%
假期多、容易請假
43.5%
認同保育理念
38.7%
福利制度完善
36.6%
資料來源：東京都《東京都保育士實態調查》（2018），在職保育士 n=9,379，複選，列出前 8 項。
BEHAVIOR · 用 MICROSOFT CLARITY 觀察企業端
理想的處理流程應該是四個步驟依序完成：
STEP 1
確認求職者資料
STEP 2
確認應徵內容
STEP 3
和求職者聊天
STEP 4
更新應徵狀態
ACTUAL
實際上，企業常在聊天和資料之間來回切換，也常忽略狀態更新，導致資訊遺漏、回覆變慢。
CLARITY · 企業端求職者頁面的實際動線
畫面上的位置和處理順序對不上，人資只能上下來回找
4
應徵狀態
第一屏以下，需往下捲動
1
求職者資料
2
應徵內容
3
聊天
理想順序：① 求職者資料 → ② 應徵內容 → ③ 聊天 → ④ 更新狀態
① ② 是最先要看的資訊，卻放在第一屏以下，要往下捲動才看得到。
③ 聊天在右上，人資在資料和聊天之間來回切換，容易漏看。
④ 狀態放在最上面，卻是最後一步，看完聊天後常被略過。
根據 Microsoft Clarity 的熱點與操作錄影整理
05 / TESTING
測試與驗證
10
位外部企業的人資人員
任務
以第一版提案的原型，變更求職者狀態、設定面試時間
測試在上線前完成；因公司資源安排，測試結果在上線後的優化期才實作。
FINDING
只調整順序和文字後，人資仍需要上下捲動、來回確認，還是會漏掉求職者的需求。這個結果促成了決策三。
2019 年 7 月，邀請オネストリィ株式会社的人資進行易用性測試（受測者臉部已馬賽克處理）。
06 / TRADE-OFFS
取捨
DECISION 01 · TO C
精簡邀約訊息，讓一個畫面看到更多企業
邀約功能的使用率很低。和市場分析人員討論後，我增加了到達未讀訊息的路徑，並精簡每則訊息的顯示內容，讓使用者在一個畫面中看到更多企業的邀約。考量到 20 到 50 歲的使用者大多習慣 LINE、Facebook 和 Instagram，我採用類似通訊軟體的列表，降低學習成本。
BEFORE · 原邀約頁
一次只看到一則完整訊息，要一直往下捲。
AFTER · 優化後
邀約一覽
2 則未讀邀約
像通訊軟體一樣列出所有邀約，未讀一眼就看得到。
DECISION 02 · TO B
預算有限，先調整順序與文字，不大改版
第二版提案只調整資訊的排列順序並修改文字，以最小成本改善流程。
DECISION 03 · TO B
把完整的求職者資訊集中在第一個畫面
易用性測試證實，只調整順序和文字無法解決資訊分散的根本問題。因此第二版以「在第一個畫面看到完整的求職者資訊」為目標，把資料和聊天並排呈現，人資不用再捲動、來回切換。
第一版
調整順序與文字
仍需上下捲動、來回確認
第二版
資料與聊天並排
第一個畫面看到完整資訊
觀察：原畫面
4
應徵狀態＋Web 面試＋備註
1
求職者資料
2
應徵內容
3
聊天
第一屏
④ 狀態、Web 面試和備註佔滿第一屏，① ② 要往下捲才看得到。
提案：調整順序與文字
4
應徵狀態＋備註
1
2
求職者資料（含應徵日期、動機）
1
資料表（續）
3
聊天
2
應徵內容（自動帶入）
第一屏
拿掉 Web 面試和獨立的應徵內容區，② 併進 ① 和聊天；但資料表仍在第一屏以下。
最終改版（上線版）
1
個人資料
4
狀態變更
1
資料表（合併欄位）
3
聊天
2
應徵內容（自動帶入）
第一屏
改成 680px 高的彈出視窗，① ② ③ ④ 都在第一屏內；狀態變更另開小視窗。
07 / FINAL DESIGN
最終設計
從使用者最重視的條件出發
依區域、車站、路線搜尋職缺
通勤是幼教老師選擇職場的首要考量。
沿用熟悉的操作
邀約改為類通訊軟體列表，並標示未讀
降低不同年齡層的學習成本。
讓下一步清楚
新增邀約詳細頁，下方固定「應徵」按鈕
看完內容就能直接行動。
減少來回切換
企業端資料與聊天並排呈現
人資不會漏看資訊，回覆更快。
求職者端 · 邀約列表
所有邀約集中在一個列表，未讀標示紅點，職種用標籤區分。
求職者端 · 邀約詳細頁
點開邀約就看到完整內容與招募條件，下方固定「應徵」按鈕，看完就能直接應徵。
企業端 · 求職者管理視窗
資料與聊天並排在同一個視窗，應徵內容自動成為聊天第一則訊息，狀態變更另開小視窗。
08 / IMPACT
成果
+150%
To C · 優化後一個月，到達邀約頁的求職者比前一個月成長
回覆更快
To B · 上線後企業反應良好，人資可以依求職者的狀況更快回覆
LEARNINGS
從數據找問題，而不是從感覺
邀約使用率低、企業漏看資訊，都是透過 GA 與 Clarity 的實際行為發現的，再和市場分析人員一起確認改善方向。
小改版也有價值
預算有限時，先調整順序和文字驗證方向，再用測試結果爭取更大的改動。
NEXT CASE STUDY
AI ExpertMeet →