การออกแบบสำหรับตัวแทนอัตโนมัติทำให้เกิดความยุ่งยากที่ไม่เหมือนใคร เรามอบงานที่ซับซ้อนให้กับ AI โดยงานจะหายไปเป็นเวลา 30 วินาที (หรือ 30 นาที) จากนั้นงานจะกลับมาพร้อมผลลัพธ์ เราจ้องมองที่หน้าจอ มันได้ผลเหรอ? มันประสาทหลอนหรือเปล่า? ได้ตรวจสอบฐานข้อมูลการปฏิบัติตามข้อกำหนดหรือข้ามขั้นตอนนั้นหรือไม่ โดยทั่วไปแล้วเราจะตอบสนองต่อความวิตกกังวลนี้ด้วยหนึ่งในสองแบบสุดโต่ง เราเก็บระบบให้เป็น Black Box ซ่อนทุกอย่างเพื่อรักษาความเรียบง่าย หรือเราตื่นตระหนกและจัดให้มี Data Dump ซึ่งสตรีมทุกบรรทัดบันทึกและการเรียก API ไปยังผู้ใช้ ไม่มีแนวทางใดระบุโดยตรงถึงความแตกต่างที่จำเป็นเพื่อให้ผู้ใช้ได้รับความโปร่งใสในระดับที่เหมาะสมที่สุด กล่องดำทำให้ผู้ใช้รู้สึกไร้พลัง การถ่ายโอนข้อมูลทำให้เกิดการมองไม่เห็นการแจ้งเตือน ซึ่งทำลายประสิทธิภาพที่ตัวแทนสัญญาว่าจะให้ได้ ผู้ใช้เพิกเฉยต่อกระแสข้อมูลอย่างต่อเนื่องจนกว่าจะมีบางอย่างขัดข้อง ซึ่ง ณ จุดนี้พวกเขาขาดบริบทในการแก้ไข เราต้องการวิธีการจัดระเบียบเพื่อค้นหาความสมดุล ในบทความก่อนหน้าของฉัน “การออกแบบสำหรับ Agentic AI” เราได้ดูองค์ประกอบอินเทอร์เฟซที่สร้างความไว้วางใจ เช่น การแสดงการกระทำที่ตั้งใจของ AI ไว้ล่วงหน้า (การแสดงตัวอย่างเจตนา) และให้ผู้ใช้ควบคุมว่า AI ทำอะไรได้ด้วยตัวเองมากน้อยเพียงใด (Autonomy Dials) แต่การรู้ว่าองค์ประกอบใดที่จะใช้เป็นเพียงส่วนหนึ่งของความท้าทายเท่านั้น คำถามที่ยากกว่าสำหรับนักออกแบบคือการรู้ว่าเมื่อใดควรใช้สิ่งเหล่านี้ คุณจะรู้ได้อย่างไรว่าช่วงเวลาใดในเวิร์กโฟลว์ 30 วินาทีที่ต้องใช้ Intent Preview และช่วงเวลาใดที่สามารถจัดการได้ด้วยรายการบันทึกแบบง่ายๆ บทความนี้มีวิธีการตอบคำถามนั้น เราจะเดินผ่านการตรวจสอบโหนดการตัดสินใจ กระบวนการนี้ทำให้นักออกแบบและวิศวกรอยู่ในห้องเดียวกันเพื่อแมปตรรกะแบ็กเอนด์กับอินเทอร์เฟซผู้ใช้ คุณจะได้เรียนรู้วิธีระบุช่วงเวลาที่ผู้ใช้ต้องการการอัปเดตว่า AI กำลังทำอะไรอยู่ นอกจากนี้เรายังจะครอบคลุมเมทริกซ์ผลกระทบ/ความเสี่ยงที่จะช่วยจัดลำดับความสำคัญว่าโหนดการตัดสินใจใดที่จะแสดงและรูปแบบการออกแบบที่เกี่ยวข้องเพื่อจับคู่กับการตัดสินใจนั้น ช่วงเวลาแห่งความโปร่งใส: ตัวอย่างกรณีศึกษา พิจารณา Meridian (ไม่ใช่ชื่อจริง) ซึ่งเป็นบริษัทประกันภัยที่ใช้ AI ตัวแทนเพื่อประมวลผลการเคลมอุบัติเหตุเบื้องต้น ผู้ใช้อัปโหลดภาพถ่ายความเสียหายของยานพาหนะและรายงานของตำรวจ จากนั้นตัวแทนจะหายไปหนึ่งนาทีก่อนที่จะกลับมาพร้อมการประเมินความเสี่ยงและช่วงการจ่ายเงินที่เสนอ ในตอนแรก อินเทอร์เฟซของ Meridian แสดงสถานะการคำนวณการเรียกร้องสิทธิ์ ผู้ใช้เริ่มหงุดหงิด พวกเขาได้ส่งเอกสารรายละเอียดหลายฉบับและรู้สึกไม่แน่ใจว่า AI ได้ตรวจสอบรายงานของตำรวจซึ่งมีสถานการณ์บรรเทาทุกข์หรือไม่ กล่องดำสร้างความไม่ไว้วางใจ เพื่อแก้ไขปัญหานี้ ทีมออกแบบได้ดำเนินการตรวจสอบโหนดการตัดสินใจ พวกเขาพบว่า AI ดำเนินการสามขั้นตอนที่แตกต่างกันตามความน่าจะเป็น โดยมีขั้นตอนเล็กๆ มากมายฝังอยู่:
การวิเคราะห์รูปภาพ เจ้าหน้าที่เปรียบเทียบภาพถ่ายความเสียหายกับฐานข้อมูลสถานการณ์อุบัติเหตุรถชนทั่วไปเพื่อประเมินค่าซ่อม เรื่องนี้เกี่ยวข้องกับคะแนนความเชื่อมั่น การตรวจสอบข้อความ จะสแกนรายงานของตำรวจเพื่อหาคำหลักที่ส่งผลต่อความรับผิด (เช่น ข้อบกพร่อง สภาพอากาศ ความมีสติ) สิ่งนี้เกี่ยวข้องกับการประเมินความน่าจะเป็นของสถานะทางกฎหมาย การอ้างอิงโยงนโยบายจะจับคู่รายละเอียดการอ้างสิทธิ์กับข้อกำหนดนโยบายเฉพาะของผู้ใช้ โดยค้นหาข้อยกเว้นหรือขีดจำกัดความครอบคลุม นอกจากนี้ยังเกี่ยวข้องกับการจับคู่ความน่าจะเป็นด้วย
ทีมงานได้เปลี่ยนขั้นตอนเหล่านี้ให้เป็นช่วงเวลาที่โปร่งใส ลำดับอินเทอร์เฟซได้รับการอัปเดตเป็น:
ภาพถ่ายการประเมินความเสียหาย: เปรียบเทียบกับโปรไฟล์การชนของยานพาหนะ 500 คัน ทบทวนรายงานของตำรวจ: วิเคราะห์คำสำคัญความรับผิดและตัวอย่างทางกฎหมาย การตรวจสอบความครอบคลุมของนโยบาย: การตรวจสอบข้อยกเว้นเฉพาะในแผนของคุณ
ระบบยังคงใช้เวลาเท่าเดิม แต่การสื่อสารที่ชัดเจนเกี่ยวกับการทำงานภายในของตัวแทนช่วยคืนความมั่นใจให้กับผู้ใช้ ผู้ใช้เข้าใจว่า AI กำลังทำงานที่ซับซ้อนตามที่ออกแบบมาเพื่อ และพวกเขารู้ดีว่าจะมุ่งความสนใจไปที่จุดใดหากการประเมินขั้นสุดท้ายดูเหมือนไม่ถูกต้อง ตัวเลือกการออกแบบนี้เปลี่ยนช่วงเวลาแห่งความวิตกกังวลให้กลายเป็นช่วงเวลาแห่งการเชื่อมต่อกับผู้ใช้ การใช้เมทริกซ์ผลกระทบ/ความเสี่ยง: สิ่งที่เราเลือกที่จะซ่อน ประสบการณ์ AI ส่วนใหญ่ไม่มีปัญหาเรื่องเหตุการณ์และโหนดการตัดสินใจที่อาจแสดงระหว่างการประมวลผล ผลลัพธ์ที่สำคัญที่สุดประการหนึ่งของการตรวจสอบคือการตัดสินใจว่าสิ่งใดควรซ่อนไว้ ในตัวอย่าง Meridian บันทึกแบ็กเอนด์สร้างเหตุการณ์มากกว่า 50 รายการต่อการอ้างสิทธิ์ เราอาจตั้งค่าเริ่มต้นให้แสดงแต่ละเหตุการณ์เมื่อมีการประมวลผลเป็นส่วนหนึ่งของ UI แต่เรานำเมทริกซ์ความเสี่ยงมาตัดออกแทน:
บันทึกเหตุการณ์: เซิร์ฟเวอร์ส่ง PingWest-2 สำหรับการตรวจสอบความซ้ำซ้อน คำตัดสินของตัวกรอง: ซ่อน (เดิมพันต่ำ เทคนิคสูง)
บันทึกเหตุการณ์: การเปรียบเทียบการประมาณการการซ่อมแซมกับมูลค่า BlueBook คำตัดสินของตัวกรอง: แสดง (เดิมพันสูง ส่งผลต่อการจ่ายเงินของผู้ใช้)
การตัดรายละเอียดที่ไม่จำเป็นออกไป ข้อมูลสำคัญ เช่น การตรวจสอบความครอบคลุม จึงมีผลกระทบมากขึ้น เราสร้างอินเทอร์เฟซแบบเปิดและออกแบบประสบการณ์แบบเปิด แนวทางนี้ใช้แนวคิดที่ว่าผู้คนรู้สึกดีขึ้นเกี่ยวกับบริการเมื่อเห็นว่างานกำลังทำเสร็จแล้ว ด้วยการแสดงขั้นตอนเฉพาะ (การประเมิน การทบทวน และการยืนยัน) เราได้เปลี่ยนการรอ 30 วินาทีจากช่วงเวลาแห่งความกังวล (“มันพังหรือเปล่า”) เป็นเวลาที่รู้สึกเหมือนมีบางสิ่งที่มีค่ากำลังถูกสร้างขึ้น (“กำลังคิด”) ตอนนี้เรามาดูวิธีที่เราจะตรวจสอบกระบวนการตัดสินใจในผลิตภัณฑ์ของเราเพื่อระบุช่วงเวลาสำคัญที่ต้องใช้ข้อมูลที่ชัดเจนกันดีกว่า การตรวจสอบโหนดการตัดสินใจ ความโปร่งใสจะล้มเหลวเมื่อเราถือว่ามันเป็นตัวเลือกสไตล์มากกว่าข้อกำหนดด้านการใช้งาน เรามักจะถามว่า “UI ควรมีลักษณะอย่างไร” ก่อนที่เราจะถามว่า “จริง ๆ แล้วตัวแทนกำลังตัดสินใจอะไรอยู่” Decision Node Audit เป็นวิธีที่ตรงไปตรงมาในการทำให้ระบบ AI เข้าใจง่ายขึ้น มันทำงานโดยการจัดทำแผนผังกระบวนการภายในของระบบอย่างระมัดระวัง เป้าหมายหลักคือการค้นหาและกำหนดช่วงเวลาที่ระบบหยุดทำตามกฎที่ตั้งไว้อย่างชัดเจน และตัดสินใจเลือกตามโอกาสหรือการประมาณค่าแทน ด้วยการแมปโครงสร้างนี้ ผู้สร้างสามารถแสดงจุดความไม่แน่นอนเหล่านี้แก่ผู้ที่ใช้ระบบได้โดยตรง สิ่งนี้จะเปลี่ยนการอัปเดตระบบจากข้อความที่คลุมเครือไปเป็นรายงานเฉพาะเจาะจงและเชื่อถือได้เกี่ยวกับวิธีการที่ AI บรรลุข้อสรุป นอกเหนือจากกรณีศึกษาเกี่ยวกับการประกันภัยข้างต้นแล้ว ฉันเพิ่งทำงานร่วมกับทีมในการสร้างตัวแทนจัดซื้อจัดจ้าง ระบบตรวจสอบสัญญาของผู้ขายและตั้งค่าสถานะความเสี่ยง เดิมที หน้าจอแสดงแถบความคืบหน้าง่ายๆ: “การตรวจสอบสัญญา” ผู้ใช้เกลียดมัน การวิจัยของเราระบุว่าพวกเขารู้สึกกังวลเกี่ยวกับผลทางกฎหมายของประโยคที่หายไป เราแก้ไขปัญหานี้โดยดำเนินการตรวจสอบโหนดการตัดสินใจ ฉันได้รวมรายการตรวจสอบทีละขั้นตอนสำหรับการดำเนินการตรวจสอบนี้ไว้ที่ส่วนท้ายของบทความนี้ เราจัดเซสชันกับวิศวกรและสรุปวิธีการทำงานของระบบ เราระบุ “จุดตัดสินใจ” — ช่วงเวลาที่ AI ต้องเลือกระหว่างสองตัวเลือกที่ดี ในโปรแกรมคอมพิวเตอร์มาตรฐาน กระบวนการมีความชัดเจน: ถ้า A เกิดขึ้น B จะเกิดขึ้นเสมอ ในระบบ AI กระบวนการมักขึ้นอยู่กับโอกาส AI คิดว่า A น่าจะเป็นตัวเลือกที่ดีที่สุด แต่อาจมีความแน่นอนเพียง 65% เท่านั้น ในระบบสัญญา เราพบช่วงเวลาที่ AI ตรวจสอบเงื่อนไขความรับผิดตามกฎของบริษัทของเรา มันไม่ค่อยเป็นคู่ที่สมบูรณ์แบบ AI ต้องตัดสินใจว่าการจับคู่ 90% นั้นดีเพียงพอหรือไม่ นี่เป็นจุดตัดสินใจสำคัญ
เมื่อเราระบุโหนดนี้แล้ว เราก็เปิดเผยให้ผู้ใช้เห็น แทนที่จะเป็น "การตรวจสอบสัญญา" อินเทอร์เฟซได้รับการอัปเดตเป็น "ส่วนความรับผิดชอบจะแตกต่างจากเทมเพลตมาตรฐาน การวิเคราะห์ระดับความเสี่ยง" การอัปเดตเฉพาะนี้ทำให้ผู้ใช้มั่นใจ พวกเขารู้ว่าตัวแทนได้ตรวจสอบข้อกำหนดความรับผิดแล้ว พวกเขาเข้าใจสาเหตุของความล่าช้าและได้รับความไว้วางใจว่าการดำเนินการที่ต้องการนั้นเกิดขึ้นที่ส่วนหลัง พวกเขายังรู้ว่าจะต้องเจาะลึกลงไปที่ไหนเมื่อตัวแทนสร้างสัญญา ในการตรวจสอบว่า AI ตัดสินใจอย่างไร คุณต้องทำงานอย่างใกล้ชิดกับวิศวกร ผู้จัดการผลิตภัณฑ์ นักวิเคราะห์ธุรกิจ และบุคคลสำคัญที่กำลังตัดสินใจเลือก (มักซ่อนเร้น) ซึ่งส่งผลต่อวิธีการทำงานของเครื่องมือ AI วาดขั้นตอนที่เครื่องมือใช้ ทำเครื่องหมายทุกจุดที่กระบวนการเปลี่ยนทิศทางเนื่องจากเป็นไปตามความน่าจะเป็น นี่คือจุดที่คุณควรมุ่งเน้นที่ความโปร่งใสมากขึ้น ดังแสดงในรูปที่ 2 ด้านล่าง การตรวจสอบโหนดการตัดสินใจเกี่ยวข้องกับขั้นตอนเหล่านี้:
รวมทีมเข้าด้วยกัน: ดึงเจ้าของผลิตภัณฑ์ นักวิเคราะห์ธุรกิจ นักออกแบบ ผู้มีอำนาจตัดสินใจหลัก และวิศวกรที่สร้าง AI เข้ามา ตัวอย่างเช่น ลองนึกถึงทีมผลิตภัณฑ์ที่สร้างเครื่องมือ AI ที่ออกแบบมาเพื่อตรวจสอบสัญญาทางกฎหมายที่ยุ่งยาก ทีมงานประกอบด้วยนักออกแบบ UX ผู้จัดการผลิตภัณฑ์ นักวิจัย UX ทนายความฝึกหัดซึ่งทำหน้าที่เป็นผู้เชี่ยวชาญในเนื้อหา และวิศวกรแบ็กเอนด์ที่เขียนโค้ดการวิเคราะห์ข้อความ
วาดกระบวนการทั้งหมด: บันทึกทุกขั้นตอนที่ AI ทำ ตั้งแต่การกระทำครั้งแรกของผู้ใช้ไปจนถึงผลลัพธ์สุดท้าย ทีมงานยืนอยู่บนกระดานไวท์บอร์ดและร่างลำดับทั้งหมดสำหรับขั้นตอนการทำงานหลักที่เกี่ยวข้องกับ AI เพื่อค้นหาส่วนความรับผิดชอบในสัญญาที่ซับซ้อน ทนายกำลังอัพโหลด.PDF ห้าสิบหน้า → ระบบแปลงเอกสารเป็นข้อความที่อ่านได้ → AI จะสแกนหน้าต่างๆ เพื่อหาข้อความรับผิด → ผู้ใช้รอ → สักครู่หรือนาทีต่อมา เครื่องมือจะไฮไลต์ย่อหน้าที่พบเป็นสีเหลืองบนอินเทอร์เฟซผู้ใช้ พวกเขาทำเช่นนี้กับขั้นตอนการทำงานอื่นๆ มากมายที่เครื่องมือนี้รองรับเช่นกัน
ค้นหาสิ่งที่ไม่ชัดเจน: ดูแผนผังกระบวนการเพื่อหาจุดที่ AI เปรียบเทียบตัวเลือกหรืออินพุตที่ไม่มีคู่ที่ตรงกัน ทีมงานดูกระดานไวท์บอร์ดเพื่อระบุขั้นตอนที่ไม่ชัดเจน การแปลงรูปภาพเป็นข้อความเป็นไปตามกฎเกณฑ์ที่เข้มงวด การค้นหาข้อกำหนดความรับผิดที่เฉพาะเจาะจงเกี่ยวข้องกับการคาดเดา ทุกบริษัทเขียนอนุประโยคเหล่านี้แตกต่างกัน ดังนั้น AI จึงต้องชั่งน้ำหนักหลายตัวเลือกและทำการคาดเดาแทนการค้นหาคำที่ตรงกันทุกประการ
ระบุขั้นตอน "การเดาที่ดีที่สุด": สำหรับจุดที่ไม่ชัดเจนแต่ละจุด ให้ตรวจสอบว่าระบบใช้คะแนนความเชื่อมั่นหรือไม่ (เช่น แน่ใจ 85% หรือไม่) นี่คือจุดที่ AI ตัดสินใจขั้นสุดท้าย ระบบจะต้องเดา (ให้ความน่าจะเป็น) ว่าย่อหน้าใดที่มีลักษณะใกล้เคียงกับข้อกำหนดความรับผิดมาตรฐาน โดยจะกำหนดคะแนนความเชื่อมั่นให้กับการคาดเดาที่ดีที่สุด การคาดเดานั้นเป็นโหนดการตัดสินใจ อินเทอร์เฟซจำเป็นต้องบอกทนายความว่ากำลังเน้นการจับคู่ที่อาจเกิดขึ้น แทนที่จะระบุว่าพบประโยคที่ชัดเจน
ตรวจสอบตัวเลือก: สำหรับแต่ละจุดตัวเลือก ให้หาคณิตศาสตร์ภายในที่เฉพาะเจาะจงหรือการเปรียบเทียบที่กำลังทำอยู่ (เช่น จับคู่ส่วนหนึ่งของสัญญากับกรมธรรม์ หรือเปรียบเทียบภาพรถที่เสียหายกับคลังภาพถ่ายรถที่เสียหาย) วิศวกรอธิบายว่าระบบจะเปรียบเทียบย่อหน้าต่างๆ กับฐานข้อมูลของประโยคความรับผิดมาตรฐานจากคดีของบริษัทในอดีต จะคำนวณคะแนนความคล้ายคลึงกันของข้อความเพื่อตัดสินการจับคู่ตามความน่าจะเป็น
เขียนคำอธิบายที่ชัดเจน: สร้างข้อความสำหรับผู้ใช้ที่อธิบายการกระทำภายในเฉพาะที่เกิดขึ้นเมื่อ AI ตัดสินใจอย่างชัดเจน ผู้ออกแบบเนื้อหาเขียนข้อความเฉพาะในช่วงเวลานี้ ข้อความอ่านว่า: การเปรียบเทียบข้อความในเอกสารกับข้อกำหนดของบริษัทมาตรฐานเพื่อระบุความเสี่ยงในการรับผิดที่อาจเกิดขึ้น
อัปเดตหน้าจอ: ใส่คำอธิบายใหม่ที่ชัดเจนเหล่านี้ลงในอินเทอร์เฟซผู้ใช้ โดยแทนที่ข้อความที่คลุมเครือ เช่น "การตรวจสอบสัญญา" ทีมออกแบบลบตัวหมุนโหลด Processing PDF ทั่วไปออก พวกเขาแทรกคำอธิบายใหม่ลงในแถบสถานะที่อยู่เหนือโปรแกรมดูเอกสารในขณะที่ AI กำลังคิด
ตรวจสอบความน่าเชื่อถือ: ตรวจสอบให้แน่ใจว่าข้อความบนหน้าจอใหม่ให้เหตุผลง่ายๆ แก่ผู้ใช้ในการรอหรือผลลัพธ์ ซึ่งจะทำให้ผู้ใช้รู้สึกมั่นใจและไว้วางใจมากขึ้น
เมทริกซ์ผลกระทบ/ความเสี่ยง เมื่อคุณดูกระบวนการของ AI อย่างใกล้ชิด คุณอาจพบหลายจุดที่ทำให้ตัดสินใจเลือกได้ AI อาจสร้างทางเลือกเล็กๆ น้อยๆ มากมายให้กับงานที่ซับซ้อนเพียงงานเดียว การแสดงทั้งหมดทำให้เกิดข้อมูลที่ไม่จำเป็นมากเกินไป คุณต้องจัดกลุ่มตัวเลือกเหล่านี้ คุณสามารถใช้เมทริกซ์ผลกระทบ/ความเสี่ยงเพื่อจัดเรียงตัวเลือกเหล่านี้ตามประเภทการดำเนินการที่ AI กำลังดำเนินการ นี่คือตัวอย่างเมทริกซ์ผลกระทบ/ความเสี่ยง: ขั้นแรก ให้มองหาการตัดสินใจที่มีเดิมพันต่ำและมีผลกระทบต่ำ เดิมพันต่ำ / ผลกระทบต่ำ
ตัวอย่าง: การจัดโครงสร้างไฟล์หรือการเปลี่ยนชื่อเอกสาร ความต้องการความโปร่งใส: น้อยที่สุด การแจ้งเตือนแบบปิ้งเล็กๆ น้อยๆ หรือรายการบันทึกก็เพียงพอแล้ว ผู้ใช้สามารถยกเลิกการกระทำเหล่านี้ได้อย่างง่ายดาย
จากนั้นระบุการตัดสินใจที่มีเดิมพันสูงและมีผลกระทบสูง เดิมพันสูง / ผลกระทบสูง
ตัวอย่าง: การปฏิเสธการสมัครสินเชื่อหรือการดำเนินการซื้อขายหุ้น ความต้องการความโปร่งใส: สูง การดำเนินการเหล่านี้จำเป็นต้องมีหลักฐานการทำงาน ระบบจะต้องแสดงเหตุผลก่อนหรือทันทีที่ดำเนินการ
พิจารณาบอทการซื้อขายทางการเงินที่ปฏิบัติต่อคำสั่งซื้อ/ขายทั้งหมดเหมือนกัน มันดำเนินการซื้อขาย $5 ด้วยความทึบเช่นเดียวกับการซื้อขาย $50,000 ผู้ใช้อาจตั้งคำถามว่าเครื่องมือนี้รับรู้ถึงผลกระทบที่อาจเกิดขึ้นจากความโปร่งใสในการซื้อขายด้วยเงินจำนวนมากหรือไม่ พวกเขาต้องการให้ระบบหยุดชั่วคราวและแสดงการทำงานของมันสำหรับการซื้อขายที่มีเดิมพันสูง วิธีแก้ปัญหาคือการแนะนำสถานะลอจิกการทบทวนสำหรับธุรกรรมใดๆ ที่เกินจำนวนเงินดอลลาร์ที่ระบุ ทำให้ผู้ใช้สามารถเห็นปัจจัยที่ขับเคลื่อนการตัดสินใจก่อนดำเนินการ การแมปโหนดกับรูปแบบ: รูบริกการเลือกรูปแบบการออกแบบ เมื่อคุณระบุส่วนการตัดสินใจที่สำคัญของประสบการณ์ของคุณแล้ว คุณต้องตัดสินใจว่ารูปแบบ UI ใดที่จะนำไปใช้กับแต่ละส่วนที่คุณจะแสดง ในการออกแบบสำหรับ Agentic AI เราได้แนะนำรูปแบบต่างๆ เช่น Intent Preview (สำหรับการควบคุมที่มีเดิมพันสูง) และ Action Audit (เพื่อความปลอดภัยย้อนหลัง) ปัจจัยชี้ขาดในการเลือกระหว่างพวกเขาคือการพลิกกลับได้ เรากรองทุกโหนดการตัดสินใจผ่านเมทริกซ์ผลกระทบเพื่อกำหนดรูปแบบที่ถูกต้อง: เดิมพันสูงและไม่สามารถย้อนกลับได้: โหนดเหล่านี้จำเป็นต้องมีการแสดงตัวอย่างเจตนา เนื่องจากผู้ใช้ไม่สามารถเลิกทำการกระทำได้อย่างง่ายดาย (เช่น การลบฐานข้อมูลอย่างถาวร) ช่วงเวลาที่โปร่งใสจะต้องเกิดขึ้นก่อนดำเนินการ ระบบจะต้องหยุดชั่วคราว อธิบายเจตนา และต้องการการยืนยัน เดิมพันสูงและพลิกกลับได้: โหนดเหล่านี้สามารถพึ่งพารูปแบบการตรวจสอบการดำเนินการและเลิกทำ หากตัวแทนฝ่ายขายที่ขับเคลื่อนด้วย AI ย้ายลูกค้าเป้าหมายไปยังไปป์ไลน์อื่น ก็สามารถดำเนินการดังกล่าวได้โดยอัตโนมัติ ตราบใดที่แจ้งผู้ใช้และเสนอปุ่มเลิกทำทันที การจัดหมวดหมู่โหนดอย่างเคร่งครัดด้วยวิธีนี้จะช่วยหลีกเลี่ยง "การแจ้งเตือนความเหนื่อยล้า" เราสงวนการแสดงตัวอย่างเจตนาที่มีแรงเสียดทานสูงเฉพาะในช่วงเวลาที่ไม่สามารถย้อนกลับได้อย่างแท้จริง ในขณะที่อาศัยการตรวจสอบการดำเนินการเพื่อรักษาความเร็วสำหรับทุกสิ่งทุกอย่าง
กลับด้านได้ กลับไม่ได้ ผลกระทบต่ำ ประเภท: Auto-ExecuteUI: Passive Toast / LogEx: การเปลี่ยนชื่อไฟล์ ประเภท: ConfirmUI: ตัวเลือกเลิกทำแบบง่ายเช่น: การเก็บถาวรอีเมล ผลกระทบสูง ประเภท: ReviewUI: การแจ้งเตือน + รีวิว TrailEx: การส่งฉบับร่างไปยังไคลเอนต์ ประเภท: Intent PreviewUI: Modal / Explicit PermissionEx: การลบเซิร์ฟเวอร์
ตารางที่ 1: เมทริกซ์ผลกระทบและการพลิกกลับได้สามารถใช้เพื่อแมปช่วงเวลาแห่งความโปร่งใสของคุณกับรูปแบบการออกแบบ การตรวจสอบคุณภาพ: “รอทำไม” ทดสอบ คุณสามารถระบุโหนดที่เป็นไปได้ได้บนไวท์บอร์ด แต่คุณต้องตรวจสอบโหนดเหล่านั้นด้วยพฤติกรรมของมนุษย์ คุณต้องตรวจสอบว่าแผนที่ของคุณตรงกับแบบจำลองทางจิตของผู้ใช้หรือไม่ ฉันใช้โปรโตคอลที่เรียกว่า “รอทำไม” ทดสอบ. ขอให้ผู้ใช้ดูตัวแทนทำงานให้เสร็จสิ้น สั่งให้พวกเขาพูดออกเสียง เมื่อใดก็ตามที่พวกเขาถามคำถามว่า “เดี๋ยวก่อน ทำไมจึงทำเช่นนั้น?” หรือ “มันติดอยู่หรือเปล่า?” หรือ “มันได้ยินฉันไหม” — คุณทำเครื่องหมายประทับเวลา คำถามเหล่านี้ส่งสัญญาณความสับสนให้กับผู้ใช้ ผู้ใช้รู้สึกว่าการควบคุมของตนหลุดลอยไป ตัวอย่างเช่น ในการศึกษาเกี่ยวกับผู้ช่วยจัดตารางเวลาด้านการดูแลสุขภาพ ผู้ใช้เฝ้าดูตัวแทนจองการนัดหมาย หน้าจอหยุดนิ่งเป็นเวลาสี่วินาที ผู้เข้าร่วมถามอย่างต่อเนื่องว่า “นี่กำลังดูปฏิทินของฉันหรือตรวจหมอหรือเปล่า”
คำถามนั้นเผยให้เห็นช่วงเวลาแห่งความโปร่งใสที่หายไป ระบบจำเป็นต้องแบ่งการรอสี่วินาทีออกเป็นสองขั้นตอนที่แตกต่างกัน: “การตรวจสอบความพร้อมของคุณ” ตามด้วย “การซิงค์กับกำหนดเวลาของผู้ให้บริการ” การเปลี่ยนแปลงเล็กๆ น้อยๆ นี้ช่วยลดระดับความวิตกกังวลของผู้ใช้ ความโปร่งใสจะล้มเหลวเมื่ออธิบายเฉพาะการดำเนินการของระบบเท่านั้น อินเทอร์เฟซจะต้องเชื่อมต่อกระบวนการทางเทคนิคกับเป้าหมายเฉพาะของผู้ใช้ หน้าจอที่แสดง "กำลังตรวจสอบความพร้อมของคุณ" ไม่แสดงผลเนื่องจากไม่มีบริบท ผู้ใช้เข้าใจว่า AI กำลังดูปฏิทิน แต่ไม่รู้ว่าทำไม เราต้องจับคู่การกระทำกับผลลัพธ์ ระบบจำเป็นต้องแบ่งการรอสี่วินาทีออกเป็นสองขั้นตอนที่แตกต่างกัน ขั้นแรก อินเทอร์เฟซจะแสดงข้อความ “กำลังตรวจสอบปฏิทินของคุณเพื่อค้นหาเวลาเปิด” จากนั้นจะอัปเดตเป็น “กำลังซิงค์กับกำหนดการของผู้ให้บริการเพื่อประกันการนัดหมายของคุณ” นี่เป็นพื้นฐานของกระบวนการทางเทคนิคในชีวิตจริงของผู้ใช้ พิจารณา AI จัดการสินค้าคงคลังสำหรับร้านกาแฟในพื้นที่ ระบบพบปัญหาการขาดแคลนอุปทาน อินเทอร์เฟซที่อ่านว่า "การติดต่อผู้ขาย" หรือ "ตัวเลือกการตรวจสอบ" ทำให้เกิดความวิตกกังวล ผู้จัดการสงสัยว่าระบบกำลังยกเลิกคำสั่งซื้อหรือซื้อทางเลือกอื่นที่มีราคาแพงหรือไม่ แนวทางที่ดีกว่าคือการอธิบายผลลัพธ์ที่ต้องการ: “การประเมินซัพพลายเออร์รายอื่นเพื่อรักษากำหนดการส่งมอบในวันศุกร์ของคุณ” สิ่งนี้จะบอกผู้ใช้อย่างชัดเจนถึงสิ่งที่ AI พยายามทำให้สำเร็จ การปฏิบัติงานตรวจสอบ คุณได้เสร็จสิ้นการตรวจสอบ Decision Node และกรองรายการของคุณผ่านเมทริกซ์ผลกระทบและความเสี่ยง ตอนนี้คุณมีรายการช่วงเวลาสำคัญสำหรับความโปร่งใสแล้ว ถัดไป คุณต้องสร้างสิ่งเหล่านี้ใน UI ขั้นตอนนี้ต้องใช้การทำงานเป็นทีมในแผนกต่างๆ คุณไม่สามารถออกแบบความโปร่งใสได้ด้วยตัวเองโดยใช้เครื่องมือออกแบบ คุณต้องเข้าใจว่าระบบทำงานอย่างไรเบื้องหลัง เริ่มต้นด้วยการทบทวนลอจิก พบกับนักออกแบบระบบหลักของคุณ นำแผนที่โหนดการตัดสินใจของคุณมาด้วย คุณต้องยืนยันว่าระบบสามารถแชร์สถานะเหล่านี้ได้จริง ฉันมักจะพบว่าระบบทางเทคนิคไม่เปิดเผยสถานะที่แน่นอนที่ฉันต้องการแสดง วิศวกรอาจบอกว่าระบบเพิ่งคืนสถานะ "ใช้งานได้" ทั่วไป คุณต้องผลักดันให้มีการอัปเดตโดยละเอียด คุณต้องมีระบบในการส่งประกาศเฉพาะเมื่อเปลี่ยนจากการอ่านข้อความเป็นการตรวจสอบกฎ หากไม่มีการเชื่อมต่อทางเทคนิค การออกแบบของคุณก็ไม่สามารถสร้างขึ้นได้ ถัดไป ให้เกี่ยวข้องกับทีมออกแบบเนื้อหา คุณมีเหตุผลทางเทคนิคสำหรับการดำเนินการของ AI แต่คุณต้องการคำอธิบายที่ชัดเจนและเป็นมิตรต่อมนุษย์ วิศวกรจัดเตรียมกระบวนการพื้นฐาน แต่ผู้ออกแบบเนื้อหาจัดเตรียมวิธีการสื่อสาร อย่าเขียนข้อความเหล่านี้เพียงลำพัง นักพัฒนาอาจเขียนว่า “Executing function 402” ซึ่งมีความถูกต้องทางเทคนิคแต่ไม่มีความหมายต่อผู้ใช้ นักออกแบบอาจเขียนว่า “Thinking” ซึ่งเป็นมิตรแต่คลุมเครือเกินไป นักยุทธศาสตร์ด้านเนื้อหาค้นหาจุดกึ่งกลางที่เหมาะสม พวกเขาสร้างวลีเฉพาะ เช่น “การสแกนหาความเสี่ยงในการรับผิด” ซึ่งแสดงว่า AI กำลังทำงานโดยไม่ทำให้ผู้ใช้สับสน สุดท้าย ทดสอบความโปร่งใสของข้อความของคุณ อย่ารอจนกว่าผลิตภัณฑ์ขั้นสุดท้ายจะถูกสร้างขึ้นเพื่อดูว่าข้อความใช้งานได้หรือไม่ ฉันทำการทดสอบเปรียบเทียบกับต้นแบบอย่างง่าย โดยสิ่งเดียวที่เปลี่ยนแปลงคือข้อความสถานะ ตัวอย่างเช่น ฉันแสดงข้อความกลุ่มหนึ่ง (กลุ่ม A) ที่ระบุว่า “กำลังยืนยันตัวตน” และอีกกลุ่มหนึ่ง (กลุ่ม B) แสดงข้อความว่า “กำลังตรวจสอบฐานข้อมูลของรัฐบาล” (นี่คือตัวอย่างที่สร้างขึ้น แต่คุณเข้าใจประเด็นนี้) จากนั้นฉันก็ถามพวกเขาว่า AI ตัวไหนรู้สึกปลอดภัยกว่า คุณมักจะพบว่าคำบางคำทำให้เกิดความกังวล ในขณะที่คำบางคำสร้างความไว้วางใจ คุณต้องถือว่าถ้อยคำเป็นสิ่งที่คุณต้องการทดสอบและพิสูจน์ว่ามีประสิทธิภาพ สิ่งนี้เปลี่ยนแปลงกระบวนการออกแบบอย่างไร การดำเนินการตรวจสอบเหล่านี้มีศักยภาพในการเสริมสร้างการทำงานร่วมกันเป็นทีม เราหยุดแจกไฟล์การออกแบบที่สวยงาม เราเริ่มใช้ต้นแบบที่ยุ่งเหยิงและสเปรดชีตที่แชร์ เครื่องมือหลักจะกลายเป็นเมทริกซ์ความโปร่งใส วิศวกรและผู้ออกแบบเนื้อหาแก้ไขสเปรดชีตนี้ร่วมกัน พวกเขาจับคู่รหัสทางเทคนิคกับคำที่ผู้ใช้จะอ่าน ทีมจะพบกับความขัดแย้งระหว่างการทบทวนตรรกะ ลองนึกภาพนักออกแบบถามวิศวกรว่า AI ตัดสินใจปฏิเสธธุรกรรมที่ส่งมาในรายงานค่าใช้จ่ายอย่างไร วิศวกรอาจบอกว่าแบ็กเอนด์ส่งออกเฉพาะรหัสสถานะทั่วไป เช่น “ข้อผิดพลาด: ข้อมูลหายไป” ผู้ออกแบบระบุว่านี่ไม่ใช่ข้อมูลที่สามารถดำเนินการได้บนหน้าจอ นักออกแบบจะเจรจากับวิศวกรเพื่อสร้างตะขอทางเทคนิคเฉพาะ วิศวกรเขียนกฎใหม่เพื่อให้ระบบรายงานสิ่งที่ขาดหายไป เช่น รูปภาพใบเสร็จที่หายไป นักออกแบบเนื้อหาทำหน้าที่เป็นนักแปลในช่วงนี้ นักพัฒนาซอฟต์แวร์อาจเขียนสตริงที่มีความแม่นยำทางเทคนิค เช่น “การคำนวณเกณฑ์ความเชื่อมั่นสำหรับการจับคู่ผู้ขาย” ผู้ออกแบบเนื้อหาแปลสตริงนั้นเป็นวลีที่สร้างความไว้วางใจสำหรับผลลัพธ์ที่เฉพาะเจาะจง นักยุทธศาสตร์เขียนใหม่ว่า “การเปรียบเทียบราคาผู้ขายในท้องถิ่นเพื่อรับประกันการจัดส่งในวันศุกร์ของคุณ” ผู้ใช้เข้าใจการกระทำและผลลัพธ์ ทีมงานข้ามสายงานทั้งหมดเข้าร่วมการทดสอบกับผู้ใช้ พวกเขาดูคนจริงตอบสนองต่อข้อความสถานะต่างๆ การเห็นผู้ใช้ตื่นตระหนกเนื่องจากหน้าจอระบุว่า "กำลังดำเนินการซื้อขาย" บังคับให้ทีมต้องคิดใหม่เกี่ยวกับแนวทางของตน วิศวกรและนักออกแบบใช้ถ้อยคำที่ดีกว่า พวกเขาเปลี่ยนข้อความเป็น “ยืนยันเงินทุนเพียงพอ” ก่อนซื้อหุ้น การทดสอบร่วมกันรับประกันว่าอินเทอร์เฟซสุดท้ายจะตอบสนองทั้งตรรกะของระบบและความอุ่นใจของผู้ใช้ ต้องใช้เวลาในการรวมกิจกรรมเพิ่มเติมเหล่านี้ลงในปฏิทินของทีม อย่างไรก็ตาม ผลลัพธ์สุดท้ายควรเป็นทีมที่สื่อสารอย่างเปิดเผยมากขึ้นและผู้ใช้ที่มีความเข้าใจที่ดีขึ้นว่าเครื่องมือที่ขับเคลื่อนด้วย AI ของพวกเขากำลังทำอะไรในนามของพวกเขา (และทำไม) แนวทางบูรณาการนี้เป็นรากฐานสำคัญของการออกแบบประสบการณ์ AI ที่น่าเชื่อถืออย่างแท้จริง ความไว้วางใจคือทางเลือกในการออกแบบ เรามักมองว่าความไว้วางใจเป็นผลพลอยได้ทางอารมณ์จากประสบการณ์ผู้ใช้ที่ดี ง่ายกว่าที่จะมองว่าความไว้วางใจเป็นผลทางกลไกของการสื่อสารที่คาดเดาได้ เราสร้างความไว้วางใจด้วยการแสดงข้อมูลที่ถูกต้องในเวลาที่เหมาะสม เราทำลายมันโดยการครอบงำผู้ใช้หรือซ่อนเครื่องจักรไว้อย่างสมบูรณ์ เริ่มต้นด้วยการตรวจสอบโหนดการตัดสินใจ โดยเฉพาะอย่างยิ่งสำหรับเครื่องมือและผลิตภัณฑ์ AI แบบตัวแทน ค้นหาช่วงเวลาที่ระบบทำการตัดสิน แมปช่วงเวลาเหล่านั้นกับเมทริกซ์ความเสี่ยง หากเดิมพันสูง ให้เปิดกล่อง แสดงผลงาน. ในบทความถัดไป เราจะดูวิธีการออกแบบช่วงเวลาเหล่านี้: วิธีเขียนสำเนา จัดโครงสร้าง UI และจัดการกับข้อผิดพลาดที่หลีกเลี่ยงไม่ได้เมื่อตัวแทนทำผิด ภาคผนวก: รายการตรวจสอบการตรวจสอบโหนดการตัดสินใจ ขั้นตอนที่ 1: การตั้งค่าและการแมป ✅ รวมทีม: ดึงเจ้าของผลิตภัณฑ์ นักวิเคราะห์ธุรกิจ นักออกแบบผู้มีอำนาจตัดสินใจคนสำคัญ และวิศวกรที่สร้าง AI คำแนะนำ: คุณต้องให้วิศวกรอธิบายตรรกะแบ็กเอนด์ที่แท้จริง อย่าพยายามขั้นตอนนี้เพียงอย่างเดียว ✅ วาดกระบวนการทั้งหมด: บันทึกทุกขั้นตอนที่ AI ทำ ตั้งแต่การกระทำครั้งแรกของผู้ใช้ไปจนถึงผลลัพธ์สุดท้าย คำแนะนำ: เซสชั่นไวท์บอร์ดจริงมักจะทำงานได้ดีที่สุดในการสรุปขั้นตอนเริ่มต้นเหล่านี้ ขั้นตอนที่ 2: การค้นหาลอจิกที่ซ่อนอยู่ ✅ ค้นหาสิ่งที่ไม่ชัดเจน: ดูแผนผังกระบวนการเพื่อหาจุดที่ AI เปรียบเทียบตัวเลือกหรืออินพุตที่ไม่มีคู่ที่ตรงกัน ✅ ระบุขั้นตอนการเดาที่ดีที่สุด: สำหรับแต่ละจุดที่ไม่ชัดเจน ตรวจสอบว่าระบบใช้คะแนนความเชื่อมั่นหรือไม่ เช่น ถามว่าระบบมั่นใจ 85 เปอร์เซ็นต์หรือไม่ นี่คือจุดที่ AI ตัดสินใจขั้นสุดท้าย ✅ ตรวจสอบตัวเลือก: สำหรับแต่ละจุดตัวเลือก ให้ค้นหาคณิตศาสตร์ภายในเฉพาะหรือการเปรียบเทียบที่กำลังทำอยู่ ตัวอย่างคือการจับคู่ส่วนหนึ่งของสัญญากับนโยบาย อีกตัวอย่างหนึ่งเกี่ยวข้องกับการเปรียบเทียบภาพรถที่เสียหายกับคลังภาพถ่ายรถที่เสียหาย ขั้นตอนที่ 3: การสร้างประสบการณ์ผู้ใช้ ✅ เขียนคำอธิบายที่ชัดเจน: สร้างข้อความสำหรับผู้ใช้ที่อธิบายการกระทำภายในเฉพาะที่เกิดขึ้นเมื่อ AI ตัดสินใจอย่างชัดเจน คำแนะนำ: วางข้อความของคุณในความเป็นจริงที่เป็นรูปธรรม หาก AI จองการประชุมกับลูกค้าที่ร้านกาแฟในพื้นที่ ให้บอกผู้ใช้ว่าระบบกำลังตรวจสอบระบบการจองร้านกาแฟ ✅ อัปเดตหน้าจอ: ใส่คำอธิบายใหม่ที่ชัดเจนเหล่านี้ลงในอินเทอร์เฟซผู้ใช้ แทนที่ข้อความที่คลุมเครือ เช่น การทบทวนสัญญาด้วยคำอธิบายเฉพาะของคุณ ✅ ตรวจสอบความน่าเชื่อถือ: ตรวจสอบให้แน่ใจว่าข้อความบนหน้าจอใหม่ให้เหตุผลง่ายๆ แก่ผู้ใช้เกี่ยวกับเวลารอหรือผลลัพธ์ สิ่งนี้ควรทำให้พวกเขารู้สึกมั่นใจและไว้วางใจ คำแนะนำ: ทดสอบข้อความเหล่านี้กับผู้ใช้จริงเพื่อยืนยันว่าพวกเขาเข้าใจผลลัพธ์ที่เฉพาะเจาะจงที่กำลังได้รับ
