一連の作業が伝わる30秒のSaaSデモ動画を作るには

30秒のSaaSデモ動画でも、役に立つストーリーは伝えられます。ただし、伝え損ねた内容を取り戻す余裕はほとんどありません。冒頭で作業内容がわからなければ、視聴者は次の場面でも何を見ているのか考え続けます。結果が一瞬で通り過ぎれば、画面の見た目は覚えても、その意味は理解できないかもしれません。多くの場合、足りないのはアニメーションではなく、画面同士を結ぶつながりです。

一連の作業を見せることは、すべてのクリックを見せることではありません。 入力、操作、意味のある結果の関係を理解できるだけの根拠を示すことです。短いデモでは、ありふれた画面移動を省きつつ、この因果関係を残せます。ただし、製品が行うはずの肝心な処理まで編集で飛ばすと、誤解を招きます。

架空の日程調整ツールを例に考えましょう。視聴者は、会議の時間を決めたいチームリーダーです。予定の重複、候補となる時間帯、確定した会議を見せれば、無理なく収まる話になります。そこへカレンダー連携、レポート、請求、モバイル版の紹介まで加えると、機能のカタログになってしまいます。この記事では日程調整の例を使い、短くても完結する動画の作り方を説明します。

画面上で完了できる作業を選ぶ

製品の説明がなくても視聴者に通じる作業から始めます。「全員が参加できる時間を見つける」なら理解できます。「インテリジェントなオーケストレーションプラットフォームをご紹介」では、利点を知る前に独自の言葉を覚えなければなりません。作業が見えてくるのに合わせて、製品名を紹介すれば十分です。

適した作業には、開始時の状態と目に見える結果があります。請求書の送信、レビューコメントの解決、二つの提案の比較、予約の確定は、いずれも画面で記録できる状態を持ちます。「コラボレーションを改善する」といった約束は、そのままでは実演できません。まず、もっと小さな具体例にする必要があります。

冒頭の言葉を書く前に、完了時の状態を書き出しましょう。 作業が終わったとき、何が見えているべきでしょうか。日程調整なら、予定した参加者が入った確定済みのイベントのほうが、お祝いのチェックマークだけより確かな根拠になります。チェックマークは完了に気づく助けにはなりますが、製品上の結果の代わりにはなりません。

そこから逆算します。その結果の意味を理解するために、最低限どの準備を見せる必要があるかを考えます。参加者と予定の重複は必要でも、アカウント作成の全手順までは必要ないでしょう。こうすれば、中身を失わずに話を短くできます。

プロのデモから、問いを軸にする構成を取り入れる

Salesforceの製品デモ研修では、視聴者の問い、明確な持ち帰り、意図的な順序を中心にデモを組み立てています。研修が扱う範囲は30秒動画より広いものの、役立つ原則はそのまま使えます。画面は、視聴者がすでに気にしている問いに答えるべきです。製品ツアーと製品デモでは、編集の目的が異なります。

日程調整動画での問いは、「何度もメッセージをやり取りせず、都合のよい時間を見つけられるか」です。持ち帰ってほしい内容は、実際に収録した作業で裏づけられるものにします。例の中で空き時間しか確認していないなら、会議準備のすべてを自動で完了できるという主張で締めてはいけません。

画面に文字として出さなくても、作業用の文書にはこの問いを残しておきましょう。そのショットを入れる価値があるか判断する基準になります。見栄えのよいダッシュボードでも問いに答えなければ別の動画向きです。地味な確認画面のほうが不可欠な場合もあります。

関係者のレビューも進めやすくなります。会社にとってその機能が重要かどうかを議論する代わりに、この作業を説明するために必要かを考えます。重要な機能には、それぞれのデモを用意できます。短い動画で製品ロードマップ全体を表現する必要はありません。

操作とその結果は、同じまとまりで見せる

WistiaのChannelsの画面は、大きなダッシュボードを読み込まなくても話が伝わるため、特に参考になります。チャンネルのプレビューの隣にChannel Stylesパネルがあり、ColorsとFontの操作項目が同時に見えます。この隣接関係が、変更とその反映先を結びつけます。設定パネルだけを切り抜けば操作は残りますが、その価値が消えます。プレビューだけなら見た目は伝わっても、どう変わったかは説明できません。

日程調整でも同じ関係を作りましょう。選択した会議時間の長さと空き時間のグリッドを、関連がわかる距離に置きます。検索後にも、準備段階で登場した参加者か会議名を残します。こうした共通の識別情報は、目立たないながら説明の役割を果たします。視聴者は追加の口頭説明なしで、結果を認識できます。

二つの領域を同時に読めない場合は、共通の識別情報を残したまま、静止した二つのショットに分けます。入力を見せ、結果に切り替え、そこで止めます。カメラ移動は、結果がどこに現れるかをその軌道で説明できる場合に使います。関係のないサイドバーを素早く横切っても、時間を使うだけでつながりは増えません。

場面を均等に分けず、理解に必要な時間を割り当てる

まず30秒を仮の時間枠として使い、実際の素材を見て調整します。判断や結果を速める前に、ありふれた画面移動を短くします。複数の予定の重複を見比べる必要があるなら、その比較に十分な時間を確保しましょう。

区別したいのは、動いている時間と読める時間です。カードが入ってくるのに2秒かかり、止まっているのが1秒なら、ショット全体は3秒でも、落ち着いて内容を確認できる時間が3秒あるわけではありません。静止している部分の長さを別に測ります。

結果には、冒頭より長い時間が必要なこともあります。ここで視聴者は、直前の出来事と結果を結びつけようとしています。確定した詳細を見える状態で残しましょう。長いロゴアニメーションの後に結果が一瞬しか映らない構成では、優先順位が逆です。

ある場面が長すぎるなら、まず別の場所で伝えるべき情報を削ります。次に画面の見せ方を簡潔にします。それでも必要な場合に再生速度を上げます。録画全体を早送りすると、ポインターの動きが不自然になり、製品の違いを生む操作まで見えなくなることがあります。

最初から最後まで、同じ例を収録する

一連の場面では、同じデモ用アカウント、参加者、プロジェクト、サンプルデータを使います。一貫性は見た目を整えるだけのものではありません。結果がその入力から生まれたと認識する手がかりです。最後のショットでイベント名が変われば、各画面はもっともらしくても、そのつながりが切れることがあります。

収録前にアカウントを整えます。個人的なメッセージ、実際の顧客情報、無関係な通知を取り除きます。追いやすいサンプル名を選びましょう。ランダムなテスト文字列で埋まった画面は、実演の信頼性を上げず、読む負担だけを増やします。

決め手となる操作は、途中で止めずに収録します。後から待ち時間を削れますが、元の連続した映像があれば、実際に起きたことを記録できます。処理の遅延が製品についての主張に関わる場合は、正直に表現します。長い処理が瞬時に終わったように、編集で見せてはいけません。

収録をやり直せるよう、きれいな開始状態を保存します。途中まで進んだ作業からやり直すと、チェックが残る、前の結果がキャッシュされる、通知が消えるといった小さな違いが生じがちです。編集後に説明するより、事前に防ぐほうが簡単です。

省いてよいクリックを判断する

説明の中心でない画面移動は、たいてい短くできます。使い慣れたプロジェクトを一覧から開くだけなら、数秒も使う必要はないでしょう。一方、結果が会議時間の長さに依存するなら、その選択は欠かせません。短縮できる秒数だけでなく、視聴者が何を失うかでカットを判断します。

役立つ確認方法は、画面間の変化を平易な一文で説明することです。「参加者を選ぶと、製品が共通の空き時間を表示する」ならつながりがわかります。「ダッシュボードが確定した会議になる」では、省略が多すぎます。抜けた部分こそ、実演の根拠を追加すべき箇所でしょう。

カットの前後で、カーソルにありえない移動をさせないようにします。あるボタンの上にポインターがあり、直後に画面が変わると、そのボタンが変化を起こしたように見えることがあります。原因が重要なら、明確な切り替えを使うか、実際の操作を残します。装飾的なカーソルの動きで、製品の挙動を作り上げてはいけません。

待ち時間を含む作業なら、短い切り替えやナレーションで省略を知らせることもできます。扱い方は視聴者や主張によって異なります。大切なのは、経過時間を黙って削り、処理速度の約束に変えてしまわないことです。

視線の行き先を一つにする

デスクトップのUIには、短い動画では説明しきれない情報があります。まず作業場所を把握できる範囲を見せ、そこから関係する操作項目に寄ります。イベント名や参加者名など、認識できる目印を残すと、拡大した画面と全体画面のつながりが保たれます。

カメラを動かし続けないようにします。ズームには到着点があり、視聴者にはそこで見る時間が必要です。次の指示を出す前に画面を落ち着かせます。UIが画面内を移動している間に新しい文字が現れると、両方が注意を奪い合います。

強調は控えめに使います。候補の時間帯を柔らかく囲む程度なら助けになります。光る枠、動く矢印、跳ねるラベルがいくつもあると、簡単な操作まで難しく感じられます。注釈を一つずつ外し、それがなくても流れを理解できるか確認しましょう。

背景にも同じ原則が当てはまります。独自のブランド表現は動画に個性を与えますが、その動きが作業領域を圧倒してはいけません。製品デモでは、製品が画面内で最も情報を伝える存在である必要があります。

画面だけでは伝わらないことをナレーションで補う

ナレーションですべてのラベルを読む必要はありません。UIにすでに「Find a time」とあれば、音声はその操作の意味や注目点を説明できます。一度ボタン名を読むことは役立つかもしれませんが、それだけで台本を組むと、UI項目の読み上げになってしまいます。

実際のショットに合わせてナレーションを書きます。映像を再生しながら声に出して読みましょう。紙面では短い文でも、製品名、慣れない用語、複数の数字が入ると、その場面の長さでは無理のある速さになることがあります。

無言の時間にも役割を与えます。重要な操作の後に少し静かな間を置けば、結果を受け止める余裕が生まれます。すべての秒を言葉で埋めると、視聴者は聞くかUIを読むかを選ばなければなりません。音楽はテンポを支え、もう一つの指示源にならないようにします。

無音でも意味が通る版を用意します。必要なのは短い字幕や厳選したラベルであり、すべての操作項目に全文の書き起こしを重ねることではありません。最終的な表示サイズで、それらが操作を隠さないか確認します。

実際のソフトウェア動画を編集の参考にする

Wistiaのソフトウェア製品動画ガイドには、自社製品の例と、意図的な見せ方によってソフトウェアをわかりやすくする説明があります。Channelsのアップデート動画は、UIの変更とその価値を結びつける必要があるソフトウェア告知として、観察に適しています。出演者と実際の製品画面を交互に使い、説明とUIにそれぞれ時間を与えています。

他社の動画を見るときは、表面的な見た目をまねるのではなく、各ショットの役割を記録します。作業を示すのか、操作項目の位置を伝えるのか、結果を見せるのか、個性を添えるのか。こうした役割の言葉は、製品の外観がまったく違っても使えます。

参考動画が何を省いているかにも注目しましょう。既存顧客がUIを知っていることに頼っている可能性があります。初めての視聴者には、もっと案内が必要かもしれません。視聴者の前提知識が違うままテンポだけを借りると、わかりにくくなることがあります。

操作とその結果を一緒に見る

公開されたWistiaのChannelsアップデート動画では、30秒の時点で、色の操作項目が変更先のチャンネルの隣に現れます。製品画面によって、設定がもたらす結果が見えます。日程調整の例でも、同じつながりが必要です。選んだ時間と十分なイベント情報を一緒に見せ、確定画面がその選択の結果だと伝えます。

最初のレビューでは、入力を認識できたか、操作を理解できたか、結果を特定できたかの三点をメモします。それぞれを視聴者自身の言葉で説明してもらいましょう。操作は明確でも結果が不明なら、次の修正では冒頭のつかみを足すより、完了画面に時間を使います。これにより、実際に伝わっていない部分に編集の労力を向けられます。

確認済みの収録映像を軸にモーションを組む

編集可能な構成では、録画、説明文、背景、最後の画面を分けます。収録した作業を作り直さず、機能名や最後の案内を変更できます。また、元の根拠を保ったまま、別のアスペクト比にも展開しやすくなります。

OpenDesign Motionへの指示には、提供する録画、場面の意図、画面に出す正確な文言、尺、アスペクト比、必要な出力ファイルを指定できます。編集可能なプロジェクトとレンダリング済みMP4を依頼し、両方を確認します。プレビューでアニメーションが動くだけでは、書き出したファイルまで正しいとはいえません。

事実を保つべき部分を明記します。存在しない画面状態を作らない、製品ラベルを変更しない、合成した操作を録画のように扱わない、といった条件です。その境界を明確にしたうえで、装飾の選択は任せられます。実演の信頼性を弱めず、構成を改善する余地を残せます。

あるショットでもっと寄る必要があるなら、まずそのショットを直します。動画全体がせわしないなら、ストーリーと時間配分を見直します。この二つは別の問題です。「もっと高級感を」「もっとダイナミックに」という依頼だけでは、どちらも安定して解決できません。

編集後にも作業の流れが残っているか確かめる

制作に関わっていない人に動画を見せます。登場人物は何をしようとしていたのか、製品はどの操作を助けたのか、最後の画面には何が出ていたのかを尋ねます。見栄えがよいかと聞くより、理解を直接確かめられます。

答えの途中で訂正しないようにしましょう。場面を誤解した場合は、説明する前にその誤解を記録します。補足した説明こそ、動画に足りなかった内容かもしれません。目的は動画を非公式なテストに通すことではなく、流れを改善することです。

想定するサイズと場所で見ます。デスクトップの全画面表示では、モバイルのフィードや狭いランディングページの列で読めなくなる小さなラベルを見落としがちです。編集プレビューだけに頼らず、圧縮やプラットフォームの重なり表示も含めた、実際の書き出しファイルを確認します。

最後のレビューも具体的に行います。イベント名、参加者、選択した時間、最後の行動を確認します。最初と最後のフレームに意図しない切れ方がないか、音がきれいに終わるか、次の行動を読めるかを確かめます。完結した30秒のSaaSデモは、半分の1分に大量の機能を詰め込むのではなく、一つの作業を追いやすくすることで、その短さを成立させます。