UI Principles · สำหรับมือใหม่

5 หลักการออกแบบหน้าจอ

ก่อนจำชื่อ component ต้องเข้าใจ "หลักคิด" ก่อน — 5 ข้อนี้ใช้ได้กับทุกหน้าจอ. ซ้ายอธิบาย ขวากดเล่นได้จริง

อ่านยังไง

แต่ละหลักการ: ฝั่งซ้ายอธิบาย + ตัวอย่างจริง + ใช้เมื่อไหร่ (เขียว) ระวัง (แดง) · ฝั่งขวาเป็นของจริงกดลองได้. อยากรู้จัก component แต่ละตัว → เปิด คัมภีร์ UI(ลิงก์ท้ายหน้า)

1 · ปุ่มเด่น2 · สี3 · ฟีดแบ็ก4 · ยืนยัน5 · หน้าว่างFlowระบบจริง
11 หน้า = 1 ปุ่มเด่น

ในหน้านึง ควรมี "ปุ่มหลัก" (เด่นสุด สีเข้ม) อันเดียวเพื่อบอกผู้ใช้ว่า "สิ่งที่ควรทำคืออะไร" ที่เหลือทำให้เบาลง. ถ้าทุกปุ่มเด่นเท่ากัน = ผู้ใช้ลังเล ไม่รู้จะกดอะไร

ตัวอย่างจริงหน้าแก้ไขสินค้า มี "บันทึก" เป็นปุ่มเข้มเด่นอันเดียวส่วน "ยกเลิก" เป็นปุ่มขอบจาง ๆ — ผู้ใช้กวาดตาปุ๊บรู้เลยว่ากรอกเสร็จกดบันทึก
ใช้เมื่อ
ทุกหน้าที่มีการกระทำหลัก — บันทึก · ยืนยัน · ส่ง · ถัดไป
ระวัง
อย่ามีปุ่มเข้มหลายอันแย่งความสนใจกัน · ปุ่มรองทำเป็นขอบ/จาง
✓ ถูก
แก้ไขสินค้า
✗ ผิด
แก้ไขสินค้า
เข้มทั้งคู่ = งง กดอันไหน?
2สี = ความหมาย

คนอ่าน "สี" ก่อนอ่านตัวหนังสือ — ใช้สีให้สื่อความหมายตรงกัน: เข้ม/น้ำเงิน = หลัก· เทา = รอง· เหลือง = เตือน· แดง = อันตราย/ลบ. อย่าใช้สีมั่ว เดี๋ยวผู้ใช้ตีความผิด

ตัวอย่างจริงปุ่ม "ลบลูกค้า" ต้องเป็น สีแดงเพื่อเตือนว่าอันตราย — ถ้าทำเป็นสีน้ำเงินเหมือนปุ่มทั่วไป ผู้ใช้อาจเผลอกดลบโดยไม่ทันระวัง
ระวัง
แดงใช้กับลบ/ย้อนไม่ได้เท่านั้น — อย่าเอาไปใช้กับปุ่ม "บันทึก" เด็ดขาด
หลัก
รอง
เตือน
อันตราย
✓ ถูก
ลบ=แดง เห็นปุ๊บรู้ว่าอันตราย
✗ ผิด
ลบ=น้ำเงิน เผลอกดโดนของหาย
3กดแล้วต้องมีอะไรตอบ

ทุกการกระทำต้องมี "ฟีดแบ็ก" บอกว่าระบบรับรู้แล้ว — ห้ามกดแล้วเงียบ เพราะผู้ใช้จะไม่รู้ว่าสำเร็จไหม แล้วกดซ้ำ. สำเร็จ→Toast· กำลังทำ→หมุน/ปิดปุ่ม· พลาด→บอก error

ตัวอย่างจริงกดบันทึกแล้วเงียบ 2 วิ ผู้ใช้นึกว่าไม่ติด กดซ้ำอีก 3 ที → บันทึกซ้ำ 3 รายการ. แก้ด้วย ปิดปุ่ม+โชว์หมุนระหว่างทำ แล้วเด้ง toast "บันทึกแล้ว"
ใช้เมื่อ
ทุกปุ่มที่ไปเรียกระบบ — บันทึก · ส่ง · ลบ · อัปโหลด
พลาด → บอกเหตุผลตรง ๆ เช่น "เน็ตหลุด กดลองใหม่"
4สิ่งย้อนไม่ได้ ต้องยืนยันก่อน

การกระทำที่ "ทำแล้วกู้คืนไม่ได้" — ลบ · จ่ายเงิน · ส่งออก — ต้องมีจังหวะให้ผู้ใช้คิดอีกที โดยเด้ง Modal ยืนยันก่อนทำจริง กันพลาดจากการกดเร็ว/กดผิด

ตัวอย่างจริงกด "ลบลูกค้า" → modal ถาม "ลบรายการนี้? ย้อนกลับไม่ได้"ต้องกดยืนยันอีกที — ถ้าลบทันทีโดยไม่ถาม วันนึงเผลอกดโดนข้อมูลสำคัญหายเลย
ระวัง
อย่าใช้ modal ยืนยันกับทุกอย่าง (น่ารำคาญ) — ใช้เฉพาะสิ่งที่ย้อนไม่ได้จริง
↑ กดแล้วจะเด้ง modal ให้ยืนยัน
5อย่าปล่อยหน้าโล่ง

หน้าที่ยังไม่มีข้อมูล หรือกำลังโหลด ก็ต้องสื่อสาร — Empty stateบอกว่าทำไมว่าง + ปุ่มให้เริ่ม · Skeletonโชว์โครงเทา ๆ ระหว่างโหลด. ปล่อยหน้าโล่ง = ผู้ใช้นึกว่าเว็บเสีย

ตัวอย่างจริงลูกค้าเพิ่งสมัคร เปิดมาหน้าออเดอร์ว่างเปล่า → ถ้าโชว์ "ยังไม่มีออเดอร์ กด + เพิ่ม" ผู้ใช้รู้ว่าต้องทำอะไรต่อ ไม่ปิดหนีไปเพราะคิดว่าระบบพัง
ใช้เมื่อ
รายการว่าง · ครั้งแรกที่เข้าใช้ · ระหว่างดึงข้อมูล · ค้นหาไม่เจอ
Empty state
ยังไม่มีรายการ
Skeleton (กำลังโหลด)
Flow ที่ใช้บ่อย

หลักการพวกนี้มัก "ทำงานร่วมกัน" เป็นลำดับ. ตัวอย่างคลาสสิกคือการลบ — ใช้ครบ 3 หลักการ: สีแดง (หลัก 2)ยืนยัน (หลัก 4)ฟีดแบ็ก (หลัก 3)

ตัวอย่างจริงขั้นตอนลบที่ดี: กดปุ่มลบสีแดง → modal "ยืนยันลบ?" → กดยืนยัน → toast "ลบแล้ว ✓" — ผู้ใช้มั่นใจทุกขั้น ไม่พลาด
ลบของ
ปุ่มลบ (แดง)Modal ยืนยันToast "ลบแล้ว"
บันทึกฟอร์ม
กดบันทึกปุ่ม loadingToast สำเร็จ
ระบบจริงใช้ยังไง

หลักการพวกนี้ไม่ใช่ทฤษฎี — ระบบจริงอย่าง HomeOffice(ระบบจัดการสำนักงาน) ใช้ครบทุกข้อ: badge สีบอกสถานะ · banner เตือนค้างไว้ · toast บอกผลการส่ง · สีแบรนด์ navy/ฟ้า แดงเฉพาะลบ

ตัวอย่างจริงหน้าส่งเอกสารให้ผู้เรียน 18 คน — กดส่งแล้วเด้ง toast "ส่งแล้ว 15/18 คน"(3 คนยังไม่ผูกไลน์ขึ้น badge แดงเตือน) ผู้ใช้รู้ผลทันทีว่าใครตกหล่น
HomeOffice · ส่งเอกสาร
ทดลองใช้เหลือ 3 วัน— อัปเกรดเพื่อใช้ต่อ
ผู้เข้าอบรม (18)
สมชาย✓ ผูกไลน์
น้องพายยังไม่ผูก
ส่งแล้ว 15/18 คน

เช็ก 5 ข้อนี้ก่อนส่งงาน — ก๊อปไปต่อท้ายพรอมต์ AI ได้เลย

เวลาสั่ง AI สร้างหน้าจอ วางบรรทัดพวกนี้ต่อท้าย กันงานออกมาดิบ:

ทุกหน้าให้มีปุ่มหลักเด่นอันเดียว ปุ่มรองทำเป็นขอบจาง ปุ่มลบ/ยกเลิกถาวรใช้สีแดง ส่วนบันทึก/ยืนยันใช้สีเข้ม ทุกปุ่มที่เรียกระบบ ให้ปิดปุ่ม+โชว์กำลังทำ แล้วเด้ง toast เมื่อเสร็จ ลบ/จ่ายเงิน/ส่งออก ต้องเด้ง modal ยืนยันก่อนทำจริง หน้าที่ยังไม่มีข้อมูล ใส่ empty state พร้อมปุ่มเริ่ม และใช้ skeleton ตอนโหลด

อยากรู้จัก component แต่ละตัว?

ปุ่ม · Toast · Modal · Alert · ฟอร์ม · ตาราง 30+ ตัว พร้อมตัวอย่างกดเล่นได้

เปิดคัมภีร์ UI →
อ่านต่อจากแหล่งอื่น (บทความภายนอก)
บทความภายนอกเป็นของผู้เขียนแต่ละเว็บ (ไม่ใช่ของเรา) · เปิดในแท็บใหม่
กลับห้องสมุดออกแบบ

อ่านต่อ — เรื่องที่เกี่ยวข้อง

คัมภีร์ UI — ปุ่ม·Toast·Modal Design Style — สี·Typography Do & Don't ออกแบบ UI AI vs กูรูออกแบบ