อย่าซ่อนคอนโทรลของฉัน: คอนโทรลอินเทอร์เฟซที่ซ่อนอยู่ส่งผลต่อการใช้งาน

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

---

บทนำ: ตำแหน่งของความรู้และอินเทอร์เฟซ

• ในทศวรรษ 1960 Douglas Engelbart ได้นำเสนอแนวคิดเรื่อง “ความรู้อยู่ในโลก หรืออยู่ในหัว”
• “knowledge in the world” หมายถึงการที่คอนโทรลสำหรับการใช้งานถูกแสดงอยู่บนอินเทอร์เฟซ ทำให้ผู้ใช้สามารถหาและใช้งานได้โดยตรงโดยไม่ต้องอาศัยความจำ
  • ตัวอย่าง: กราฟิกอินเทอร์เฟซที่มีเมนูแบบดรอปดาวน์
• “knowledge in the head” หมายถึงสภาพแวดล้อมที่ผู้ใช้ต้องจดจำคอนโทรลและคำสั่งทั้งหมดเอง
  • ตัวอย่าง: ใน DOS command prompt หากไม่รู้คำสั่งอย่าง DIR ก็แทบจะไม่สามารถทำอะไรได้เลย

เหตุผลที่คอนโทรลที่ซ่อนอยู่เพิ่มขึ้นและผลเสียที่ตามมา

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

ตัวอย่างคอนโทรลที่ซ่อนอยู่ในชีวิตประจำวัน

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

ปัญหาทั่วไปจากคอนโทรลที่ซ่อนอยู่และผลกระทบต่อผู้ใช้ระดับมืออาชีพ

• แม้จะตั้งระดับเสียงไว้ที่ 0 แต่แอปก็ยังส่งเสียงออกมาเองได้ แสดงให้เห็นว่ามี “การตั้งค่าที่ซ่อนอยู่” ซึ่งไปทับคำสั่งโดยตรงของผู้ใช้
• แม้แต่ผู้ใช้ขั้นสูงก็ยังเผชิญการพึ่งพา อินเทอร์เฟซแบบคำสั่ง อย่างหนักในสภาพแวดล้อมเช่น R หรือหน้าต่าง DOS ซึ่งเป็นการพึ่งพาแบบ knowledge in the head อย่างชัดเจน
• มีแนวโน้มค่อย ๆ ย้อนกลับไปสู่อินเทอร์เฟซแบบดั้งเดิมที่หยาบกว่าเดิม

ทำไมคอนโทรลที่ซ่อนอยู่จึงเพิ่มขึ้น

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

กรณีที่ประสบความสำเร็จและความแตกต่างของระบบ mission-critical

• บางระบบ เช่น ระบบนำทางของ General Motors แสดงคอนโทรลที่จำเป็นทั้งหมดไว้อย่างชัดเจนบนหน้าจอเสมอ ทำให้แม้แต่มือใหม่ก็สำรวจได้ง่าย
  • ตัวอย่าง: ฟังก์ชันซูมผ่านปุ่มหมุนจริงใน Buick LaCrosse
• ในระบบ mission-critical (เช่น อากาศยานหรือโรงงาน) การออกแบบแทบทั้งหมดจะยึดคอนโทรลที่ มองเห็นได้ตลอดเวลา เป็นหลัก
  • ไม่มีใครยอมรับความเสี่ยงที่คอนโทรลที่ซ่อนอยู่จะขัดขวางการควบคุมอย่างรวดเร็ว

การปกป้องอินเทอร์เฟซแบบซ่อนและข้อจำกัดของแนวคิดนี้

• คอนโทรลที่ซ่อนอยู่ ไม่ใช่แค่เรื่องการบ่นข้ามรุ่น แต่เป็นปัญหาด้านการใช้งานจริง
• บางฝ่ายโปรโมตว่า “การค้นหาฟังก์ชันที่ซ่อนอยู่” เป็นข้อดีในตัวเอง แต่ในความเป็นจริง การเข้าถึงที่ลดลงนั้นชัดเจน
• จากมุมมองของผู้ใช้ คอนโทรลที่หาไม่เจอ ก็ไม่ต่างจากคอนโทรลที่ไม่มีอยู่จริง

Ubiquitous computing และการทำให้คอนโทรลเป็นอัตโนมัติ/โปร่งใส

• Mark Weiser และ Donald Norman เคยคาดการณ์อนาคตที่เทคโนโลยีจะ “โปร่งใส” และถอยไปทำงานอยู่เบื้องหลัง
  • ตัวอย่าง: การควบคุมเครื่องยนต์รถยนต์ถูกปรับโดยอัตโนมัติทั้งหมดในพื้นหลังโดยไม่ต้องให้ผู้ใช้ควบคุมเอง
• กรณีที่คอนโทรลถูกซ่อนอย่างสมบูรณ์เพราะ ระบบอัตโนมัติ นั้น มีความจำเป็นและบริบทที่ชัดเจน
  • แต่ในสถานการณ์ที่ผู้ใช้ยังต้องมีปฏิสัมพันธ์ จำเป็นต้องมี คอนโทรลที่ชัดเจน เสมอ

บทสรุปและทิศทางสำหรับนักออกแบบอินเทอร์เฟซ

• นักออกแบบอินเทอร์เฟซ ควรหลีกเลี่ยงการใช้คอนโทรลที่ซ่อนอยู่ และเปลี่ยนทุกฟังก์ชันไปสู่แนวคิด “ความรู้ที่ปรากฏอยู่ในโลก”
• ความสามารถในการค้นพบคอนโทรล (discoverability) ยังคงเป็นหลักการออกแบบที่สำคัญ
• การลดลงของความสามารถในการค้นพบในอินเทอร์เฟซสมัยใหม่ แท้จริงแล้วคือการถอยหลังกลับไปสู่ยุคคอมพิวเตอร์ยุคแรก

เอกสารอ้างอิง

• Engelbart, D.C. (1962) และเอกสารหลักอื่น ๆ ที่เกี่ยวข้อง
• มีการอ้างอิงหนังสือและบทความที่เกี่ยวข้อง เช่น Apple Macintosh, The Psychology of Everyday Things, The Invisible Computer

ข้อมูลผู้เขียน

• Philip Kortum: ศาสตราจารย์ภาควิชาจิตวิทยาแห่ง Rice University ทำวิจัยด้านการพัฒนาระบบที่ยึดการใช้งานเป็นศูนย์กลาง ครอบคลุมทั้งการประเมิน usability และความน่าเชื่อถือ สุขภาพระดับโลก และระบบมือถือ

[GN⁺]

ความคิดเห็นจาก Hacker News

• มีการแชร์ประสบการณ์ผู้ใช้ที่รู้สึกไม่สะดวกกับดีไซน์ที่ซ่อนแถบเลื่อนในช่วงหลัง ๆ และมีการพูดถึงด้วยว่าตัวอย่างปุ่มหมุนแบบกายภาพที่ดูใช้งานเข้าใจง่ายบางส่วนในบทความก็มีข้อจำกัดด้านต้นทุนและความคุ้มค่า อีกทั้งยังเคยเจอสวิตช์ toggle ที่ป้ายกำกับสื่อถึงสถานะที่จะถูกสลับไป ไม่ใช่สถานะปัจจุบัน จนทำให้สับสน
  • มีความเห็นว่าไม่ชอบสวิตช์ toggle จริง ๆ อยู่แล้วเพราะมันกำกวม checkbox หรือปุ่มที่กดค้างอยู่ชัดเจนกว่ามาก แต่น่าเสียดายที่สิ่งเหล่านี้ถูกสละทิ้งไปในกระแสความทันสมัย
  • มีคนเล่าว่าเคยเจอสวิตช์ toggle สำหรับการยืนยันแบบทันทีในตู้ขายตั๋วรถไฟของออสเตรียซึ่งทำให้งง แถบเลื่อนก็ผอมเกินจนแทบต้องมีฝีมือระดับเกม FPS ถึงจะใช้งานได้ และบางครั้งแถบเลื่อนแนวนอนก็สะดวกกว่า พร้อมเหน็บ Firefox และมาตรฐาน CSS
  • บน macOS สามารถตั้งค่าให้แสดงแถบเลื่อนตลอดเวลาได้จาก System Settings หรือผ่านคำสั่งในเทอร์มินัล
  • ถ้า toggle สื่อถึงการกระทำ ก็ควรใช้คำกริยาอย่าง "TURN ON" ให้ชัดเจน และถ้าจะแสดงสถานะก็ควรใช้รูปแบบชัด ๆ อย่าง "IS ON" ยกเว้นบางกรณีที่บริบททำให้สับสน การใช้คำกริยาแทบจะช่วยให้ชัดเจนได้เสมอ
  • ขอให้รองรับ PgUp และ PgDn ด้วย
• มีคนบอกว่าตนเองยังขับ Toyota รุ่นเก่าอยู่ และคอนโทรลทุกอย่างมองเห็นได้ตลอด ติดป้ายกำกับชัดเจน และแยกแยะได้ด้วยปลายนิ้ว มองว่านี่เป็นสิ่งที่ทำซ้ำได้ง่ายและแทบจะเป็นวิศวกรรมขั้นต่ำ แต่ผู้ผลิตรถส่วนใหญ่ในปัจจุบันกลับทำไม่ได้ด้วยซ้ำ จึงมองว่าเป็นเพราะฝีมือไม่ถึง
  • มีคนเห็นด้วยบางส่วน แต่บอกว่าการยืนยันว่า "คอนโทรลทุกอย่างต้องมองเห็นได้" เป็นมุมมองที่ประเมินงานดีไซเนอร์ต่ำเกินไป ในทางปฏิบัติมีเพียงคอนโทรลที่จำเป็นระหว่างขับขี่เท่านั้นที่ต้องถูกเปิดเผย ส่วนที่เหลือมักเล็ก ซับซ้อน หรือถูกซ่อน เช่น คันปรับความสูงเบาะ คันเปิดฝากระโปรง ซึ่งแม้จะซ่อนอยู่ก็ยังเข้าถึงได้ กระบวนการออกแบบที่คำนึงถึงรายละเอียดเหล่านี้ไม่ง่ายและไม่ trivial การลดทอนเรื่องนี้ว่าเป็นของง่ายต่างหากที่ทำให้ UX ปัจจุบันแย่ลง
  • อีกมุมมองหนึ่งคือ นี่ไม่ใช่ปัญหาเรื่องฝีมือแต่เป็นเรื่องต้นทุน ทุกวันนี้การใช้หน้าจอสัมผัสถูกกว่าและผลิตง่ายกว่าการทำปุ่มและปุ่มหมุนแยกจำนวนมากแล้วค่อยประกอบ
  • มีคนแชร์ว่าตนเคยได้รับข้อเสนอสมัครงานจากผู้ผลิตรถยนต์ในสหรัฐฯ จำนวนมากในตำแหน่ง system developer แต่ในชุมชน Hacker News มักมีเสียงว่า “ถ้าอยากรักษาสุขภาพจิตก็อย่าไป”
  • อีกความเห็นอธิบายว่าถ้าจะทำชิ้นส่วนกลไกอย่างปุ่มหมุนให้แตกต่างกัน ต้นทุนการผลิตรวมถึง custom mold จะสูงขึ้นมาก การใส่ทุกอย่างไว้บนหน้าจอจึงคุ้มค่ากว่ามากในเชิงต้นทุน
• เข้าใจได้ถ้าจะซ่อนองค์ประกอบ UI เพื่อประหยัดพื้นที่หน้าจอ แต่ถ้าปล่อยพื้นที่นั้นว่างไว้แล้วกลับซ่อน ก็ยอมรับไม่ได้ มีคนยกตัวอย่างว่าใน IntelliJ ไอคอนเหนือ project tree ถูกซ่อนไว้ ต้องเอาเมาส์ไปชี้ถึงจะโผล่มา จึงสงสัยว่าไม่มีเหตุผลอะไรที่ต้องทำแบบนั้น
  • มีคนตั้งคำถามกับเหตุผลที่ทำให้องค์ประกอบบนหน้าจอถูกซ่อน ทั้งที่หน้าจอมือถือ เดสก์ท็อป และโน้ตบุ๊กทุกวันนี้ใหญ่กว่าที่เคย พร้อมรำลึกว่าแม้แต่ Macintosh จอขาวดำขนาดเล็กในปี 1984 ก็ยังยอมเสียสัดส่วนพื้นที่จอเพื่อวางปุ่มให้ชัดเจนและมองเห็นได้
  • บางคนบ่นว่า "noise" ทางสายตารบกวนสมาธิ ขณะที่อีกบางคนอยากให้คอนโทรลและไฟแสดงผลทุกอย่างมองเห็นได้ตลอดเหมือนแผงหน้าปัด ดังนั้นค่าเริ่มต้นของ IDE จึงเป็นการประนีประนอมเพื่อพยายามตอบสนองรสนิยมสุดโต่งทั้งสองฝั่ง และบางเครื่องมือก็มีโหมดอย่าง "no distractions mode" ให้ปรับละเอียด
  • ใน IntelliJ เวอร์ชัน Windows เมนูก็ถูกซ่อนไว้ในไอคอน hamburger ทั้งที่มีพื้นที่ว่างมาก โชคดีที่กู้กลับมาได้จากการตั้งค่า แต่ค่าเริ่มต้นนั้นชวนไม่เข้าใจ
  • บางครั้งแม้จะรู้ว่ามีปุ่มนั้นอยู่และจำได้ด้วยว่าต้องทำให้มันแสดงอย่างไร ก็ยังเผลอลืมว่ามันอยู่ตรงไหน แล้วนั่งจ้องหน้าจอแบบงง ๆ
  • บางแอปกลับไม่ซ่อนปุ่มเพิ่มเลย และบางคนก็อยากให้มีตัวเลือกสำหรับซ่อนเสียมากกว่า โดยยก Google Maps เป็นตัวอย่าง
• มีการวิจารณ์ว่าการซ่อนคอนโทรลสำคัญเป็นวิศวกรรมที่ไม่เป็นมิตรต่อผู้ใช้อย่างมาก เช่น กรณี smart key รถยนต์ที่ซ่อนกุญแจจริงไว้ และถึงขั้นต้องถอดมือจับประตูรถถึงจะเจอรูเสียบกุญแจ
  • มีคนเล่าว่าเคยเจอสถานการณ์คล้ายกันกับรถเช่า เมื่อรีโมตกุญแจเสีย ของทั้งหมดจึงติดอยู่ในรถ แม้จะรู้ว่ามีกุญแจจริงอยู่ แต่ก็มองหารู keyhole ได้จากรอยขีดข่วนรอบมือจับที่ผู้ใช้ก่อนหน้าพยายามงัดหาไว้เต็มไปหมด
  • อีกความเห็นบอกว่าสถานการณ์แบบนี้เป็นเรื่องที่ผู้ใช้ควรรู้เป็นพื้นฐาน และสามารถค้นข้อมูลจาก Google ได้ พร้อมยกตัวอย่างว่าหลังรับรถรุ่นใหม่มาก็ตรวจสอบ backup option และวิธีการทำงานทันที เน้นว่าควรรู้ข้อมูลพื้นฐานของสิ่งที่ตัวเองเป็นเจ้าของ
• มีคนเล่าว่าหนึ่งในเหตุผลที่ย้ายจาก iPhone ไป Android คือการหายไปของปุ่ม Home ซึ่งทำให้อธิบายและช่วยคนสูงอายุในครอบครัวยากขึ้น เวลาได้ Pixel เครื่องใหม่ก็จะเปิดใช้ 3-button navigation ก่อนเสมอ แต่แอปสมัยนี้มักสมมติว่ามีเพียง bottom navigation bar ทำให้เนื้อหาถูกบังเมื่อใช้ 3 ปุ่ม จึงถูกวิจารณ์ว่าเป็นข้อเสียด้าน UI
  • มีความเห็นว่าคอนโทรล UI หลักต้องมองเห็นได้เสมอ แม้ Apple เองก็ละเมิดหลักนี้บ้างเป็นครั้งคราว แต่โดยรวมถือว่ายังต้านกระแสนี้อยู่ การเอาปุ่ม Home ออกอาจตีความได้ว่าไม่ใช่การซ่อนองค์ประกอบ UI ตรง ๆ แต่เป็นการเปลี่ยนรูปแบบปฏิสัมพันธ์ ซึ่งอาจถกเถียงกันได้ว่าใช้งานเข้าใจง่ายหรือดีกว่าหรือไม่ แต่เมื่อชินแล้วแทบไม่มีแรงเสียดทานในการใช้งาน และใน iOS ก็มีฟีเจอร์ช่วยการเข้าถึงที่เป็นปุ่มลัดวงกลมเล็ก ๆ พร้อมป้ายข้อความให้ลากไปมาบนหน้าจอได้
  • อาการที่เมนูไอเท็มในซอฟต์แวร์ทั่วไปหายไปแบบเงียบ ๆ ก็คล้ายกัน ตัวอย่างเช่นใน MS Word ไอคอนสำหรับบันทึกไฟล์แบบ read-only หายไปเลย มีคนเสนอว่าปล่อยให้มันเป็นสถานะ disabled ไว้จะดีกว่า และค่อยแจ้งสาเหตุพร้อมวิธีแก้เมื่อผู้ใช้พยายามบันทึก
  • มีคนบอกว่าตนใช้ Android มานาน และทุกครั้งที่ต้องยืม iPhone มาก็มักหงุดหงิดกับปฏิสัมพันธ์ที่ไม่ intuitive หรือไม่มีอยู่เลย อีกทั้งคุณภาพกล้องของ Pixel และ Samsung ก็ดีขึ้นมากแล้ว จึงไม่มีเหตุผลจะย้ายไป ecosystem ของ Apple
• มีความเห็นว่าบทความยังพูดไม่พอว่าการหายไปของ UI ไม่ได้เกิดจากอุบัติเหตุหรือความผิดพลาด แต่เป็นปรากฏการณ์เพื่อ lock-in ผู้ใช้ โดยมองว่าเมื่อซอฟต์แวร์เข้าสู่จุด saturated แล้ว บริษัทจะเปลี่ยน UI ให้ไม่ intuitive เพื่อป้องกันไม่ให้ผู้ใช้เดิมย้ายออก ทำให้อุปกรณ์ไม่ใช่สิ่งที่เรา "ใช้" แต่กลายเป็นสิ่งที่ถูก "internalize" จนสร้างกำแพงต่อการย้ายไปใช้ตัวอื่น และทำให้ผู้ใช้กลัวการเปลี่ยนผลิตภัณฑ์ใหม่หลังลงทุนเรียนรู้ UI ไปแล้ว ซึ่งอธิบายได้ว่าทำไมบริษัทซอฟต์แวร์ใหญ่ส่วนมากจึงใช้แนวทางนี้
  • มีคนแย้งว่าสมมติฐานนี้ถ้ามองเป็นบางกรณีก็อาจจริง แต่ในโลกจริงก็มีแรงต้านต่อ "อินเทอร์เฟซที่ซับซ้อนและแออัด" มากเช่นกัน ทั้งกระแสมินิมัลลิสม์และผู้ใช้หลากหลายกลุ่มอย่าง /r/unixporn ก็มีแนวโน้มซ่อนคอนโทรลด้วยตัวเอง อีกทั้ง GNOME และที่อื่น ๆ ช่วงหลังก็เน้นอินเทอร์เฟซมินิมัล หลายคนก็รู้วิธีค้นหาฟังก์ชันเมื่อจำเป็นอยู่แล้ว จึงมองว่าเป็นเรื่องของทางเลือกด้วย
  • วิธีนี้เป็นดาบสองคม เพราะอาจขัดขวางผู้ใช้หน้าใหม่ มีคนแชร์ว่าตนไม่ชอบที่ทุกอินเทอร์เฟซของ Apple ไปกองอยู่กับปุ่มเดียว จึงคุ้นกับ Android มากกว่า และยังมีเหตุผลอื่นอีกมากที่ไม่ชอบ Apple
  • มีคนเห็นว่าแม้แต่ OSS แบบไม่แสวงกำไรก็ยังทำตามเทรนด์อย่างไม่วิจารณ์ เช่น Firefox ที่เปลี่ยนดีไซน์ซ้ำ ๆ และ GNOME ก็อยู่ในบริบทเดียวกัน
• มีความเห็นว่าถ้าดีไซเนอร์สาย "artist" เป็นคนมีอำนาจตัดสินใจเรื่อง UI มักจะหมกมุ่นกับความสะอาดตา จนมองข้าม affordance และโอกาสในการเรียนรู้วิธีใช้ โดยยก cockpit เครื่องบินเป็นตัวอย่างเปรียบเทียบที่ชัดเจน แม้สำหรับคนนอกจะดูท่วมท้น แต่สำหรับผู้เชี่ยวชาญทุกอย่างมีป้ายกำกับครบ
  • มีคนโต้แย้งว่าก๊อกน้ำในบ้านทั่วไปก็ไม่ได้จำเป็นต้องติดป้ายบอกทิศทาง และ cockpit เครื่องบินสำหรับมือใหม่ก็ท่วมท้นเกินไปจริง ๆ พร้อมยืนยันว่านักออกแบบอินเทอร์เฟซรู้ดีว่าอะไร intuitive และมีความสามารถในการบีบอัดฟังก์ชันที่ซับซ้อนให้อยู่ใน form factor ที่เรียบง่าย การคิดว่าคนที่ไม่มีการศึกษาด้านดีไซน์จะทำได้ดีกว่าเป็นทั้งความหยิ่งและการดูแคลน อีกทั้งการที่ผู้ใช้จำนวนมากสามารถใช้สมาร์ตโฟนสมัยใหม่ได้อย่างคล่องแคล่วโดยแทบไม่ต้องฝึก ก็ถือเป็นความสำเร็จที่ยอดเยี่ยม
• คำบ่นเกี่ยวกับซอฟต์แวร์เดสก์ท็อปจาก Hacker News และคำถามเรื่องสภาพปัจจุบัน
• มีคนบอกว่าหนึ่งในหลักการออกแบบ UI ของบริษัทตนคือ keyboard shortcut และ context menu ต้องเข้าถึงได้ผ่านปุ่มหรือเมนูที่มองเห็นชัดเสมอ แม้จะดู old-fashioned ไปบ้างแต่สำคัญมาก อีกทั้งมุมทั้งสี่ของหน้าจอเป็นพื้นที่สำคัญใน UI เพราะเมาส์เคลื่อนไปถึงได้เร็ว จึงยกกรณี Windows 11 ย้ายเมนู Start มาไว้กลางจอเป็นตัวอย่างของความไม่สะดวกต่อผู้ใช้ และอาจเป็นเพราะนโยบายที่เน้น touch มากกว่าการใช้งานแบบไม่ใช่มือถือ
• มีการเน้นว่าการเข้าถึงและความ intuitive ที่ลดลงของ UI ส่งผลมากต่อผู้พิการและผู้สูงอายุ แม้ touch และ gesture จะกลายเป็นกระแสหลัก แต่ UI มือถือยุคแรกกลับเข้าถึงง่ายกว่า ปัจจัยหลักคือแนวโน้มที่มินิมัลและ flat จนเกินไป มีการรำลึกถึง palm, compaq pilot, iPod และ UI ยุคแรกของ iPhone ในแง่บวก และมองว่านับจากนั้นมาคือการถดถอย
  • ในทางกลับกัน ก็มีคนมองว่าเวลาดูคอมเมนต์ HN บนมือถือ เช่นตอนนี้ การที่คอนโทรลจำนวนมากถูกซ่อนไว้ช่วยให้โฟกัสกับเนื้อหาได้จริงและดูสวยงามน่าใช้งานกว่า สมัย palm pilot ปุ่มและคอนโทรลกินพื้นที่หน้าจอไปเกือบครึ่ง ทำให้พื้นที่เนื้อหาลดลง คอนโทรลที่ซ่อนไว้จึงไม่จำเป็นต้องแย่เสมอไป และเมื่อเรียนรู้แล้วก็เป็นเครื่องมือทรงพลังสำหรับผู้ใช้ระดับสูง การบังคับให้ผู้ใช้เรียนรู้ UI บางส่วนเป็นสิ่งที่หลีกเลี่ยงได้ยาก และเครื่องมือความสามารถสูงอย่าง code editor หรือ git ก็มี trade-off ระหว่างความเรียบง่ายกับพลัง แต่ปัญหาปัจจุบันคือหลายแอปชอบสร้างคอนโทรลเฉพาะของตัวเองมากเกินไปจนความรู้ที่เรียนมาใช้ต่อข้ามแอปไม่ได้ ซึ่งต่างจากโครงสร้างแบบ palm pilot ที่ถ้าเรียนครั้งเดียวก็ใช้ได้เหมือนกันทุกแอป