ออกแบบสําหรับหางยาว

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

ไม่ออกแบบมากเกินไป

ในส่วนข้อกําหนด คุณต้องกําหนดกรณีการใช้งานที่สําคัญที่ชัดเจน โปรดคํานึงถึงลําดับความสําคัญเหล่านี้และหลีกเลี่ยงไม่ให้เกิดกรณีพิเศษในรายการนี้ ขณะที่คุณให้รายละเอียดเกี่ยวกับการออกแบบ สถานการณ์ใหม่จะปรากฏขึ้นโดยที่คุณไม่ได้คํานึงถึง ก่อนขยายขอบเขตของการออกแบบเพื่อรองรับสถานการณ์ใหม่เหล่านี้ โปรดพิจารณาผลกระทบอย่างรอบคอบ

ศีรษะ เนื้อความ หางยาว

กรณีการใช้งานหลัก

นี่คือเส้นทางการสนทนาที่สําคัญมากที่สุดและพบบ่อยที่สุดที่ผู้ใช้เลือกเพื่อใช้ฟีเจอร์ เน้นความพยายามส่วนใหญ่ในการทําให้เส้นทางเหล่านี้มอบประสบการณ์ของผู้ใช้ที่ยอดเยี่ยม

ทางอ้อม

ซึ่งมักเกิดขึ้นน้อย และมักจะเป็นเส้นทางการสนทนาผ่านฟีเจอร์โดยตรงหรือไม่ค่อยประสบความสําเร็จ โปรดสละเวลาเพื่อให้การสนับสนุนอย่างเพียงพอ แต่อย่าเสียเวลาและออกแบบมากเกินไป

ประวัติการช่วยเหลือ

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

สําหรับการออกแบบการสนทนา กฎนี้เป็นวิธีที่จะบอกว่าเส้นทางต่างๆ ไม่ได้มีค่าเท่ากัน ผู้ใช้ 80% ปฏิบัติตามเส้นทางที่ใช้กันมากที่สุด 20% ในกล่องโต้ตอบ ดังนั้น ให้ลงทุนทรัพยากรตามนั้นเพื่อให้ได้ผลลัพธ์ที่ดีที่สุด

ในทํานองเดียวกัน ก็ยังมีข้อดีและข้อเสียครบถ้วน การทํางานอาจ 80% เพื่อขัด 20% สุดท้ายของโครงการ ในกรณีเหล่านี้ ความพยายามที่ไม่ถูกขัดเกลาอาจ "ดีพอ" ได้

ทางอ้อม

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

ข้อผิดพลาดที่พบได้ทั่วไป 2-3 ข้อที่ควรพิจารณามีดังนี้

ผู้ใช้อาจต้องลิงก์บัญชีหรืออุปกรณ์ (เช่น ระบบอัตโนมัติในบ้าน) ก่อนจึงจะใช้ฟีเจอร์บางอย่างได้

ในกรณีนี้ผู้ใช้ยังไม่ได้ลิงก์บัญชีของตนเอง

การดําเนินการของคุณอาจไม่รองรับคําขอของผู้ใช้บางส่วนที่พบบ่อย

ผู้ใช้อาจขอให้ดําเนินการที่การดําเนินการของคุณไม่รองรับ

การครอบคลุมของ Intent

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

จุดประสงค์คือการเชื่อมโยงระหว่างสิ่งที่ผู้ใช้พูดและการกระทําของคุณ ตัวอย่างเช่น ข้อความแจ้ง "คุณชอบพิซซ่าไหม" ต้องมี Intent สําหรับ "yes" และ "no" แต่ละความตั้งใจควรมีวลีการฝึกอบรมที่หลากหลาย เช่น ใช่ "ใช่" และ "ไม่" รวมถึงรูปแบบอื่นๆ เช่น "ฉันชอบมาก" หรือ "น่ารังเกียจ" โดยน้ําหนักอาจถ่วงน้ําหนักด้วยความถี่ในการเกิดขึ้น Intent อาจรวมคําอธิบายประกอบ เช่น จัดหมวดหมู่ “Fresh mozzarella” เป็นพิซซ่าขึ้นหน้าใหม่ในการตอบกลับผู้ใช้ “เฉพาะเมื่อทําโดยใช้ชีสมอซซาเรลล่าสด”

หากคุณใช้ Dialogflow อยู่ โปรดดูที่นี่เพื่ออ่านข้อมูลเพิ่มเติมเกี่ยวกับ Intent

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

ควรทํา

ใส่จุดประสงค์ "เสร็จสิ้น" ที่มีวลีการฝึกอบรม เช่น "เสร็จแล้ว" หรือ "เท่านี้"

สิ่งที่ไม่ควรทํา

หากการดําเนินการต้องการเฉพาะคําถามเกี่ยวกับ I/O การตอบกลับของผู้ใช้จะแสดงข้อผิดพลาด "ไม่ตรงกัน"

เกิดข้อผิดพลาดในการจัดการ

แม้จะมีความตั้งใจที่ชัดเจน แต่ก็ยังมีโอกาสผิดพลาดได้ ผู้ใช้อาจปิดเสียงสคริปต์โดยปิดเสียงการแจ้งเตือนไว้ (ข้อผิดพลาดที่ระบุว่าไม่มีอินพุต) หรือพูดสิ่งที่คาดไม่ถึง (ข้อผิดพลาด "ไม่พบที่ตรงกัน") ใช้ข้อความแจ้งข้อผิดพลาดเพื่อค่อยๆ เปลี่ยนเส้นทางผู้ใช้ไปสู่เส้นทางที่ประสบความสําเร็จหรือรีเซ็ตความคาดหวังในสิ่งที่เราทําได้และทําไม่ได้

การจัดการข้อผิดพลาดที่ดีเป็นเรื่องเฉพาะบริบท ดังนั้น ข้อความเตือนข้อผิดพลาด "ไม่มีอินพุต" และ "ไม่พบที่ตรงกัน" จึงต้องออกแบบสําหรับทุกเลี้ยวในกล่องโต้ตอบ

ก่อนหน้า
ทดสอบและทําซ้ํา
ถัดไป
ปรับขนาดการออกแบบของคุณ