Sense of query, Tense of data

"ตอบไม่ตรงคำถามหรือถามไม่ตรงคำตอบ ความคาดหวังของผู้ใช้กับสิ่งที่โปรแกรมตอบ"
 
ผมตั้งใจออกแบบโปรแกรม ที่เริ่มต้นด้วยหน้าจอว่างเปล่า ไม่มีเมนูอย่างที่คุ้นเคย มีแค่กล่องค้นหาอยู่ด้านบนของจอ ให้ความรู้สึกไม่ต่างจากเพจ google.com
 
หลายปีก่อนผมทดลองเปลี่ยนความเคยชินของผู้ใช้โปรแกรมบัญชี จากเดิมที่ต้องทำงานผ่านเมนู อยากจะทำอะไรหรือค้นหาอะไรก็ต้องเข้าไปในเมนูของระบบนั้นๆ เปลี่ยนเป็นคำแนะนำสั้นๆ ว่า "อยากทำอะไร ก็สั่งผ่านกล่องค้นหา"
 
ในแง่ของการออกแบบ User Interface (UI) เป็นการตัดขั้นตอนกระบวนการเรียนรู้ของผู้ใช้ที่จะต้องจดจำว่าเรื่องอะไรอยู่ตรงไหน มีเส้นทางที่ต้องผ่านเมนูแต่ละชั้นไปอย่างไร ในแง่ของคนทำโปรแกรมเป็นการตัดความซับซ้อนของการจัดหมวดหมู่การทำงาน ภายใต้โครงสร้างเมนูออกไปด้วย แต่เบื้องหลังกว่าจะทำให้ผู้ใช้รู้สึกว่าสะดวกเป็นอย่างไร ผมจะเล่าให้ฟัง
 
"ถามอะไรมาก็ไปค้นให้หมด" รุ่นแรกที่ทำออกมาเป็นอะไรประมาณนั้น ทุกคำถามเป็นยูนิเวอร์แซล เอาคำค้นวิ่งไปหาข้อมูลทุกอย่างในดาต้าเบส ไม่ว่าจะเป็น สินค้า, ลูกค้า, บิล ฯลฯ เจอตรงไหนก็เอามาแสดง ง่ายดี ผู้ใช้ก็ถูกใจเพราะเอาคำตอบจากทุกระบบมากองให้เห็น ไม่เคยเจอมาก่อน
 
เช่น ค้นหาคำว่า "การไฟฟ้า" ก็จะเจอใบเสนอราคา, ใบส่งสินค้า, ใบกำกับภาษี, บิลค่าใช้จ่าย, ข้อมูลลูกค้า ฯลฯ ที่มีคำนี้ขึ้นมาให้ แล้วอยากทำอะไรต่อไปกับข้อมูลไหน ก็เลือกได้เลย จนกระทั่งเจอการใช้งานจริง เมื่อมากกว่า 50 คนใช้งานพร้อมๆ กัน ดาต้าเบสเริ่มทำงานไม่ทัน ตอบได้บ้าง ไม่ได้บ้าง ไม่เหมือนกับที่เคยทดสอบและลองใช้งานในกิจการขนาดเล็ก
 

"เลือกค้นเฉพาะข้อมูลที่ใช้บ่อย" เป็นการปรับปรุงวิธีค้นข้อมูลรุ่นต่อไป เริ่มคำนึงถึงภาระการทำงานของดาต้าเบสด้วย ปรับปรุงให้ค้นเฉพาะข้อมูลที่คาดว่าน่าจะใช้บ่อยๆ ได้แก่ เอกสารขาย, ลูกค้า และสินค้า ส่วนข้อมูลอื่น ทำเป็นตัวเลือกให้สั่งค้นเพิ่มได้
 
ทุกวันโปรแกรมจะมี log ที่บันทึกคำค้นที่ใช้เวลานานให้ตรวจสอบ เพื่อทำความเข้าใจความต้องการของผู้ใช้
 
ครั้งหนึ่งพบว่ามีการค้นหาโดยใช้เลขชุด 4 ตัว เช่น 0135 จากผู้ใช้รายหนึ่ง และโปรแกรมก็บันทึก long search มาจำนวนมากจนผิดสังเกต เมื่อตรวจสอบอย่างละเอียดจึงได้คำตอบว่า มีเอกสารที่ต้องตรวจสอบจึงใช้วิธีค้นหาโดยป้อนแค่เลข 4 ตัวท้ายของเอกสาร
 
เคสนี้ทำให้ผมเริ่มตระหนักถึงคำว่า "ความคาดหวังของผู้ใช้" จนกลายเป็นหลักคิดสำคัญในเวลาต่อมา โปรแกรมที่ดีในสายตาของผู้ใช้คือโปรแกรมที่รู้ใจ และการทำโปรแกรมให้รู้ใจคือตอบสนองให้ตรงกับความคาดหวัง
 
โปรแกรมถูกปรับปรุงอีกครั้ง ให้ทำนายคำตอบที่คาดหวังโดยพิจารณาจากคำค้นก่อน ไม่ได้ตะลุยหาทุกคำตอบจากทุกที่เหมือนเดิม ถ้าเป็นเลขชุด 3 ตัวขึ้นไป มีโอกาสที่เป็นเลขที่เอกสาร มากกว่าชื่อลูกค้าหรือสินค้า ถ้าข้อความมีเคาะวรรค หรือเป็นตัวอักษรมากกว่าตัวเลข หรือไม่ได้ลงท้ายด้วยตัวเลข ก็จะมีโอกาสที่จะหาชื่อลูกค้าหรือสินค้า ไม่ใช่เลขเอกสารแน่ๆ การใช้งานที่ยาวนาน ข้อมูลสะสมมีจำนวนมาก ดาต้าเบสมีขนาดใหญ่ขึ้น มีกรณีของคำค้นที่หาไม่พบ หรือได้คำตอบไม่ครบตามเป้าหมายที่ต้องการแสดง ภาระของการค้นหาไปจนสุดทางทุกครั้ง กลายเป็นราคาที่ต้องจ่ายแพงขึ้น ใช้เวลานานขึ้น
 
บทเรียนที่ได้เรียนรู้เมื่อดาต้าเบสมีการสะสมข้อมูลยาวนาน คือ "กาละของข้อมูล"​ เมื่อคุณเก็บข้อมูลไว้ในดาต้าเบส มันจะอยู่ตรงนั้นไม่เคยหายไปไหน ไม่เหมือนกับความจำของคนที่อาจลืมเรื่องราวเก่าๆ ที่ผ่านไปนาน เมื่อคนสั่งให้ค้นหาเพื่อใช้ทำงาน เขาต้องการคำตอบที่เป็น "ข้อมูลปัจจุบัน" หรือต้องการ "ข้อมูลเก่า" ที่นานมาแล้ว เป็นคำถามที่ต้องครุ่นคิด ระหว่างการใช้เวลาค้นหานานจนเจอ กับการหยุดค้นหาแต่เนิ่นๆ แล้วตอบว่าไม่เจอข้อมูล อย่างไหนจะรู้สึกดีกว่ากัน เป็นการคาดเดาความคาดหวังของผู้ใช้ที่ซับซ้อน
 
ในการออกแบบจริง ผมเริ่มจากนิยามของคำว่า "ปัจจุบันและอดีต" แยกข้อมูลที่กำลังใช้งาน กับข้อมูลเก่าที่นานๆ ใช้ และจำกัดขอบเขตการค้นหาข้อมูลภายในเวลาปัจจุบัน จนได้ตัวเลขที่เหมาะสมอยู่ที่ 3 เดือนล่าสุด ทำให้การค้นหาใช้เวลาไม่เกิน 5 วินาที เพื่อให้ได้คำตอบที่ผู้ใช้ส่วนใหญ่คาดหวังภายในเวลารวดเร็ว สำหรับผู้ที่ต้องการค้นหาย้อนหลังยาวนานกว่านั้น ก็มีทางเลือกให้สั่งค้นหาแบบละเอียด ซึ่งจะยอมรับความยาวนานในการค้นหาว่านานกว่าปกติ
 
นี่คือเรื่องราวบางส่วนเกี่ยวกับการออกแบบเล็กๆ น้อยๆ ผมโชคดีที่มีโอกาสอยู่กับโปรแกรมนี้ได้ยาวนาน เพราะมีผู้ใช้ที่หลากหลายจำนวนมากพอ คุ้มค่าที่จะทุ่มเทใส่ใจแง่มุมเล็กๆ น้อยๆ ปรับปรุงให้เก่งขึ้น ฉลาดขึ้น รู้ใจมากขึ้น ตามวันเวลาที่ผ่านไป
 
ไม่น่าเชื่อว่าจากกล่องค้นหากล่องเดียว จะมีเรื่องให้คิดให้ทำมากมายขนาดนี้
 

July 2022 / Sathit J.