什麼時候會需要由產品主導跨部門討論？
通常一般的小功能迭代與優化，都是奠基在一個比較具體的需求背景上，例如：需要有個提示來提醒信用卡即將過期的使用者去更新他的付款資訊。這種體驗上的優化，通長會是直接由 PM 排給產品設計師發想流程與畫面後，就排進下一個 sprint 的開發。
但有時候會出現一些非常模糊的需求，通常對應到年度 OKR，例如：我們想要打造一個全新的功能，提高用戶對平台的黏著度，但要朝哪個方向、形式、受眾…一切都還是個問號。像這種摸不著邊際的需求，在直接執行設計前，就會需要跟跨部門進行前期討論。除了可以藉此了解每個部門的需求和關注點，進而開發出更全面且符合市場需求的功能。也可以確保團隊成員彼此之間的認知是否一致並朝著相同目標前進。
雖然 Google 提出的 UX framework — Design Sprint 會是專門用來解決這種模糊問題的利器，但要讓大家花時間與產品團隊共同進行為期五天的專注討論，在現實中是滿難發起的會議（畢竟大家事情都很多…)，因此我通常偏向先和產品經理進行完 “Develope” ，再請大家以 1–2 小時的時間進行 define & Ideation 的部分，目標是取得各部門對方向上的共識，以下是通常我進行的流程：
Develop-1: 問卷調查 Quantitative Survey Research
我通常和產品經理會先確認我們拿到什麼資料/數據有助於定義問題，然後規劃好問卷，進行問卷調查，拿到量化的資料後進行初步的分析。這樣可以幫助我們了解到用戶的需求和想法，以及他們希望產品能夠實現的功能和特性。我們會分析這些數據，以確定用戶真正想要什麼，以及找到 insight, 歸納出我們的產品可以朝哪些方向發展的機會點。
Develop-2: 競品分析 Competitor analysis
根據問卷分析中得出的幾個機會點，分別找出擁有相似功能、方向的產品。我們會分析競爭產品的特點和優點，以及他們的缺點和不足之處。這樣可以幫助我們在設計時避免重複和避免犯類似的錯誤。了解競爭對手的產品，可以讓我們更好地了解市場趨勢和客戶需求。
Define & Ideation: 跨部門設計衝刺 Use Design Sprint frame work to collaborate cross-departments
在這個過程中，我們會邀請各部門的代表參加產品設計會議，利用 Prons&Cons, HMW, Note-n-map 等framework 讓大家聚焦與定義問題，接著讓大家分組，每人利用紙跟筆 sketch 出自己的想法並分享給組內聽，每組再討論出一個最好的想法進行細化，最後每組的想法將會被上傳到 Figjam 上，接著每組輪流報告組內的想法，當報告完後，每人都可以利用便利貼去在別組想法上留下自己的意見(Question, Like, Don’t like, Want…)，最後進行投票並達成共識。
透過這個過程，我們也會理解從不同部門角度會有的 Concern 和 Want。例如，BD 團隊可能關心產品的推廣策略與商業價值，而 Product 團隊可能更關注產品的技術實現方式。了解這些需求和關注點可以幫助我們在產品設計中做出更好的決策。並且也可以確保所有部門都參與到設計決策中，達成共識。
準備設計草稿，進行使用者訪談 Low fidelity-wireframe for Qualitative User Interview
在達成共識後，我們會準備 Low fidelity 的 wireframe。這些 wireframe 可以讓我們更加具體地了解產品的外觀和功能。並與產品經理共同規劃下一階段的使用者質化訪談，以驗證在上一階段我們和其他部門的共識設計策略是否能讓真正的使用者買單。
這些訪談可以幫助我們更好地了解客戶對產品的看法和需求，並進一步優化產品設計。在訪談結束後，我們會根據這些訪談結果進行修正，確保產品能夠最大程度地滿足客戶需求。
進行 mid fidelity 的設計與各部門確認
在進行使用者質化訪談之後，我們會進行 mid fidelity 的設計。這些設計可以更加具體地表現產品的細節和特點。我們會再次邀請各部門的代表進行確認，以確保產品設計有符合各部門需求。
擬真互動原型提供易用性測試 Prototype for Usability Testing
與各部門確認方向後，我會再根據 mid fidelity 的 mockup 建立一份互動原型 prototype 讓使用者進行易用性測試。我們會邀請有參與問卷調查的使用者參與易用性測試，為了方便進行與提高參與意願，我們通常會採取線上進行，分享 figma prototype 連結給使用者，並全程錄音錄影。透過使用者的 feedback, 再逐步修正我們的原型。
高擬真原型設計 High fidelity Mockup
進行完易用性測試後，根據使用者意見進行修改，完成高擬真的設計稿，並與跨團隊進行最終確認。
交付設計稿 Planning with Engineer and Handoff
最終與工程師進行 planning 並切開發階段，確認最小可開發的 MVP 功能與流程，再進行最後的 Handoff 稿。
