7 個產品解說影片腳本範例

探索七個產品解說影片腳本範例，包含旁白範例、視覺規劃，以及實用的改編技巧。

當你清楚知道影片需要回答什麼問題時，撰寫產品影片就會變得更容易。「這項功能有什麼作用？」與「我要如何開始使用？」需要的是不同的解說方式。

以下七個產品解說影片範例，是針對虛構產品設計的原創腳本概念。每個範例都包含旁白、視覺規劃，以及適合採用該架構的情境說明。這些是寫作範例，並非客戶案例研究，也不代表任何經過測量的轉換率成果。

你可以利用這些範例，為實際產品選擇合適的影片架構。接著，將虛構的產品操作方式替換成你能夠實際展示並確認的功能。

先決定要回答的問題，再選擇影片形式

你可能會接到製作首頁影片、產品上市影片或銷售影片的需求。這些名稱描述的是影片會出現在哪裡，卻無法完整說明觀眾需要理解什麼。

請先詢問提出影片需求的人：這支影片應該消除哪種困惑？訪客可能不了解產品所屬的類別；客戶可能知道產品類別，卻需要看到某項具體操作；現有使用者則可能只需要了解產品有哪些變更。

觀眾的問題	適合的腳本架構
這項功能有什麼作用？	單一功能解說
我該如何開始？	首次使用操作指南
這項產品如何解決我的問題？	問題與解決方案
整個流程會如何進行？	工作流程解說
這適合我的情況嗎？	使用情境範例
它如何與其他系統搭配運作？	整合功能解說
遇到這種特殊情況時會怎麼辦？	常見問題解說

每支影片只設定一個主要問題。如果一份腳本試圖回答全部七個問題，通常就需要採用不同的架構，並投入比短篇解說影片更多的時間。

七個產品解說影片腳本範例

1. 透過具體操作解說單一功能

虛構產品： Pinboard，一個共享專案工作空間，提供釘選更新資訊的功能。

旁白：

重要的專案更新，很容易淹沒在日常留言之中。Pinboard 讓你釘選團隊需要再次查看的更新資訊。開啟專案，選取已核准的更新內容，然後選擇「釘選」。這則更新就會保留在專案的釘選區，讓團隊成員隨時開啟完整訊息。當資訊有所變動時，請重新檢查已釘選的項目，並以最新版本取代舊內容。你可以釘選需要日後再次查閱的決策，例如交付日期或已達成共識的專案範圍。

視覺規劃： 先展示一串繁忙的留言清單，再呈現明確的釘選操作，接著展示釘選區。最後以某位使用者開啟完整更新訊息作結。

這種架構為何有效： 這項功能的用途明確。影片只需展示它如何完成這項工作，不必逐一介紹整個工作空間的所有功能。

實際產品需要確認的事項： 哪些人有權釘選項目、釘選是否會影響通知，以及如何取代過時的釘選內容。如果這項功能不會通知任何人，就不要在影片中呈現通知出現的畫面。

2. 協助使用者完成第一項實用任務

虛構產品： PackList，一款可重複使用打包清單的應用程式。

旁白：

下次旅行時，從一份可以重複使用的清單開始。在 PackList 中建立清單，並依照旅行類型命名，例如「兩天一夜商務出差」。加入實際需要的物品，再將它們分類為服裝、工作用品和必需品。將這份清單儲存為基本清單。下次旅行時，複製這份清單，再依照需求調整副本。保留原始基本清單不變，避免某次旅行才需要的物品，變成每次旅行都會出現的項目。你的第一個實用成果，就是一份符合個人旅行習慣、可以重複使用的清單。

視覺規劃： 展示一份空白清單如何逐漸變成簡潔、有條理的範例。接著並排呈現基本清單與複製後的旅行清單。

這種架構為何有效： 它為使用者設定明確的完成目標。影片最後呈現的是一份可以實際使用的成果，而不是帶領觀眾瀏覽所有選單。

需要確認的事項： 實際的建立與複製步驟。如果產品只支援手動複製，就不要展示不存在的已儲存範本功能。

3. 將具體問題與具體改變連結起來

虛構產品： ReviewLane，一款設計審查工具，可將留言附加至特定版本。

旁白：

上週設計稿的留言，可能會被誤認為是針對今天版本提出的意見。ReviewLane 會將每則留言附加到正在審查的版本。開啟目前的設計稿，確認版本標籤，然後在該版本中留下留言。新增版本時，先前的討論仍會保留為歷史紀錄。在進行修改之前，請先確認回饋意見是針對哪個版本。如此一來，團隊就能針對同一份設計進行討論，不必猜測某則留言是否仍然適用。

視覺規劃： 先呈現兩個版本，以及一則無法明確判斷所屬版本的留言。接著清楚展示如何將留言附加到其中一個版本，再呈現目前正在審查的版本。

這種架構為何有效： 開場提出的問題具體且容易展示。產品操作能直接解決這個特定的資訊模糊問題。

需要確認的事項： 新版本新增後，留言會如何處理。除非已確認留言會自動轉移，否則不要暗示有這項功能。

4. 解說多人參與的工作流程

虛構產品： RequestDesk，一款支援手動指派任務與結案確認的需求追蹤工具。

旁白：

一項需求，通常始於需要協助的人。在這個工作流程範例中，使用者會先在 RequestDesk 提交需求描述。接著由協調人員指派負責人，而負責人在工作完成後記錄處理結果。之後，提出需求的人會確認結果是否符合需求。請清楚呈現這三種角色：需求提出者、協調人員與負責人。如果處理結果不完整，需求就會保持開啟狀態，等待進一步處理。整個流程以確認結果作為結尾，讓人們能清楚區分已完成的任務與已獲接受的結果。

視覺規劃： 使用一張需求卡片，在標示清楚的不同角色之間移動。展示處理結果不完整時，流程如何返回負責人。

這種架構為何有效： 它能解釋工作交接方式與完成條件，這些都是單純列出功能時容易忽略的細節。

需要確認的事項： 實際的狀態、權限與例外處理方式。流程圖再簡潔，也不能憑空創造出比產品實際支援方式更簡單的工作流程。

5. 展示符合觀眾實際情境的使用案例

虛構產品： BriefBox，一個用於準備客戶會議筆記的工作空間。

旁白：

明天的客戶會議涉及三個尚待釐清的問題，以及兩項近期決策。在 BriefBox 中建立會議摘要，並將這些項目分別放入不同區塊。在每項決策下方附上來源筆記連結，讓任何人都能查閱詳細內容。準備會議時，標記哪些問題需要客戶回答，哪些問題可以由團隊事先解決。接著將會議摘要分享給與會者。如此一來，大家就能以一份重點明確的資料作為討論起點，並在需要時隨時查閱相關資料。

視覺規劃： 展示零散的範例筆記，如何整理成包含待解決問題、決策事項與來源連結的會議摘要。

這種架構為何有效： 具體情境能幫助觀眾辨識自己已經在進行的工作。它呈現明確的成果，同時不會誇大或宣稱一定能節省時間。

需要確認的事項： 支援的來源類型與分享方式。如果實際工作流程需要手動整理，就不要展示自動擷取或自動摘要的功能。

6. 透過展示資料如何流動來解說整合功能

虛構產品： TaskBridge，假設提供行事曆連線功能，可將選定的任務到期日複製為行事曆活動。

旁白：

專案截止日期應該記錄在任務資料中，但你可能也希望它出現在行事曆上。在這個虛構的 TaskBridge 整合功能中，先連結行事曆帳戶，再選擇要複製哪些任務到期日。每個選定的日期都會建立一筆連結至該任務的行事曆活動。在實際使用之前，請確認你的設定如何處理日期變更與刪除。請繼續以任務紀錄作為管理工作的主要位置。行事曆活動則能協助你將截止日期與其他行程一併查看。

視覺規劃： 展示連線步驟、明確選取某項任務，以及建立後附有返回連結的行事曆活動。整個示範都應標示為虛構的整合功能概念。

這種架構為何有效： 它清楚指出資料來源、目的地，以及實際傳輸的資料。相較於單純展示兩個標誌合而為一的動畫，這些細節更能幫助觀眾評估整合功能。

需要確認的事項： 同步方向、支援欄位、同步延遲、權限，以及刪除資料後的處理方式。整合功能影片特別容易出現誇大描述的問題。

7. 回答阻礙使用者做決定的特殊情況

虛構產品： GuestRoom，一款提供候補申請功能的預訂工具。

旁白：

你需要的房間已經被預訂了。在 GuestRoom 中，你可以針對該時段提交候補申請。填寫日期、時間與聯絡資料，然後查看申請狀態。加入候補名單並不代表預訂已獲確認。如果有空房，請依照收到的訊息中所列的確認步驟進行操作。在收到確認之前，請先保留其他備用方案。候補名單能記錄你的預訂意願，同時清楚區分申請與正式預訂。

視覺規劃： 展示無法預訂的時段、候補申請表單，以及標示為「已提出申請」的狀態。最後清楚區分「已提出申請」與「已確認」。

這種架構為何有效： 它能解決實際操作上的不確定性，而這種不確定性可能正是阻礙客戶繼續使用產品的原因。

需要確認的事項： 是否提供通知、候補優先順序如何決定，以及什麼情況才代表預訂已獲確認。避免承諾一定能預訂成功。

改編範例，而不是照搬其中的假設

如果你需要可重複使用的逐場景架構，可以從解說影片腳本範本開始。首先準備一份經過確認的產品簡介，列出功能的實際運作方式、使用者角色、使用前提與例外情況。接著，根據這份簡介，將選定架構中的虛構細節替換成真實資訊。如果旁白已經核准，Script to Video 就是適合用來製作影片的起點。

接著，仔細檢查腳本中的動詞。「偵測」、「同步」、「核准」與「發布」等詞語，都暗示了特定的功能行為。如果產品只是協助使用者執行某項操作，就應該在影片中呈現使用者實際參與的角色。

在適當的情況下，請使用真實素材來規劃視覺畫面。簡化的示意圖可以解釋流程，但不應被呈現成實際運作介面的截圖。如果概念場景可能被誤認為真實功能，就應清楚標示其概念性質。

有一個值得在審查時提出的問題：客戶是否有理由認為產品真的能完成影片中展示的所有操作？如果答案不確定，就應該先修改場景，再進行動畫潤飾。

為 Felo 準備產品解說影片簡介

提供已核准的產品描述、相關截圖或參考資料，以及選定的腳本。同時說明目標觀眾，以及影片需要回答的問題。

例如：

為新使用者解說一項已核准的產品工作流程。請依照附上的腳本，並且只使用提供的功能資訊。清楚呈現使用前提與例外情況。如果截圖資訊過於密集，請改用示意圖。不要自行加入自動化操作、整合功能、客戶引言或效能統計數據。最後以簡介中指定的單一操作作結。

Felo 的 Product Explainer Video 入口主要用於解說產品資訊與用途。請將產出的內容視為初稿，並依據產品簡介進行審查，尤其要留意那些可能暗示產品具備未曾明確說明之功能的場景。

關於產品解說範例的常見問題

哪種架構適合放在首頁？

選擇新訪客最需要先獲得解答的問題。這可能是問題與解決方案的故事，也可能是使用情境範例。等訪客了解產品的用途後，再透過功能操作指南進一步介紹產品。

每個範例都應該以要求使用者註冊作結嗎？

不需要。現有使用者的下一步可能是完成某項任務，或檢查某個設定。請根據目標觀眾，以及影片出現的頁面，選擇合適的行動呼籲。

腳本範例可以取代真實的產品示範嗎？

腳本有助於規劃解說內容，而真實示範則能提供產品實際運作方式的證據。如果購買或新手引導的決策取決於產品真正能做到什麼，就應該同時使用兩者。

選擇你需要回答的客戶問題，確認對應的工作流程，然後探索 Felo Product Explainer Video。