案例背景:讓技術變得有人味#
技術沒有意義,直到你理解人類如何使用它、從中受益。這正是技術簡報常見的兩難——強調的是物件本身與功能,而不是它如何幫到使用者。
原始版本:純功能清單#
思科原本的腳本長這樣:
這是一個「整合通訊」(Unified Communications)在製造業上的應用範例。
團隊可以透過 Cisco IP 觸控螢幕電話,或透過手機上的電話使用者介面進入會議。
會議能輕易從單純的語音會議切換到網路會議(若需分享文件),或切換到視訊會議(若需檢視機器即時畫面以解決問題)。
這份描述準確、簡潔——卻完全沒有魅力或角色:
- 它只回答「what」與「how」
- 完全忽略「why」
- 技術能做很多事,但聽眾需要被給予「為何要在乎」的理由
用故事取代功能列舉#
那個「為何在乎」的理由,起點就是故事。先畫一張圖、給聽眾一個能與之共鳴的人物;告訴他們「為什麼」。一旦勾住他們,你才能拉開幕簾,展示技術如何運作。
如果你還沒先表演那場讓人下巴掉下來的魔術,直接跳到「魔術怎麼運作」,你會失去聽眾。
改寫版本:啤酒釀造商 Dave 的故事#
當公司的 tagline 是「the human network」時,讓「人類如何從這個網路中受益」變成簡報的主軸,就更應該。
故事結構與情節#
1. 介紹英雄(Introduce Hero)#
Dave 是一家大型微釀酒廠的老闆。他贏過比任何人都多的區域啤酒大獎,並渴望下一個——他相信自己的得獎配方會再帶他一座獎盃。
2. 設定衝突(Set Up Conflict)#
不幸的是,當他要為比賽釀造新批時,他發現他的祕密原料、心愛的啤酒花還沒到。
3. 用新角色帶入更多資訊#
此時 Dave 的供應鏈經理收到通知——啤酒花在海關卡住了。網路偵測到這則訊息,將它轉給 Dave 的釀酒公司,簡訊提醒了供應鏈經理。
4. 升高賭注(Raise Stakes)#
Dave 處境堪憂:啤酒花未到、海關不知扣多久。他依賴這次比賽的媒體曝光把新品變成今年熱銷,並為了這次活動暫停了大部分產線——錯過時程就會損失營收。
5. 揭露解法但加大挑戰(Reveal Solution, Raise Stakes Further)#
但似乎有解法:在國家的另一端,另一家種同品種啤酒花的供應商今年豐收,需要在腐爛之前出貨。但 Dave 該怎麼辦?他能保住冠軍嗎?比賽方能吸引到所需的觀眾嗎?另一家啤酒花供應商找得到客戶嗎?讓我們看下去……
6. 懸念(Cliffhanger)#
此時可以暫停故事,解說技術如何運作。聽眾會留在懸念中,而你提供解法的背景。這做了兩件事:讓聽眾擁有角色都不知道的資訊,同時讓你能把必要的硬資料分享出去。
7. 解決(Resolution)#
生產經理依新配方計算實際缺額,透過安全網路連線檢查其他關鍵供應商的潛在來源。
他找出替代啤酒花供應商,標明所需數量、確認品種、下單。
種植者的業務代表收到訂單,找到可用的生產主管,點擊跨多種裝置與他連線——確認可立即出貨。
國內供應商與 Dave 確認出貨日期,Dave 也得以確認參賽……
8. 結局#
……他當然又贏了一次。
這個版本把「整合通訊」的功能融進真人故事:以英雄、衝突、解決的結構,讓聽眾在乎、記得、且想複述。