【 iCHEF 設計分享會 】產品設計師的進化之路：官方筆記（上）
歷經一個半月的籌備，iCHEF 設計團隊順利的在六月中舉辦首次對外設計分享會！感謝所有前來參與的聽眾們，首場分享會獲得的 NPS 淨推薦值 是 72 分，Soking 說講座活動有達到 40~50 分就是不錯的分數了。
這次的分享會主題是「產品設計師的進化之路 —— 告訴我該如何 Level up！」，談論 junior / mid-level / senior 設計師分別該具備哪些思維和能力，以及各自面對的職涯難題。
會選擇這個主題是因為，我們觀察到目前大部分的設計講座主要聚焦在整段職涯旅程，或者是面向海外設計師，較少著墨於「不同階段」的成長方向，剛好我們團隊內就有這三個不同等級的設計師（總共九人！），所以能以較全面的視角提供多種觀點。
當天由於時間緊湊，Q&A 環節無法回答所有聽眾提問，因此我們會在本文補充較完整的回應，如果你對講座內容有興趣，歡迎閱讀這位聽眾用心撰寫的心得文章：
以下問題的回答者為：Kat (Mid-level Designer) 和 CC (Lead Designer)一、自我專業成長
Q1：想知道在職場上，一人設計師要怎麼持續檢討與優化自己的設計？
🔸 Kat：雖然團隊裡只有你一位設計師，不過你還是能從其他工作角色身上取得回饋，例如產品經理或專案經理可以給予設計規格、時程、迭代方面的建議，工程師可以給予開發、維護、文件交付方面的建議。
不過，如果要取得「設計思考」層面的建議的話，還是會建議加入擁有 3 位以上設計師的環境，因為你能在相互討論的過程中，看見自己的思考死角、汲取他人的思考模式，這是一人設計師難以獲得的。你現在所面臨的困境，可能也會成為讓你想進入不同環境的動力。
🔹 CC：首先，想要對一人設計師說聲加油，請你持續相信與探索自己的價值，我也曾任一人設計師約 2 年左右，可以了解那股不安與徬徨的心情。現在回頭思考那段歷程，其實會發現在獨自探索的道路上，恐懼是很好的學習驅動力，促使自己往內心深處探索根源，進而試圖採取行動，尋找資源。
根據過去的經驗，有 3 個方法可以分享給各位。
- 探索自己的不安 ➝ 找方法破解 ➝ 追蹤效益：因為有些恐懼，只是假設，尚未經過證實，例如：我擔心自己的資歷，要找外面工作不好找。
- 透過「專案」探索進步空間，並依需求排優先序 ➝ 找課程、講座、社群等資源學習 ➝ 運用在工作並持續優化：強烈建議排序想進步的項目，因為我們時間有限，透過架構性的學習，一點一滴的成長。
- 參與社群或讀書會，找到志同道合的夥伴：因為有些議題（例如：合作溝通、向上管理等）是上課或獨自想破頭後，依舊會陷入盲點，透過互相討論，更有機會找到關鍵問題 ; 同時，還可以互相吐苦水、取暖，身心靈都滿放鬆的 XD。
Q2：想知道如果想在設計職涯不斷向前，且走比較遠，比較重要的會是多能（比如會設計，剪片，寫程式）還是是專精在 UI/UX 相關的技能？
🔸 Kat：不太確定你指的「遠」是多遠，但我們要意識到現在的設計環境仍不斷變動中，一直有新技術和新概念出現，所以在職涯前期可以專注在那些「不變」的底層能力上，例如專案管理、溝通能力、提問能力等。就算你轉換到不同產業、擔任不同設計角色，這些能力都可以移轉。
再來就是要讓自己保持彈性、能夠接受並持續學習新事物。至於要學習多個技術還是專精於特定領域技能？這需要問自己「我想成為什麼樣的設計師」，這題沒有標準答案。
🔹 CC：這題沒有標準答案，但有很多角度可以思考並找出交集點，我先列舉兩個：
- 外在雇用者思考：「未來變動的環境中，你會比較想要雇用怎樣的人來做事，才會令你相信專業，提升公司收益？」。換個生活的例子來思考，當在選擇一間餐廳時，大多數會傾向選擇「賣很多不同類型的餐點」或是「專心在幾樣餐點」的餐廳？
- 內在自身思考：「斜槓」與「工匠」，哪個是我有熱情且一直持續的？我會建議勇於嘗試，並嘗試過後勇於放棄那些「以為必須做」或「認為社會需要會的事」，因為要走的遠其中一個條件就是「持續且穩定的喜愛」。我也曾經被社會風氣影響過，認為設計師需要學會寫程式，所以曾去學過 python 語法，過程中發現一點興趣都沒有，而且執行效率很差，因此毅然決然放棄，不過仍獲得「工程邏輯思維」，對工作也是加分效果。
最後，別怕做錯選擇，既然都進來產品設計行業了，應該很懂的運用迭代跟敏捷精神吧。
Q3：雖然有底層能力，但從 to C 跨到 to B 難度感覺還是有點高，如果目前從事的是 to C 想要轉到 to B 端，除了做 side project 之外，有什麼 know how 或是更需要去練習的？
🔸 Kat：就算你原本就是做 to B，要轉換到其他 to B 產業時，也會因為 know how 不同，而需要學習不同領域知識，所以企業不一定是看重你已有的專業知識，而是你的學習能力，還有文化契合度 (culture fit) 的部分。
另外如果你要做 side project 也需要注意這個專案是否具備真實性，因為 side project 通常是基於很多假設之上去進行的，除非有經過實際驗證、開發等等，不然說服力相較於真實專案來說，會低一些。
🔹 CC：坦白說，每個產品都會有其脈絡與挑戰，與消費型產品或企業型產品沒有太大關係。因此，幾個重點提供你思考：
- 你想去哪間 toB 產業？
- 列舉你現在工作和 toB 的產品設計的差異點，找出相異與相同點。例如：產業脈絡、使用者、情境、底層技術、開發方式（敏捷或是瀑布式）等。
- 補足你想要去的 toB 產業需要的能力，例如：Domain Knowledge。
反過來想，想要到一間公司去上班，怎麼做你才會比較輕鬆勝任工作？那這些事就是你需要預先準備的。以我自己為例，是一定會先去了解 Domain Knowledge，規劃一系列需要學習的清單，否則在沒有一定基礎點上，很難跟團隊合作與溝通，甚至面試還會因無法使用對方的語言而氣餒呢。
如果你沒有相關經驗，你也可以展現既有工作的「解決問題能力」 。剩下，我會建議你多面試，多吸收資訊，補足不齊的部分囉！
Q4：要怎麼自己做設計的覆盤呢？會問自己哪些問題？
🔸 Kat：我覺得不太可能有時間跟精力，像寫日記一樣每天覆盤，所以我會針對一些關鍵事件 (Critical Incidents) 覆盤，例如專案結束的時候、發現讓我情緒特別敏感的事件的時候。很推薦使用 ORID 這個框架來覆盤，透過它的提問，你能更瞭解自己的價值觀與感受，並做出下一步行動。
🔹 CC：我只會針對「自己在意或學習中的事」做覆盤，並問自己四個問題：
- 發生什麼事了？
- 為什麼發生？
- 我的感受與學習？
- 下次要如何行動？
Q5：有碰過從工程師轉職設計師的人嗎？想知道通常這樣背景的人有什麼樣的特長或優勢嗎？
🔸 Kat：目前 iCHEF 設計團隊沒有前工程師，不過我有認識一位設計師，他學了前端技術後，短暫去當前端工程師，又回來當產品設計師。比起特長或優勢，我認為更重要的應該是要「知道自己為什麼想走這條道路」。
二、前期規劃與設計決策
Q6：有點好奇在和 PM 合作時，senior 會如何和 PM 合作拆分主題與功能？在前期規劃就會邀請 senior 討論嗎？那如果是junior，對已經定義好的問題有疑問或想法，會如何與 PM 討論和合作？
每間公司的職責劃分、溝通風格、工作流程都不一樣，因此這題會以 iCHEF 的情況回答。
🔸 Kat：我們跟 PM 很緊密協作，也會根據專案性質、彼此的工作狀況彈性的互相協助，所以設計師在 PM 做前期探索時，就會先加入討論，大致了解專案目標，後續會再根據功能範疇、工程資源、deadline 等等，拆分出多個設計階段和開發階段。
不論是 junior / mid-level / senior，只要你對規格有任何想法，都可以提出討論，當然，要能有清楚的脈絡，說明為什麼要討論、預期討論結果能帶來什麼好處、你有先做過哪些充足的調查。推薦閱讀產品三眼怪的〈產品策略怎麼做？〉，相信你能更瞭解 PM 是如何訂定產品目標的。
Q7：能分享一個 Senior 考量設計與商業價值後，所做的一個決定或判斷嗎？
🔹 CC：產品設計中往往有大量決策需要判斷執行，舉個一簡單的例子，RD開發時，最常跑來問設計師「使用者用 A 分頁，再用 B 分頁，這個情境會需要特別考慮和設計嗎？」，此時就要判斷這個情境發生頻率，與商業目標相關性、影響度，團隊會盡量避免花大量人力處理僅符合工程 Edge Case 邏輯，但對商業與產品目標沒有任何影響的項目。
三、在作品集中說出好故事
Q8：當 PM 把決策和規格都做得很好了，設計師可以在作品集裡如何講個好故事呢？
🔸 Kat：就算你在這個專案中沒有太大的決策權，僅能作為執行端的角色，但還是可以說出「好故事」，故事好不好，取決於你的觀點全不全面，以及內容有沒有深度。所以日常中就能多跟 PM 請教各個決策背後的原因，這些決策如何影響自己的設計？如何帶動產品發展？
當你了解每個選擇的前因後果，你才能在講述作品時，清楚說出產品的主要目標是什麼、自己擔任什麼樣的角色、怎麼將 PM 的決策轉化為實際的設計方案。
Q9：想請問如果在公司都是做比較小的功能，較缺乏一個完整的脈絡、研究的話，可以在作品集或面試呈現自己在公司做的事呢？
🔸 Kat：不太確定這題指的「比較小的功能」是什麼，但這就像是你手上握著四散的樹葉，忽略這些樹葉是什麼時候從哪棵樹落下來的，當然會覺得沒有完整的脈絡。事出必有因，再小的功能都有它存在的理由，建議多和 PM 請教規劃的原因為何，找出主要的那個「樹」，這就會是你要找的脈絡。
🔹 CC：沒有完整的脈絡與研究，都僅是假設，建議可以的話要記得問脈絡，或者上線後驗證假設，驗證假設方式有多種，例如：數據、訪談、用戶回饋等，逐漸累積數據與脈絡，小功能也能長出大故事。
四、公司內部設計文化
Q10：想知道 iCHEF 是否遇過公司資源不足，對「用戶前期探索」的重要性不夠理解的階段，你們是怎麼推動讓這塊得到重視，並變成工作的流程之一？
🔸 Kat：iCHEF 體質算是滿好的，很能理解用戶研究的重要性，也願意投注資源在這塊。不過一年半前，我們倒是還沒有建立完整的 Design System，直到今年才有專職部門在處理設計系統相關工作。要讓組織願意改變，是件很困難的事，如果你想推動一些事，可以掌握這些原則：
- 累積信任感：改變要從自己做起，如果其他人對你想推動的事不夠瞭解，或是對你這個人沒有足夠信任感，那麼改變一定遙遙無期。所以可以先專注於自己的本分，到了有餘力的時候，再來思考如何改變組織。
- 從小處做起：改變一定要一步一步來，才能積沙成塔。最初在導入設計系統文化時，也是先從基本元件做起，再陸續建置其他元件，再延伸到各個產品線。如果能找到戰友，其他人對這件事的重視度也會再拉高。
- 改變非易事：不要預設自己一定可以成功改變組織，有時候是自己能力還不足，有時候是組織可塑性還不夠大。如果現在的環境讓你不滿意，可以思考要怎麼提升自己，前往制度更完善的環境。
🔹 CC：基本上並非所有專案都要執行「用戶前期探索」方法，做一個專案最有趣的挑戰就是在資源有限下完成目標。因此，我會建議反過來思考：
- 哪些專案為什麼「不採用」跟「採用」前期探索方法？
- 前期探索可以獲得什麼？可以協助我們哪些策略輔助？
與其直接跟公司說我要做探索，更建議你先問清楚自己探索的價值，才能去影響他人。
Q11：公司曾經主動發起給設計師的內訓活動嗎？（除了讀書會或分享會）如果有，成效好嗎？
🔸 Kat：我們曾經邀請過 Soking 在 iCHEF 舉辦一日的訪談工作坊！當天所有的設計師和產品經理都有一起參與，雖然我們日常就有不少訪談機會，但還是從 Soking 身上學到了有關游擊訪談和需求訪談的重要觀念。
🔹 CC：我們是自主發起內訓需求，如果沒有發出需求，那公司不會知道內訓對公司的好處。發動方式如下：
- 口頭詢問 keyman，並理解其態度
- 提出需求申請書：目的、價值、價格
- 經費管道募資、參與成員確認、日期確認
- 追蹤成效
個人在日常觀察中，參與的成員在溝通與產品研究方法都更為順暢。
感謝看到這裡的你！
最後想送上分享會的簡報內，引述自〈產品思維 30 講〉的一段話：
今天你在一個什麼樣的點位上沒有那麼重要，重要的是在未來的幾年裡，你會用什麼樣的方式持續迭代。
期待你們都有能力可以形塑出屬於自己的職涯答案。
🔗 iCHEF Yourator｜最新職缺都在這裡
🔗 iCHEF Medium｜不定期分享設計文章
🔗 iCHEF Q 報｜最真實的團隊幕後記錄
