ปรากฏการณ์การลดลงของ 'Usability' (2020)
(datagubbe.se)- ราวปี 1994~2012 GUI บนเดสก์ท็อปแม้จะต่างระบบปฏิบัติการกันก็ยังมี กฎร่วมกัน อยู่มาก ทำให้ผู้ใช้ที่ชำนาญปรับตัวเข้ากับสภาพแวดล้อมใหม่ได้อย่างรวดเร็ว แต่ปัจจุบันรากฐานนั้นอ่อนแอลง
- เมื่อ แนวคิดแบบแอปเดี่ยว ที่ออกแบบให้เข้ากับหน้าจอเล็กและการป้อนข้อมูลแบบสัมผัสของสมาร์ตโฟนถูกย้ายมาสู่เดสก์ท็อป จึงเกิดความขัดแย้งกับรูปแบบการใช้งานหลายหน้าต่างที่ตั้งอยู่บนสมมติฐานว่ามีคีย์บอร์ดและเมาส์ที่แม่นยำ
- กรณีของแอป Windows 10, Slack, Chrome, Firefox 75, QT5 และแอป Gnome แสดงให้เห็นการเปลี่ยนแปลงที่ทำให้แนวคิด UI เดิมพร่าเลือนซ้ำแล้วซ้ำเล่า เช่น วิดเจ็ตบนแถบชื่อหน้าต่าง, megabar, แถบเลื่อนซ่อนอัตโนมัติ, และแถบเมนูที่หายไป
- เมนูดรอปดาวน์, แถบชื่อหน้าต่างที่ชัดเจน, การแสดงหน้าต่างที่มีโฟกัส, ปุ่มและช่องป้อนข้อมูลที่แยกแยะได้ เคยเป็น ภาษากลาง ที่เรียนรู้ข้ามแพลตฟอร์มได้ แต่พฤติกรรมที่ต่างกันไปในแต่ละแอปกลับบังคับให้ต้องเรียนรู้เพิ่มเติมแยกกัน
- การประหยัดพื้นที่หน้าจอ, ความหลีกเลี่ยงไม่ได้ของการเปลี่ยนแปลง, ข้อจำกัดข้ามแพลตฟอร์มของ Electron, หรือเหตุผลว่าเป็นซอฟต์แวร์ฟรี ล้วนยากจะใช้เป็นข้ออ้างในการทำลายแนวคิด UI ที่ผ่านการพิสูจน์มาแล้ว และโครงการกับบริษัทที่มีอิทธิพลก็ควรมี มาตรฐานด้านความสม่ำเสมอ
กฎร่วมกันที่อ่อนแอลงใน GUI บนเดสก์ท็อป
- ราวปี 1994~2012 ผู้ใช้ที่มีทักษะการใช้คอมพิวเตอร์ในระดับเหมาะสมแทบจะสามารถนั่งหน้าระบบ GUI ของระบบปฏิบัติการใดก็ได้แล้วปรับตัวได้อย่างรวดเร็ว
- ไม่ใช่แค่ Windows, MacOS, CDE, OpenStep, OS/2 เท่านั้น แต่แม้แต่สภาพแวดล้อมอย่าง Amiga, Atari, BeOS ก็ยังมี ความเหมือนกัน มากกว่าความต่าง
- ในเวลานั้น หน้าต่างโดยทั่วไปใช้แถบชื่อหน้าต่างเพื่อการลาก การระบุตัวตน และการแสดงว่าอินพุตโฟกัสอยู่ที่ใด
- เมนูดรอปดาวน์ มาตรฐานอย่าง File, Edit, View, Help ทำให้การสำรวจความสามารถของแอปใหม่และการเรียนรู้คีย์ลัดทำได้ง่าย
- ปุ่ม ช่องป้อนข้อมูล และวิดเจ็ตอื่น ๆ สังเกตได้ง่ายว่าเป็นองค์ประกอบที่โต้ตอบได้ ด้วยสัญญาณทางภาพอย่างขอบนูนแบบ 3D bevel
- แม้จะมีบางแอปที่เป็นข้อยกเว้นและไม่ทำตามกฎ แต่ในพื้นที่พื้นฐานที่สำคัญ ซอฟต์แวร์ส่วนใหญ่ก็ยังใช้ธรรมเนียมเดียวกัน
ปัญหาเมื่อแนวคิดของสมาร์ตโฟนย้ายมาสู่เดสก์ท็อป
- บนแพลตฟอร์มที่ค่อนข้างใหม่อย่างสมาร์ตโฟน วิธีป้อนข้อมูลและการโต้ตอบกับหน้าจอแตกต่างจากเดสก์ท็อป จึงอาจต้องใช้แนวคิดใหม่
- ปัญหาคือกระแสที่แนวคิดนี้แพร่เข้ามายังเดสก์ท็อป ซึ่งสามารถใช้คีย์บอร์ดและการควบคุมเมาส์ระดับพิกเซลได้
- เมื่อรวมกับ flat design องค์ประกอบ UI มีแนวโน้มจะใหญ่ขึ้น แต่ในขณะเดียวกันก็แยกออกจากของตกแต่งหรือเนื้อหาได้ยากขึ้น
- การออกแบบแอปพลิเคชันเดสก์ท็อปกำลังอ่อนแรงลงจากสมมติฐานที่ว่าสามารถแสดงหลายแอปและหลายหน้าต่างพร้อมกันได้ และขยับไปสู่รูปแบบใช้งานแอปเดี่ยวแบบสมาร์ตโฟน
- การเลี่ยงธรรมเนียม UI ของเดสก์ท็อปที่ฝังแน่นเป็นความจำของกล้ามเนื้อสำหรับผู้ใช้จำนวนมากแล้ว กลับนำไปสู่ความไม่สะดวกที่มากขึ้น
การจัดการหน้าต่าง: แถบชื่อหน้าต่างไม่ใช่พื้นที่สำหรับหน้าต่างอีกต่อไป
- แถบชื่อหน้าต่างของแอปยอดนิยมหลายตัวบน Windows 10 แม้จะเป็นภาพที่จับจากคอมพิวเตอร์เครื่องเดียวกันภายในไม่กี่นาที ก็ยังเห็นได้ชัดถึง ความไม่สม่ำเสมอ
- ทั้งหกหน้าต่างต่างก็เป็นหน้าต่างที่กำลังใช้งานอยู่ แต่ Outlook กับ Slack ดูแทบไม่ต่างจากสถานะไม่ใช้งาน และหน้าต่างอื่น ๆ ก็แทบแยกความต่างระหว่าง active/inactive ได้ยาก ยกเว้น cmd.exe
- แถบชื่อหน้าต่างส่วนใหญ่มีไอคอนเครื่องมือ แท็บ เมนูดรอปดาวน์ หรือการผสมกันของสิ่งเหล่านี้
- ความกว้างของพื้นที่ที่คลิกได้สำหรับการกระทำแบบดั้งเดิม เช่น การย้ายหน้าต่าง การโฟกัส หรือการดึงขึ้นมาด้านหน้า จึงต่างกันไปตามแต่ละแอป
- ผู้ใช้ที่เรียนรู้ว่าแถบชื่อหน้าต่างคือพื้นที่สำหรับควบคุมหน้าต่าง อาจเผลอไปเรียกใช้ฟังก์ชันของแอปโดยไม่ตั้งใจได้ง่าย
- ยังมีองค์ประกอบอย่างโลโก้เล็ก ๆ ของ Visual Studio Code ที่ดูเหมือนไอคอน แต่จริง ๆ แล้วเป็นเพียงของตกแต่ง
- จากหกแอป มีสี่แอปเป็นแอปของ Microsoft จึงมีความเสี่ยงที่ดีไซน์ไม่เป็นระเบียบเช่นนี้จะกระจายตัวราวกับเป็นมาตรฐาน
- ใน Slack เวอร์ชันล่าสุด พื้นที่สำหรับลากย่อ-ขยายที่ขอบบนและมุม ซึ่งทำได้มาตั้งแต่ยุค Windows 2 ถูกลดลงอย่างมาก
- พื้นที่สีแดงหมายถึง hotspot ที่เหลืออยู่สำหรับย่อ-ขยาย และพื้นที่สีน้ำเงินหมายถึง hotspot สำหรับย้ายหน้าต่าง
- พื้นที่ที่เหลือถูกยึดครองโดยชุดวิดเจ็ตที่ไม่เป็นมาตรฐาน
- อัปเดตวันที่ 22 เมษายน 2020 ทำให้ Slack เวอร์ชันเดสก์ท็อปเริ่มแสดงแถบชื่อหน้าต่างของหน้าต่างที่ไม่ active ให้มืดลงเล็กน้อย
UI ของเบราว์เซอร์: tooltip และแถบที่อยู่กำลังสั่นคลอนแนวคิดเดิม
- Chrome มี tab tooltip ขนาดใหญ่ที่แสดงขึ้นทันทีเมื่อเอาเมาส์ไปชี้บนแท็บ
- tooltip ของแท็บในเบราว์เซอร์ทั่วไปมักจะแสดงเป็น tooltip ลอยขนาดเล็กหลังหน่วงเวลาเล็กน้อย
- tooltip แบบใหม่ของ Chrome ปรากฏขึ้นทันทีโดยไม่มีการหน่วง และบังพื้นที่ขนาดใหญ่ของ UI ด้านล่าง
- แม้ประโยชน์ของ tooltip ของแท็บเองก็ยังถกเถียงกันได้ แต่รูปแบบนี้ถูกมองว่าเป็นองค์ประกอบที่รบกวนและไม่จำเป็น
- การเปลี่ยนแปลงของ URL bar ใน Firefox 75 ถูกเรียกว่า megabar
- มันเด้งออกมาในจังหวะที่คาดเดาได้ยาก
- ปิดหรือเอาออกได้ยาก และยังทับแถบ bookmarks ด้านล่าง
- ช่องป้อนข้อความเป็นองค์ประกอบ UI เก่าแก่ที่อย่างน้อยตั้งแต่ต้นทศวรรษ 1980 แนวคิดพื้นฐานแทบไม่เปลี่ยน แต่ megabar กลับเปลี่ยนพฤติกรรมของมันอย่างมาก
แถบเลื่อน: การซ่อนและคอนทราสต์ต่ำทำให้รับรู้ตำแหน่งได้ยาก
- แถบเลื่อนซ่อนอัตโนมัติอาจมีประโยชน์บนสมาร์ตโฟน เพราะช่วยเพิ่มพื้นที่หน้าจอขนาดเล็ก และใช้นิ้วโป้งเลื่อนได้ทันที
- แต่บนเดสก์ท็อป แถบเลื่อนทำหน้าที่เป็น ตัวบอกสถานะ ที่แสดงตำแหน่งปัจจุบันของเนื้อหา
- ผู้ใช้สามารถรู้ตำแหน่งปัจจุบันได้โดยไม่ต้องหยุดสิ่งที่กำลังทำอยู่แล้วไปจับเมาส์
- ยังตรวจสอบตำแหน่งได้แม้ในหน้าต่างที่ไม่มีโฟกัส
- ในโปรแกรมอ่านไฟล์ล็อกแบบ tailing หรือ command prompt ที่มี debug stream แถบเลื่อนช่วยให้รู้ว่ากำลังดูเอาต์พุตล่าสุดอยู่หรือไม่
- เมื่อใช้แถบเลื่อนซ่อนอัตโนมัติ การตรวจสอบนี้ทำได้ยากขึ้น และต้องใช้วิธีอื่นที่ชัดเจนน้อยกว่าหรือยุ่งยากกว่า
- การเรนเดอร์แถบเลื่อนค่าเริ่มต้นของ QT5 ทำให้แยกแถบกับรางได้ยากและมีคอนทราสต์ต่ำมาก
- ต่อให้รู้ว่าส่วนที่สว่างกว่าเล็กน้อยคือแถบจริง ก็ยังคลิกพลาดบ่อย
- บนหน้าจอโน้ตบุ๊กราคาถูกและเก่า อาจแยกความต่างระหว่างแถบกับรางได้ยาก
- แม้ QT5 จะสามารถตั้งค่าให้ดูแบบดั้งเดิมกว่าได้ผ่านเครื่องมือ แต่ผู้ใช้ใหม่มักไม่รู้เรื่องนี้ จึงทำให้รูปลักษณ์ค่าเริ่มต้นสำคัญมาก
แถบเมนูและความไม่สอดคล้องกันของแอป Gnome
- แถบเมนูเคยเป็น ตัวหารร่วมที่เล็กที่สุด ซึ่งทำงานคล้ายกันพอสมควรใน Windows, Mac และสาย Unix
- รูปแบบดั้งเดิมอย่าง File, Edit, View เคยเป็นเส้นทางมาตรฐานสำหรับสำรวจความสามารถของแอป แต่ดีไซน์ของ Gnome กลับแทนที่สิ่งนี้ด้วยวิธีอื่น
- เมนู hamburger อาจมีประโยชน์บนสมาร์ตโฟน แต่บนเดสก์ท็อปที่ใช้หน้าจอกว้าง เหตุผลเรื่องพื้นที่แนวนอนไม่พอแทบไม่หนักแน่นนัก
- ใน Gnome เมนู hamburger ดูเหมือนถูกใช้เพื่อเก็บคำสั่ง UI ที่ไม่ได้ถูกวางไว้ที่อื่น
- เมนู hamburger ของ Evince มี Open, Save, Print, Close
- เมนู hamburger ของ Gnome-MPV ไม่มี Open หรือ Close และการเปิดไฟล์ต้องกดปุ่มไอคอนเครื่องหมายบวกทางซ้าย
- ปุ่มไอคอนแอปของ Gnome-MPV มีตัวเลือก preferences และ quit แต่ปุ่มไอคอนแอปของ Evince กลับให้เมนูอีกแบบหนึ่ง
- เพราะ ความสม่ำเสมอ ระหว่างแอปลดลง ผู้ใช้จึงต้องเรียนรู้ตำแหน่งที่ต่างกันเพื่อค้นหาฟังก์ชันเดียวกัน
- ต่างจากเมนูดรอปดาวน์ทั่วไปหรือเมนู hamburger บางแบบ เมนูเหล่านี้เมื่อเปิดแล้วกลับหาวิธีนำทางด้วยคีย์บอร์ดได้ยาก
การรวมแถบชื่อหน้าต่างของ Gnome และแถบเครื่องมือเพิ่มเติม
- แอป Gnome ใช้แนวคิดใหม่ที่รวมแถบเครื่องมือเข้ากับแถบชื่อหน้าต่าง ซึ่งเท่ากับทำให้รูปแบบการยึดพื้นที่แถบชื่อหน้าต่างที่วิจารณ์ในกรณีแอป Windows กลายเป็นแนวปฏิบัติอย่างเป็นทางการ
- เมื่อนำไปใช้กับตัวจัดการหน้าต่างอื่น อาจเห็นปุ่มปิดซ้ำกันทั้งบนแถบชื่อหน้าต่างและในตัวแอปเอง
- เนื่องจากยังต้องเหลือพื้นที่บางส่วนไว้สำหรับการย้ายหน้าต่าง วิดเจ็ตที่แต่ก่อนอาจอยู่ในแถบเครื่องมือใต้แถบชื่อหน้าต่างจึงกลายเป็นโครงสร้างที่ต้องเปิดแยกออกมา
- ช่องค้นหาของ Evince มาในรูปแบบที่ต้องขยายออกแยกต่างหาก
- แถบเครื่องมือคำอธิบายประกอบมีเพียงสองไอคอน แต่กลับต้องใช้ไอคอนแยกอีกหนึ่งอันเพื่อเปิดมัน
คำตอบต่อข้อโต้แย้งที่พบบ่อย
- คำพูดว่า “เทคโนโลยีก้าวหน้าและไม่อาจหยุดการเปลี่ยนแปลงได้” ใกล้เคียงกับสำนวนสำเร็จรูปที่ใช้โดยไม่มีเหตุผลรองรับจริง
- การเปลี่ยนดีไซน์ UI ไม่ใช่พลังของธรรมชาติ แต่เป็นการตัดสินใจของมนุษย์
- การเปลี่ยนแปลงไม่ได้หมายถึงการปรับปรุงเสมอไป และเป้าหมายควรเป็นการปรับปรุง ไม่ใช่การเปลี่ยนเพียงเพื่อเปลี่ยน
- ข้อโต้แย้งว่าเป็นการ “ติดอยู่กับอดีต” อาจถูกในแง่ที่ผู้เขียนชอบองค์ประกอบ UI แบบดั้งเดิม แต่ไม่ได้หมายความว่าเดสก์ท็อปสมัยใหม่ทั้งหมดต้องหน้าตาเหมือน Windows 95 หรือ CDE
- ยังมีหนทางอื่นในการปรับปรุงรูปลักษณ์และประสบการณ์ของ UI โดยไม่ทำลายแนวคิดพื้นฐาน
- สำหรับข้อโต้แย้งว่า “แอป Electron ทำตามมาตรฐานของแพลตฟอร์มเดียวไม่ได้” นั้น แอปข้ามแพลตฟอร์มยิ่งควรรักษาแนวคิดที่ถ่ายทอดข้ามแพลตฟอร์มร่วมกันได้
- เมนูดรอปดาวน์ แถบชื่อหน้าต่างที่เรียบร้อย และการแสดงโฟกัสของหน้าต่างอย่างชัดเจน ไม่ใช่แนวคิดที่ทำได้ยาก
- เฟรมเวิร์กข้ามแพลตฟอร์มควรทำให้แนวคิดเหล่านี้นำไปใช้ได้ง่าย และทำให้การหลีกเลี่ยงทำได้ยากขึ้น
- แม้แต่ข้อโต้แย้งว่า “ไม่ควรบ่นกับซอฟต์แวร์ฟรี” ก็ยังใช้ไม่ได้เต็มที่ เพราะโครงการ FOSS ขนาดใหญ่อย่าง Gnome และ KDE มีอิทธิพลอย่างมากต่อผู้ใช้ ดีไซเนอร์ และโปรแกรมเมอร์ เช่นเดียวกับ Microsoft หรือ Google
- หากเป็นโครงการที่ต้องการเป็นแบบอย่าง ก็ควรถูกใช้ มาตรฐาน ที่เหมาะสมกับสถานะนั้น
การประหยัดพื้นที่หน้าจอและความซับซ้อนของ UI
- การใส่องค์ประกอบลงในแถบชื่อหน้าต่างอาจช่วยประหยัดพื้นที่หน้าจอได้บ้าง
- แต่โดยทั่วไปแล้ว พื้นที่หน้าจอไม่ได้เป็นปัญหาใหญ่เหมือนในอดีตอีกต่อไป
- ผู้ใช้ที่ใช้งานคอมพิวเตอร์มากพอสามารถซื้อจอมอนิเตอร์ขนาดใหญ่ความละเอียด 2560x1440 ได้ในราคาประมาณ US$200
- แม้แต่โน้ตบุ๊กราคาถูกที่สุดก็มักให้ความละเอียดอย่างน้อย 1366x768
- ปัญหาเรื่องพื้นที่หน้าจอกลับรุนแรงขึ้นเพราะพื้นที่ว่างกว้าง ๆ ในดีไซน์ UI ปัจจุบันเอง
- มีกรณีที่หน้าต่างคำขอธรรมดาในอดีตกลับดูเหมือนแอปแบบเต็มหน้าจอ
- สำหรับผู้ใช้ที่เขียนโค้ดทั้งวันบนโน้ตบุ๊ก 13 นิ้ว ผู้เขียนเห็นว่าควรกังวลเรื่องสุขภาพหลัง คอ มือ และไหล่มากกว่าพิกเซลไม่กี่จุด
- แม้จะจริงที่การออกแบบ UI เป็นเรื่องยากและไม่สามารถทำให้ผู้ใช้ทุกคนพอใจได้เสมอ แต่ก็ไม่ใช่เหตุผลที่จะจงใจทำลายแนวคิด UI พื้นฐานที่ผ่านการพิสูจน์มาหลายทศวรรษ
- หากผู้ใช้ต้องเรียนรู้รายละเอียดความต่างของการตกแต่งและวิธีควบคุมหน้าต่างในแต่ละแอปแยกกัน ก็เท่ากับต้องเสียเวลาและพลังงานซ้ำ ๆ ไปกับการตีความความต่างเหล่านั้น
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ช่วงราว 10 ปีที่ผ่านมา รู้สึกเหมือนต้องสู้กับ ทีม UI/UX อยู่ตลอด และประเด็นหลักดูเหมือนอยู่ที่เกณฑ์การออกแบบได้ย้ายจากเครื่องมือสำหรับมืออาชีพไปสู่แพラダイムการบริโภคคอนเทนต์สำหรับผู้บริโภค
เมื่อ 20 ปีก่อน ซอฟต์แวร์ส่วนใหญ่เป็นเครื่องมือสำหรับมืออาชีพ แต่ตอนนี้ถ้าวัดตามปริมาณการใช้งาน ซอฟต์แวร์สำหรับผู้บริโภคอย่างวิดีโอและโซเชียลมีเดียกลายเป็นศูนย์กลาง นักออกแบบพยายามเอากฎของการบริโภคคอนเทนต์มาใช้กับผลิตภัณฑ์ที่มีไว้เพื่อ “ทำงานให้เสร็จ” ด้วย
ตัวอย่างเด่น ๆ คืออ้างว่า “ดูสะอาดและเข้าใจง่ายขึ้น” แล้วซ่อนเครื่องมือที่เคยมองเห็นได้ไว้หลัง เมนูจุดสามจุด เปลี่ยนการคลิกหนึ่งครั้งให้เป็นสองครั้ง และผู้ใช้เครื่องมือต้องทำแบบนั้นซ้ำวันละหลายร้อยครั้ง ตารางที่เมื่อก่อนเคยแสดง 20 รายการพร้อมรายละเอียด 6–8 อย่างในพื้นที่เดียวกัน ตอนนี้แสดงได้แค่ 10 รายการกับรายละเอียด 4 อย่าง แดชบอร์ดแสดงกราฟแค่ 4 อันแทนที่จะเป็น 10 อัน เมนูกินพื้นที่ด้านบนของแอป 10–20% และหัวข้อ H1 ก็ใหญ่โตขึ้น
มีป้าคนหนึ่งที่เปลี่ยนตำแหน่งเฟอร์นิเจอร์อยู่เรื่อย ๆ ไม่ใช่เพราะมีการจัดวางที่ดีกว่า แต่เพราะเบื่อการจัดวางปัจจุบัน ผมเห็นแนวโน้มแบบนี้ได้บ่อยในฝั่ง PM หรือ UX การเพิ่มมุมมองตารางแบบที่สี่ให้ผลิตภัณฑ์แล้วบอกว่า “ต้องใช้สไตล์ที่ต่างไปโดยสิ้นเชิง” ก็ไม่ได้เป็นเพราะมันดีกว่าเช่นกัน หลัง COVID ผมใช้ Google Meet กับเพื่อน ๆ ทุกสัปดาห์ และแทบทุกครั้งจะมีอะไรบางอย่างเปลี่ยนไป ล่าสุด flow การขอเข้าร่วมก็เปลี่ยนอีก แต่ไม่ได้ดีขึ้นเลย
ถึงจุดหนึ่งก็ได้แต่ยอมรับ และรอจนกว่าวิธีที่ดีกว่าจะกลายเป็น best practice ใหม่
แต่กระแสที่เดิมตั้งใจจะแก้ปัญหานั้นเหมือนถูกขยายต่อเนื่องไปเรื่อย ๆ จนไม่มีใครสังเกตว่าเลยจุดที่ควรไปแล้ว หรือบางทีนักออกแบบรุ่นใหม่ที่ไม่รู้บริบท UI แบบเก่า อาจกำลังเอาใบสั่งยาเดิมไปใช้ซ้ำกับ UI ที่ถูกแก้ไปแล้วก็ได้
มันรู้สึกเหมือนไม่ใช่ลูกตุ้มที่กำลังแกว่งกลับ แต่เหมือนถึงความเร็วหลุดพ้นไปแล้ว
ปุ่มและ scrollbar ทุกอันบนหน้าจอคอยบอกอยู่ตลอดว่า “นี่คือสิ่งที่ทำได้แต่ยังไม่ได้ทำ” ซึ่งสำหรับนักออกแบบแต่ละคนอาจน่ารำคาญและโจ่งแจ้งเกินไป จนสุดท้ายอยากลบมันออกให้หมด
ผมสงสัยว่าเมื่อไรแนวทาง UI จะกลับไปสู่ skeuomorphism ในระดับเท่าที่ผู้ใช้ทั่วไปต้องการ แม้แต่แพราดายม์เว็บลิงก์ก็ดูยากเกินไปสำหรับผู้สูงอายุหรือผู้ใช้ที่มีประสบการณ์น้อย และสักวันมันคงปรากฏเป็นข้อมูลที่หลีกเลี่ยงไม่ได้
PM และคนทำ UX ก็ได้รับเงินให้ทำงาน และงานของพวกเขาคือการเปลี่ยน UI/UX ถ้าพวกเขาได้รับเงินให้ดูแลซอฟต์แวร์ที่เกือบสมบูรณ์แล้ว ก็คงใช้เวลาไปกับการ refactor หรือแก้ไขเล็ก ๆ น้อย ๆ ต่างกันตรงที่ไม่ใช่ทุกอย่างที่พวกเราทำจะมองเห็นได้ต่อผู้ใช้
ฝั่ง UX จะทำอะไรก็ช่าง ขอแค่ให้กด Ctrl-K แล้วพิมพ์ตัวอักษรขึ้นต้นของคำสั่งที่ต้องการได้ก็พอ
ในฐานะ UX designer ที่ออกแบบเว็บ มือถือ และ UI ที่เกี่ยวข้องมาตั้งแต่ราวปี 2000 ผมเห็นด้วยว่า การเปลี่ยนเพื่อให้ได้เปลี่ยน สร้างปัญหาด้าน usability มากมาย
แต่ปัญหาที่ใหญ่กว่านั้นคือการถกเถียงเชิงวิชาชีพหรือการวิเคราะห์การออกแบบอย่างจริงจังแทบจะหายไปจากหมู่คนที่ลงมือออกแบบจริง ๆ แล้ว
นักออกแบบจำนวนมากที่ทำงานด้วยกันไม่มีคำศัพท์หรือความรู้พอจะอธิบายว่าอะไรทำให้บางอย่าง “ใช้งานได้” ในความหมายกว้าง ๆ และยังขาดความสามารถในการแก้ปัญหา interaction design หรือการนำเสนอข้อมูลที่ละเอียดอ่อน ไม่มีความรู้หรือความสนใจใน heuristic พื้นฐาน จึงไม่รู้ด้วยซ้ำว่าควรเริ่มจากตรงไหน
ดังนั้นพวกเขาจึงใช้ชีวิตอยู่กับการปรับสี รูปร่าง และเอฟเฟกต์ใน Figma แล้วอย่างมากก็ส่งรูปแบบต่าง ๆ ไม่กี่แบบของ UI เดิมไป “ทดสอบกับผู้ใช้” มันกลายเป็นลัทธินวัตกรรมแบบ “ไม่ใช่สายเทคนิค” ที่จงใจไม่รู้เรื่อง และสูญเสียเป้าหมายเดิมไปโดยสิ้นเชิง
การบอกว่าผมอับอายในอาชีพของตัวเองไม่ใช่คำพูดเกินจริง มันล้มเหลวครั้งใหญ่เกินไป
ตอนนั้นผมคิดว่าเราคงได้ชิมโลกที่นักออกแบบ UI/UX คุ้นเคยกันมากกว่าเราอยู่หน่อย ๆ แต่บางทีอาจไม่ใช่ก็ได้
หลายคนแทนที่จะคิดถึงบริบท ระบบนิเวศ และผลเชิงระบบของการตัดสินใจด้านการออกแบบ กลับถามคำถามแคบ ๆ ด้วยงานวิจัยที่อ่อนแอ แล้วหวนกลับไปทำให้มัน “สวย” อีกครั้ง
ผมมีความรู้พื้นฐานมาก ๆ จากบทนำ HCI และจากนักออกแบบที่เก่ง ๆ แต่ยังไม่ถึงระดับเทคนิคหรือเป็นทางการ
เท่ากับใส่แรงงานทางความคิดเท่าขั้นต่ำที่จำเป็นเพื่อรับค่าจ้างเท่านั้น
ไม่ได้จะโทษพวกเขา คนเหล่านี้ทำงานอยู่ในสาขาที่อิ่มตัว และถูกชี้นำด้วยอารมณ์แปรปรวนกับรสนิยมของผู้บริหารที่ให้ความสำคัญกับเสน่ห์ทางภาพหรือความรู้สึกมากกว่า usability
สุดท้ายมันก็คือ การตลาด ถ้าผู้คนไม่อยากใช้ ผลิตภัณฑ์จะใช้ง่ายแค่ไหนก็แทบไม่มีความหมาย มีหลายอุตสาหกรรมที่ทำของที่มี usability สูง เช่น กองทัพ แต่โดยทั่วไปมันก็แค่หน้าตาไม่น่าดู
ผู้เขียนบอกว่าตนมีประสบการณ์กับ macOS ไม่มากพอจึงขอสงวนความเห็นไว้ แต่ปรากฏว่าที่นี่ก็เกิดการถดถอยแบบเดียวกัน โดยเฉพาะ Apple ดูเหมือนจะหมกมุ่นกับการซ่อนฟังก์ชันไว้หลังเอฟเฟกต์ hover ที่เชื่องช้าและเฉดสีเทาที่ละเอียดอ่อนเกินไป
อาจเป็นเพราะอยากให้ดูประณีต แต่กำลังทำลาย ความสามารถในการค้นพบ ของอินเทอร์เฟซ ต่อให้เรียนรู้แล้วว่ามีอะไรบางอย่างอยู่หลังแอนิเมชัน hover ก็ยังเล็งได้ยาก เพราะพื้นที่เป้าหมายจริงจะมองเห็นและเปิดใช้งานก็ต่อเมื่อเลื่อนเมาส์ไปตรงตำแหน่งนั้นอย่างแม่นยำแล้วเท่านั้น แอป Music และการทำงานของการแจ้งเตือนเป็นกรณีที่หนักเป็นพิเศษ
บนแถบชื่อหน้าต่างก็ไม่ชัดเจนเช่นกันว่าส่วนไหนลากได้ ผมไม่เคยเข้าใจเลยว่าทำไมพิกเซลหนึ่งลากหน้าต่างได้ แต่พิกเซลที่หน้าตาเหมือนกันทุกอย่างซึ่งอยู่ถัดลงไปกลับทำไม่ได้
ในความเห็นของผม ความใช้งานง่ายของ UI จาก Apple ไม่ได้เป็นจุดแข็งมานานแล้ว ในฐานะคนที่ต้องใช้ทั้ง Mac และ PC, macOS ก็แย่พอ ๆ กับ PC หรือแย่กว่าด้วยซ้ำในหลายด้าน
สิ่งที่ Apple ทำได้ดีคือ ความใช้งานง่ายของการผสานอุปกรณ์ ทั่วทั้ง ecosystem ของตน
แต่ macOS จะเล่นแอนิเมชันที่อืดอาดเวลาสลับหน้าจอ ปิดไม่ได้ และเลือกได้แค่หนึ่งในสองแบบที่ช้าพอ ๆ กัน
ผมนึกเหตุผลดี ๆ ที่จะอธิบายเรื่องนี้ไม่ออก ไม่รู้ว่า user model แบบไหนถึงสรุปได้ว่า “แอนิเมชันช้า ๆ ตอนสลับหน้าต่างเป็นเรื่องดี”
การพิมพ์สองหน้าไม่รองรับ ต้องทำด้วยมือ และบางแอปพิมพ์หน้าออกมาเรียงย้อนกลับจนต้องเอามาจัดใหม่
ถ้าอยากให้
.บนแป้นตัวเลขเป็น.ไม่ใช่,ก็ต้องดาวน์โหลดแอปเพื่อให้ได้ค่าเริ่มต้นที่ควรจะเป็นตามปกติถ้าไม่ได้ใช้คีย์บอร์ดอังกฤษ ในเทอร์มินัลก็ใช้ Alt+. ไม่ได้
ถ้าจะรันแอปที่ดาวน์โหลดมา ต้องลองรันก่อน ยอมรับความล้มเหลว แล้วไปที่การตั้งค่าและความปลอดภัยเพื่อหาแอปที่ถูกบล็อกแล้วอนุญาต แย่กว่า Windows Vista อีก
ถ้าจะให้สิทธิ์แอปใดแอปหนึ่ง ก็ต้องรู้ประเภทของสิทธิ์ก่อน และค้นหาตามแอปไม่ได้ เรื่องแบบนี้เกิดขึ้นต่อไปเรื่อย ๆ
ทุกวันนี้ผมยังเสียเวลามากเกินไปกับการพยายามถอดความหมายรูปไอคอนสีเทาอมฟ้าใน sidebar ของ Finder
มันเดินหน้าไปทางการซ่อนโครงสร้างไฟล์ และแม้กระทั่ง แนวคิดของไฟล์ เองด้วยซ้ำ ถ้าถามผู้ใช้ Windows หรือ Mac ที่ไม่ใช่สายเทคนิคว่าไฟล์ถูกเก็บไว้ที่ไหน พวกเขาไม่รู้ ถามว่าอยู่บนคลาวด์หรือไม่ก็ไม่รู้
ที่แย่กว่านั้นคือ เช่นเดียวกับ UI แต่ละแอปมีตำแหน่งจัดเก็บข้อมูลไม่สอดคล้องกัน และอย่าลืมเรื่องโง่ ๆ อย่างการซ่อนนามสกุลไฟล์ด้วย
Windows ยังโกหกผู้ใช้ที่ไม่ได้ใช้ภาษาอังกฤษอีกด้วย เช่น ในภาษาเยอรมันมันบอกว่าโฮมไดเรกทอรีอยู่ใน “Benutzer” แต่จริง ๆ แล้วไม่มีไดเรกทอรีแบบนั้น มีแต่ “Users” ความพยายามจะซ่อนความซับซ้อนลงเอยด้วยการสร้างความสับสนและความซับซ้อนที่มากกว่าเดิม
นึกถึงอีกปัญหาหนึ่งที่เคยเจอตอนงาน iOS ประจำงานแรก ในคำอธิบายแอปเขียนคำว่า “button” และคำแปลเยอรมันคือ “Knopf” แต่โดนตัวกรองคำต้องห้ามของ Apple อาจเป็นเพราะ “Knopf” เป็นคำแปลของ “knob” ด้วย แต่ในภาษาเยอรมัน “Knopf” ไม่มีนัยทางเพศแบบคำว่า “knob” ในภาษาอังกฤษ
Apple ให้ความรู้สึกว่าเป็นฝ่ายที่ผลักดันอย่างหนักที่สุดในการออกจากแนวคิดเรื่อง “ไฟล์” ไปสู่การย้าย “คอนเทนต์” ไปมาระหว่างแอปต่าง ๆ แต่แต่ละแอปก็มี paradigm ของการแชร์ นำเข้า และส่งออกที่ต่างกันเล็กน้อย
ตอนนี้ยังมีแอป “Files” ของ iCloud Drive อีกด้วย มันหมายความว่าอะไร จะรู้ได้อย่างไรว่าสิ่งนั้นอยู่ในโทรศัพท์ของผมหรือเป็นแค่การแสดงสิ่งที่อยู่ใน iCloud Drive? ไอคอนรูปเมฆหมายความว่าดาวน์โหลดแล้วหรือยังไม่ได้ดาวน์โหลด แล้วสีเทาที่เข้มขึ้นนิดหนึ่งกับอ่อนลงนิดหนึ่งหมายถึงอะไรอีก ผมก็ไม่รู้
ทั้งที่แม้แต่ผู้ใช้ที่ไม่ใช่สายเทคนิคที่สุดก็รู้ว่านามสกุลไฟล์คืออะไรและทำงานอย่างไร
ไม่รู้จริง ๆ ว่า Microsoft กำลังทำอะไรอยู่
การถอยหลังอีกอย่างของ Explorer คือ เมื่อก่อนจะมีเครื่องหมาย “+” เล็ก ๆ ข้างไดเรกทอรีที่มีเนื้อหา แต่ Microsoft เอาออกไปแล้ว
พอเลื่อนเคอร์เซอร์ผ่านแผงด้านซ้าย มันถึงโผล่มาโดยไม่มีเหตุผล หรือไม่ก็อาจถอยหลังยิ่งกว่าเดิมจากเครื่องหมาย “+” ที่เข้าใจกันทั่วไปไปเป็นสามเหลี่ยมโง่ ๆ
ตอนนี้ตามความถดถอยไม่ทันแล้ว
การใช้งานบนเดสก์ท็อปถูกลดทอนลงเพราะต้องรองรับมือถือ แต่ในหลายสภาพแวดล้อมก็ยังแทบไม่มีตัวตนบนมือถืออยู่ดี ถึงเวลาแล้ว ขอเถอะ เอา แถบเลื่อน กลับมาให้หน่อย
ครั้งหนึ่งผมกับนักพัฒนาเสียเวลาไปมากเพื่อหาการตั้งค่าบางอย่าง แต่ไม่มีสัญญาณบอกเลยว่าด้านล่างของหน้าต่างยังมีเนื้อหาและช่องทำเครื่องหมายอยู่อีก ถ้าเป็นยุคก่อนแถบเลื่อนที่ถูกซ่อนจะค่อย ๆ โผล่มา เรื่องนี้ก็คงเห็นได้ชัดอยู่แล้ว
ปัญหาคือถ้าตัวชี้อยู่เหนือแผงนำทาง ซึ่งเป็นตำแหน่งที่มันแทบจะอยู่ตลอดเวลา แถบเลื่อนของแผงอื่นจะถูกซ่อนไว้ พอไม่มีเบาะแสทางสายตาอย่างแถบเลื่อน ก็ไม่มีเหตุผลให้ย้ายตัวชี้ไปเพื่อค้นพบว่าแผงอื่นยังมีเนื้อหาอยู่อีก ตอนนี้เส้นแบ่งทุกอย่างก็ถูกเอาออกไปหมด จนอาจไม่รู้ด้วยซ้ำว่านั่นเป็นแผงแยกต่างหาก
พอส่งภาพหน้าจอให้นักพัฒนาและยืนยันว่าผมใช้เวอร์ชันล่าสุดอยู่ คำตอบที่ได้คือ “เลื่อนลงครับ” แน่นอน คงเป็นผมเองที่โง่สินะ /s
เหมือนบนมือถือที่ต้องลองแตะองค์ประกอบ UI ทุกอย่างแบบสุ่มเพื่อหาว่ามันทำงานอย่างไร และทักษะที่เรียนรู้มาก็ใช้ได้กับแอปนั้นแอปเดียว แตะ, แตะค้าง, แตะค้างด้วยระยะเวลาต่างกัน, แตะให้เร็วขึ้น, กดรัว ๆ, “กูเกิลหา”, แล้วคราวนี้ต้องลากจากจุดที่ดูไม่เหมือนองค์ประกอบ UI เลยด้วยซ้ำ
“ช่องทำเครื่องหมายถูกติ๊กอยู่ไหม?” ไม่เคยคลุมเครือเท่า “สวิตช์สไลเดอร์เปิดอยู่ไหม?” ช่องทำเครื่องหมายยังกินพื้นที่หน้าจอน้อยกว่าด้วย นี่ไม่ได้ปรับให้เหมาะกับพื้นที่หรือความเป็นมิตรต่อผู้ใช้เลย แค่ปรับให้เหมาะกับหน้าตาเท่านั้น
มันอาจแย่ลงได้อีกถ้าทำให้แบนยิ่งขึ้นจนดูเหมือนสี่เหลี่ยมสองอัน พื้นที่สีเข้มคือส่วนของสวิตช์หรือเปล่า? ใครจะสน ขอแค่ดูสะอาดและไม่มีสิ่งรบกวนก็พอ ดูเหมือนผมคงเสียสมาธิเกินไปเพราะยังพอบอกสถานะสวิตช์ได้
หนังสือเล่มนั้นใช้พื้นที่อธิบายว่าควรหลีกเลี่ยงโหมด พร้อมบอกเหตุผลด้วย สิ่งที่ควรทำและไม่ควรทำเกี่ยวกับ UI ในหน้า 70 ยังควรค่าแก่การย้ำ
สิ่งที่ควรทำคือให้ผู้ใช้ควบคุมรูปลักษณ์ของวัตถุได้มากที่สุด ใช้คำกริยากับคำสั่งเมนูที่ทำงานได้ ทำให้คำเตือนอธิบายตัวเองได้ และใช้คอนโทรลกับกราฟิก ไม่ใช่แค่คำสั่งเมนู
สิ่งที่ไม่ควรทำคือใช้โหมดมากเกินไป บังคับให้ใช้คีย์บอร์ดกับงานที่ใช้เมาส์ง่ายกว่า หรือบังคับในทางกลับกัน โดยเฉพาะสิ่งที่เปลี่ยนหน้าตาของหน้าจอแบบไม่คาดคิดอย่างการเลื่อน วาดวัตถุใหม่โดยไม่จำเป็น และสร้างเมนูของตัวเองที่ชื่อเหมือนเมนูมาตรฐาน หนังสือเล่มนี้นิยามไว้ถึง About, File, Edit และสิ่งที่ควรอยู่ข้างใน
เราเข้ามาอยู่ในจุดต่ำสุดเฉพาะที่แปลก ๆ ซึ่งแต่ละแอปมี UI คำตอบเดียวที่ถูกต้อง ของตัวเอง และบังคับใช้รูปแบบเดียวกันกับผู้ใช้ทุกคน ในทางกลับกัน ในพื้นที่อย่างระบบควบคุมอุตสาหกรรมที่มีคน 1–3 คนใช้แอปที่มากับอุปกรณ์ราคา 50,000 ดอลลาร์ การจัดวางอินเทอร์เฟซมือถือแบบ responsive ทำได้ง่ายเหมือนทำสไลด์เด็ก และแดชบอร์ดแบบปรับแต่งเองก็แค่วิดเจ็ตเดียว
ถ้าคลาวด์เป็นคนทำรองเท้า ก็คงมีรองเท้าสำหรับสนามหญ้ากับสำหรับคอนกรีตแยกกัน แต่ทั้งหมดจะมีไซซ์เดียวกัน ถ้าเท้าใหญ่ก็ต้องตัดนิ้วเท้า ถ้าเท้าเล็กก็ต้องยัดอุปกรณ์เสริมเข้าไป
เกี่ยวกับข้อบ่นเรื่องการเลื่อน เมื่อดู UI เดสก์ท็อปรุ่นเก่า ๆ จะเห็นหลักการเฉพาะของเดสก์ท็อปที่ชัดเจนอย่างหนึ่งคือ คอนโทรลจะไม่เลื่อนเด็ดขาด มีแต่เนื้อหาเท่านั้นที่เลื่อน
ถ้าคอนโทรลไม่พอดีกับหน้าต่าง ก็จะไม่ทำให้หน้าต่างนั้นเลื่อนได้ แต่จะแบ่งเป็นแท็บ หรือใส่คอนโทรลเพิ่มเติมไว้ในหน้าต่างแยกที่เปิดผ่านปุ่ม อย่างน้อยใน Windows และ macOS ก็ดูเหมือนจะเป็นหลักการทั่วไป
ช่องทำเครื่องหมายดีกว่ามาก แค่ขออย่าให้มีป้ายกำกับแบบปฏิเสธซ้อนปฏิเสธก็พอ เช่น นักพัฒนาที่ทำให้การติ๊กหมายถึงการปิดใช้งานอะไรบางอย่าง ควรถูกยิงเป้าตอนรุ่งสาง
ผมไม่รู้ด้วยซ้ำว่าวงกลมที่เลื่อนไปมานั้นจริง ๆ แล้วเปิดหรือปิดอยู่ และครึ่งหนึ่งของกรณีก็ยังไม่รู้ด้วยซ้ำว่าระหว่างเปิดกับปิด อันไหนคือสิ่งที่ผมต้องการ มีปฏิเสธซ้อนปฏิเสธเต็มไปหมด ถ้อยคำก็ประหลาด และไม่มีการบอกผลกระทบจริง ๆ
ทั้งหมดดูบ้าบอไปหมด
มีคนบอกว่าที่อย่าง Google ช่วงหลังหมกมุ่นกับการทดสอบ A/B มากขึ้นเรื่อย ๆ แต่ในประวัติศาสตร์งานวิจัยผู้ใช้ ยังไม่เคยมี การทดสอบ A/B ใดวัดความเดือดดาลรุนแรงที่ปะทุจากผู้ใช้ระดับสูงเมื่อปุ่มถูกย้ายด้วยเหตุผลใดก็ตามได้อย่างถูกต้อง
เครื่องเล่นเพลงพกพา หรือถ้าพูดแบบสมัยก่อนก็คือ Walkman หรือเครื่องเล่น MP3 และถ้าพูดแบบสมัยนี้ก็คือวงการ DAP เป็นเรื่องที่ผมบ่นประจำ เครื่องเล่นที่ขายกันอยู่ตอนนี้ใช้งานแย่มากจนไม่เข้าใจว่าใครจะอยากซื้อ
ของดี ๆ หายไปเพราะโดนการผสมกันของบริการสตรีมมิงกับอุปกรณ์ Android เบียดตกไปหมดแล้ว ตอนนี้ไม่มีเครื่องเล่นที่เบา เรียบง่าย ความจุสูง มีปุ่มกดจริง และแบตเตอรี่อยู่ได้นานอีกแล้ว แบบที่ใส่กระเป๋าแล้ววิ่งได้โดยไม่ทำให้ช้ำอะไรแบบนั้น
หน้าจอที่อ่านง่าย โครงสร้างเมนูที่ปกติ อุปกรณ์ที่อ่านแท็กไฟล์ได้และลากเพลย์ลิสต์ลงไปได้เฉย ๆ แน่นอนว่ามีคนอยากได้ของแบบนี้ แต่ผู้ผลิตกลับทำก้อนอิฐยักษ์ที่มีปุ่มหมุนยื่นออกมา มุมประหลาด ๆ จอสัมผัสขนาดมหึมาที่กินแบต และระบบปฏิบัติการ Android ดัดแปลงอันเลวร้ายออกมา
“ตัวนี้มี DAC สองตัวนะครับ!” แล้วไงจริง ๆ? ผมใส่หูฟังนั่งอยู่บนรถเมล์ ไม่ได้อยู่ในห้องฟังเก็บเสียงที่มีมอนิเตอร์ราคา 10,000 ยูโร
รีวิวแทบไม่พูดถึงแง่มุมที่สำคัญที่สุดของอุปกรณ์เพลงพกพา แต่กลับชื่นชมกลิ่นหรือรสของเพลงเหมือนนักวิจารณ์ไวน์ อันนี้ครึ่งหนึ่งพูดเล่นนะ ยิ่งเป็นรีวิวเวอร์ที่มีชื่อเสียงมากเท่าไร ก็ยิ่งเขียนเรื่องไร้สาระมากขึ้นเท่านั้น และบ่อยครั้งหาแม้แต่การพูดถึงน้ำหนักหรือขนาดยังไม่เจอ
ต่อให้พูดถึงก็มักผิด เช่นบอกว่า “Shanling Q1 เป็นอุปกรณ์พกพาน้ำหนักเบา” ซึ่งไม่ใช่เลย มันเป็นก้อนอิฐแย่ ๆ ที่มี OS ห่วย อายุแบตไม่ดี และปุ่มที่ไวเกินไป ต่อให้เสียงดีแค่ไหน ถ้าใส่เพลย์ลิสต์ไม่ได้ หนัก และอินเทอร์เฟซแย่จนไม่อยากใช้ ผมก็ไม่สน
Rockbox บน Sansa Clip+ เมื่อ 13 ปีก่อนนั้นยอดเยี่ยม ถ้าด้วยเทคโนโลยีวันนี้สามารถทำของแบบนั้นซ้ำได้เป๊ะ ๆ ผมจะเลือกมันแทนก้อนอิฐยักษ์ราคาแพงไร้สาระพวกนั้นแน่นอน
จริง ๆ แล้วมันน่าเศร้าที่การตัดสินใจออกแบบแย่ ๆ อย่าง UI รูปทรง และจอสัมผัส มาทำลายฮาร์ดแวร์ที่ดีอยู่แล้ว
หลังใช้เวลาหลายชั่วโมง ในที่สุดก็เจอทางออกที่พอใช้ได้ ผมซื้อ Hifi Walker H2 จาก Amazon ซึ่งมีการออกแบบ UI แย่ ๆ รวมถึงพิมพ์ผิดด้วย แต่ฮาร์ดแวร์ดี
แล้วผมติดตั้ง RockBox ลงไป ปรับแต่งนิดหน่อยก็แก้ปัญหา UI ห่วย ๆ ได้ จุดที่น่าเสียดายคือ RockBox ไม่รองรับ Bluetooth หรือ USB DAC ซึ่งถ้าต้องใช้ฟีเจอร์พวกนี้ก็จะเป็นปัญหา
“เราต้องประหยัดพื้นที่หน้าจอครับ เพราะงั้น… ขอเช็กโน้ตก่อน… เราจะใส่ปุ่มที่กินพื้นที่ทั้งหน้าจอลงไปครับ”
ตรงที่บอกว่า “ย้ายไปไว้บนแถบชื่อเรื่องแล้วจะประหยัดพื้นที่หน้าจอ” นี่เป็นจุดที่ผมติดใจอยู่เสมอ
อีกเรื่องที่ทำให้หงุดหงิดช่วงนี้คือแอปพลิเคชันจำนวนมากขโมยโฟกัสหลายครั้งระหว่างกำลังเปิดอยู่ มีคนเผลอโพสต์รหัสผ่านลงในแชตทีมผิดเพราะ การขโมยโฟกัส บ้า ๆ นี่เยอะเกินไปแล้ว
ผมรู้สึกว่ามันแทบจะจบแล้วตั้งแต่ตอนที่ iOS นำ การกดค้าง เข้ามาใช้ กดองค์ประกอบ UI ไหนแล้วจะทำอะไรไม่รู้เลย ต้องลองแตะทุกอย่าง และตอนนี้ถ้าจะทำการกระทำอื่นก็ต้องกดค้าง
เราไม่สามารถเสียเวลาแตะทุกองค์ประกอบแล้วตามด้วยกดค้าง เพื่อหาสิ่งที่คิดหรือคาดว่าแอปน่าจะทำได้หรอก
มันดูเหมือนควรจะทำงานแบบนั้นโดยธรรมชาติ แต่ตอนนี้การกดค้างถูกใช้ไปกับสารพัดอย่างตามใจ
พิสูจน์ไม่ได้ก็จริง แต่ผมคิดว่าหายนะด้าน UI/UX แบบนี้บางครั้งเกิดจาก แรงกดดันที่ต้องเปลี่ยนแปลงอยู่เสมอ เพื่อแสดงให้เห็นว่าซอฟต์แวร์ยังมีชีวิตอยู่
ลองจินตนาการว่าในปี 2023 มีแอปหนึ่งไปถึงจุดสูงสุดของความง่ายในการใช้งานแล้ว แม้จะไม่สมบูรณ์แบบ แต่ก็นึกไม่ออกแล้วว่าจะปรับปรุงการใช้งานของแอปนั้นให้ดีขึ้นได้อย่างไร ผู้ใช้ก็ใช้กันได้ค่อนข้างคล่อง และเมื่อผ่านอุปสรรคพื้นฐานในการเรียนรู้แอปไปแล้ว ทุกอย่างก็ลงตัวโดยรวม
สภาพนี้จะคงอยู่ได้ไหม? ไม่ได้ ถ้าปล่อย UI ไว้เหมือนเดิม โลกซอฟต์แวร์มักจะมองว่าแอปนั้น “ล้าสมัย” หรือถึงขั้นตายไปแล้ว ดังนั้นจึงต้องเปลี่ยน แต่หลังจากถึงจุดสูงสุดด้าน usability แล้ว หากเปลี่ยนอะไรบางอย่าง ก็ย่อมทำให้ UX แย่ลงอย่างหลีกเลี่ยงไม่ได้ และบางครั้งก็แย่ถึงขั้นหายนะ
ผมคิดว่านี่เป็นหนึ่งในเหตุผลที่ UI ที่เคยดีของบางแอปและบาง desktop environment ถูกทำลายจนพังยับ
การที่อินเทอร์เน็ตความเร็วสูงแบบเชื่อมต่อตลอดเวลาแพร่หลาย ทำให้ปัญหานี้แย่ลงมาก เมื่อก่อนนักพัฒนาซอฟต์แวร์ต้องเอาผลิตภัณฑ์ใส่ CD หรือ floppy disk แล้วส่งไปวางขายในร้าน และไม่มีโอกาสอัปเดตได้ง่าย ๆ อย่างน้อยจึงต้องมีเป้าหมายและเดดไลน์ที่ชัดเจน
แม้จะออกอัปเดต ก็ต้องมีความหมายและมีน้ำหนักมากพอให้ผู้ใช้ยอมลงแรงไปหาเวอร์ชันใหม่มาติดตั้ง ในทางกลับกัน ซอฟต์แวร์สมัยใหม่เข้ากับสุภาษิตที่แปลหยาบ ๆ เป็นภาษาเราได้ว่า “ซามูไรไม่มีเป้าหมาย มีแต่เส้นทาง” มากที่สุด
อุดมคติของผมคือสร้างผลิตภัณฑ์ที่เป็นที่รักและใช้กันอย่างแพร่หลาย จากนั้นทำให้ customer support และปัญหาด้าน operations ทั้งหมดที่เป็นไปได้เป็นอัตโนมัติ แล้วค่อยย้ายไปทำผลิตภัณฑ์อื่น หรือไปพักผ่อนที่ชายหาด
ไม่มีใครต้องการการเปลี่ยนแปลง ผมเห็นแต่กลุ่มคนที่บ่นทุกครั้งที่ UI เปลี่ยน และไม่เคยเห็นฝั่งตรงข้ามมีสาวกตัวจริงแห่กันออกมาในจำนวนใกล้เคียงกันเลย
ในช่วงเริ่มต้น เราอยากให้คนชอบผลิตภัณฑ์ของเรา จึงใส่ใจ รับฟัง และจัดสรรทรัพยากรให้ usability ลูกค้าที่มีความสุขทำให้เรามีความสุข
ในช่วงกลาง เราตระหนักว่า usability เป็นเรื่องยาก งานด้าน ergonomics และการสร้าง affordance ไม่ง่ายอย่างที่คิด แถมยังมี internationalization ตามมาอีก ไม่มีใครสอนเรื่องนี้อย่างถูกต้อง คนส่วนใหญ่จึงต้องเรียนรู้เอง และ contractor ก็แพง
ในช่วงเสื่อมถอย เราอยากสร้างฟีเจอร์เพิ่ม จึงจ้างโปรแกรมเมอร์เพิ่ม และไล่ทีม usability ออกโดยบอกว่า “ทำสิ่งที่จำเป็นไปหมดแล้ว” ทีมเอกสารก็ถูกไล่ออกด้วย มองว่านักพัฒนาซอฟต์แวร์เป็นวิศวกร ดังนั้นแค่ FAQ ก็น่าจะเขียนได้
ในช่วงถึงก้นเหว เราโยนฟีเจอร์จำนวนมากให้ลูกค้าด้วย sprint สุดเท่ แต่ลูกค้าก็ยังไม่พอใจ จนต้องถามว่า “ลูกค้าเป็นอะไรไป?”
หลังจาก Office 2007 อยู่พักหนึ่ง ผมลุ้นแทบกลั้นหายใจว่าเหล่านักพัฒนา OpenOffice/LibreOffice จะไม่รีบไปทำ Ribbon ตาม การที่ยังทนอยู่ได้จนถึงตอนนี้ถือเป็นจุดสว่างเล็ก ๆ
ยังต้องจ่ายเงินเดือนให้ทีม UX ทั้งทีมที่เคยมีประโยชน์กับ v1 ที่เกือบสมบูรณ์แบบต่อไป ก็เลยต้องป้อนงานให้พวกเขา