설명 영상 대본: 템플릿, 사례, 워크플로

01

1. 이 60초 및 90초 대본 템플릿 복사하기

템플릿을 커뮤니케이션 작업 순서로 사용하고, 완성된 사본으로는 사용하지 마십시오. 모든 괄호를 시청자가 사용하는 언어와 팀이 확인할 수 있는 증거로 교체하십시오. 60초 버전은 하나의 문제와 하나의 메커니즘을 위해 설계되었습니다. 90초 버전은 증명이나 두 번째 사용 사례를 추가함으로써 추가 시간을 얻으며, 이점을 다른 말로 반복하는 것이 아닙니다.

• 메시지 브리프 뒤에 훅을 작성하여 새로운 것을 쫓지 않고 올바른 상황을 명시하십시오.
• 오프닝과 증명에서 동일한 문제를 사용하십시오; 문제를 바꾸면 결과가 무관하게 느껴집니다.
• Routes, compares, assigns, highlights, convert와 같은 동사를 사용하여 메커니즘을 설명하십시오.
• CTA를 가시적이고 말할 수 있도록 유지하십시오; 탐색 메뉴는 스크립트 종료가 아닙니다.

02

2. 먼저 6개 질문으로 메시지 브리프 작성하기

스크립트는 이미 여섯 가지 결정이 고정되어 있을 때 더 쉬워집니다: 시청자, 트리거 시점, 현재 우회 방법, 메커니즘, 증명, 그리고 다음 행동. 이것들은 인식 제고와 같은 광범위한 목표보다 더 유용합니다. 왜냐하면 시청자가 듣고 보는 것을 결정하기 때문입니다. 각 필드마다 한두 문장을 작성하고, 시작을 다듬기 전에 제품 또는 주제 소유자에게 승인을 요청하십시오.

공유받은 편지함 테스트의 경우, 시청자는 소규모 SaaS 지원 팀이었습니다. 트리거는 여러 팀원이 활동 중일 때 새로운 요청이 도착하는 것이었습니다. 우회 방법은 하나의 받은 편지함에서 수동으로 조정하는 것이었습니다. 그 메커니즘은 요청을 올바른 채널과 소유자에게 할당하는 라우팅 규칙이었습니다. 증거는 한 번 도착하고 하나의 협조된 응답을 받은 요청이었습니다. 다음 작업은 첫 번째 규칙을 만드는 것이었습니다.

• 시청자는 누구이며, 문제가 발생할 때 그들은 어떤 역할을 수행합니까?
• 제품, 프로세스 또는 아이디어가 설명될 필요성을 일으키는 정확한 사건은 무엇입니까?
• 시청자는 지금 무엇을 하며, 그 우회책이 느려지거나 위험해지거나 혼란스러워지는지는 어디입니까?
• 어떤 관찰 가능한 메커니즘이 단순히 더 나은 결과를 약속하는 것이 아니라 기존 과정을 변화시키는 것입니까?
• 어떤 승인된 화면, 예시, 상태 변경 또는 출처가 메커니즘이 작동함을 입증합니까?
• 설명을 이해한 후 즉시 시청자가 취해야 할 단일 행동은 무엇입니까?

03

3. 공식에만 의존하지 말고 시간을 재며 읽어 재생 시간 계획하기

단어 수는 시작 범위를 제공하지만, 말의 속도는 어휘와 의도에 따라 달라집니다. 제품명, 약어, 숫자 및 익숙하지 않은 용어는 짧은 대화형 문구보다 더 많은 시간이 필요합니다. 의도적인 멈춤은 특히 증명이나 CTA 이전에 의미를 부여할 수 있습니다. 화면상의 텍스트는 내레이터가 넘어갔을 때도 시각적인 대기 시간이 필요합니다. 스토리보드가 승인되기 전에 대략적인 읽기를 기록하십시오.

• 문장이 맞는지 판단하기 전에 약어의 발음과 확장을 표시하십시오.
• 가시적인 숫자, 인터페이스 라벨 및 비교를 읽고 확인할 수 있도록 충분한 시간을 허용하십시오.
• 음악 전환, 장면 변경 및 현지화된 버전을 위해 작은 여백을 남겨 두십시오.
• 구조적 변화가 있을 때마다 전체 읽기를 다시 테스트하십시오. 나중에 비트는 타이밍을 잃을 수 있기 때문입니다.
• 시청자가 반응하기 전에 사라지는 경우, 마지막 프레임을 유용한 CTA 시간으로 간주하지 마십시오.

04

4. 각 비트에 역할이 있는 5부 구조 사용하기

다섯 부분으로 구성된 구조는 후크, 문제, 메커니즘, 증명, 그리고 CTA입니다. 그 값은 라벨이 아닙니다. 그것은 인과 사슬을 생성합니다. 후크는 상황을 식별합니다. 문제는 현재 상태가 왜 중요한지 보여줍니다. 그 메커니즘은 무엇이 변하는지 설명합니다. 증명은 동일한 조건 하에서 변경된 상태를 보여줍니다. CTA는 이해에 목적지를 제공합니다. 링크를 제거하면 스크립트가 광고나 튜토리얼 조각처럼 느껴집니다.

• 집중된 60초 스크립트에서 훅에 5~8초를 부여하십시오.
• 문제를 사용하여 결과를 더하고, 더 강한 형용사로 훅을 재진의하지 마십시오.
• 메커니즘에 가장 큰 비중을 투자하십시오, 왜냐하면 그곳이 이해가 형성되는 곳이기 때문입니다.
• 오프닝 상황에서 제기된 동일한 질문에 시각적으로 답하도록 증거를 만드십시오.
• 제품 탐색 옵션 목록 대신 하나의 작업과 하나의 목적지로 마무리하십시오.

05

5. 오디오와 영상의 2열 대본 사용하기

내레이션 전용 문서는 시각 팀이 각 줄이 증명해야 할 것을 추측해야 하기 때문에 불완전합니다. 스토리보드 전용 문서는 움직임이 약한 주장을 숨길 수 있기 때문에 또한 불완전합니다. 음성 오디오와 시각 작업을 나란히 배치하십시오. 타이밍, 화면 텍스트, 소스, 전환 및 검토자를 위한 선택적 열을 추가하십시오. 이 형식은 스크립트를 영감을 주는 단락이 아니라 제작 계약으로 전환합니다.

• 각 라인당 시각적 작업을 하나씩 할당하고, 프레임이 관련 없는 작업을 요청하면 라인을 분할합니다.
• 승인된 제품 버전에 표시된 대로 UI 라벨을 정확히 작성하십시오.
• 개념적인 시각 자료를 표시하여 리뷰어가 이를 문자 그대로의 제품 행동으로 오해하지 않도록 하십시오.
• 제품, 편집, 브랜드, 법무 및 관련될 경우 최종 승인에 대한 검토자 칼럼을 유지하십시오.

06

6. 시각적 역할을 포함한 공유 받은편지함 SaaS 전체 대본

아래 표는 실습형 공유 인박스 설명에 사용되는 작업 스크립트입니다. 그것은 의도적으로 좁습니다. 보고, 통합, 권한 또는 전체 지원 범주에 대해 설명하지 않습니다. 각 줄마다 이야기가 전개됩니다: 중복된 답글은 하나의 소유자와 하나의 다음 행동이 있는 라우팅된 워크플로가 됩니다. 프로덕션 파일의 소스 열은 승인된 화면 및 문서에 연결됩니다.

• 제품은 메커니즘이 시작될 때만 소개되므로, 오프닝은 시청자 중심으로 유지됩니다.
• 증명은 동일한 요청 패턴으로 돌아가며, 이를 통해 전후 비교를 쉽게 따라갈 수 있습니다.
• CTA는 무관한 가입 약속으로 바꾸는 대신 첫 번째 규칙을 요청함으로써 메커니즘을 지속합니다.
• 시각적 보류를 포함하면 구두 계획은 60초보다 약간 길어지며, 이는 테스트에서 확인되었습니다.

귀하의 제품이 이러한 상태 중 하나를 지원할 수 없는 경우, 생산 전에 스크립트를 변경하십시오. 제품이 제공하지 않는 과제, 상태 또는 자동화를 애니메이션에 암시하도록 요청하지 마십시오. 허구의 예는 여전히 글쓰기 구조를 가르칠 수 있지만, 브랜드 제품 비디오는 실제 행동과 설명 흐름을 구분해야 합니다. 검증은 각본 작성의 일부이며, 최종 법적 통과가 아닙니다.

07

7. 대본과 66.837초 렌더링 결과 비교하기

내보낸 테스트 비디오는 66.837초였으며, 따라서 약 60초 길이의 짧은 영상은 라운드 목표보다 약 6.8초 더 긴 결과를 도출했습니다. 그 차이는 유용한 편집 증거입니다. 스크립트에는 여러 라벨, 메커니즘 시퀀스 및 CTA 보류가 포함되어 있습니다. 모든 멈춤을 없애거나 목소리를 가속시키면 숫자는 보호되지만 이해력이 약해집니다. 두 번째 수정은 증거를 압축하기 전에 언어를 삭제해야 합니다.

• 첫 번째 컷: 시각 자료가 이미 전달하고 있는 반복 설정을 제거하십시오.
• 두 번째 편집: 긴 명사구를 명확한 주어와 능동사로 교체하십시오.
• 세 번째 절단: 메커니즘이나 증명을 다루기 전에 보조 예제를 제거하십시오.
• 최종 타이밍: 새로운 읽기를 기록하고 실제 장면이 유지되는 그대로 재생하십시오.

08

8. 약한 도입부, 기능 나열, CTA 다시 쓰기

좋은 편집은 문장이 수행하는 역할을 바꿉니다. 그것은 단순히 평범한 단어를 더 활기찬 단어로 대체하는 것에 그치지 않습니다. 아래 예시들은 실패를 식별하고, 필요한 정보를 보존하며, 라인을 시청자, 문제, 메커니즘, 증거 또는 행동과 다시 연결합니다. 이해관계자가 스크립트를 더 흥미롭게 만들고자 요청할 때마다, 시청자가 아직 이해하지 못하는 부분을 식별하지 않고 이 과정을 사용하십시오.

• 추상 명사를 원으로 표시하고 사람이나 시스템이 실제로 무엇을 하는지 물어보세요.
• 카테고리 주장을 의도된 시청자가 인식하는 트리거 순간으로 교체하십시오.
• 스토리에서 보여지는 메커니즘에 참여할 때만 기능을 유지하십시오.
• 증명을 그것이 뒷받침하는 주장 옆으로 이동하고, 마지막에 모호한 이익을 수집하지 마십시오.
• CTA를 규칙을 만들거나 초안을 검토하는 등 눈에 보이는 동사와 객체로 다시 작성하십시오.

09

9. 소리 내어 읽기를 녹음하고 올바른 순서로 덜어내기

조용한 방에서 휴대폰이나 노트북으로 대략적인 읽기를 기록하십시오. 목표는 음성 품질이 아닙니다. 숨소리와 리듬, 모호함, 그리고 타이밍을 듣는 것입니다. 재시작하는 모든 위치를 표시하거나, 계획하지 않은 단어를 추가하거나, 잘못된 용어에 강세를 가하는 위치를 표시하십시오. 자연스러운 교정은 종종 당신의 입이 기대한 더 간단한 문장을 드러냅니다. 녹음을 스크립트와 함께 공유하여 검토자들이 무음 페이지의 산문이 아닌 구어체를 평가하도록 하십시오.

의도적인 순서대로 자르세요. 먼저 반복적인 설정을 제거하고, 그 다음에 의미를 바꾸지 않는 형용사, 보조 예시, 기능 부수적인 요소 및 추가 CTA를 제거하십시오. 메커니즘, 승인된 증거, 필요한 안전 또는 준수 상황, 그리고 시각적 이해를 위한 충분한 시간을 보호하십시오. 그 편집 후에도 이야기가 아직 너무 길다면, 약속을 좁히거나 실행 시간을 늘리는 것이 자연스럽지 않게 빠르게 말하는 대신에 진행하십시오.

• 의미를 위해 한 번 읽고, 목표를 쫓지 않고 자연스러운 지속 시간을 기록하십시오.
• 의도된 에너지로 다시 읽고 숨소리, 강조, 발음 및 어색한 구문을 표시하십시오.
• 녹음을 거친 장면과 대비시키고 라벨 및 증거에 대한 시각적 보관 시간을 추가하십시오.
• 반복되는 컨텍스트, 수정자, 사이드 예시 및 추가 작업을 그 순서대로 잘라내십시오.
• 수정된 스크립트를 처음부터 녹음하십시오. 로컬 컷은 나중에 리듬을 바꿀 수 있기 때문입니다.
• 낯선 청자에게 한 번 들은 후 문제, 메커니즘, 증거, 그리고 CTA를 말해 달라고 요청하십시오.

10

10. 다양한 설명 과제에 프레임워크 적용하기

다섯 개의 직무는 카테고리 전반에 걸쳐 여전히 유용하지만, 그 강조점은 변합니다. SaaS 제품 비디오는 일반적으로 눈에 보이는 워크플로우 증거가 필요합니다. 전문 서비스는 인터페이스가 아니라 진단, 절차 및 신뢰를 설명할 수 있습니다. 기술적 개념은 정확한 정의와 신중하게 선택된 추상화가 필요합니다. 온보딩은 의도를 가정하고 작업에 더 가깝게 시작할 수 있습니다. 교육에서는 전환 CTA 대신 검색 검사나 요약이 필요할 수 있습니다.

• 짧은 스크립트당 한 명의 청중을 유지하고, 역할이 다른 증명이나 언어가 필요할 때는 변형을 생성하십시오.
• 정확한 동작이 중요하고 화면이 충분히 최신 상태를 유지할 때만 실제 인터페이스를 사용하십시오.
• 기술 설명에서 가정을 명시하여 단순화가 부정확해지지 않도록 하십시오.
• 시청자가 이미 제품 사용을 결정한 경우, 판매 증명을 작업 확인으로 교체하십시오.
• 보존과 적용이 목표인 경우 마케팅 CTA보다 학습 행동을 사용하십시오.

성공적인 SaaS 구조를 주제 검토 없이 의료, 재무, 법률 또는 안전에 민감한 설명으로 복사하지 마십시오. 스크립트는 필요한 맥락, 위험 언어 또는 다른 조치가 필요할 수 있습니다. 프레임워크는 커뮤니케이션을 조직하지만 도메인 책임을 대체하지는 않습니다. 인계에서 승인 전문가의 이름을 지정하고, 각 민감한 진술에 사용된 출처를 유지하십시오.

11

11. 제품 정보를 지어내지 않고 AI의 도움 활용하기

AI는 원본 자료를 정리하고, 대체 문구를 생성하며, 반복을 식별하고, 장면 구분을 제안하며, 구조가 완전한지 테스트하는 데 도움을 줄 수 있습니다. 어떤 제품 주장이 사실인지 결정해서는 안 됩니다. 승인된 증거 패킷, 명시적인 청중, 메커니즘, 실행 시간, 금지된 주장, 용어 및 CTA를 제공하십시오. 누락된 증거를 표시하도록 요청하고, 가능성이 높은 세부 사항으로 공백을 보완하도록 하십시오.

• 승인된 메시지 요약과 원본 구절을 제공하고, 회사에 대한 설명을 제한 없이 요청하지 마십시오.
• 인용된 제품 사실을 작성된 설명서와 분리하여 모델이 청구 범위를 유지할 수 있도록 하십시오.
• 특정 비트에 대해 반복적인 전체 스크립트 재작성 대신 두세 가지 대안을 요청하십시오.
• 제공된 출처 또는 소유자 검토를 가리키도록 모든 숫자, 기능 및 비교를 요구합니다.
• 버전 이름, UI 라벨, 발음, 요금제 제한 및 현재 가격을 일반적인 가정 외에 유지하십시오.
• 빈 강조어, 반복된 결론 및 인과를 암시하는 전이에 대해 생성된 언어를 검토하십시오.

TapVid 실행에서 생성된 요약은 설명이 인터페이스 주도 스토리에 의존했기 때문에 9:16에서 16:9로 이동할 것을 권고했습니다. 그것은 유용한 제안이었지만, 여전히 승인이 필요합니다. 스크립트 제안에 동일한 표준을 사용하십시오. 모델은 트레이드오프를 드러낼 수 있으며, 창작자는 그것이 시청자, 배치, 증거 및 브랜드와 일치하는지 여부를 결정합니다.

12

12. 추측을 방지하는 제작 인계 자료 준비하기

제작 준비가 된 대본은 승인된 내레이션 그 이상입니다. 여기에는 타이밍, 시각 작업, 필수 화면, 소스 링크, 화면 텍스트, 발음, 음악 방향, 비율, 캡션, 브랜드 제약, 전환 및 각 승인의 상태가 포함됩니다. 목표는 조용한 가정을 없애는 것입니다. 디자이너는 어떤 요소가 증거이고, 어떤 것이 삽화이며, 시각적 명확성을 위해 어떤 요소를 변경할 수 있는지 알아야 합니다.

• 각 제품 화면에 캡처 날짜와 해당 버전 또는 플랜을 표시하십시오.
• 개념 다이어그램이 문자적 행동인지, 단순화된 행동인지, 혹은 순수한 은유인지 설명하십시오.
• 모든 의도된 종횡비에 대해 안전한 작물 구역과 모바일 텍스트 검사를 포함하십시오.
• 사실, 편집, 브랜드, 법률 및 수출 변경을 승인할 수 있는 사람을 지정하십시오.
• 시각적 리비전이 암시된 제품 동작을 변경할 경우 스크립트 승인을 다시 요구합니다.

실제 문서를 사용하여 짧은 인계 검토를 진행하십시오. 메시지 요약을 읽고, 거친 내레이션을 재생하며, 증거를 검토하고, 어려운 장면들을 진행하십시오. 이 회의에서 답변된 질문은 핸드오프에 기재해야 합니다. 파일에 도달하지 않는 구두 결정은 다른 팀원이나 도구가 프로젝트를 재개할 때 미래의 일관성 부족이 됩니다.

13

13. 제작 전에 현지화와 자막 계획하기

현지화는 타이밍, 줄 바꿈, 강조, 그리고 때때로 장면 디자인을 변경합니다. 직접 번역은 시각적 고정과 충돌할 정도로 충분히 확장될 수 있습니다. 제품 UI는 동일한 라벨 길이를 사용하거나 동일한 기능 이름을 사용할 수 없습니다. 유머와 은유는 그 기능을 잃을 수 있습니다. 편집 가능한 텍스트, 유연한 장면 타이밍, 안전한 캡션 영역 및 현지화된 인터페이스 증거를 계획한 후, 모든 모션 큐를 영어 파형에 고정하십시오.

각 비트의 커뮤니케이션 작업을 번역한 다음, 자연스러운 구어를 재구성하십시오. 현지화된 훅은 동일한 트리거 모멘트를 식별해야 하지만, 동일한 어순은 필요하지 않습니다. 메커니즘과 증명은 사실적 의미를 보존해야 합니다. CTA는 목적지 인터페이스에서 찾은 용어를 사용해야 합니다. 원어민 또는 유창한 읽기를 기록하고, 모든 언어를 영어 시간에 억지로 삽입하는 대신 시각 순서의 시간을 재조정하십시오.

• 제품명, UI 라벨, 약어 및 번역되지 않은 단어에 대한 용어 시트를 유지하십시오.
• 제작이 허용되는 경우 내레이션, 캡션 및 화면 라벨을 별도의 편집 가능한 필드로 유지하십시오.
• 특히 모바일 배치의 경우 최종 디스플레이 크기에서 읽기 속도와 줄 바꿈을 확인하십시오.
• 렌더링된 장면에서 숫자, 단위, 날짜 형식, 구두점 및 텍스트 방향을 검토하십시오.
• 제품과 대상 독자를 이해하는 유창한 리뷰어를 사용하십시오, 문법만을 이해하는 것이 아니라.
• 정확한 텍스트가 여전히 시기가 맞지 않거나 잘릴 수 있으니, 모든 현지화된 버전을 내보내어 시청하십시오.

콘텐츠 패키지에서 구조적 동등성을 유지하여 모든 언어가 동일한 예시, 증명, 제한 사항, FAQ 및 행동을 받도록 하십시오. Parity는 문자 그대로의 표현을 의미하지 않습니다. 이는 현지화된 시청자가 동일한 유용한 결정과 증거를 받는다는 의미입니다. 소스 또는 제품 화면이 영어로만 제공되는 경우, 지원 세부 정보를 조용히 제거하는 대신 해당 제약 조건을 설명하십시오.

14

14. 설명 영상 대본 FAQ

이 답변들을 지침으로 사용하십시오. 제작 워크플로와 15개 사례 분석를 계속 진행하십시오. W3C 가이드와 함께 캡션을 계획하십시오.