เริ่มจากผลลัพธ์ที่ต้องแยก
เขียนปลายทางก่อน เช่น แก้ไขแล้ว ขอข้อมูลเพิ่ม หรือส่งต่อ Incident จากนั้นถามว่าข้อมูลใดทำให้เลือกปลายทางเหล่านี้ได้ วิธีนี้ลดคำถามที่น่าสนใจแต่ไม่ได้เปลี่ยนการตัดสินใจ
ผลลัพธ์ควรทำต่อได้ ไม่ใช้คำกว้างอย่าง ผ่าน หรือ ไม่ผ่าน เพียงลำพัง ให้บอกว่าจะปิดเรื่อง ส่งต่อทีมใด หรือขอหลักฐานอะไร
เขียนคำถามที่ผู้ใช้ตอบจากหลักฐานได้
คำถามที่ดีอ้างถึงสิ่งสังเกตได้ เช่น ปัญหาเกิดกับผู้ใช้อื่นด้วยหรือไม่ แทน ระบบฐานข้อมูลล่มหรือไม่ ซึ่งผู้ใช้ทั่วไปตอบไม่ได้ จัดคำถามที่ปลอดภัยและตรวจง่ายไว้ก่อนการตรวจที่มีต้นทุนสูง
ตัวเลือกในระดับเดียวกันต้องไม่ทับซ้อน ถ้ามี อื่น ๆ ให้ระบุว่าพาไปเก็บข้อมูลเพิ่ม ไม่ควรใช้เป็นถังรวมที่ไม่มีเจ้าของ
- หนึ่ง Decision ถามหนึ่งเรื่อง
- ตัวเลือกใช้เกณฑ์เดียวกัน
- ทุกตัวเลือกมีเส้นทาง
- มีทางออกเมื่อข้อมูลไม่พอ
ควบคุมความลึกและการย้อนกลับ
ต้นไม้ที่ลึกมากทำให้ผู้อ่านจำบริบทไม่ได้ ให้แยก Hub ตามกลุ่มปัญหาและตั้ง Breadcrumb ที่อ่านรู้เรื่อง การย้อนกลับไปลองใหม่ทำได้ แต่ต้องมีเงื่อนไขหยุด เช่น จำนวนครั้งหรือการเปลี่ยนข้อมูล มิฉะนั้นจะกลายเป็น Cycle ที่คนติดอยู่
ถ้าหลายสาขากลับมาทำขั้นตอนเดียวกัน ให้รวมที่ Node เดียวแทนการคัดลอกคำอธิบายหลายชุด ช่วยลดข้อมูลไม่ตรงกันเมื่อแก้ไขภายหลัง
ทดสอบด้วย Case จริงและ Case ขอบ
นำ Ticket หรือเหตุการณ์ที่ปิดแล้วมาเดินตาม Tree โดยไม่ข้ามคำถาม ตรวจว่าเส้นทางให้ผลลัพธ์เดียวกับหลักฐานจริง จากนั้นลองกรณีไม่รู้คำตอบ ข้อมูลขัดแย้ง และไม่มีเจ้าหน้าที่พร้อม เพื่อดูว่า Tree ยังพาไปจุดปลอดภัยได้หรือไม่
Validator ช่วยค้นหา Node ที่ขาดการเชื่อมและตัวเลือกไม่มี Handle แต่คุณภาพของคำถามต้องใช้ผู้เชี่ยวชาญงานและผู้ใช้จริงทบทวน
- ทดสอบกรณีปกติ
- ทดสอบทุกผลลัพธ์ปลายทาง
- ทดสอบข้อมูลไม่ครบ
- บันทึกสาขาที่ทำให้ผู้ใช้ต้องเดาแล้วแก้คำถาม