從定位到履歷：怎麼決定要留下什麼，拿掉什麼

上一篇寫了我怎麼把 13 年經驗收斂成「複雜系統 Fintech 設計師」這句話。這篇接著寫，定位想清楚之後，怎麼把它具體落實到履歷裡。

這中間有一個常見的誤會。很多人以為定位想清楚之後，履歷自然就會寫得好。實際上不是這樣，定位只是給你一個篩選的標準，履歷還是要一行一行決定，哪些留下來，哪些拿掉。

在動手改履歷之前，先做一件事：把三到五個目標職缺的 JD 貼在一起，標出重複出現的詞。

我當時看的 Fintech 職缺，反覆出現的詞是「regulated」「complex systems」「end-to-end」「scale」。這些詞不是巧合，它們是招募方篩履歷時，眼睛會停下來的地方。列出這些詞之後，履歷要怎麼寫，才有一個具體的判斷標準，而不是憑感覺覺得「這段寫得好像不錯」。

上一篇提到的三個 UX CIRCLES 專案，跟 Y TREE 的七年經歷，複雜度都遠超過履歷上那幾行字。判斷留或拿掉，不是單一標準，而是幾個實際會遇到的考量疊在一起。

第一層，最直接的標準，這段細節能不能直接對應到關鍵字清單上的詞。對得上就留，對不上，不管做起來多有成就感，先拿掉。

第二層，是角色的主導權夠不夠。pod 管理、風險再平衡工具這兩項，是 Y TREE 規模化之後才出現的功能，我雖然是主要設計師，但 Product Manager 在這兩塊的掌控權更大，比較像是支援角色，不是真正主導。就算內容跟「複雜受監管系統」這個定位對得上，主導權不夠，寫進履歷也很難撐起一個有份量的 bullet，所以優先被拿掉。

第三層，是這段內容好不好被理解。資料品質指標這一項，情況比較複雜，很多時候資料品質的呈現結果是紅色的，代表品質不好，要解釋清楚背後原因需要很多脈絡，對方不一定有耐心或背景去理解。招募方或 HR 看履歷的時間很短，我會傾向挑對方比較容易快速理解的專案放上去，而不是最能展現技術深度、但需要大量解釋才聽得懂的專案。

這幾層標準不是死的規則，也會依應徵的公司調整。如果某個職缺描述裡剛好提到 data quality 相關的字眼，我可能就會把這項加回履歷，不是每次都固定拿掉，但核心的定位主軸不會變，調整的是要不要為了對齊某個職缺而多放一項細節進去。

前面幾層標準講起來還是有點抽象，我後來會用兩個軸線去判斷，一個是跟定位的吻合度高不高，一個是這段內容的份量夠不夠、有沒有實際數據佐證。四個象限對應四種不同的處理方式。

吻合度高、份量也重，這種直接留下、放大寫。billing system（£3.5B+ billable assets）、ESG 專案、advice tooling、trade execution、client dashboards，全都屬於這一類，跟「regulated」「complex systems」這些關鍵字直接對得上，也有實際數據可以佐證規模，這是履歷裡該花最多篇幅的部分。

吻合度高、但份量不穩定、要看情況，資料品質指標屬於這一類。內容本身跟「複雜受監管系統」沾得上邊，但因為呈現結果常常是紅色、需要很多脈絡才解釋得清楚，招募方不一定聽得懂，所以平常會先拿掉，只有目標職缺明確提到 data quality 相關字眼時才加回來，是條件式保留，不是固定留或固定刪。

吻合度低、但份量重、自己覺得很有成就感，pod 管理跟風險再平衡屬於這一類，這是最容易捨不得刪的一種。做的時候投入很多，成果也不差，但因為主導權在 PM 手上，我比較像支援角色，跟「我主導複雜受監管系統設計」這個定位對不上，這種情況要優先拿掉，就算心裡覺得可惜。

吻合度低、份量也輕，這種通常直接刪除，不會留下任何篇幅。但這一類有一個例外情況值得提，Acer 跟 Synology 這兩段經歷，嚴格算起來跟「Fintech 複雜受監管系統」這個定位吻合度都不算高，照四象限的邏輯應該被刪掉，但我還是各留了一句到兩句。Acer 留下來是因為品牌本身的辨識度，招募方看到會有印象；Synology 留下來是因為規模，跨區域、使用者人數多，能證明「scale」這個關鍵字。這代表四象限是判斷的起點，不是絕對的規則，遇到品牌辨識度或特殊佐證價值這種例外情況，還是要靠自己判斷要不要破例保留。

光講標準還太抽象，直接看改寫前後的差別。

改寫前： “Responsible for the ESG project at UX CIRCLES, handling corporate data disclosure requirements.”

改寫後： “Delivered an ESG proof of concept focused on data disclosure, enabling financial institutions to meet evolving regulatory requirements.”

改寫前那句話，招募方讀完不知道這件事有多複雜、牽涉到什麼規則。改寫後把「regulatory requirements」這個詞放進去，跟目標職缺的關鍵字對上了，同一件事，招募方看到的重要性完全不同。

再看一組。

改寫前： “Managed the billing system at Y TREE, handling client invoicing data.”

改寫後： “Optimised billing and onboarding workflows, including an invoice system tracking £3.5B+ in billable assets, improving data accuracy and operational efficiency.”

改寫前是一句平淡的工作描述，任何一個做過計費系統的人都能這樣寫。改寫後把規模的數字放進去，£3.5B+，這個數字本身就是「我處理過的東西有多複雜」的證據，不需要再多加形容詞。

決定好每一段要留多少細節之後，實際塞進一到兩頁履歷時，還是會遇到取捨的掙扎，版面該怎麼分配，也沒有一個固定公式，我是照每段經歷的份量跟意義去分配的。

Y TREE 那七年是我內容最豐富的一段，這段完全不會被省略，因為這是我在英國最重要的核心經歷，而且多半有實際數據可以佐證，這部分佔的版面自然最多，留了 advice tooling、trade execution、client dashboards、計費系統這四項最貼近目標關鍵字的內容。

Acer 的經歷，我濃縮成一句話。留下來的原因不是內容有多貼近定位，是因為 Acer 這個品牌名本身有辨識度，招募方看到會有印象，值得用一句話的篇幅換取這個品牌加分。

Synology 留了兩句，一句提到同時做過 web app 跟 mobile app，另一句提到產品跨區域、使用者人數很多。留這兩句的理由是規模，不是深度，證明我處理過的產品觸及範圍夠大。

UX CIRCLES 因為都是新創的 MVP 專案，沒有實際上線數據可以佐證，這部分我會刻意強調產品本身的複雜度，用複雜的角色跟流程去補數據不足的空缺，不是每一段經歷都要靠數字說話，沒有數字的時候，用複雜度本身當證據也是一種辦法。

這個掙扎沒有標準答案，取捨的當下會覺得可惜，好像在丟掉自己的心血。但履歷不是工作日誌，是給招募方看的篩選工具，讀者要看到的是「這個人適合我們要的位置」，不是「這個人做過的所有事」。

前面提過的取捨邏輯，可以借助 AI 加速初步篩選的過程。把目標職缺的 JD 貼給 AI，同時貼上自己完整的經歷清單，請它根據 JD 的重點，抓出哪幾項最貼合、哪幾項可以先拿掉，當作第一輪篩選，比自己從頭一項一項比對更快。

但 AI 做的只是第一輪篩選，不是定案。像前面提到的 pod 管理、資料品質指標這種取捨，牽涉到「主導權夠不夠」「對方聽不聽得懂」這類只有自己在現場才清楚的判斷，AI 看不到這些脈絡，只能根據字面上的關鍵字比對去猜。決定哪一段複雜的真實工作該留、哪一句該拿掉，這件事沒辦法完全外包，因為只有你自己知道，哪些細節真正對應到你想要的定位，哪些只是看起來厲害而已。

AI 會放大你原本的樣子。如果履歷背後的判斷標準是模糊的，AI 只會把模糊的東西寫得更漂亮，不會讓它變清楚。

我提供設計師求職諮詢服務，包含履歷／作品集健診、一對一諮詢，也不定期開線上講座。詳情請見 chundesigncareer.com

這篇是系列文章的其中一篇，完整大綱跟後續文章規劃，可以到 chundesigncareer.com/guide.html 看。

我是 Chun-Chuan，台灣設計師，在倫敦工作第八年。寫職涯、財務、還有那些在工作與自由之間說不清楚的事。如果你也在35-45歲之間，感覺不上不下，我的分享或許有你想看的東西，歡迎訂閱我的故事，我會持續書寫。