演講者：許弘霖

時間：2025年6月6日 10：00-11：30

地點：DDS THU AI中心

整理：NotebookLM、張運宗

 

【編按】繼前一期「AI Agent研發案例分享會」介紹「如何打造一個AI Agent」的入門方向後，2025年6月6日邱浩修邀請東海建築校友許弘霖在DDS-THU AI中心，以「洞察產品開發新紀元：假設/驗證為核心，融合設計思考、逆向工作法與LLM驅動實作」為題，分享國際大型公司的產品開發案例。　

許弘霖曾任AWS資深創新顧問、阿里巴巴資深產品設計師，任職Harman International 設計主管時，兩度獲得德國紅點設計獎，作品「JBL Pulse 2」（防濺水藍牙無線喇叭）更榮獲 2016 年「Best of the Best」。　

許弘霖從實戰經驗觀察到，產品開發雖歷經不同技術世代演進，但以用戶需求為中心的「假設與驗證」核心原則始終不變。　此次分享即深入淺出從設計思考（Design Thinking）、逆向工作法（Working Backwards），一路剖析到大型語言模型（LLM）如何改變產品開發流程，賦能未來設計師。　

 

 

設計思考（Design Thinking）

 

　　設計思考是一種將設計過程解構為不同步驟的方法論，著重使用者需求洞察與快速原型，透過觀察與測試，在早期驗證設計想法，是一套以人為本、實驗導向的設計流程。　

 

一、核心概念與階段

• 發散與收斂的過程：設計思考包含一個重要的發散（Ideation）和收斂（Convergence）過程，即廣泛地探索想法，然後將其聚焦並精煉。　
• 以真實需求為基礎：所有設計都應從真實的需求出發，透過足夠的使用者研究，確保設計挑戰是真實存在的。　
• 三個主要步驟：

◦ 使用者研究 (User Research)：第一步，確保從真實現象或需求中觸發設計挑戰。　

◦ 構思 (Ideation / Brainstorming)：多人共同參與，產生大量不同的想法。　設計思考的一大精神是讓「對的人在對的時間」參與，在腦力激盪時，鼓勵多元視角。　

◦ 原型製作與驗證 (Prototyping / Validation)：從眾多想法中收斂出幾個可行的點，然後透過製作原型來驗證。　「原型」不單指實體產品，任何將模糊不清的概念具象化的過程，都可視為原型；例如，建築中的模型或圖面。　

 

二、實踐案例1：Harman 音響公司

• IoT產品開發：許弘霖在全球最大音響公司之一Harman時期，利用過去在學術實驗室的經驗，專注於IoT產品的設計和原型開發。　
• 影片原型溝通：具象化的方式比單純文字描述讓產品概念更容易被想像。　例如，影片原型展示一款音響如何透過搖晃播放歌曲，以及偵測桌面位置播放不同歌曲的功能。　
• 解決量產挑戰：當第一代產品因晶片限制無法實現工業設計師的創意（如64個LED燈隨音樂跳動）時，將複雜的技術挑戰分解，透過不斷溝通與協作，將設計想像轉化為可對應量產晶片的功能，逐步解決問題。　
• 具象化Use Case溝通：在開發音響串聯功能時，面對開發團隊和副總之間溝通效率低下的問題，許弘霖將複雜的需求轉化為十個具體的「使用情境」（use case），明確定義產品能做到什麼，以及哪些是技術上不可行的，有效提升了溝通效率。　
• 組織內部影響力：在大型公司中推動任何創新，更重要的是如何在組織內部建立信用（credit）和影響力。　透過一步步的成功案例，甚至讓開發人員直接轉入設計團隊，建立信任（trust）是關鍵。

 

三、實踐案例2：Lazada 電商支付產品

 

• 跨文化使用者研究：在阿里巴巴旗下的東南亞電商Lazada，許弘霖負責開發類似信用卡的「先用後付」服務。　他們深入印尼（穆斯林國家）進行使用者訪談，了解當地文化對借貸的特殊看法（如不接受有利息的錢，轉而以買斷商品再分期償還的方式）。　
• 使用者分群：透過訪談18位用戶，根據「對借貸的開放程度」和「收入多寡」將用戶分為四群，特別關注中間層的用戶：有錢但對借貸概念模糊，小額不願借，但大額（如買手機）則願意突破宗教限制。　
• UI/UX設計與測試：在設計介面時，同時向用戶展示介面並讓其操作，觀察用戶反應以進行改進。　例如，發現當地用戶不理解「年利率」，只在乎「每個月付多少錢」，因此調整介面資訊呈現方式，使其更符合當地心智模型。　
• 精準行銷策略：針對不同用戶群體的需求，全面應用設計思考，制定精準的行銷策略，最大程度地減少用戶使用服務的摩擦。　例如，對於對價格敏感的用戶，提供直接購買商品的優惠券；對「利息」敏感的商家，採取「先用後付」，將「利息」視為「補貼」，而這是一種「特權」。　

 

 

逆向工作法（Working Backwards）

 

一、核心概念

　　逆向工作法是亞馬遜（Amazon）在產品開發初期採用的核心方法，其獨特性在於不從傳統的產品需求文檔（Product Requirements Document, PRD）開始，而是先為產品的構思「撰寫新聞稿」（Press Release），逼迫設計者從使用者需求的角度思考，並在產品開發前就清晰地定義產品的價值和用戶體驗。　

• 新聞稿的要素：

◦ 這是什麼？(What)：清晰定義產品本身。　

◦ 為什麼有這個需求？(Why)：闡述產品存在的真實用戶需求。　

◦ 如何解決這個需求？(How)：描述產品如何滿司戰略層面看待產品。　

◦ 顧客評價：模擬真實用戶使用產品後的感想。　

◦ 使用流程：以文字描述用戶使用產品的體驗流程。　

• 常見問題集（FAQ）是新聞稿的溝通，分為內部和外部(對客戶)兩個部分，用於回答公司內外各利益相關者可能提出的任何問題。　

◦ 外部：涵蓋客戶能得到什麼、比現有方案好在哪裡、客戶服務、定價、商業模式、安全性、上線時間、試用方式、市場進入策略等。　

◦ 內部：更細緻地闡述產品價值、目標用戶、需求迫切性、早期使用者、競品差異、供應鏈價值鏈、團隊組成和收益模型等。　

 

二、精神與應用

• 用戶至上 (Customer Obsession)：新聞稿的撰寫格式限制了技術細節的過度膨脹，迫使團隊聚焦於解決真正從用戶角度出發的真實需求。　
• 三層驗證模型：

◦ 用戶驗證 (User Validation)：確認用戶是真實存在的，並且有真實的需求。　這須要透過訪談、洞察分析（如用戶畫像、痛點分析、現有行為）來完成。　

◦ 產品驗證 (Product Validation)：確認解決方案能真正解決用戶的痛點。　要求產品功能與痛點完全對應，避免功能過多或無法有效解決痛點。　這過程包含用戶旅程設計和原型驗證。　

◦ 商業驗證 (Business Validation)：明確商業邏輯、市場大小及商業利益關係。　這要求在FAQ中詳細寫清財務、營運和競爭對手相關的細節。　

• 「書面化」的重視：亞馬遜非常重視書面溝通，開會時不使用PPT，而是閱讀預先準備好的文檔，並直接在文檔上標註問題和回覆。　貝佐斯認為，只有寫下來的東西才是明確的，否則一切都像「模糊狀態」。　
• 與設計思考的區別：設計思考在IoT時代，產品「一定會有人用」，只須要優化體驗。　逆向工作法則特別適用於軟體或全新服務，其更重要的問題是：客戶「須要」這個服務嗎？是否會有「根本沒人要用」的風險？

 

三、實踐案例：大型國企客服系統優化

• 挑戰傳統設計原則：一家集中供暖的國有企業的客服系統設計，初期目標是「讓客服快速解決問題」。　然而，老闆卻不在乎，其核心訴求是「不要讓客戶撥打12345政府投訴熱線」。　
• 數據驅動問題發現：透過分析一年的客服通話數據，發現17,000通電話中，14,000通是諮詢電話，60%可以當場回答，甚至5,000通是重複性的「查詢卡號繳費」。　也就是說只有3,000多通須要派工單，且不必全部上門服務，因為50%的用戶問題只要照著視頻教程或簡單操作就能自行解決。　
• 以終為始的解決方案：基於數據分析，團隊放棄了快速解決客服問題的初衷，轉而針對老闆最在意的「不打12345」和用戶最常遇到的問題設計解決方案。　例如，推廣已有的查詢網頁，並確保用戶容易找到「卡號」；預先派人上門服務以解決簡單操作引發的問題。　這使得通話量顯著下降，並提升了整體用戶體驗。　這個過程證明了從數據中找出真實痛點，而非盲目開發新功能。　

 

四、實踐案例：門禁考勤品牌商的商業模式設計

• 挑戰複雜經銷網絡：中國最大的傳統門禁考勤公司面臨競品的強勢壓制，後者能要求經銷商註冊進入其系統，而前者只有一級經銷商，無法觸及二級經銷商，且不同省份的價格體系複雜，存在「竄貨」問題，品牌商難以有效管理及補貼。　
• 使用者旅程的重新定義：「使用者旅程」的定義是，最終面對用戶的經銷商如何從尋找客戶、建立信任到最終銷售的全流程，而非單純的系統使用流程。　
• 設計商業邏輯而非僅介面：這個項目核心是設計商業邏輯和新的營銷策略，因此，提出一個「憑證」機制：品牌商給予一級經銷商帶有信息的優惠憑證，一級經銷商再將此憑證發給二級經銷商或最終客戶。　透過憑證，品牌商能追溯商品流向，將優惠直接給到二級經銷商或最終用戶，解決了過去優惠被一級經銷商截留的問題。　
• 這個機制的成果：

◦ 無需強迫經銷商進入系統，降低了推廣阻力。　

◦ 維持了經銷商之間的價格不透明性，避免了因公開價格而引起的內部矛盾。　

◦ 憑證機制天然地防止了竄貨行為。　

◦ 透過精準補貼，銷量提升至平常的18倍（原政策為10倍），一級經銷商利潤提高，二級經銷商也因得到直接優惠而更願意銷售。　在相同補貼成本下，公司一年可多出3,000萬營業額。　

• 這個案例證明了設計思維不僅僅是介面或體驗設計，相同的設計方法也能用於設計商業邏輯和利益關係。　

 

 

LLM驅動實作 (LLM-driven Implementation)

 

一、核心原則

　　許弘霖認為我們應該視LLM為使用者，對話 (Prompt) 應該避免以下常見錯誤，以獲取更準確、有用的結果。　

• LLM的「自動補全」特性：LLM在生成答案時，會自動補全用戶未明確說明的條件。　如果用戶沒有提供足夠清晰的需求，AI補全的內容可能不符合預期（例如：設計短網址系統時，AI會預設為最高級別的企業級、軍用級別系統，但實際可能只須要簡單的內部使用，造成資源浪費）。　
• 借鑒使用者訪談的原則：

◦ 不推銷 (No Pitching)：不要預設答案或試圖引導AI說出你想聽的內容。　像在訪談中不向客戶推銷產品一樣，不要一開始就告訴AI你的「神性」需求。　

◦ 無冰淇淋問題 (No Ice Cream Questions)：避免提出顯而易見或只能得到肯定答案的問題。　這類問題無法提供有用信息，只是自我驗證。　

◦ 拉出資訊，不要推入資訊 (Pull, Don’t Push)：盡量從AI那裡「挖取」資訊，而非將自己的想法「推給」它。　以開放式問題提問，讓AI從一張白紙開始思考，並不斷追問，探索不同的解決方案，避免被自己的認知限制。　

◦ 孤證不立 (One of One is Not Proof)：不要因為AI給出一個答案就認為它是絕對正確的。　一個答案並不能證明或推翻任何事物。　

◦ 過去行為是最佳預測者 (Past Behavior is the Best Predictor of Future Behavior)：在提問時，應關注事實和過去的實際行為，而非理想化的「聲明」或「計畫」（例如：問「你如何飲食？」不如問「你上一餐吃了什麼？」）。　故事比聲明更有用。　

• 敏捷開發流程：與LLM互動時，將大的任務切分為小的、可執行的步驟。　這可以增加對AI產出過程的掌控度，避免黑盒效應，並更容易修正錯誤。　

 

二、實作分享：利用AI工具提升產品開發的效率和品質

• 新聞稿和FAQ的快速生成：LLM可以極大地幫助產品開發的初期階段，例如快速生成新聞稿和FAQ；只需提供簡單的概念，ChatGPT就能迅速產出結構化的內容。　
• AI輔助程式碼撰寫 (AI Coding)：

◦ 多樣化的應用層次：AI可以用於撰寫特定功能、修改程式碼片段、提供新功能建議，甚至在類別（class level）或整體架構層面進行規劃。　

◦ 提升效率：AI能同時修改多處程式碼，相比人工修改能大幅節省時間，特別是在處理較長程式碼時。　

◦  AI的互動模式可分為三種層級，類似於企業中的角色：

▪ 工讀生：執行明確的小塊任務。　

▪ 員工：處理類別級別的任務，有明確的工作範圍。　

▪ 主管：負責完整的架構，AI能自主清洗數據、撰寫模型並給出結果。

 

三、設計師在AI時代的定位

• 開發成本降低：在LLM時代，開發成本大幅降低，各專業領域的門檻也越來越低。
• 像「知識挖掘」的過程：與ChatGPT互動的過程，本質上是從一個裝滿人類知識的巨大資料庫中，進行知識挖掘。　
• 「創意設計師」的價值：矽谷的知名孵化器YC（Y Combinator）正尋找「創意設計師」（Founding Designers），他們具備強大的用戶同理心、解決問題的專注力，以及對品質和品味的極高要求。　在低成本環境下，設計師的結構化創新思考能力變得尤為重要。　

 

 

Q & A

 

Q1：智慧門禁考勤系統案例若從原先的B2B模式（品牌商對一級經銷商）轉為更接近B2C的模式（補貼直接傳遞給二級經銷商），會不會大幅增加客戶服務的人員需求和成本？

A1：這個模式並非真正轉向B2C。　它維持了既有的經銷通路，只是透過「優惠憑證」的技術方法，讓品牌商能將補貼精準地傳遞到最底層的經銷商（二級經銷商），而不須要額外增加客服人員，因為銷售渠道並未改變。　

 

Q2：這種直接補貼二級經銷商的方式，會不會讓原先的一級經銷商感覺被品牌商跳過，進而影響他們的合作意願？

A2：，這個「憑證」是由一級經銷商自己發放給二級經銷商的。　一級經銷商有彈性，可以選擇發放，甚至自己購買使用。　儘管這確實會讓品牌商得知其客戶資訊，但團隊透過詳細的財務模型證明，這種模式能讓一級經銷商無需壓貨，成本更低，且整體銷量可大幅提升（甚至達到原來的18倍）。　這是一種逐步鬆動經銷商心態，讓他們意識到透過這種模式能將生意做更大的方式。　

 

Q3：目前「智慧門禁考勤系統」產品的實際形式是什麼？是雲服務還是實體產品？

A3：這是一個雲服務，目標是建立一個經銷商的服務後台，讓經銷商能更好地管理客戶。　核心邏輯是透過憑證機制，逐步收集二級經銷商的數據，並鼓勵其參與，最終達到共同擴大市場的目標。　

 

Q4：在進行使用者地圖（User Journey Map）時，初期通常會訪談多少位使用者？

A4：至少須要訪談5到6位使用者。　如果產品面對不同類型的使用者，那麼每個類型（User Type）至少要有4到5位訪談對象，以確保足夠的代表性。　

 

Q5：以「先用後付」服務為例，最初是如何進行使用者分群與訪談的？是預先分好？還是訪談後？

A5：總共訪談了18個商家。　最初並未預先設定分群，而是根據訪談回來的購買行為、收入水平（三等）和購買品類等資訊，利用兩個軸線（對借貸的開放程度與薪水收入多寡）來劃分出不同的使用者群體。　

 

Q6：當使用者研究的結論與公司高層（如投資人、最高老闆）的期望方向不一致時，應如何處理？

A6：想辦法讓老闆「漸漸真實地」去接觸使用者，這比直接說服他們更有效。　當高層親身見證使用者的真實需求和困境時，他們的想法可能會隨之改變。　

 

Q7：在產品開發中，當使用者需求與「出錢的人」（高層或客戶）的需求發生衝突時，應該優先考慮誰？

A7：「出錢的人」永遠是最重要的。　以供暖客服系統為例，老闆最在乎的是「不要打12345政府熱線」，而非客服效率。　因此，產品設計必須優先滿足「出錢者」的核心痛點。　然而，這也為設計師提供了一個機會，思考如何從使用者需求中挖掘出新的商業機會。　

 

Q8：在初期向最高老闆展示產品概念時，原型（Prototype）應該做到多精細？是須要視覺化很完整的模型，還是簡單的線框圖即可？

A8：高層老闆可能不那麼在意原型的精細度，而更關心最終能產生什麼樣的「報告」或成果。　因此，最重要的是驗證該報告的價值是否符合老闆的期望。　即使初期須要人工手動產生報告，只要能證明其價值，就應以最簡單的方式實現，而不須要在產品開發上投入過多資源。　

 

Q9：在開發早期階段的AI產品（例如AI與法律結合的產品），客戶可能無法想像其應用方式，難以獲取真實需求。　除了讓有興趣的人自己來體驗之外，還有其他獲取客戶需求的方法嗎？

A9：這涉及到「AI-first company」的概念。　如果客戶無法想像，或許就應該自己成為這個產品的最大用戶，甚至開一家「AI驅動」的律師事務所。　透過將自己的業務做大，證明AI賦能的能力，客戶自然會被吸引，這比試圖說服那些缺乏想像力的既有玩家更有效率。　

 

 

 

 

 

---