ตอนที่ 8 สื่อสารกับผู้ใช้

ตอนที่ 8 สื่อสารกับผู้ใช้

ถ้าโปรแกรมที่ออกแบบมาไม่สอดคล้องกับความเข้าใจของผู้ใช้ ขอให้กลับไปดูว่าเรามัวกังวลเรื่อง feature หรือเปล่า สิ่งที่เราจะต้องใส่ลงไปในโปรแกรมคือ solution ไม่ใช่ feature เพราะสิ่งที่ผู้ใช้ 80% ต้องการคือสิ่งที่เป็นตัวหลักของโปรแกรม ไม่ใช่ feature ถ้าโปรแกรมของเราเต็มไปด้วย feature มันยิ่งจะทำให้ผู้ใช้สับสนว่าจริงๆ แล้วโปรแกรมของเราเข้ามาช่วยลูกค้าแก้ปัญหาอะไร เช่น โปรแกรมสำหรับ ftp ควรจะเป็นโปรแกรมที่ส่งไฟล์หรืออ่านไฟล์ที่ server ได้ง่ายที่สุด การที่เราใส่ text editor ลงไปในโปรแกรม ftp อาจจะเป็นเรื่องดีเพราะมีคนต้องการ แต่ถ้าโปรแกรมนั้นทำให้ขั้นตอนของการใช้งานยุ่งยากขึ้นหรือ ทำให้หน้าจอดูสับสน เราควรจะพิจารณาใหม่ เพราะผู้ใช้ 80% ไม่ได้ใช้ feature “text editor”

การสื่อสารกับผู้ใช้ มีสิ่งที่ต้องคำนึงถึงดังนี้

• Parallel with good human interactions ระหว่างที่ผู้ใช้กำลังใช้งานโปรแกรมของเรา โปรแกรมควรที่จะสื่อสารกับผู้ใช้อยู่ตลอดเวลา เช่นระหว่างการ search บนหน้าจอควรมี icon ที่เคลื่อนไหวเพื่อบอกกับผู้ใช้ว่า “ฉันกำลังพยายามอย่างเต็มที่เพื่อคนหาข้อมูลให้คุณ” อาจเป็น icon เล็กๆ หรือเป็น progress bar ก็ยังดีกว่าการนิ่งไปเฉยๆ เพราะนั่นคือการปลอยให้ผู้ใช้เดาเอาเองว่าโปรแกรมพังไปแล้ว หรือว่าผู้ใช้ยังไม่ได้สั่งงาน

• Be non-intrusive, non-interruptive เช่น error message ของ safari ก่อนหน้านี้ทุกครั้งที่มี error มันจะแสดงหน้าต่างขึ้นมาแจ้งปัญหา และมีปุ่ม OK ให้เรากดเพื่อรับทราบ มันขัดจังหวะการใช้งานมากๆ ครับ เมื่อผมทราบในสิ่งที่ผิด สิ่งที่ผมต้องการทำต่อคือการแก้ไขความผิดพลาด แต่โปรแกรมดันขึ้นมาขัดจังหวะโดยการให้ผมกด OK ก่อนทั้งๆ ที่การกด OK ของผม ไม่ได้มีผลอะไรกับโปรแกรมเลย ตอนนี้ดีแล้วครับที่เค้าปรับปรุงให้ไม่มีหน้าแต่งแจ้งความผิดพลาดขึ้นมา แต่จะแสดงความผิดพลาดลงไปบนหน้าจอ ให้เรารับทราบอย่างเดียว ลดขั้นตอนไปได้อีกหนึ่งขั้นตอน สำหรับนักออกแบบทุกคนอย่าคิดว่านี่เป็นแค่ขั้นตอนเดียวลูกค้าน่าจะรับได้ ลองนึกถึงว่าลูกค้าต้องใช้โปรแกรมนี้ทั้งวัน เข้าจะต้องกด OK กี่รอบ

• Only communicate status that matters ไม่ต้องแสดงสถานะไปซะทุกอย่างครับ เพราะอย่าลืมว่าทุกข้อความที่แสดงบนหน้าจอ ผู้ใช้จะต้องใช้สมองในการทำความเข้าใจ และถ้ามันมันหลายอย่าง สุดท้ายเค้าจะไม่พยายามทำความเข้าใจกับอะไรเลย ทำให้การสื่อสารกับผู้ใช้ล้มเหลว นอกจากนี้พยายามให้ข้อความแสดงสถานะอยู่ที่เดียวกันตลอดผู้ใช้จะได้ไม่ต้องหา

ในตอนนี้เราจะพูดถึงสองเรื่องสุดท้าย คือการสื่อสารผ่าน error message เราควรแสดง error ครับ แต่ไม่ใช่แบบนี้แน่นอน

หรือแบบนี้

การที่บอกผู้ใช้ว่า feedbag error 0 ไม่ได้ช่วยให้ชีวิตของผู้ใช้ดีขึ้นเลยครับ ไม่บอกน่าจะดีกว่า อย่างน้อยก็อ่านน้อยลง (และต้องตรวจสอบคำผิดด้วย อันนี้โดน… ใน blog ผมก็นั่งแก้คำผิดในกระทู้เก่าๆ อยู่เหมือนกัน)

ลองมาดูอีก error นึงครับ error อันนี้เกิดขึ้นตอนที่ drag รูปต้นฉบับจากด้านซ้ายมือมาใส่โปรแกรมด้านขวามือแล้ว แล้วโปรแกรมแจ้ง error ว่าไฟล์ของรูปใหญ่เกินไป

ผมแค่ต้องการเลือกรูปมาใส่ในโปรแกรม และผมไม่ต้องการ Extend ไม่ได้ต้องการ crop เพราะไม่รู้ว่าจะมีผลกับรูปต้นฉบับของผมหรือเปล่า แล้วก็ไม่รู้ว่าเมื่อกด Distort แล้วโปรแกรมจะทำอะไร ที่สำคัญคือผมเลือกได้แค่ 3 อย่าง!! ซวยเลยทีนี้ cancel ก็ไม่ได้ด้วย

error message ควรบอกปัญหาที่เกิดขึ้น และอย่าให้มีตัวเลือกที่น่าสงสัยเกิดขึ้น วิธีการรายงานปัญหาที่เกิดขึ้นให้มีประโยชน์สูงสุดควรบอกตามลำดับดังนี้

• เกิดอะไรขึ้น
• เกิดขึ้นเพราะอะไร
• จะแก้ปัญหาได้อย่างไร

หลีกเลี่ยงปุ่ม Yes/No เพราะผู้ใช้จะสับสนไม่รู้ว่าควรทำอะไร ให้เราดูว่า error ที่เราเขียนมี keyword อะไร แล้วใช้ keyword นั้นในปุ่มที่จะให้ผู้ใช้กด แบบนี้จะเข้าใจง่ายกว่าเพราะผู้ใช้พยายามหาทางแก้ปัญหาจากข้อความของเราอยู่แล้ว

ดู error อันตอนไปนะครับ

error อันนี้ดูเหมือนจะดีเพราะอ่านรู้เรื่อง แต่ไม่ได้บอกสาเหตุของปัญหา

อันนี้ปรับปรุงขึ้น โดยบอกปัญหาและสาเหตุ แต่ก็จังไม่ได้บอกทางแก้ให้กับผู้ใช้

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

The document “Trip Request” could not be saved บอกว่าเกิดอะไรขึ้น โดยระบุให้ชัดเจนว่าเกิดที่เอกสาร Trip Request

because the disk “Work Stuff” is full. เกิดขึ้นเพราะ disk เต็ม และรบุไปเลยว่า disk ที่ชื่อ Work Stuff เต็ม

Try deleting document from “Work Stuff” or saving the document on another disk ชี้ทางสว่างให้กับผู้ใช้ว่าควรแก้ปัญหาที่เกิดขึ้นอย่างไร

สิ่งเหล่านี้จะเพิ่มงานให้กับนักพัฒนาโปรแกรมแต่ขอบอกเลยครับ ว่ามันจะสร้างประสบการณ์ที่ดีให้กับผู้ใช้(ลูกค้า) ของโปรแกรมของเรา

สุดท้ายให้เราพยายามป้องกันก่อนที่ปัญหาจะเกิด

ตัวอย่างนี้บอกว่า “เราไม่สามารถ print ได้ถ้ายังไม่ได้เลือก student ซักคน” วิธีที่ดีกว่าการทำ error message คือการปิดไม่ให้ผู้ใช้ click ปุ่ม print ก็จะไม่มี error เกิดขึ้นครับ และผู้ใช้ไม่ต้องเสียเวลาอ่าน error ด้วย

เรื่อง feedback เป็นเรื่องสำคัญที่นักพัฒนาโปรแกรมควรจะให้ความสำคัญ ไม่เฉพาะเจาะจงว่าต้องเป็นบน OS X เท่านั้น เราควรให้ความสำคัญกับโปรแกรมของเราในทุก platform แม้แต่บน web ก็ตาม