--- title: "為自己建立 UX 學習地圖" slug: servicedesign19 url: https://lms.soking.cc/posts/servicedesign19 published_at: 2025-10-02 modified_at: 2026-06-04 author: "Soking" category: "服務設計" access: public_access --- # 為自己建立 UX 學習地圖 By **Soking** - 產品與服務設計顧問 | 2025-10-02 哈囉，朋友我在成為數位領域的產品設計者之後，最大的發現就是自己經常處於無知與茫然的狀態。​我們要理解手上開發產品的商業邏輯，這樣才能提出符合策略的產品設計提案。我們要洞察產品服務的使用者情境，搞懂現場的用途以及願意產生行為的動機。我們還要設計產品服務流程，在商業目的、使用者需求與技術可行性之間取得平衡。​最後我們還要持續的評估是否還有改善的可能性。產品真的有滿足使用者需求嗎？產品有滿足商業目標上的期待嗎？​這些林林總總的議題，就沒有一個是簡單的，也別期待標準答案。那麼，我們該如何在這一片混沌之中找到立足點，建立自己認知的地圖呢？​我想分享以下幾個方向，提供你作為參考：理解利害關係人的商業目標與需求洞察使用者情境與動機設計產品服務流程評估持續改善的可能性​▋理解利害關係人的商業目標與需求我們曾經在訪談一位 UX 主管時，聽到一段很有意思的感嘆，他說：「我們遇到的設計師大多數在學習期間，都有被訓練，或者很有意識的知道要關心使用者，去同理用戶的需求。然而，大多數的設計師卻很難去意識到，要去同理利害關係人的需求。」「利害關係人也是人，他們也是產品要服務的一環，沒有這些人的參與以及理解，產品是不可能成功的。」這就像一個軟體平台經常會分為前後台，人們經常只注意到光鮮亮麗的前台，但很少有人在意後台的設計規劃。理解利害關係人的需求，更多的是軟技能以及領域知識的展現。這邊羅列幾篇先前文章作為參考：需求訪談的三個階段性（https://lms.soking.cc/posts/https-subscribe-soking-cc-posts-soking-75）如何對大忙人進行需求訪談？（https://lms.soking.cc/posts/https-subscribe-soking-cc-posts-soking-99-8）關於用戶增長的五個 UX 策略觀點（https://lms.soking.cc/posts/servicedesign029）在需求訪談中辨認多方利害關係人的類型（https://lms.soking.cc/posts/https-subscribe-soking-cc-posts-soking-83）​▋洞察使用者情境與動機洞察使用者情境這件事情就像是廚師要懂得如何辨認好食材。當然，我知道如果是在速食店廚房打工的人，根本不需要搞懂薯條跟漢堡肉的來源。但如果我們以黑白大廚那樣子可以獨當一面的大廚為目標，主動去探尋與辨識各種食材，就是大廚之路的基本功了。身為產品設計者，我們是為了讓自己的設計有所本，為了解決真實存在的問題而去進行研究。如果我們還相信設計的本質是解決問題，那麼了解問題的長相，就是第一步。​參考文章：一個產品人的極限，同理心是我們專業的瓶頸（https://subscribe.soking.cc/posts/soking-95）訪談技術中的語言模式（https://lms.soking.cc/posts/interviewskills005）如何認識目標受眾？我推薦從專家與小白開始（https://lms.soking.cc/posts/servicedesign030）低成本的消費者市場研究方式 –「游擊訪談」（https://lms.soking.cc/posts/interviewskills007）​▋設計產品服務流程設計產品的服務流程是傳統意義上我們對於設計師工作的理解。這包含了以設計思考為骨幹，透過發散與收斂的過程，有意識的去洞察情境、識別問題、規劃原型、測試與評估。​我很喜歡致遠體驗設計的卓致遠設計師（江湖人稱卓學長，廣為人知的案例是台灣報稅系統改善的推手），將設計思考轉化為東方風味的：見、識、謀、斷。​設計思考常常被忽略的一個核心精神，就是將利害關係人的共識納入設計流程。在《我們的行為是怎樣被設計》一書中提到，發明設計思考的 IDEO 公司，當年所強調的是「設計不再仰賴天才的直覺」。​IDEO 共同創辦人蘇瑞說：「老一輩藝術學院出身的設計師不太喜歡與人交流，藝術學院總是挑選靦腆、有創意的人當學生，討厭去觀察真實生活裡的人，也不喜歡賣力摸索日常生活的小細節。」​在將利害關係人納入設計流程這件事情上，數位領域的產品設計師，最艱鉅的挑戰之一就是與程式設計師的合作了。要怎麼樣讓不會寫程式的人，設計出要用程式來實現的產品服務呢？​關鍵在於資訊架構的規劃。軟體任務的本質是滿足資訊需求，而不是介面的美觀。​根據產品服務的情境，定義出可結構化的資訊，並且設計出讓使用者與這些資訊內容互動的流程。千萬別搞錯了，使用者並不是想要跟音樂播放器的介面互動，使用者想要的是點播喜歡的歌單，用來點綴他的生活。​參考文章：軟體任務的本質是滿足資訊需求（https://subscribe.soking.cc/posts/soking-85）撰寫產品需求文件 PRD 時的閱讀體驗七宗罪（https://subscribe.soking.cc/posts/soking-prd-2）8個產品設計文件 PRD 的 SPEC 書寫原則小技巧（https://subscribe.soking.cc/posts/soking-8-prd-spec）如何畫出爛爛沒人看的 UserFlow？（https://lms.soking.cc/posts/servicedesign036）​▋評估持續改善的可能性我曾經在一場新創團隊的內部工作坊當中，與開發團隊的PM、設計師、RD 們討論，怎麼樣算是「需求的終點」呢？大家很有共識的得出結論：當我們解決使用者問題時。不是需求被變成設計稿、不是需求被開發、不是新功能推上線。而是當初我們定義了一個問題，這個問題在新版本更新之後，有沒有真的被解決了？你會發現，如果一開始定義需求時，只談論了很表面的「功能性需求」。例如我要一個投票功能。那我們根本不知道這個投票功能推上線之後，到底有沒有發揮效益。所以我們需要「清晰的目的」、「可驗證的方法」以及「持續改善的行動」。​參考文章：不確定性的三種成因（https://lms.soking.cc/posts/https-subscribe-soking-cc-posts-soking-76）定義一個好問題，問題就解決了一半（https://lms.soking.cc/posts/servicedesign042）怎麼樣算是產品服務的使用者體驗不佳呢？六大常見原因（https://lms.soking.cc/posts/servicedesign021）系統化洞察顧客服務體驗的三個檢查清單（https://lms.soking.cc/posts/servicedesign022）​▋結語成為數位產品領域的產品設計師，是一個多元且複雜的職業道路。網路與軟體的行業不像餐飲、醫療、金融、製造等等行業，動輒百年甚至千年以上的歷史。有句話是這樣說的：「軟體正在吃掉全世界。」長期而言，軟體不是一個行業，而是成為各行各業的一部分。分工曖昧不明、各個行業招募標準不一、管理不成熟、能力要求又深且廣，這些都是我們面對的日常。所以我們會看見，每一個在產業中獨當一面的人，都有各自的機運，很難說怎麼樣的成長路徑就是標準答案。為了好好與你分享這個議題，我預計舉辦一場直播講座。​by Soking