ผู้ช่วยที่แค่ตอบคำถาม อยู่ในหน้าต่างแชตธรรมดาได้ แต่ผู้ช่วยที่จองนัดเยี่ยมชม ส่งการติดต่อสอบถาม หรือแก้ไขข้อมูลของลูกค้า อยู่แบบนั้นไม่ได้ และความต่างนี้เองคือจุดเริ่มต้นของการออกแบบ UX สำหรับ AI agent คนต้องรู้ว่ากำลังคุยกับอะไร มันกำลังจะทำอะไร และจะหยุดมันได้อย่างไร ก่อนที่อะไรจะเกิดขึ้น ไม่ใช่หลังจากนั้น
ความไว้ใจจะได้มาหรือเสียไป อยู่ที่อินเทอร์เฟซรอบ ๆ ตัวโมเดล: ข้อความแรก การ์ดยืนยัน ลิงก์ย้อนกลับ ปุ่มที่พาไปหาคนจริง และแบบฟอร์มติดต่อธรรมดา ที่ยังอยู่บนหน้าเว็บ
รูปแบบด้านล่างอ้างอิงจากแนวทาง 18 ข้อสำหรับการโต้ตอบระหว่างคนกับ AI ที่นักวิจัยของ Microsoft เผยแพร่ในปี 2019 (ปัจจุบันเป็นส่วนหนึ่งของ HAX Toolkit ของ Microsoft) คู่มือ People + AI Guidebook ของ Google และ WCAG 2.2 ถ้าคุณยังเลือกเครื่องมืออยู่ เริ่มจากบทความ แชตบอต เวิร์กโฟลว์ หรือ AI agent
ออกแบบ UX ของ AI agent ใน 7 ข้อ
- บอกว่าเป็น AI ตั้งแต่ข้อความแรก พร้อมบอกว่าทำอะไรได้ และทำอะไรไม่ได้
- แสดงที่มาของคำตอบ: ลิงก์ไปยังแหล่งข้อมูล และแสดงความคืบหน้าในงานที่มีหลายขั้นตอน
- แสดงตัวอย่างและขอยืนยัน ทุกการจอง การส่งข้อมูล หรือการเปลี่ยนแปลง ด้วยคำตอบ “ใช่” ที่ชัดเจน ซึ่งบังคับไว้ในโค้ด
- ทำให้ย้อนกลับได้ง่าย และบอกก่อนยืนยัน ถ้ามีอะไรที่ย้อนกลับไม่ได้
- ให้ติดต่อคนจริงได้ในแตะเดียว ในทุกขั้นตอน ไม่ใช่เฉพาะหลังจากเอเจนต์ทำพลาด
- บอกว่า “ไม่ทราบ” เมื่อเนื้อหาที่มีไม่พอ แล้วเสนอทางที่ดีที่สุดถัดไป
- สร้างวิดเจ็ตให้ได้มาตรฐาน WCAG 2.2 AA และให้แบบฟอร์มปกติกับเบอร์โทร ยังมองเห็นอยู่ เพื่อให้เอเจนต์เป็นทางเลือก ไม่ใช่สิ่งกีดขวาง
บอกให้ชัดว่าเป็น AI และทำอะไรได้
บอกว่าเป็น AI ตั้งแต่แรก แบบตรง ๆ
ใส่ไว้ที่ส่วนหัวของวิดเจ็ต และในข้อความเปิด ซึ่งทำงานได้ 3 อย่าง ในไม่กี่ประโยค:
ฉันเป็นผู้ช่วย AI ตอบคำถามเกี่ยวกับบริการของเรา เช็กวันว่าง และจองนัดเยี่ยมชมสถานที่ให้ได้ แต่แก้ไขสัญญาที่มีอยู่แล้ว หรือให้คำแนะนำทางกฎหมายไม่ได้ และคุณขอคุยกับเจ้าหน้าที่ได้ทุกเมื่อ
ตั้งชื่อเรียกที่เป็นมิตรได้ ถ้ามีป้าย “ผู้ช่วย AI” ที่ชัดเจนอยู่ข้าง ๆ แต่ตัวละครที่สร้างขึ้นให้ดูเหมือนเพื่อนร่วมงาน พร้อมรูปจากคลังภาพ และการแกล้งหน่วงเวลาเหมือนกำลังพิมพ์ จะกลายเป็นการผิดคำสัญญา ทันทีที่มีคนจับได้ กฎหมายก็ไปในทางเดียวกัน: มาตรา 50 ของ AI Act ของสหภาพยุโรป กำหนดให้ระบบ AI ที่โต้ตอบกับคนโดยตรง ต้องออกแบบให้คนเหล่านั้นรู้ว่ากำลังติดต่อกับ AI เว้นแต่จะเห็นได้ชัดจากบริบทอยู่แล้ว
บอกขอบเขตและความแม่นยำให้ชัด
แนวทางสองข้อแรกของ Microsoft ขอให้คุณบอกให้ชัดว่า ระบบทำอะไรได้ และทำได้ดีแค่ไหน ในทางปฏิบัติคือ:
- คำถามแนะนำที่ตรงกับความสามารถจริง ปุ่มเริ่มต้นอย่าง “เช็กวันว่าง” สอนให้คนรู้ว่าควรถามอะไร อย่าเสนอปุ่มที่เอเจนต์ทำให้สำเร็จไม่ได้
- หนึ่งประโยคที่ซื่อตรงเรื่องความแม่นยำ “คำตอบมาจากเว็บไซต์ของเรา ส่วนเรื่องที่เกี่ยวกับสัญญา ทีมงานของเราจะยืนยันให้”
- ความชัดเจนเรื่องข้อมูล บอกว่าบทสนทนาจะถูกนำไปทำอะไร และลิงก์ไปยังนโยบายความเป็นส่วนตัวของคุณ
การออกแบบ UX เชิงสนทนาที่ดี ให้บุคลิกแค่เบา ๆ แล้วปล่อยให้ความเร็วและความแม่นยำ เป็นตัวโน้มน้าว
ลองเช็กด้วยตัวเอง เปิดผู้ช่วยบนมือถือ ที่หน้าจอแรก คุณบอกได้ไหมว่านี่คือ AI บอกได้ไหมว่ามันทำอะไรได้ 2 อย่าง และทำอะไรไม่ได้ 1 อย่าง และเห็นไหมว่าจะติดต่อคนจริงได้อย่างไร?
แสดงแหล่งที่มาและความคืบหน้า
ใส่ลิงก์ที่มาให้ทุกคำตอบเชิงข้อเท็จจริง
เมื่อเอเจนต์บอกราคา นโยบาย หรือเวลาเปิดทำการ ให้ลิงก์ไปยังหน้าที่เป็นที่มาของข้อมูลนั้น ลูกค้าจะได้ตรวจสอบเองได้ ทีมของคุณสืบย้อนคำตอบที่ผิดได้ และเว็บไซต์ยังคงเป็นแหล่งข้อมูลหลัก คะแนนความมั่นใจเป็นเปอร์เซ็นต์ แทบไม่ช่วยให้ใครตัดสินใจได้ แต่ลิงก์ช่วยได้ วิธีนี้ได้ผลก็ต่อเมื่อหน้าเว็บถูกต้อง นี่คือเหตุผลที่การเตรียมฐานความรู้สำหรับ AI มักสำคัญกว่าตัวโมเดล
แสดงว่าเข้าใจอะไร และกำลังทำอะไร
หลักข้อแรกในหลักการด้านการใช้งาน 10 ข้อ ของ Jakob Nielsen คือทำให้ผู้ใช้เห็นสถานะของระบบ ซึ่งใช้ได้ตรง ๆ:
- ทวนคำขอกลับไป “นัดเยี่ยมชมสถานที่ 2 คน สัปดาห์หน้า” ความเข้าใจผิดจะโผล่ขึ้นมา ก่อนที่จะมีการจองอะไร
- แสดงแต่ละขั้นตอน ขณะที่เกิดขึ้น “กำลังเช็กปฏิทิน… พบช่วงเวลาว่าง 3 ช่วง” ไม่ใช่ไอคอนหมุน ๆ ที่ไม่มีคำอธิบาย
- ให้เหตุผลสั้น ๆ ในวลีเดียว “วันศุกร์เป็นช่วงแรกที่มีที่ปรึกษาอยู่ที่หน้างาน” นี่คือแนวทางข้อที่ 11 ของ Microsoft (บอกให้ชัดว่าทำไมระบบถึงทำแบบนั้น) ในทางปฏิบัติ
แสดงตัวอย่างและยืนยัน ก่อนเกิดผลจริง
นี่คือรูปแบบที่สำคัญที่สุด และถูกข้ามได้ง่ายที่สุด ตอนเดโม
แยกการพูดออกจากการลงมือทำ
การกระทำของเอเจนต์มี 2 แบบ คือการอ่าน ซึ่งเป็นการค้นหาข้อมูล หรือการเขียน ซึ่งเป็นการจอง ส่ง ยื่น หรือเปลี่ยนข้อมูล (บทความAI agent คืออะไร และทำงานอย่างไร อธิบายความต่างนี้) การเขียนทุกครั้งต้องมีขั้นตอนยืนยัน ที่บังคับไว้ในโค้ด ไม่ใช่แค่ขอไว้ในคำสั่งของเอเจนต์ คำสั่งถูกพูดโน้มน้าวให้เลี่ยงได้ แต่การตรวจสอบในโค้ดเลี่ยงไม่ได้ นี่คือเหตุผลที่บทความความเสี่ยงของ AI agent จัดให้การยืนยันก่อนเกิดผลตามมา เป็นหนึ่งในมาตรการป้องกัน prompt injection และการให้อำนาจเอเจนต์มากเกินไป
WCAG 2.2 ตั้งมาตรฐานที่ใกล้เคียงกันไว้ สำหรับเรื่องที่มีเดิมพันสูงที่สุด เกณฑ์ความสำเร็จข้อ 3.3.4 กำหนดว่า อะไรก็ตามที่สร้างข้อผูกพันทางกฎหมาย หรือธุรกรรมทางการเงิน หรือเปลี่ยนแปลงหรือลบข้อมูลที่ผู้ใช้เก็บไว้ ต้องย้อนกลับได้ มีการตรวจข้อผิดพลาดของข้อมูลที่กรอก หรือเปิดให้ทบทวน แก้ไข และยืนยันได้ ก่อนจะมีผลถาวร เอเจนต์ที่ทำการแทนใครสักคน ไม่ได้ทำให้มาตรฐานนี้ลดลง
ออกแบบการ์ดยืนยัน
แสดงสรุปที่มีโครงสร้าง ไม่ใช่ย่อหน้าที่จมอยู่ในแชต ทุกการ์ดต้องมี:
ให้การยืนยันเป็นการแตะปุ่ม ไม่ใช่การเดาว่า “ได้เลย ฟังดูโอเค” แปลว่าตกลงหรือเปล่า
ให้ขั้นตอนยืนยันเหมาะกับเดิมพัน
การยืนยันทุกขั้นตอนเล็ก ๆ จะทำให้คนเคยชินกับการแตะ “ใช่” โดยไม่อ่าน ให้ปรับระดับตามเดิมพันแทน:
ถามดีกว่าเดา
“ศุกร์หน้า” และ “ที่อยู่เดิม” กำกวม แนวทางข้อที่ 10 ของ Microsoft คือจำกัดขอบเขตการทำงานเมื่อไม่แน่ใจ ในทางปฏิบัติ มันกลายเป็นคำถามเพื่อความชัดเจน พร้อมตัวเลือกให้แตะ: “วันศุกร์ที่ 2 ตุลาคม หรือวันศุกร์ที่ 9 ตุลาคม?” คำถามเสียเวลาไม่กี่วินาที แต่การจองผิด ต้องเสียโทรศัพท์อีกหนึ่งสาย
ย้อนกลับ แก้ไข และทางไปหาคนจริง
ทำให้ย้อนกลับได้ง่ายและตรงไปตรงมา
ข้อความแจ้งว่าสำเร็จ ควรมีทางย้อนกลับติดมาด้วย (“จองนัดเยี่ยมชมวันศุกร์ที่ 9 ตุลาคม เวลา 10:00 แล้ว เปลี่ยนหรือยกเลิก”) อีเมลยืนยันก็เช่นกัน สำหรับข้อความที่ส่งแทนใครสักคน การหน่วงเวลาสั้น ๆ พร้อมปุ่ม “เลิกทำ” ช่วยรับมือความเสียดาย ที่มักมาถึง 2 วินาทีหลังแตะส่ง
ทำให้แก้ไขได้ง่าย
ให้คนแก้รายละเอียดทีละจุดได้ โดยไม่ต้องเริ่มใหม่: ช่องบนการ์ดที่แก้ไขได้ และตัวเลือก “ไม่ใช่แบบนี้” ที่ย้อนกลับไปหนึ่งขั้น ไม่ใช่กลับไปจุดเริ่มต้น นี่คือแนวทางข้อที่ 9 ของ Microsoft คือรองรับการแก้ไขอย่างมีประสิทธิภาพ เกณฑ์ Redundant Entry (3.3.7) ของ WCAG 2.2 เพิ่มกฎที่มีประโยชน์: ข้อมูลที่คนกรอกไปแล้วในกระบวนการเดียวกัน ควรเติมไว้ให้ หรือให้เลือกได้ ไม่ใช่ถามซ้ำ
ให้ติดต่อคนจริงได้ในแตะเดียว
ปุ่ม “คุยกับเจ้าหน้าที่” ควรอยู่ที่ส่วนหัวของวิดเจ็ตในทุกหน้าจอ ไม่ใช่ซ่อนอยู่หลังความพยายามที่ล้มเหลว 3 ครั้ง เอเจนต์ควรเข้าใจคำขอนี้ ไม่ว่าจะพูดแบบไหน ในภาษาใด และส่งต่อทันที พร้อมบอกว่าจะมีคนตอบกลับเมื่อไร ถ้าตอนนั้นไม่มีใครออนไลน์ บทความAI agent สำหรับบริการลูกค้า อธิบายขั้นตอนการส่งต่อ
เมื่อเอเจนต์ไม่รู้คำตอบ
คำตอบผิดที่พูดอย่างมั่นใจ สร้างความเสียหายมากกว่าการบอกตรง ๆ ว่า “ไม่ทราบ” นี่คือเหตุผลที่ People + AI Guidebook ของ Google ให้เรื่องข้อผิดพลาด และการล้มเหลวอย่างนุ่มนวล มีบทเป็นของตัวเอง การไม่รู้แต่ละแบบ ต้องตอบสนองต่างกัน:
อย่าแสดงข้อความสำรองแบบเดิมซ้ำสองครั้งติดกัน: หลังเข้าใจผิดเป็นครั้งที่สอง ให้เสนอคนจริง และบันทึกทุกคำถามที่ตอบไม่ได้ไว้ด้วย เพราะเมื่อรวมกันแล้ว คำถามเหล่านี้คือรายการเนื้อหา ที่เว็บไซต์ของคุณยังขาด
ทำให้วิดเจ็ตเข้าถึงได้และไม่รบกวน
วิดเจ็ตแชตเป็นส่วนหนึ่งของทุกหน้าที่มันปรากฏ ดังนั้นถ้าเว็บไซต์ของคุณตั้งเป้ามาตรฐาน WCAG 2.2 AA วิดเจ็ตก็ต้องผ่านด้วย เช็กข้อเหล่านี้ก่อน:
เกณฑ์ Consistent Help (3.2.6) ของ WCAG 2.2 นับ “ช่องทางติดต่อที่ทำงานอัตโนมัติเต็มรูปแบบ” เป็นความช่วยเหลือประเภทหนึ่ง ที่เมื่อปรากฏซ้ำในหลายหน้า ต้องอยู่ในลำดับเดิมเมื่อเทียบกับเนื้อหาอื่น ดังนั้นให้ปุ่มเปิดแชตอยู่ตำแหน่งเดียวกันทุกหน้า คู่มือการเข้าถึงเว็บไซต์สำหรับทุกคน อธิบายมาตรฐานในภาพกว้าง
ไม่รบกวนเป็นค่าเริ่มต้น
- อย่าเปิดขึ้นมาเอง แผงที่เด้งขึ้นมาตอนโหลดหน้า จะบังเนื้อหา และขัดจังหวะโปรแกรมอ่านหน้าจอ
- ปิดแล้วต้องปิดจริง แนวทางข้อที่ 8 ของ Microsoft คือรองรับการปิดอย่างมีประสิทธิภาพ: ปิดแผงได้ในแตะเดียว และแผงปิดอยู่อย่างนั้น ตลอดการเข้าชมครั้งนั้น
- โหลดทีหลัง สคริปต์แชตอาจหนัก ให้โหลดวิดเจ็ตเต็มรูปแบบ เมื่อมีคนเปิด บทความสคริปต์ภายนอกกับความเร็วเว็บไซต์ อธิบายเหตุผล
ให้เอเจนต์เป็นทางเลือก ไม่ใช่ผู้เฝ้าประตู
วิธีที่เร็วที่สุดในการเสียความไว้ใจ คือทำให้ผู้ช่วยเป็นประตูบานเดียว บางคนชอบแบบฟอร์มที่กรอกได้ตามจังหวะของตัวเอง หรืออยากคุยกับคน บางคนเคยติดวนอยู่ในแชตบอตมาก่อน บางคนใช้เทคโนโลยีช่วยเหลือ ที่ทำงานกับแบบฟอร์มที่สร้างมาดี ได้ดีกว่าบทสนทนาสด
ดังนั้นให้แบบฟอร์มติดต่อ เบอร์โทร และอีเมล อยู่ที่เดิม ข้าง ๆ ปุ่มหรือข้อความชวนให้ติดต่อ (CTA) ของคุณ ข้อมูลติดต่อที่มองเห็นได้ เป็นสัญญาณความน่าเชื่อถือในตัวเอง และบทความความน่าเชื่อถือของเว็บไซต์ อธิบายว่าผู้เข้าชมมองหาข้อมูลเหล่านี้อย่างไร ในช่วงที่กำลังตัดสินใจ เอเจนต์ควรเสนอช่องทางเหล่านี้เป็นตัวเลือกปกติ ไม่ใช่ทางออกเมื่อล้มเหลว และส่งต่อข้อมูลที่เก็บมาแล้ว เพื่อไม่ให้ใครต้องเริ่มใหม่ เพราะแบบฟอร์มที่ดี คือทางสำรองที่ทุกเอเจนต์ต้องพึ่ง การออกแบบแบบฟอร์มบนเว็บ จึงควรทำให้ดีตั้งแต่แรก
แล้ววัดผลทั้งภาพ ถ้าบทสนทนาในแชตเพิ่มขึ้น การติดต่อผ่านแบบฟอร์มลดลง และจำนวนการติดต่อที่มีคุณภาพโดยรวมเท่าเดิม แปลว่าเอเจนต์แค่ย้ายการติดต่อไปมา ไม่ได้เพิ่มขึ้นเลย
ทดสอบแบบที่ลูกค้าจะใช้จริง
ก่อนเปิดตัว และหลังการเปลี่ยนแปลงสำคัญทุกครั้ง:
- ขอให้มันทำสิ่งที่มันทำไม่ได้
- ขอคุยกับคนจริงด้วยคำพูด 3 แบบ ในทุกภาษาที่คุณให้บริการ
- เปลี่ยนใจกลางคัน ระหว่างการจอง
- ทำงานให้เสร็จด้วยคีย์บอร์ดอย่างเดียว แล้วลองอีกครั้งด้วยโปรแกรมอ่านหน้าจอ
- สั่งให้มันเพิกเฉยต่อกฎของตัวเอง แล้วตรวจว่าไม่มีอะไรเปลี่ยน
- ทำทั้งหมดนี้บนมือถือ ด้วยเน็ตมือถือ
สร้างความไว้ใจบนเว็บไซต์ที่พร้อม
ประสบการณ์ AI ที่น่าไว้ใจ มาจากวินัยการออกแบบแบบเดิม ๆ ที่นำมาใช้กับอินเทอร์เฟซแบบใหม่ และตั้งอยู่บนเว็บไซต์ที่อยู่เบื้องหลัง: เอเจนต์ตอบจากหน้าเว็บของคุณ และทุกทางสำรอง ก็พากลับไปที่แบบฟอร์มและข้อมูลติดต่อของคุณ
ก่อนเพิ่มผู้ช่วย การตรวจสอบเว็บไซต์ฟรี จะเช็กรากฐานเหล่านั้น ตั้งแต่หน้าสำคัญทำงานบนมือถืออย่างไร ไปจนถึงผู้เข้าชมติดต่อคุณได้ง่ายแค่ไหน โดยไม่ต้องใช้ผู้ช่วย อยากคุยว่าเว็บไซต์ของคุณต้องการอะไร? ติดต่อเรา