學校沒教的跨團隊設計合作術 Ep1：專案前期原來要這樣做？！
後設資料
- URL：https://www.youtube.com/watch?v=UPQWlOAQb6s
- 頻道：Unblock
- 主持人：Blair
- 集數定位：頻道第 15 集；「跨團隊設計合作術」迷你影集第 1 集（共 3 集）
- 內容形式：YouTube 影片（口語講解 + 投影片）
- 語言：繁體中文
- ASR 來源：YouTube 自動字幕（含明顯辨識錯誤，本頁原文段落保留逐字稿，wiki 摘要段已修訂）
一句話濃縮
設計師要讓自己的點子被買單，不能直接動手做設計，而是先用「鑑識利害關係人 → 擬定溝通計畫 → 工作坊收編」三步驟把厲害但還沒被收編的人變成盟友——專案後期的成本曲線是前期溝通省下的。
提取要點
影集脈絡
- 三集迷你影集：
- Ep1（本片）：你從零開始領導一個專案時，如何鑑識並收編利害關係人
- Ep2：你中途加入已混亂專案、各方意見不一時，貪汙空洞的設計師怎麼處理（影片預告，未 ingest）
- Ep3：實際操作技巧（影片預告，未 ingest）
- 元命題：「點子不夠好」很多時候不是真因，而是設計師還沒跟厲害關心人建立健康的合作互信關係
大原則：時間 vs 成本曲線
- 產品最早期討論成本最低；隨時間推進，新意見納入時改動成本越來越高
- → 前期溝通投資 = 後期改動成本的對沖
三步驟搞定利害關係人
步驟 1：鑑識（誰是利害關係人）
四個鑑識問句：
- 誰在聽這個專案？
- 誰會受到影響？
- 誰可以影響這個專案？
- 誰說了算（專案能否成功執行的決策權）？
示範情境：FinTech 新創產品設計師，公司進入高度成長期、Dashboard 資訊架構漸不堪用，建議啟動研究專案找最佳資訊架構——影片用此情境列出對應的四類利害關係人。
步驟 2：擬定溝通計畫
態度光譜（resistance ↔ commitment 曲線）：
利害關係人的當下態度沿一條曲線分布；溝通計畫的目標是把每個人從曲線左邊（抗拒）移到右邊（承諾）。
辨識立場的方法：除了問頭銜與職位之外，需要主動聯繫 / 咖啡閒聊 / 內部打聽才能精準掌握每個人的真實態度。
利害關係人參與群目表：團隊內部的檢討工具——隨專案時間推進可回頭更新每個人的態度演進，是「有極限的」追蹤紀錄。
利害關係人特寫：對於關鍵盟友（或潛在阻力者）做的個人 profile，重要欄位包含：
- 什麼事情會讓這個利害關係人公平 / 滿意 / 願意支持
- 專案目標與這個人的個人 KPI / 在乎的事有沒有重疊區
- 如果他持續抱持負面看法，可以用什麼方式扭轉
→ 核心動作：透過更多的傾聽理解他們的擔憂，再想辦法解除擔憂、介紹他們的利益。
步驟 2 工具：影響力與利益矩陣（Influence-Interest Matrix）
四象限分群 + 對應策略：
| 高利益 | 低利益 | |
|---|---|---|
| 高影響力 | 執行夥伴：直接給意見、直接執行 | ⚠️ 隱形殺手：會議裡「這個不行 / 那個不好」的源頭，需自己主動聯繫降低擔憂 |
| 低影響力 | 變動時通知 / 定期 update | 變動時通知 / 定期 update |
重要 caveat：高影響力不等於頭銜或職位高度——一個人若人緣特別好 / 待得特別久 / 人脈特別廣，影響力也會很高。列矩陣時不要只看頭銜。
示範情境的對位：
- 品牌設計總監、設計團隊總監 → 高影響力 + 低利益（不直接受 Dashboard 改動好處，但影響力大）→ 應主動衝擊
- 產品線上的提案設計師、寫手 → 低影響力 + 高利益
- 產品線上負責買數據的設計師 → 低影響力 + 低利益
配套產出：寫一個溝通計畫模板，並分享給利害關係人——讓對方知道何時會收到怎樣的訊息，是降低焦慮的方法。
1:3 聆聽比例：對極端有影響力但難搞的對象，溝通時自己說話 vs 對方說話 = 1:3——主要是聽對方在忙什麼、想推動什麼，把焦點放在雙方可共鳴的部分，從對方的立場找到「賣點子、賣專案」的入口。
步驟 3：工作坊（收編而非交付）
目的不在產出多漂亮的成果，而在於讓利害關係人提早對專案有貢獻 = 自動變盟友。
參與者組合 tip：除了核心利害關係人，還可以邀請影響力低但已是專案支持者的人——靠氣氛擴散讓「這個專案對公司有好處」的感覺更廣。
工作坊應該釐清的「專案執照原則 / 指導原則」：
- 專案的價值 — 例：「FinTech 產品必須讓非專業財經人士都可以直覺使用，但現行導覽列違反此目標。」
- 完成的方法 — 例：「透過研究與設計部門協作，做更直覺的重設計。」
- 已知的數據 — 例：「>50% 企業用戶曾向客服抱怨打開列使用體驗。」
- 符合 SMART 的目標 — 例：「第一季完成嚴重設計與網頁版上線；新導覽列將因產品導覽列造成的客服數量在第三季末降低 X%，並縮短版本注意時間，以確保產品在所有平台的競爭力。」
SMART 拆解：
- S Specific（具體）
- M Measurable（可衡量）
- A Acceptable / Attainable（可被接受 / 可達成）
- R Relevant（相關，與其他產品團隊目標 / engine 連動）
- T Time-bound（時限）
→ 元紀律：「專案目標、指導原則沒基礎之前，千萬不要讓產品團隊或利害關係人跳進需求——否則專案會被立刻帶偏」。
步驟 3 配套：成功度量框架
- Google HEART framework（影片提及，未展開）
- AARRR（影片提及，未展開）
- → 影片建議再附資料延伸閱讀；本頁列為觀察清單。
步驟 3 推薦工作坊活動（3 個）
- Jobs to Be Done（JTBD）
- POD（影片發音「P-O-D」；推測為 Point of Difference 或 Persona-On-Demand；ASR 解析失準，待驗證）
- 顧客旅程地圖 / Persona（影片暗示，第三項口語不清晰）
重要的元命題：這些活動「通常需要研究數據才能反映真實使用者」——但在這個早期收編階段，沒有數據也照樣辦——因為唯一的目的是偷窺利害關係人對使用者的看法並對齊對專案目標的精細定義。
提取概念
連結到此來源衍生 / 更新的 wiki 頁：
- 利害關係人管理 — 本來源新建：vault 第一個 stakeholder management umbrella
- 影響力與利益矩陣 — 本來源新建：2×2 利害關係人分群工具
- SMART目標 — 本來源新建：vault 第一個 SMART 目標頁
- Unblock — 更新：補入「跨團隊設計合作術」迷你影集第 15 集；先前主軸為品牌設計，此 Ep 顯示 Unblock 也涵蓋 UX / 跨團隊協作主題（主軸註解需修訂）
- 立場與利益 — 既有概念呼應：1:3 聆聽比例 + 「理解擔憂、介紹利益」是同精神在 in-house 設計師場景的應用
- 原則性談判法 / 把人跟問題分開 — 利害關係人特寫的「先理解擔憂再介紹利益」對位「對事不對人 + 利益優先」
- 專案管理 — sibling 概念：專案管理是甲方 account 視角的「預防勝於治療」；本來源是 in-house 設計師視角的「前期收編利害關係人」——同精神不同場景
- Goal-Signal-Metric — SMART 目標可作為 G-S-M 框架的「目標」層具體寫法
- 使用者研究 / 人物誌 / 顧客旅程地圖 — 工作坊活動清單呼應
Ingest 筆記
本次 ingest 由使用者直接貼入 YouTube 影片連結 + 完整 ASR 逐字稿（含明顯辨識錯誤）。本來源是 vault 第一個 in-house 設計師視角的跨團隊協作 / 利害關係人管理主題影片，為 Unblock entity 補上「品牌設計以外的第二條主軸」。
ASR 辨識錯誤修訂（不窮盡，僅列影響理解的部分）
- 「厲害關心人」→ 利害關係人（stakeholder）
- 「PinPage 新土地公司」→ FinTech 新創公司
- 「保持功能不多」→ 推測為「Dashboard 功能不多」
- 「HARC 這個 brainwork」→ HEART framework（Google UX 量化指標：Happiness / Engagement / Adoption / Retention / Task Success）
- 「ARR」→ 上下文判斷為 AARRR（Pirate Metrics：Acquisition / Activation / Retention / Referral / Revenue）
- 「POD」→ 未確認；可能是 Point of Difference、Persona-On-Demand 或其他工作坊活動代稱
- 「執照原則」→ 指導原則（guiding principles）
- 「貪汙空洞的設計師」→ 推測為「夾在中間 / 卡在中間的設計師」（middle / sandwich position designer）
- 「迷你影集」→ 設計用詞，非錯誤
- 「公平」→ 上下文是「讓他滿意 / 有面子 / 願意支持」（look good / win），ASR 把 “make X happy” 類概念辨成「公平」
概念抽取的判斷
為什麼建 利害關係人管理 為 umbrella，而非掛在 專案管理 之下？
- 專案管理 既有頁是 只要有人社群顧問 傑哥 account 視角，聚焦「預防勝於治療」+ Account 三流分級 + 執行前四確認 + 執行期四習慣——是甲方 / 接案場景的專案執行紀律。
- 本來源是 in-house 產品設計師視角的前期準備工法，主軸不是「執行期不出包」，而是「啟動期把人收編」——同樣處理「多方利害關係人」但角度與場景不同。
- 兩頁應為 sibling，互相對位：專案管理「讓專案不出問題」/ 利害關係人管理「讓人變成盟友」——前者守過程，後者爭支持。
- 未來如累積 PMP / Scrum / RACI / 跨組織協作等更通用的「組織協調」內容，可考慮再上一層 umbrella 收攏。但目前 vault 只有兩頁，不必過早抽象——保持兩個 sibling 並列即可。
為什麼 影響力與利益矩陣 獨立成頁而非寫在 利害關係人管理 內？
- 此矩陣是獨立可重用的工具——對位 優先順序矩陣（任務 2×2）、價值主張畫布（顧客 vs 產品 2×2）等 vault 中的「2×2 工作坊工具」族系。
- 未來其他來源可能單獨引用此矩陣（例如 PMP 教材、敏捷組織書），先獨立建頁有利長期累積。
- 但此頁初版內容會較精簡——主要敘述工具本身 + 高影響低利益的「隱形殺手」洞見 + 不要只看頭銜的 caveat；其他 stakeholder 細節（態度曲線 / 特寫 / 工作坊）留在 umbrella 頁。
為什麼 SMART目標 獨立成頁而非寫在 Goal-Signal-Metric 之下？
- Goal-Signal-Metric 是 Google 提出的指標體系框架（G→S→M 三層拆解，最後落到事件埋點），重點是「從目標到指標的拆解流程」。
- SMART 是目標寫法的檢驗工具——可以說 SMART 是 G-S-M 中「Goal」層的書寫品質檢驗。
- 兩者同 cluster 但語義粒度不同：G-S-M 解決「指標體系怎麼建」/ SMART 解決「目標句型寫得好不好」。
- 獨立成頁更有利於後續 ingest 命中（其他來源大量提及 SMART，會引用本頁）。
本來源帶出的觀察清單（未在本次 ingest 動工）
| # | 待 ingest 項 | 來源 |
|---|---|---|
| 1 | 跨團隊設計合作術 Ep2（中途加入混亂專案的處理） | 本影片預告 |
| 2 | 跨團隊設計合作術 Ep3（實作工具） | 本影片預告 |
| 3 | HEART framework 完整版（Google UX 五指標） | 本影片提及，未展開 |
| 4 | AARRR / Pirate Metrics 完整版 | 本影片提及，未展開 |
| 5 | Jobs-to-Be-Done（JTBD）方法論完整版 | 本影片提及，未展開 |
| 6 | POD 確切含義驗證（Point of Difference? Persona-On-Demand?） | 本影片 ASR 模糊，需獨立查證 |
| 7 | 利害關係人態度曲線（Resistance ↔ Commitment）的學術出處 | 本影片提及曲線但未引用出處 |
元觀察：Unblock entity 的主軸需修訂
Unblock entity 目前簡介稱「主軸聚焦品牌設計」——但本影片屬於「跨團隊設計合作術」迷你影集（迷你影集從 Ep15 起算），顯示頻道至少有兩條主軸：(a) 品牌設計流程框架（Ep 1-4）/ (b) UX 設計師職場協作（Ep 15-）。本次 ingest 會在 Unblock 頁補上此修訂。
pipeline 視角：原本的「設計教育型 YouTube 頻道 = vault 少數案例」備註仍然成立——但本來源證明，當頻道累積多條主軸時，entity 的「主軸」描述要從單條變多條——未來其他多主題創作者 entity（劉潤 / Tim Ferriss 等）也會有類似修訂時刻。
原文（可選）
以下為 YouTube 自動字幕逐字稿，含明顯 ASR 錯誤（最大量為「厲害關心人」應為「利害關係人」）。保留原文以利長期保存；wiki 摘要段已修訂。
哈囉 大家好 歡迎大家來到 學上沒教的跨團隊設計合作 第15集 今天這一集裡面提到的所有的模板 我們都會直接投信好不好 做好打包在YouTube這邊直接下載 我直接給你這些連結 然後我們把那些模板全部都下載進來 那這樣以後我們在收看這些節目 就可以更順利的跟你的厲害 關心你的資訊 做出策略囉
哈囉 大家好 我是Blair 今天很高興終於就回來看到你們啦 那這一次非常的特別 我們這個迷你影集 主要要包含了所有所有專案裡面 厲害關鍵的大大小小是各種的Tip 這一次的迷你影集三集 要一次交給你好不好
身為設計師的你 是不是曾經很沮喪過 為什麼每一次你有很好的點子的時候 你覺得你的客戶 你的老闆 還是你的同事 好像是聽不進去跟同學一樣 其實可能不是你的點子不夠好 可是你還沒有跟他們建立起 良好的健康的合作的互信關係 希望透過這一次的迷你影集 讓大家都能夠學到一些 和厲害關心人的一些偶遇小技巧
也不要忘了如果你喜歡我的內容的話 記得按讚訂閱開小鈴鐺 好 那我們就直接進入正題吧
好 那這一次的影集總共分成三集 今天的第一集會告訴你 如何用三個步驟搞定厲害關心人 那第一個階段就是 那第二個階段我們就要來到了 第三個階段是有一些工作碼 可以教給大家大概怎麼樣去操作
好 第一個步驟準備型 誰是你的厲害關心人 很多新手設計師常常犯什麼錯誤呢 就是什麼都沒有問 什麼樣的工作都沒有做 你能搞清楚 對於這個案子的厲害關心人到底是誰 就一頭栽下去的 直接開始會就要做設計啊什麼的 最後一次成果發表給大家看到之後 其他厲害關心人才發掘說 這個不對啊 這個不好啊 調成點是的啊 那你那時候就覺得 唉 怎麼這麼多力 這麼辛苦的花這麼多力氣 為什麼沒有人買單做設計
那其實除了設定本人心理健康 從這張圖表也看得出來 其實跟厲害關心人溝通 跟專案的成本有非常直接的關係 產品最剛開始出擊的時候 其實也還是有很多討論的空間 當然這樣子的改動上面的成本 隨著時間的溝通在裡面 越來越成熟之後 如果你這種又納入了一些 厲害關心人的意見啊什麼的 其實改動的可能就會越來越高
那到底你要怎麼樣辨別出 誰是你的厲害關心人呢 其實有四個非常重要的問題 可以問大家 第一個就是 誰在聽這個專案 第二個就是 誰會受到這個專案的影響 第三個就是 到底誰可以影響這個專案呢 好 最後一個就是 這個專案到底能不能成功執行 到底是誰說了算
那我現在會給大家一個情境 我是一個PinPage 新土地公司的產品設計師 公司呢已經有一個 已經支援我們的Dashboard 但是因為保持功能不多 資訊架構裡面的Action 都非常的簡單 公司進入高度成長期之後呢 新科學開了各樣的功能 漸漸的不是我們 必須使用現行的那個Action 你建議你的產品裡面 應該要一起發動一個研究專案 找出最佳的Dashboard 資訊架構 然後來給你設計
這一張投影片都列出了 所有我剛剛討論的 四種類別的厲害關心人
好啦 那當你鑑識完 知道誰是你的厲害關心人的時候呢 其實你就可以更進一步的去 體驗他們對於這個專案的立場
所以呢 我們才剛剛列出這四種種類的 厲害關心人之後呢 這篇專案的目的 基本上是給你一個curve 一個輔助 那其實你可以利用這張書表 就可以發現 透過所有厲害關心人的工作裡面 你們要達成的目標就是 用你的溝通技巧 跟你的溝通計畫跟策略 慢慢的把每一個人 從曲線的左邊移動到右邊
那其實呢 在大部分的專案裡面 你只要區分 這幾種態度類別就可以了 那有時候呢 可能不是這麼容易理解 厲害關心人的立場 那就要透過很多 你自己打工的方案 甚至是咖啡 閒聊這些方法 達成他們的態度跟立場
好 那在你把他們的態度 都打聽完之後呢 你就可以製作這一個 厲害關心人的參與群目表 那事實上就是給你 或是給你自己的團隊 當作一個採討用的工具而已 隨著專案的時間演進 你也可以回頭一次來說 所以在這張表 告訴你的厲害關心人的態度 是一個有極限的一種
那除了這個態度 假設你有其他 非常贊助支持這個專案的人 那你也可以呢 看他們製作一個 厲害關心人特寫的東西 這樣子讓整個團隊 專案的支持者呢 就可以一直看到 我們現在到底有哪一些人 可能是我們的路障 那怎麼樣培養這些人呢 然後什麼路障 就是可能成為我們的盟友
那這一個厲害關心人特寫 有些話題是非常重要的 就是一定一定要記住起來的 例如說什麼事情 讓這個厲害關心人公平 像假設 今天一個 Marketing Director 之類的話 他是不是很帥 那你也要等一等 等到 Marketing Director 呢 就要去看他的照片 那當然你在溝通宣言的時候 你也可以用這些小數據 貼圖看他會說什麼
那再來下一個問題是 專案跟這個厲害關心人 他在庫的地方到底有沒有重疊 那當然有重疊的地方的話呢 你能不能把它找出來 那下一點呢就是 如果這個厲害關心人 就是一直都持著這樣負面 對於這個專案這樣負面的看法的話 那你到底要怎麼樣可以扭轉他 對於專案的負面看法
這邊有一個溝通的小地方 那就是假設這個厲害關心人 你已經知道他對於這個專案 負面的看法 或是負面的態度 那千萬你就一定要透過 更多的聽人 去理解他們的擔憂 然後呢 想辦法介紹他們的擔憂 跟介紹他們的利益
好那再來就介紹第二個階段 就是你要開始擬定你的溝通計畫了 我們已經找出來了 誰是你的厲害關心人 那接下來你要怎麼樣 用不同的溝通策略 去把他們變成你的盟友
好那這邊呢 就有一個非常好用的矩陣了 我把它叫做 影響力與利益矩陣 那這個矩陣其實很簡單 它就是畫一個十字形 然後把所有的厲害關心人分成 對專案的利益程度是高和低 以及它的影響力到底是高還是低
高影響力跟高利益這個群組呢 你就算是專案的執行夥伴 他們可能會非常直接的 在你專案裡面給你意見啦 給你一些回饋啊 然後甚至可能是執行的人嘛
那接下來呢 低影響力的這兩個群組 事實上沒什麼太大的差別 那其實你就只要 譬如說有變動的時候 通知他們或是定期的 給他們update一下說 這個專案正在發生哦 自己的工作上 有一些跟這個專案有出發的東西 注意一下那種感覺
將來很多殺死各種設計師的 幕後黑手 其實就是高影響力 低利益的這個群人 他們呢 除非那些一直在你的會議裡面說 這個不行 那個不好 你這個東西做得不夠 他們可能是因為 他們自己手上的專案啊 或是個人的一些目標 跟這個專案有所衝突 所以呢 關於這一個群組的厲害關心人 應該要自己非常主動的去聯繫他們 降低他們的擔憂
好那回到剛剛 你自己舉的這個案例 你是不是可以直接列出 影響力、利益、局陣 把這些剛剛講到的厲害關心人 全部都放到這一個局陣裡面 例如說品牌設計總監 設計團隊總監 把它放在了高影響力跟低利益 他們這些人不會直接的 通過這個 Cashflow Navigation的專案 他們得到直接的好處 但是他們的影響力很高 那我就更應該 主動一點的去衝擊 因為影響他們的民族特別的擔憂
接下來例如說 低影響力、高利益這群人 其實有可能從產品線上 提到設計師啊 或者是寫手啊 那低影響力、低利益 有可能是在你的產品線 負責買數據的設計師 他一定會影響到你 但是影響真的不大
我想要補充一點的就是 在這個高影響力 有時候不一定是頭銜或職位高度 如果這個人他在行政裡面 一個人會特別好 或者他待的特別久 他知道的特別多 人會特別廣 是不是影響力就也會比較高呢 所以你在列這個局陣的時候 也要小心一點 不要只用他們的頭銜 或者是職位去看待
接下來終於想到 如何跟他們溝通了 其實你就可以列出一個 溝通計畫模板 其實這個計畫模板 也可以寫完之後 分享給你的利害專家 那這樣子你的利害專家 其實也會比較知道說 他們似乎說會收到這個計畫 和你的溝通消息 那其實也是降低他們 焦慮感的一個部分
那你在擬定你的溝通計畫的時候 如果真的對這個專案 其實非常信任太多的人 有些考慮可能要交給大家 首先是你應該要跟他們 慢慢的建立手機感 先聽他們在忙什麼 他們有什麼想推動的東西 以及開始進入正題討論的時候 當然就是把焦點放在 雙方可以共鳴的部分 一起討論 大部分時間都是在 擬定他們的想法 擬定他們的需求 把你跟他說話的時間 控制一下那個頻率 應該要一比三 你說話的時間大概只有一 那叫對方說的時間有三 那就可以更容易理解他們的想法 然後從他們的想法跟立場 去找到怎麼樣去賣點想法 賣點點子 賣點專案
好 第三個階段終於要進入一些 實際操作級的工作坊推薦了 其實這個工作坊 目的已在於 產出多麼了不起的成績 這真的都只是為了提早 那目的是利害關鍵 讓他們提早對這個專案的 跟貢獻 明明是說他們就也變成了 這個專案的盟友
在你的工作坊裡面 其實你還可以找一些 可能是影響力低 但是自己專案的支持者 來這個工作坊裡面 整個工作坊的氣氛 也會讓大家覺得 這個專案是對我們有好處的 這個專案是對公司有好處的 那這個專案的支持者變得更多
好 那其實這些工作坊 到底有什麼目標呢 我們的目標就是 要釐清專案的執照原則 應該是很重要 那這些執照原則到底有哪些呢 我覺得包括了專案的價值 以及我們要用什麼樣的方法 去完成這個專案的目標 然後呢 我們到底有什麼樣的 已知的數據 可以讓我們當作參考 以及最後列出來 符合MARK的目標
好 那我這邊呢 也舉了一個例子 例如說 我們專案的價值是 我的Fintech產品必須讓 非專業財經人士 都可以直覺的使用 但是現行的導覽鏈 已經違反了這個產品的目標 那我們要用什麼樣的方法 來達到這個目標呢 可以是透過研究與設計部門的幫忙 做一個更直覺的重設定 那我們有什麼樣的已知數據呢 可能會是產品經理 或者是數據分析師那邊 已經有一些資料了 說不定是 超過一半以上的企業用戶 曾經都跟客服部門抱怨過 打個烈使用體驗物價 然後呢 產品的FTA也持續的發展
好 那剛剛提到了 這一個符合SMART定義的 專案目標 到底是什麼 其實SMART就是五個 英文是五個 第一個 自組合而成的 第二個 APP 自組合而成的 第三個 是Measurable 第三個 APP 是Acceptable 第四個 是Acceptable 第五個 這意思就是 好的目標應該是要具體的 可以衡量的 這做得好的不是在吃人說夢的 可能跟其他產品團隊 很多的目標或是目標引擎 有相關的 那最後一個呢 就是產品 一定要有一定的時間限制 那才有可能 分配所有產品團隊的資源 想辦法在這個時間內 達到他們的想要的目標
那我這邊就舉了一個 符合SMART目標的例子 第一季呢 我們會完成 嚴重設計以及網頁版上線 新的導覽列 將因產品導覽列造成的客戶數量 在第三季末 並且降低版本注意的時間 以確保我們產品的使用者 體驗在所有的平臺 進行中的競爭力
這樣子的一個專案目標 是不是聽起來就跟 喔 我們現在的 這個東西客戶說的難用 我們要改善它 是不是 好 是不是聽起來就非常非常不一樣 天差地別
然後這邊呢 也有一個小提醒 當專案的目標 或者是指導原則 都還沒有基礎之前呢 千萬不要讓你的產品團隊 或者是品牌關係人 跳進去開始馬上將需求 這樣子呢 你的專案才不會 一下子就馬上被帶偏 被帶歪了
好 那剛剛提到的一個 我Smart的目標是 可以衡量的嗎 那其實呢 有非常多的成功數據指標 那我這邊就舉例一個 大家都非常耳熟能詳的 Google提出來的 HARC這個brainwork 然後呢 以及ARR 那這邊呢 我們會再附一些相關資料 那你就可以自由再多閱讀 這些相關的知識
那到底有哪些工作坊的活動 是我會推薦的呢 這邊呢 我選了三個 第一個是Jobs to be done 第二個呢 是POD 那第三個呢 那你可能會發現說 這些東西 好像都要需要很多的研究 才可以好好的寫出一個 可以反映真實的使用者樣貌的句子 或是反映出使用者 真實樣貌的旅程地圖
事實上呢 在這麼早期 還在想辦法收編收買 各種利害關係人的時候 當然有數據是最好的 但是沒有數據的話 你也可以把他們全部都抓來 歡迎工作坊進行這些活動 最大的好處呢 就是你可以馬上的偷窺到 你的利害關係人 對於這個專案 那他們對於使用者的利益 這到底是怎麼樣
唯一的目的就是 希望你的利害關係人 跟你的合作產品團隊的成員 都對於你的專案 或是你的想要推動的事情 然後專案的目標 受眾等等 有精細的定義 甚至呢 可能有一些初步的點子的發想
那第一集我們就講到這邊啦 這一集呢 我們講了非常多 剛開始沒有人領導的專案 或者是剛開始還混亂不清的專案的時候 你要怎麼收編你的 各種利害關係人 下一集呢 我們講的就是 如果你是中途才加入的 然後這個專案裡面 很多人都納入在這個專案裡面的 各種利害關係人 大家的意見想法都不一樣 身為一個貪汙空洞的設計師 你到底要怎麼去處理 這樣子的情況
所以呢 如果覺得這個主題跟這個內容 對你來說有用的話 就趕快按讚訂閱 好那 那就下一集看到再見囉