ควรใส่ AI เข้าไปจริงหรือไม่ - แบบตรวจสอบ 4 คำถามสำหรับทีมผลิตภัณฑ์

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

เส้นคุ้มทุนของฟีเจอร์ AI - ใครได้ ใครเสีย

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

สี่คำถามที่ต้องถามก่อนออกแบบ - ตัวอย่างคำถามที่สำคัญ

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

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

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

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

สิ่งที่ทีมควรทำต่อและข้อแนะนำสำหรับงานไอทีในไทย

อย่าตัดสินใจจากความตื่นเต้นด้านเทคโนโลยีเพียงอย่างเดียว ให้รันการตรวจสอบนี้ตั้งแต่ยังเป็นไอเดีย และเก็บคนที่ทำงานจริงมาทดสอบสั้นๆ ข้อมูลเช่นนี้ช่วยกำหนดกลุ่มเป้าหมายของฟีเจอร์ การสโคปให้เล็กลงเพื่อแก้ pain point เฉพาะ และออกแบบอินเทอร์เฟซที่แสดงแหล่งที่มาของผลลัพธ์ได้ชัด สำหรับทีมพัฒนา UX และผลิตภัณฑ์ในไทย ประเด็นเหล่านี้ใกล้ตัว - การแยกกลุ่มผู้ใช้ตามระดับประสบการณ์ และการออกแบบการตรวจสอบ (verification) ให้เบาแต่มีประสิทธิภาพ เป็นทักษะที่ควรฝึก

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

ที่มา: Smashing Magazine - เรียบเรียงและสรุปเป็นภาษาไทยโดยทีมงาน IT Genius