สองตัวชี้วัดที่เป็นที่รู้จักกันทั่วไปในแวดวง HCI คือ user performance (speed & errors) และ user satisfaction

user performance นั่นเป็นการวัดในเชิงปริมาณ ส่วน user satisfaction เป็นการวัดเชิงคุณภาพค่ะ

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

อย่างที่ทุกท่านได้ทราบมาโดยตลอดว่า KnowledgeVolution ระบบ KM ที่เราพัฒนาขึ้นและได้ติดตั้งในหลายเว็บไซต์ ได้แก่ GotoKnow.org, Learners.in.th, Researchers.in.th พัฒนาขึ้นโดยพื้นฐานที่เน้นผู้ใช้เป็นศูนย์กลาง ซึ่งหมายความว่า features ต่างๆ เป็นที่ต้องการของผู้ใช้ ผู้ใช้เห็นประโยชน์ และผู้ใช้รู้สึกว่าใช้งานได้ง่าย และด้วยสิ่งต่างๆ เหล่านี้เป็นส่วนหนึ่งที่ทำให้จำนวนผู้ใช้ GotoKnow.org เพิ่มขึ้นอย่างรวดเร็วในหนึ่งปีที่ผ่านมา

จนกระทั่ง GotoKnow มาถึงปัญหาคอขวด คือ ศักยภาพของเครื่องแม่ข่ายที่ไม่สามารถรองรับจำนวนผู้ใช้ได้พร้อมกันจำนวนมากๆ จึงทำให้ระบบช้าอย่างมาก แต่ด้วยการติดบล็อก ก็จะมีผู้ใช้จำนวนหนึ่งพยายามใช้อย่างทรมานหัวใจ รวมทั้งตัวดิฉันเองด้วย และด้วยความช้าของระบบทำให้เกิด errors ขึ้นหลายครั้งเมื่อทำการบันทึกลงบล็อก หรือบางครั้งก็เกิดขึ้นกับส่วนอื่นๆ ด้วยเช่นกัน

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

ดิฉันมานั่งคิดว่า ถ้าระบบเป็นระบบที่ใช้งานได้ยากตั้งแต่แรกเริ่ม ซึ่งหมายถึง ออกแบบมาโดยไม่สนใจผู้ใช้เลย  แม้จะไม่มีปัญหาความช้าใดๆ เลยก็ตาม ดิฉันก็คิดว่า ระบบจะไม่สามารถประสบความสำเร็จได้ เพราะ developer model กับ user model  จะขัดแย้งกันอย่างสุดขั้ว พาลทำให้เกิด errors ในการใช้งานบ่อยครั้ง ยกเว้นระบบเล็กๆ และระบบที่ผู้ใช้ถูกบังคับให้ใช้ตามสายงานนะค่ะ

สรุปแล้ว lessons learned ที่ดิฉันได้รับจากการพัฒนาระบบ KnowledgeVolution คือ ต้อง balance goals ทั้งสองอย่างให้ดีค่ะ ทั้ง user performance และ user satisfaction