7 ตัวอย่างสคริปต์วิดีโออธิบายผลิตภัณฑ์

สำรวจตัวอย่างสคริปต์วิดีโออธิบายผลิตภัณฑ์ 7 รูปแบบ พร้อมตัวอย่างบทบรรยาย แผนภาพประกอบ และเคล็ดลับในการนำไปปรับใช้จริง

การเขียนวิดีโอแนะนำผลิตภัณฑ์จะง่ายขึ้นเมื่อคุณรู้ว่าต้องการให้วิดีโอตอบคำถามอะไร คำถามอย่าง "ฟีเจอร์นี้ทำอะไรได้บ้าง?" ย่อมต้องการคำอธิบายที่แตกต่างจาก "ฉันจะเริ่มต้นใช้งานได้อย่างไร?"

ตัวอย่างวิดีโออธิบายผลิตภัณฑ์ทั้ง 7 รูปแบบต่อไปนี้เป็นแนวคิดสคริปต์ต้นฉบับสำหรับผลิตภัณฑ์สมมติ แต่ละตัวอย่างประกอบด้วยบทบรรยาย แผนภาพประกอบ และคำอธิบายว่าโครงสร้างนั้นเหมาะกับสถานการณ์ใด ตัวอย่างเหล่านี้จัดทำขึ้นเพื่อแสดงแนวทางการเขียน ไม่ใช่กรณีศึกษาจากลูกค้าจริงหรือการกล่าวอ้างเกี่ยวกับอัตราการเปลี่ยนผู้ชมเป็นลูกค้าที่วัดผลได้

นำตัวอย่างเหล่านี้ไปใช้เลือกโครงสร้างสำหรับผลิตภัณฑ์จริง จากนั้นเปลี่ยนพฤติกรรมของผลิตภัณฑ์สมมติให้เป็นฟีเจอร์ที่คุณสามารถสาธิตและตรวจสอบความถูกต้องได้

เลือกคำถามก่อนเลือกรูปแบบวิดีโอ

คุณอาจได้รับมอบหมายให้ทำวิดีโอสำหรับหน้าแรก วิดีโอเปิดตัวผลิตภัณฑ์ หรือวิดีโอเพื่อการขาย ชื่อเรียกเหล่านี้บอกเพียงว่าวิดีโอจะปรากฏที่ใด แต่ไม่ได้อธิบายอย่างครบถ้วนว่าผู้ชมจำเป็นต้องเข้าใจอะไร

สอบถามผู้ที่ต้องการวิดีโอว่าต้องการให้วิดีโอช่วยขจัดความสับสนเรื่องใด ผู้เข้าชมเว็บไซต์อาจยังไม่เข้าใจประเภทของผลิตภัณฑ์ ลูกค้าอาจรู้จักประเภทผลิตภัณฑ์อยู่แล้ว แต่ต้องการเห็นวิธีดำเนินการบางอย่างโดยเฉพาะ ส่วนผู้ใช้ปัจจุบันอาจต้องการเพียงเรียนรู้ว่ามีอะไรเปลี่ยนแปลงไปบ้าง

คำถามของผู้ชม	โครงสร้างสคริปต์ที่เหมาะสม
ฟีเจอร์นี้ทำอะไรได้บ้าง?	คำอธิบายฟีเจอร์เดียว
ฉันจะเริ่มต้นใช้งานได้อย่างไร?	ขั้นตอนการใช้งานครั้งแรก
สิ่งนี้ช่วยแก้ปัญหาของฉันได้อย่างไร?	ปัญหาและแนวทางแก้ไข
กระบวนการนี้ดำเนินไปอย่างไร?	คำอธิบายขั้นตอนการทำงาน
สิ่งนี้เหมาะกับสถานการณ์ของฉันหรือไม่?	ตัวอย่างกรณีการใช้งาน
ใช้งานร่วมกับระบบอื่นได้อย่างไร?	คำอธิบายการเชื่อมต่อระบบ
จะเกิดอะไรขึ้นในกรณียกเว้นนี้?	คำอธิบายในรูปแบบคำถามที่พบบ่อย

กำหนดคำถามหลักเพียงหนึ่งข้อสำหรับวิดีโอแต่ละชิ้น หากสคริปต์พยายามตอบคำถามทั้งเจ็ดข้อ ก็มีแนวโน้มว่าจะต้องใช้โครงสร้างที่แตกต่างออกไปและใช้เวลามากกว่าที่วิดีโออธิบายสั้น ๆ จะรองรับได้

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

จัดเตรียมคำอธิบายผลิตภัณฑ์ที่ผ่านการอนุมัติแล้ว ภาพหน้าจอหรือเอกสารต้นฉบับที่เกี่ยวข้อง และสคริปต์ที่เลือก ระบุกลุ่มเป้าหมายและคำถามที่วิดีโอต้องการตอบให้ชัดเจน

ตัวอย่างเช่น:

อธิบายขั้นตอนการทำงานของผลิตภัณฑ์หนึ่งรายการที่ผ่านการอนุมัติแล้วสำหรับผู้ใช้ใหม่ ใช้สคริปต์ที่แนบมาและอ้างอิงเฉพาะข้อมูลฟีเจอร์ที่ให้ไว้เท่านั้น แสดงข้อกำหนดเบื้องต้นและกรณียกเว้นให้ชัดเจน ใช้แผนภาพเมื่อภาพหน้าจอมีรายละเอียดหนาแน่นเกินไป ห้ามเพิ่มการดำเนินการอัตโนมัติ การเชื่อมต่อระบบ คำกล่าวอ้างจากลูกค้า หรือสถิติด้านประสิทธิภาพ ปิดท้ายด้วยการดำเนินการเพียงอย่างเดียวตามที่ระบุไว้ในบรีฟ

จุดเริ่มต้น Product Explainer Video ของ Felo ได้รับการออกแบบมาเพื่ออธิบายข้อมูลและการใช้งานผลิตภัณฑ์โดยเฉพาะ ควรถือว่าผลงานที่สร้างขึ้นเป็นเพียงฉบับร่างที่ต้องตรวจสอบเทียบกับบรีฟผลิตภัณฑ์ โดยเฉพาะฉากที่อาจสื่อถึงพฤติกรรมการทำงานที่ไม่เคยมีการระบุไว้

คำถามเกี่ยวกับตัวอย่างวิดีโออธิบายผลิตภัณฑ์

โครงสร้างแบบใดเหมาะสำหรับวิดีโอบนหน้าแรก?

เลือกคำถามที่ผู้เข้าชมใหม่จำเป็นต้องได้รับคำตอบก่อนเป็นอันดับแรก ซึ่งอาจเป็นเรื่องราวที่นำเสนอปัญหาและแนวทางแก้ไข หรือตัวอย่างกรณีการใช้งาน ส่วนการสาธิตขั้นตอนการใช้งานฟีเจอร์สามารถนำเสนอในภายหลัง เมื่อผู้เข้าชมเข้าใจบทบาทของผลิตภัณฑ์แล้ว

ตัวอย่างทุกแบบควรจบด้วยคำเชิญชวนให้สมัครใช้งานหรือไม่?

ไม่จำเป็น ขั้นตอนถัดไปของผู้ใช้ปัจจุบันอาจเป็นการทำงานให้เสร็จหรือการตรวจสอบการตั้งค่าบางอย่าง ควรเลือกการดำเนินการให้เหมาะกับกลุ่มเป้าหมายและหน้าเว็บที่วิดีโอปรากฏอยู่

ตัวอย่างสคริปต์สามารถใช้แทนการสาธิตผลิตภัณฑ์จริงได้หรือไม่?

สคริปต์ช่วยวางแผนการอธิบาย ส่วนการสาธิตจริงช่วยแสดงหลักฐานเกี่ยวกับพฤติกรรมการทำงานของผลิตภัณฑ์ ควรใช้ทั้งสองอย่างเมื่อการตัดสินใจซื้อหรือการเริ่มต้นใช้งานขึ้นอยู่กับความสามารถที่แท้จริงของผลิตภัณฑ์

เลือกคำถามของลูกค้าที่คุณต้องการตอบ ตรวจสอบขั้นตอนการทำงานที่เกี่ยวข้อง และ สำรวจ Felo Product Explainer Video.