กฎทองของการออกแบบอินเทอร์เฟซ (2013)

 (cs.umd.edu)
4 คะแนน โดย GN⁺ 2024-01-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลักการออกแบบอินเทอร์เฟซ 8 ข้อ ของ Ben Shneiderman เป็นเกณฑ์เชิงปฏิบัติที่ใช้ได้กับระบบโต้ตอบส่วนใหญ่ แต่ในแต่ละขอบเขตการออกแบบจำเป็นต้องมีการตรวจสอบและปรับให้เหมาะสม
  • คำศัพท์และพฤติกรรมที่สอดคล้องกัน การใช้งานได้อย่างทั่วถึง และ feedback ที่ให้ข้อมูล เป็นเงื่อนไขพื้นฐานที่ทำให้ผู้ใช้คาดการณ์และเข้าใจ การเปลี่ยนแปลงสถานะ ได้
  • workflow ควรถูกจัดกลุ่มเป็นหน่วยที่มีจุดเริ่มต้น กลางทาง และจุดสิ้นสุด และเมื่อเสร็จสิ้นควรมีการยืนยันที่ชัดเจน เพื่อให้ผู้ใช้ก้าวไปสู่การกระทำถัดไปได้ง่าย
  • ควรให้ความสำคัญกับการป้องกันข้อผิดพลาดเป็นอันดับแรก และเมื่อเกิดขึ้นแล้ว ควรลดความกังวลของผู้ใช้ด้วย คำแนะนำการกู้คืนที่เฉพาะเจาะจง และการย้อนกลับที่ทำได้ง่าย
  • หากวางความรู้สึกในการควบคุมและภาระความจำที่ต่ำไว้เป็นศูนย์กลาง จะช่วยเพิ่มผลิตภาพและความรู้สึกชำนาญในการใช้งานบนอินเทอร์เฟซมือถือ เดสก์ท็อป และเว็บได้

ลักษณะของหลักการและขอบเขตการใช้งาน

  • Ben Shneiderman ได้สรุปองค์ความรู้จำนวนมากด้านการออกแบบ user interface ให้เหลือเป็น Golden Rules ไม่กี่ข้อ เพื่อเป็นแนวทางที่ใช้ได้กับระบบโต้ตอบส่วนใหญ่
  • หลักการเหล่านี้มาจากประสบการณ์และได้รับการขัดเกลามากว่า 30 ปี แต่ในขอบเขตการออกแบบเฉพาะบางด้านยังจำเป็นต้องมี การตรวจสอบและปรับให้เหมาะสม แยกต่างหาก
  • รายการฉบับแรกในปี 1985 ก็ได้รับการยอมรับว่าเป็นแนวทางที่เป็นประโยชน์สำหรับนักศึกษาและนักออกแบบ และ Jakob Nielsen, Jeff Johnson และคนอื่น ๆ ได้เพิ่มการดัดแปลงและขยายต่อยอด
  • เวอร์ชันนี้เป็นเนื้อหาที่อยู่ในหัวข้อ 3.3.4 ของ Designing the User Interface: Strategies for Effective Human-Computer Interaction: Sixth Edition

กฎทอง 8 ข้อของการออกแบบอินเทอร์เฟซ

  • มุ่งสู่ความสอดคล้อง

    • ในสถานการณ์ที่คล้ายกัน จำเป็นต้องมีลำดับการกระทำที่สอดคล้องกัน
    • ควรใช้คำศัพท์เดียวกันใน prompt, menu และหน้าจอช่วยเหลือ
    • สี layout การใช้อักษรตัวใหญ่ และฟอนต์ก็ควรสอดคล้องกันโดยรวม
    • ข้อยกเว้น เช่น การยืนยันคำสั่งลบ หรือการไม่แสดงผลเมื่อป้อนรหัสผ่าน ควรเข้าใจได้และมีขอบเขตจำกัด

  • มุ่งสู่การใช้งานได้อย่างทั่วถึง

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

  • ให้ feedback ที่มีข้อมูล

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

  • ออกแบบบทสนทนาให้เกิดความรู้สึกเสร็จสมบูรณ์

    • ลำดับงานควรถูกจัดเป็นกลุ่มที่มีจุดเริ่มต้น กลางทาง และจุดสิ้นสุด
    • feedback ที่ให้ข้อมูลเมื่อกลุ่มงานหนึ่งเสร็จสิ้น จะให้ความรู้สึกสำเร็จ ความโล่งใจ และสัญญาณเตรียมพร้อมสำหรับงานถัดไป
    • ตัวอย่างในเว็บไซต์ e-commerce คือ flow ที่ย้ายจากการเลือกสินค้าไปสู่การชำระเงิน และปิดธุรกรรมด้วยหน้ายืนยันที่ชัดเจน

  • ป้องกันข้อผิดพลาด

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

  • อนุญาตให้ย้อนกลับได้ง่าย

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

  • รักษาให้ผู้ใช้มีสิทธิ์ควบคุม

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

  • ลดภาระของความจำระยะสั้น

    • ความสามารถในการประมวลผลข้อมูลของความจำระยะสั้นของมนุษย์มีจำกัด และตามหลักคร่าว ๆ เราจำได้ประมาณ “7±2 chunks”
    • ควรหลีกเลี่ยงอินเทอร์เฟซที่บังคับให้ผู้ใช้จำข้อมูลจากหน้าจอหนึ่งแล้วนำไปใช้ในอีกหน้าจอหนึ่ง
    • โทรศัพท์มือถือไม่ควรขอให้ป้อนหมายเลขโทรศัพท์ซ้ำ ตำแหน่งในเว็บไซต์ควรถูกแสดงไว้อย่างต่อเนื่อง และแบบฟอร์มยาว ๆ ควรถูกย่อให้พอดีกับหน้าจอเดียว

เกณฑ์เชิงปฏิบัติที่นักออกแบบได้รับ

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-11
ความคิดเห็นจาก Hacker News

  • แม้มักไม่ถูกมองว่าเป็นส่วนหนึ่งของ “การออกแบบ” UI แต่ ประสิทธิภาพ ก็เป็นสิ่งที่ถูกมองข้ามบ่อยเช่นกัน
    UI ที่ประสิทธิภาพแย่ก็เท่ากับละเมิดกฎการออกแบบเหล่านี้ทั้งหมด สมาร์ตทีวี Sony Android ของผมดูดีมาก แต่ UI ช้ามากจนแทบใช้งานจริงไม่ได้
    UI ที่ไม่เสถียรและเปลี่ยนไปเรื่อย ๆ ก็ละเมิดหลักการส่วนใหญ่เช่นกัน สมาร์ตทีวีแย่เป็นพิเศษในจุดนี้ด้วย เพราะเลย์เอาต์หน้าจอหลักและตำแหน่งไอคอนแอปเปลี่ยนบ่อยโดยแทบไม่มีเหตุผล
    อีกเรื่องที่เป็นความหงุดหงิดส่วนตัวและยิ่งหนักขึ้นเรื่อย ๆ คือ ไอคอนที่ไม่มีป้ายกำกับ บ่อยครั้งไม่มีแม้แต่ tooltip และถ้าต้องไปกูเกิลหาเอกสารเพื่อรู้ว่าปุ่มนั้นชื่ออะไร ก็แปลว่า UI นั้นออกแบบได้แย่

    • หลังจาก Snapchat ฮิตมาก ผมก็เริ่มคิดว่า UI แย่ ๆ คือฟีเจอร์สำหรับ Gen Z
      คนรุ่นใหม่แห่กันไปใช้อินเทอร์เฟซที่ใช้งานยาก และความเข้าใจยากนั้นทำหน้าที่เหมือนฟีเจอร์วงในที่กันรุ่นพ่อแม่ออกไป
    • ประสิทธิภาพเป็นส่วนหนึ่งของการออกแบบ
      นักออกแบบที่ดีจะคุยกับนักพัฒนาว่า UI ที่ตนเสนอกระทบต่อประสิทธิภาพอย่างไร และช่วยประนีประนอมเมื่อฝ่ายวิศวกรรมต้องตัดสินใจทางเทคนิคที่ผู้ใช้มองเห็นได้
    • ในแง่ของ ไอคอนที่ไม่มีป้ายกำกับ ซอฟต์แวร์ที่แย่ที่สุดที่ผมเคยใช้คือ CATIA V5
      ไม่ใช่แค่มีไอคอนเล็ก ๆ หลายร้อยอันใน UI เท่านั้น แต่ในเอกสารก็ใช้ไอคอนเหล่านั้นตรง ๆ ด้วย คู่มือเป็นแนว “ก่อนอื่นคลิก [] จากนั้นกด [] แล้วสุดท้ายไปที่ [] เพื่อทำ []”
      นี่เป็นเรื่องของ V5 รุ่นแรก ๆ มาก นานมาแล้ว และหวังว่าตอนนี้จะดีขึ้นแล้ว
    • สาเหตุใหญ่ที่สุดของความล้มเหลวในการออกแบบ UI คือการ แยกตัวออกจากผู้ใช้และความต้องการ
      ที่เหลือทั้งหมดใกล้เคียงกับงานเขียนโค้ด
    • Spotify ก็เปลี่ยนเลย์เอาต์หน้าจอหลักและตำแหน่งไอคอนแอปบ่อยเช่นกัน
      ทุกเช้าผมฟังพอดแคสต์ข่าวสองรายการเดิม แต่รายการแนะนำในแอปถูกสลับตำแหน่งทุกเช้าโดยไม่มีเหตุผล
      ที่น่าหงุดหงิดกว่านั้นคือ ตอนเปิดแอป มันจะแสดงเลย์เอาต์ของเมื่อวานแวบหนึ่ง แล้วค้างประมาณ 1 วินาทีเพื่อโหลด ก่อนจะจัดเรียงรายการใหม่ ช่วงที่รายการขยับนั้นทำให้ผมกดพลาดทุกครั้ง น่าหงุดหงิดสุด ๆ

  • นักออกแบบคนหนึ่งที่ผมเคยร่วมงานด้วยเมื่อหลายปีก่อน อธิบายได้อย่างยอดเยี่ยมว่าทำไม ความสม่ำเสมอ จึงสำคัญ
    มันไม่ใช่เรื่องของพาเล็ตสีที่จำกัดหรือการเลือกฟอนต์ที่ไม่มีใครสังเกตเห็น หากมัวไล่ตามกฎยิบย่อย ซอฟต์แวร์จะออกมาแย่มาก บางคนเข้าใจผิดว่ายิ่ง UI มีความหลากหลายน้อยลง ความสม่ำเสมอก็ยิ่งสูงขึ้น
    แก่นสำคัญคือการทำให้ผู้ใช้ กลายเป็นผู้เชี่ยวชาญของซอฟต์แวร์นั้นได้
    นักออกแบบคนนั้นยก Microsoft Office เป็นตัวอย่าง ผู้คนภูมิใจที่ตน “รู้จัก” Microsoft Office และเพราะสัมผัสได้ถึงแรงเฉื่อยของ “Office” จึงย้ายไปมาระหว่างแอปต่าง ๆ ได้อย่างเป็นธรรมชาติ ผมรู้สึกแบบเดียวกันกับ Vim แค่รู้ได้เองว่าสิ่งต่าง ๆ ควรทำงานอย่างไร และปลั๊กอินใหม่ที่ทำมาดีมักเคารพแพตเทิร์นนั้น
    Office และ (Neo)Vim อาจไม่ใช่ตัวอย่างของ UI ที่ยอดเยี่ยม แต่มีความเสถียรเป็นพิเศษ

    • ผมไม่ใช่นักออกแบบ แต่สิ่งที่ย้ำเสมอคือ พลังของการใช้ส่วนประกอบและแนวคิด UI ที่ผู้ใช้เรียนรู้จากที่อื่นมาแล้วเพื่อ บูตสแตรปความชำนาญ นั้นมีมาก
      เช่น เมื่อต้องแสดงตัวเลือกสี่อย่าง อาจใช้คอมโบบ็อกซ์รายการเช็กที่ค้นหาได้จาก [Insert UI Library] ซึ่งตกแต่งตามธีมแบรนด์ หรือจะเพียงแสดง radio button หรือ checkbox แบบทั่วไปที่มีป้ายกำกับก็ได้ อย่างหลังดีกว่าในทุกด้าน
      ผู้ใช้แค่มองวงกลมกับสี่เหลี่ยมก็รู้ได้ว่าต้องเลือกได้อย่างเดียวหรือเลือกได้หลายอย่าง เห็นตัวเลือกทั้งสี่ทั้งหมด ไม่มีปัญหาแป้นพิมพ์มือถือเด้งขึ้นมาเพื่อ “ค้นหา” แล้วบังหน้าจอเล็ก ๆ มากขึ้น และการเข้าถึงก็มักใกล้ 100% เสมอ
      แต่ตัวเลือกนี้สอบตกในหัวข้อ “เข้ากับดีไซน์ซิสเต็มของเราอย่างน่ารัก” ดังนั้นนักออกแบบจึงมักเลือกแบบแรก และแย่กว่านั้นคือทำให้วิธีนั้นกลายเป็นมาตรฐาน จนการใช้วิดเจ็ตทั่วไปกลายเป็น “บั๊ก”
      สุดท้าย “UX designer” จำนวนมากเกินไปบูชาสุนทรียะและแบรนดิ้ง โดยยอมสละทุกอย่างอื่น UI widget ไม่ใช่ที่สำหรับแสดงแบรนด์หรือความสร้างสรรค์ เหมือนกับที่ไม่ควรสร้างฟอนต์ของตัวเองที่บังคับให้ตัวอักษรทุกตัวมีทรงเหมือนโลโก้ ลูกค้าให้ความสำคัญกับการทำงานของตนให้เสร็จมากกว่าแบรนด์
    • นี่อาจเป็นหนึ่งในเหตุผลที่หลายคนโกรธเมื่อ Microsoft นำ adaptive ribbon ที่ “พยายามช่วย” ด้วยการแสดงเฉพาะตัวเลือกที่ดูน่าจะเกี่ยวข้องที่สุดเข้ามา
      มันทำลายความสามารถในการหาฟีเจอร์ที่ต้องการอย่างมาก
    • วลีที่ว่าทำให้ผู้ใช้กลายเป็นผู้เชี่ยวชาญของซอฟต์แวร์นั้นยอดเยี่ยมจริง ๆ
      การได้เห็นคนที่ไม่คิดว่าตัวเองเชี่ยวชาญเทคโนโลยีเคลื่อนไหวใน Excel ได้เร็วมากเป็นเรื่องพิเศษเสมอ
      กฎการออกแบบ UI ของ Microsoft ค่อนข้างน่าทึ่ง ความสม่ำเสมอตลอดหลายปีทำให้ผู้คนยังใช้ซอฟต์แวร์ต่อได้แม้อัปเกรดทุก 1–2 ปี ผมไม่ได้พูดเพราะเป็นแฟน Microsoft
      แก่นของการอัปเกรดคือ การเปลี่ยนแปลงแบบค่อยเป็นค่อยไป ที่ปรับปรุง UX เพียงแต่ผมไม่เข้าใจว่าทำไมทีมออกแบบถึงไม่คัดค้านตอน Win 95 นำแนวคิด “คลิกขวาที่ไหนก็ได้เพื่อดู properties และการตั้งค่า/รายละเอียดที่ลึกขึ้น” เข้ามา เพราะมันเป็นฟีเจอร์ที่มองไม่เห็นซึ่งไม่ได้บอกผู้ใช้ว่าตรงไหนคลิกขวาได้เลย ดูเหมือนว่าในช่วงแรก ๆ ที่ใช้ Win 95 ไม่มีใครเข้าใจการคลิกขวาเลย
    • ผมเป็นนักออกแบบภาษาโปรแกรม จึงคิดเรื่องแบบนี้ทุกวัน
      ผมเห็นด้วยว่าความชำนาญเกี่ยวข้อง แต่ดูเหมือนยังต้องเชื่อมโยงอีกหน่อยว่าทำไมความสม่ำเสมอจึงนำไปสู่ความชำนาญ
      ความสม่ำเสมอ คือการขยายสิ่งที่ผู้ใช้รู้อยู่แล้วเกี่ยวกับระบบไปยังส่วนอื่น ๆ ของระบบแบบทบต้น หากระบบสม่ำเสมอ ความพยายามที่ใช้เรียน X และ Y จะทำให้รู้ Z และ W ไปด้วย เพราะมันจะทำงานในแบบเดียวกัน ในระบบที่ไม่สม่ำเสมอ คุณค่าที่ได้จากการลงทุนเรียนรู้เดิมจะลดลงมาก
    • ผมเห็นด้วยกับความสำคัญของความสม่ำเสมอ แต่ไม่เห็นด้วยกับคำว่า “Office และ (Neo)Vim ไม่ใช่ UI ที่ยอดเยี่ยม แต่มีความเสถียรเป็นพิเศษ”
      อย่างน้อยในระยะยาว Office ก็ไม่ได้เสถียร ribbon อันฉาวโฉ่เป็นการเบี่ยงออกอย่างน่าเศร้าจาก UI ของ Word ที่เสถียรและมีประสิทธิภาพ และการถอยหลังอย่างเข้าใจยากของ Microsoft ทั่วแพลตฟอร์ม Windows ก็ทำให้ปัญหาใหญ่ขึ้น เช่น การเอาแถบเมนูออกจากแอปพลิเคชัน ไม่รู้จริง ๆ ว่าทำไปทำไม

  • “กฎ” อีกข้อที่อยากให้เพิ่มคือการเผย conceptual model ให้ผู้ใช้เห็น
    ถ้าไม่เข้าใจ conceptual model ของผลิตภัณฑ์ ต่อให้ติดป้ายกำกับไอคอนได้ดีแค่ไหนก็ยังสับสนอยู่ดี เช่น ลองนึกถึงผลิตภัณฑ์ที่มีคำสั่ง “New Configuration” ดู ก่อนอื่นคำว่า “Configuration” คืออะไรก็ยังคลุมเครือ มันเป็นเทมเพลตที่ให้กำหนดออบเจ็กต์อื่นได้หรือเปล่า? เป็นวิธีสลับอย่างรวดเร็วระหว่างชุดตัวเลือกหลายชุดหรือเปล่า? หรือเป็นคอนเทนเนอร์คล้ายโฟลเดอร์?
    UI ควรถูกออกแบบให้ผู้ใช้อนุมาน conceptual model ได้เพียงจากการสำรวจอินเทอร์เฟซ เรื่องนี้ไม่ได้ง่ายเสมอไป

    • เป้าหมายของอินเทอร์เฟซที่ดีคือการนำทางผู้ใช้ไปสู่เป้าหมาย พร้อมกับซ่อนรายละเอียดการ implement

  • ส่วนที่ว่า “เช่น เมื่อผู้ใช้กรอกรหัสไปรษณีย์ผิด ไม่ควรให้กรอกฟอร์มชื่อ-ที่อยู่ทั้งชุดใหม่ แต่ควรชี้ให้แก้เฉพาะส่วนที่ผิด” เป็นจุดที่ไม่พอใจที่สุด และทุกวันนี้ก็ยังเห็นบ่อย
    แม้แต่ฟอร์มหลายหน้าก็ควรรักษาหลักการนี้ไว้เวลาไปหน้า前/ถอยหลัง
    “การกระทำที่ผิดพลาดไม่ควรเปลี่ยนสถานะของอินเทอร์เฟซ และถ้าเปลี่ยนไปแล้วก็ควรชี้วิธีคืนกลับสู่สถานะเดิม” ก็สำคัญเช่นกัน
    บนหน้าจอขนาดเล็กอย่างโทรศัพท์มือถือและนาฬิกา ดีไซเนอร์ที่พยายามประหยัดพื้นที่พึ่งพา ไอคอน มากขึ้นเรื่อย ๆ แต่ไอคอนจำนวนมากไม่คุ้นตาหรือตีความยาก และบางครั้งต้องลองกดถึงจะรู้ ไอคอนแบบนั้นจำเป็นต้องมีวิธีกลับสู่สถานะเดิมเมื่อกดผิด

    • ใช่เลย ถ้ากรอก “Corvallis” ก็ควรถามว่า “Oregon หรือ Montana?” และถ้ากรอก “97330” แล้ว ส่วนที่เหลือก็ควรข้ามไปได้เลย
    • น่าหงุดหงิดจริง ๆ
      แค่พยายามล็อกอินด้วยอีเมลกับรหัสผ่านก็เป็นปัญหาอยู่แล้ว แต่ถ้ากด “ลืมรหัสผ่าน” ก็อย่าส่งไปยังฟอร์มที่ให้กรอกอีเมลเดิมที่เพิ่งกรอกไปอีกครั้งเลย

  • คำพูดที่ว่า “ทำรายการเมนูที่ไม่เหมาะสมให้เป็นสีเทา” มีเงื่อนไขอยู่
    ถ้าเหตุผลที่เป็นสีเทาไม่ชัดเจน ก็ไม่ควรทำแบบนั้น ควรเปิดใช้คำสั่งไว้ และถ้าคลิกแล้วใช้ไม่ได้ในตอนนี้ ก็ควรอธิบายด้วยข้อความผิดพลาดว่าทำไมถึงใช้ไม่ได้ การบังคับให้ผู้ใช้ต้องหาคำตอบเองว่าทำไมคำสั่งถูกปิดใช้นั้นน่าหงุดหงิด
    ข้อยกเว้นคือกรณีที่มีโอกาสสูงว่าผู้ใช้จะเสียเวลาไปมากจนถึงท้ายสุดแล้วค่อยถูกบอกว่าใช้ไม่ได้
    บทความที่เกี่ยวข้องให้อ่านต่อ: https://medium.com/@vedranio/james-bond-and-the-design-of-di...

    • ทำรายการเมนูให้เป็นสีเทา แต่เมื่อคลิกก็แสดงข้อความอธิบายเหมือนเดิมไม่ได้หรือ?
      ดูเหมือนเป็นวิธีที่ได้ข้อดีทั้งสองฝั่ง
    • ถึงอย่างนั้น ก่อนที่ผู้ใช้จะคลิกก็ควรมี สัญญาณภาพที่สอดคล้องกัน เพื่อบอกว่าการกระทำนั้นถูกปิดใช้งานอยู่
    • มีข้อยกเว้นหนึ่งอย่าง: ฟีเจอร์พรีเมียมแบบเสียเงิน
      มีแอป to-do แอปหนึ่งทำแบบนี้ คำสั่งพรีเมียมไม่ถูกแยกให้ต่างจากคำสั่งฟรีในเชิงภาพ เลยเผลอคลิกบ่อย และทุกครั้งก็จะมีไดอะล็อกชวนสมัครที่ตัดจังหวะโฟลว์ทั้งหมดเด้งขึ้นมา
      สำหรับผม นี่เป็นข้อผิดพลาด UI ที่ร้ายแรง
    • ทำปุ่มให้เป็นสีเทา แต่ใส่ tooltip ที่บอกว่าทำไมคลิกไม่ได้เมื่อเอาเมาส์ไปวางทับ เป็นอย่างไร
    • ไม่เห็นด้วย การปิดใช้งานการกระทำที่เป็นไปไม่ได้ในบริบทปัจจุบันมีประโยชน์ เพียงแต่ต้อง อธิบายว่าทำไม
      UI ที่ปิดใช้งานเฉพาะบางการกระทำโดยไม่บอกเหตุผลทำให้หงุดหงิดเสมอ

  • 10 usability heuristics ของ Nielsen เป็นดาวเหนือที่ดี

    1. การมองเห็นสถานะของระบบ
    2. ความสอดคล้องระหว่างระบบกับโลกจริง
    3. การควบคุมและอิสระของผู้ใช้
    4. ความสม่ำเสมอและมาตรฐาน
    5. การป้องกันข้อผิดพลาด
    6. การจดจำด้วยการมองเห็นแทนการจำจากความจำ
    7. ความยืดหยุ่นและประสิทธิภาพในการใช้งาน
    8. ดีไซน์ที่สวยงามและมินิมัล
    9. การรับรู้ วินิจฉัย และกู้คืนจากข้อผิดพลาด
    10. ความช่วยเหลือและเอกสารประกอบ
      https://www.nngroup.com/articles/ten-usability-heuristics/
    • ความต่างระหว่างหน้า Nielsen-Norman นี้กับหน้าต้นฉบับชัดเจนมาก
      หน้า NN ทำให้รับข้อมูลได้ง่ายกว่ามาก กระชับกว่า และเลย์เอาต์หน้าก็ดีกว่ามาก
      ทั้งสองบทความมีข้อมูลและทิศทางที่ควรรับฟัง แต่ก็น่าขันที่หน้าต้นฉบับใช้ขนบแบบเก่าเรื่องขนาดตัวอักษรเท่ากันและย่อหน้า ซึ่งหน้า NN เลิกใช้ไปแล้ว
      น่าหงุดหงิดที่ Hacker News เองก็ไม่ทำตามข้อมูลบางส่วนเหล่านี้ ตอนแก้ไขโพสต์เดิม หลังจากกดปุ่ม “update” แล้ว feedback ยังไม่ชัดเจนพอ น่าจะเป็นการวาดหน้าจอใหม่

  • ควรเลิกทำ UI ที่แทรกอะไรบางอย่างเข้ามาตรงตำแหน่งที่ผมกำลังจะเลือก จนทำให้ กดผิด
    มันอาจเป็นการละเมิดกฎบางข้อข้างต้น หรืออาจเป็นปัญหาที่บรรเทาได้ แต่โดยส่วนตัวแล้วมันเป็นสิ่งที่ทำให้แทบคลั่ง และมองว่าเป็นความผิดพลาดร้ายแรงเป็นพิเศษ

    • นึกถึง Unassigned/Automatic selection ที่โผล่มาเวลาเปลี่ยนผู้รับผิดชอบ story ใน Jira เป็นพิเศษ

  • มีกฎสำคัญอีกข้อที่ตกไป ซึ่งครั้งหนึ่งเคยดูเหมือนเป็นเรื่องพื้นฐานมาก นั่นคือ ต้อง แยกข้อมูลแบบคงที่ออกจากองค์ประกอบที่ใช้操作
    อีกอย่าง ไม่ควรซ่อนองค์ประกอบที่ใช้操作ซึ่งยังใช้ไม่ได้ แต่ควรทำให้เป็นสีเทา เพื่อให้ผู้ใช้ได้เรียนรู้ว่าฟีเจอร์นั้นมีอยู่ อยู่ตรงไหน และต้องผ่านเงื่อนไขอะไรจึงจะใช้ได้
    ที่เกี่ยวข้องกันคือ อย่าพึ่งพา UI แบบซ่อนหา ซึ่งจะแสดงบางอย่างเฉพาะเมื่อผู้ใช้บังเอิญเอาเคอร์เซอร์ไปวางทับ ผู้ใช้ต้องการทำงานให้เสร็จ ไม่ได้อยากสำรวจ Advent calendar

  • กฎทองข้อหนึ่งที่ผมเรียนรู้มาคือ หลังจากวาดอินเทอร์เฟซแล้ว องค์ประกอบไม่ควรขยับโดยไม่คาดคิด
    Google มีกรณีที่ปุ่มขยับระหว่างยกนิ้วโป้งขึ้นกับแตะหน้าจอบ่อยเป็นพิเศษ แต่ไม่ได้มีแค่ Google เท่านั้น

    • อยากให้เรื่องนี้ถูกจัดการในระดับระบบปฏิบัติการ
      ถ้าเป้าหมายเป็นสิ่งที่เพิ่งปรากฏขึ้นภายในราว 0.25 วินาทีก่อนถูกแตะ ก็ไม่ควรสร้าง touch event เพราะด้วยความเร็วตอบสนองของมนุษย์ เราไม่สามารถเล็งและกดปุ่มได้เร็วขนาดนั้น

  • นี่เป็นกฎทองของยูโทเปียอย่างชัดเจน
    คนส่วนใหญ่คงไม่คัดค้านกฎแบบนี้
    ถึงอย่างนั้น นักพัฒนาส่วนใหญ่ก็น่าจะเคยเจออินเทอร์เฟซที่ละเมิดกฎเหล่านี้อยู่บ่อย ๆ ไม่ใช่เพราะไม่เข้าใจหรือไม่อยากทำ แต่เพราะต้นทุน ณ เวลานั้นสูงเกินไป
    ตัวอย่างเช่น การย้อนกลับได้ นั้นทำได้ยากมาก และจะเป็นไปได้ก็ต่อเมื่อโครงสร้างข้อมูลใต้แอปพลิเคชันถูกสร้างขึ้นโดยคำนึงถึงเรื่องนี้มาตั้งแต่แรก การป้องกันข้อผิดพลาดก็เช่นกัน แค่การรู้ให้แน่ชัดว่าอะไรคือข้อผิดพลาดก็เป็นเรื่องยากและมีต้นทุนสูงอยู่แล้ว และการให้ฟีดแบ็กที่สมบูรณ์แบบในภาษาของผู้ใช้นั้นซับซ้อนยิ่งกว่านั้นมาก