ออกแบบ UI ให้สวยและใช้งานได้ทุกหน้าจอ

ลง UI เมื่อไหร่ — และทำไม mobile-first ลดค่าแก้หน้าจอ

คุ้มเมื่อ IA หรือ wireframe เคลียร์แล้ว และพร้อมลงทุนกับภาพที่ทีมพัฒนาใช้จริง ถ้ายังย้ายเมนูหรือฟอร์มบ่อย การลง UI เต็มชุดจะแพงเพราะต้องแก้ซ้ำ

เคสตัวอย่าง: สตูดิโอตกแต่งภายในแห่งหนึ่ง (ขอไม่เปิดชื่อตามสัญญา) มีเว็บเดิมที่ออกแบบเฉพาะเดสก์ท็อป หน้าบริการใช้ภาพใหญ่และข้อความยาว — พอดูบนมือถือ ปุ่มนัดดูโชว์รูมถูกบังและยากต่อการแตะ ทราฟฟิกจากมือถือกว่า 60% แต่การจองต่ำกว่าเดสก์ท็อปมาก

หลังรีดีไซน์แบบ mobile-first คู่กับเดสก์ท็อป — session บนมือถือเพิ่มขึ้น 41% และการจองนัดเพิ่ม 2.1 เท่าในไตรมาสแรก โดยไม่ต้องเพิ่มงบโฆษณา

• ก่อน: UI เดสก์ท็อปเท่านั้น ปุ่มนัดถูกบังบนมือถือ การจองต่ำ
• หลัง: mobile-first คู่เดสก์ท็อป session มือถือ +41% การจอง 2.1×
• บทเรียน: ออกแบบมือถือและเดสก์ท็อปคู่กันตั้งแต่ต้น ลดการย่อหน้าจอแล้วพัง

สิ่งที่ต้องเคลียร์ก่อนลงสี

ก่อนเปิดไฟล์ UI ควรมีรายการหน้า ลำดับเนื้อหา และทิศทางแบรนด์ขั้นต่ำ

การเริ่มจากหน้าตกแต่งโดยไม่มีกฎคอมโพเนนต์มักทำให้แต่ละหน้าไม่สอดคล้องกัน

01

สิ่งที่ควรล็อกก่อนลงสี

ลดการแก้ซ้ำตอนใกล้ส่งมอบ

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

ขอบเขตงานที่ส่งมอบจริง

UI ที่คุ้มคือหน้าจอที่พัฒนาต่อได้และใช้บนมือถือได้จริง ไม่ใช่ม็อกอัปสวยเฉพาะเดสก์ท็อป

เรากำหนดทิศทางภาพ ออกแบบหน้าสำคัญแบบ responsive จัดคอมโพเนนต์และสถานะที่ใช้บ่อย แล้วส่งไฟล์พร้อมสเปกให้ทีมพัฒนา

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

• กำหนด visual direction
• ออกแบบหน้าสำคัญแบบ responsive
• จัดคอมโพเนนต์และสถานะที่ใช้บ่อย
• ส่งมอบไฟล์และสเปกให้ทีมพัฒนา

ลำดับงาน และสิ่งที่มักพังตอนส่งพัฒนา

ลำดับที่คุ้มคือ ทิศทางภาพ → หน้าหลักมือถือ/เดสก์ท็อป → คอมโพเนนต์ → รีวิว → ส่งมอบ

ตอนส่งมอบ สิ่งที่พังบ่อยคือไม่มีสเปกระยะ ขาดสถานะฟอร์ม และมือถือถูกออกแบบทีหลังแบบย่ออย่างเดียว