สรุปสั้น ๆ (TL;DR)
- UX วัดจากอัตราทำงานสำเร็จ เวลาที่ใช้ และจุดที่คนหลุดออกจากเส้นทาง ส่วน UI วัดจากความอ่านง่าย คอนทราสต์ ขนาดพื้นที่กด และการตอบสนองของหน้าจอ
- เกณฑ์ Core Web Vitals ระดับ 'ดี' ของ Google ประเมินที่เปอร์เซ็นไทล์ที่ 75 ของผู้ใช้จริง คือ LCP ไม่เกิน 2.5 วินาที INP ไม่เกิน 200 มิลลิวินาที และ CLS ไม่เกิน 0.1
- INP เข้ามาแทน First Input Delay ในฐานะ Core Web Vital ตั้งแต่เดือนมีนาคม 2567 โดย JavaScript หนักและวิดเจ็ตจากภายนอกคือสาเหตุหลักที่ทำให้หน้าไม่ผ่าน
- มาตรฐาน WCAG 2 กำหนดคอนทราสต์ข้อความขั้นต่ำ 4.5:1 สำหรับข้อความเนื้อหาปกติ และ 3:1 สำหรับข้อความขนาดใหญ่
- การทดสอบ usability รอบเล็กกับผู้ใช้ตัวแทนประมาณห้าคน แล้วทดสอบซ้ำหลังแก้ไข เห็นปัญหาร้ายแรงที่สุดได้เร็วกว่าการศึกษาใหญ่ครั้งเดียว
UX UI คือ สองส่วนของการออกแบบเว็บไซต์และแอปที่ทำงานคู่กัน UX (User Experience) คือเส้นทางที่ผู้ใช้เดินจากความต้องการไปจนถึงผลลัพธ์ ว่าเขาหาสิ่งที่ต้องการเจอไหม เข้าใจไหม และทำงานนั้นเสร็จได้โดยไม่ติดขัดหรือเปล่า ส่วน UI (User Interface) คือสิ่งที่ผู้ใช้สัมผัสระหว่างทาง ได้แก่ ปุ่ม ตัวอักษร สี ระยะห่าง ช่องกรอกฟอร์ม และสถานะต่าง ๆ ที่ทำให้แต่ละหน้าจอใช้งานได้ UX ตัดสินว่าหน้านั้นต้องทำอะไรและเรียงลำดับอย่างไร UI ตัดสินว่าแต่ละขั้นตอนหน้าตาเป็นอย่างไรและตอบสนองอย่างไร เว็บที่ UI สวยแต่เส้นทางผิดก็ยังล้มเหลวด้าน UX ได้ และเส้นทางที่วางไว้ดีก็ยังเสียผู้ใช้ได้ถ้าหน้าจออ่านยากหรือตอบสนองช้า
UX กับ UI ต่างกันอย่างไร
วิธีแยกสองคำนี้ให้เร็วที่สุดคือถามว่าแต่ละอย่างตอบคำถามอะไร UX ตอบว่า "ผู้ใช้คนนี้ทำงานนี้สำเร็จไหม และต้องออกแรงแค่ไหน" ส่วน UI ตอบว่า "ระหว่างที่ทำ แต่ละหน้าจอชัดเจน สม่ำเสมอ และตอบสนองทันใจไหม" UX วัดจากอัตราทำงานสำเร็จ เวลาที่ใช้ จุดที่คนออกจากเส้นทาง และความผิดพลาด ส่วน UI วัดจากความอ่านง่าย ลำดับความสำคัญทางสายตา ขนาดพื้นที่กด ค่าคอนทราสต์ และการตอบสนองต่อการกระทำของผู้ใช้
ตัวอย่างสมมติ ร้านออนไลน์ขายเครื่องปรับอากาศ การตัดสินใจด้าน UX คือ ให้ผู้ซื้อเลือกขนาด BTU ก่อนเห็นราคา เพราะขนาดห้องเป็นตัวกำหนดว่ารุ่นไหนเหมาะ การตัดสินใจด้าน UI คือ ทำตัวเลือก BTU เป็นปุ่มชิปขนาดใหญ่เรียงเป็นแถว พร้อมเขียนขนาดห้องไว้ใต้แต่ละค่า แทนที่จะเป็นดรอปดาวน์เล็ก ๆ การตัดสินใจแบบ UX กำหนดลำดับของเส้นทาง ส่วนการตัดสินใจแบบ UI ทำให้ขั้นตอนนั้นใช้ง่ายบนมือถือ
สองส่วนนี้ทับซ้อนกันตลอดเวลา ข้อความสั้นบนปุ่ม ถ้อยคำในข้อความแจ้งข้อผิดพลาด และตำแหน่งของหมายเหตุค่าจัดส่ง ล้วนเป็นทั้ง UX และ UI นี่คือเหตุผลที่หลายทีมมองว่า "UX/UI" เป็นงานเดียวกันในโปรเจกต์เล็ก และแยกเป็นสองตำแหน่งเมื่อผลิตภัณฑ์ใหญ่ขึ้นเท่านั้น
UX designer กับ UI designer ทำอะไร
UX designer
UX designer ทำงานด้านโครงสร้างและพฤติกรรมก่อนจะมีการใส่สีหรือตกแต่งใด ๆ ผลงานที่พบบ่อยได้แก่
- บันทึกการวิจัยผู้ใช้ เช่น การสัมภาษณ์ การอ่านเรื่องที่ลูกค้าติดต่อฝ่ายบริการ การวิเคราะห์คำค้นในเว็บ และ funnel ใน analytics ที่บอกว่าคนออกจากเว็บตรงไหน
- User flow คือแผนภาพของทุกขั้นตอนตั้งแต่หน้าที่เข้ามาจนถึงเป้าหมายที่ทำสำเร็จ รวมถึงเส้นทางกรณีผิดพลาด เช่น "สินค้าหมด" หรือ "ชำระเงินไม่สำเร็จ"
- Information architecture คือโครงสร้างเมนู ลำดับชั้นของหน้า และการตั้งชื่อ ซึ่งมักทดสอบด้วยวิธี card sorting
- Wireframe คือเลย์เอาต์ความละเอียดต่ำที่บอกว่าเนื้อหาอะไรอยู่ตรงไหน ยังไม่มีสีหรือภาพจริง
- แผนและผลการทดสอบ usability ว่าจะทดสอบงานอะไร กับใคร และอะไรที่พัง
UI designer
UI designer เปลี่ยน wireframe ให้เป็นหน้าจอที่นักพัฒนาสร้างได้จริง ผลงานที่พบบ่อยคือ design system หรือ style guide (สี ขนาดตัวอักษร หน่วยระยะห่าง ชุดไอคอน) การออกแบบคอมโพเนนต์ในทุกสถานะ (ปกติ เอาเมาส์ชี้ โฟกัส ปิดใช้งาน กำลังโหลด ผิดพลาด) ม็อกอัปความละเอียดสูงสำหรับมือถือและเดสก์ท็อป และสเปกการโต้ตอบ เช่น เมนูเปิดอย่างไร หรือฟอร์มยืนยันการส่งอย่างไร เครื่องมืออย่าง Figma นิยมใช้กับงานนี้ เพราะคอมโพเนนต์และรูปแบบย่อยทั้งหมดอยู่ในไฟล์เดียวที่นักพัฒนาเปิดดูรายละเอียดได้
ในโปรเจกต์เว็บไซต์ขนาดเล็ก คนคนเดียวมักทำทั้งสองอย่าง สิ่งที่สำคัญคือคำถามทั้งสองชุดได้รับคำตอบ ไม่ใช่ว่าต้องมีตำแหน่งงานสองตำแหน่ง
กระบวนการออกแบบ UX: research, wireframe, prototype, usability test
กระบวนการนี้เป็นวงรอบ ไม่ใช่เส้นตรง แต่ละรอบควรมีต้นทุนต่ำกว่ารอบก่อน เพราะเราจับปัญหาได้ตั้งแต่ยังเป็นภาพร่าง
- Research (วิจัย) กำหนดงานหลักที่เว็บต้องรองรับ เช่น "ขอใบเสนอราคา" "เปรียบเทียบสองแพ็กเกจ" หรือ "ดูเวลาเปิดทำการของสาขา" ดึงข้อมูล funnel ปัจจุบันจาก analytics อ่านบันทึกคำค้นในเว็บ และอ่านคำถามที่ลูกค้าถามฝ่ายบริการในช่วงไม่กี่เดือนที่ผ่านมา เป้าหมายคือได้รายการงานจริงสั้น ๆ และจุดที่คนทำไม่สำเร็จในตอนนี้
- Information architecture และ user flow วาดว่าแต่ละงานเคลื่อนผ่านหน้าไหนบ้าง ตัดสินว่าอะไรอยู่ในเมนูหลัก และอะไรอยู่ลึกลงไปอีกหนึ่งคลิก ทุกขั้นตอนที่เพิ่มเข้ามาต้องมีเหตุผลรองรับ
- Wireframe ร่างหน้าสำคัญแต่ละหน้าเป็นสีเทา ตัดสินลำดับบล็อกเนื้อหา เช่น หัวข้อ หลักฐานความน่าเชื่อถือ ข้อเสนอ และฟอร์ม ทำให้หยาบไว้ก่อน จะได้ไม่มีใครเถียงเรื่องสีตั้งแต่ตอนนี้
- Prototype เชื่อม wireframe หรือม็อกอัปเข้าด้วยกันเป็นต้นแบบที่คลิกได้ เพื่อให้ผู้ทดสอบลองทำงานตั้งแต่ต้นจนจบ
- Usability test ให้ผู้ใช้ที่เป็นตัวแทนกลุ่มเป้าหมายประมาณห้าคนลองทำงาน สังเกตโดยไม่ช่วย แล้วจดว่าเขาลังเล อ่านผิด หรือยอมแพ้ตรงไหน การทดสอบรอบเล็กกับคนไม่กี่คนช่วยให้เห็นปัญหาที่ร้ายแรงที่สุดได้เร็ว ควรทดสอบซ้ำหลังแก้ไข แทนที่จะทำการทดสอบใหญ่ครั้งเดียว
- ออกแบบ UI และพัฒนา นำ design system มาใช้ สร้างเว็บ แล้วตรวจหน้าจริงด้วยอุปกรณ์จริงและความเร็วเครือข่ายจริง
- วัดผลและปรับปรุง หลังเปิดใช้งาน เปรียบเทียบอัตราทำงานสำเร็จและจุดที่คนหลุดกับค่าฐานก่อนเปิดตัว แล้วเลือกปัญหาถัดไปมาแก้
ความผิดพลาดที่พบบ่อยคือกระโดดไปทำม็อกอัปความละเอียดสูงเลย ผู้เกี่ยวข้องก็จะรีวิวแต่สีและรูปภาพ และไม่มีใครสังเกตว่าฟอร์มขอใบเสนอราคาอยู่ห่างจากตารางราคาถึงสามหน้าจอ
องค์ประกอบของ UI ที่ดี
UI ที่ดีส่วนใหญ่คือการตัดความลังเลของผู้ใช้ออกไป องค์ประกอบที่ทำงานมากที่สุดได้แก่
- ลำดับความสำคัญทางสายตา มีปุ่มหลักหนึ่งปุ่มต่อหน้าจอ และเด่นกว่าปุ่มรองอย่างเห็นได้ชัด ถ้าปุ่ม "ซื้อเลย" กับ "เพิ่มในรายการโปรด" หน้าตาเหมือนกัน ผู้ใช้จะชะงัก
- ตัวอักษรที่อ่านง่าย ขนาดตัวอักษรเนื้อหาใหญ่พอให้อ่านบนมือถือได้โดยไม่ต้องซูม และมีระยะห่างระหว่างบรรทัดที่สบายตา ภาษาไทยมีสระและวรรณยุกต์ที่อยู่สูงเหนือบรรทัดและต่ำกว่าบรรทัด จึงต้องการระยะห่างบรรทัดมากกว่าภาษาอังกฤษ เพื่อไม่ให้เครื่องหมายชนกัน
- คอนทราสต์ มาตรฐาน WCAG 2 กำหนดค่าคอนทราสต์ขั้นต่ำ 4.5:1 สำหรับข้อความเนื้อหาปกติ และ 3:1 สำหรับข้อความขนาดใหญ่ ตัวอักษรสีเทาอ่อนบนพื้นขาวไม่ผ่านเกณฑ์นี้บ่อยกว่าที่นักออกแบบคาดไว้
- พื้นที่กด ปุ่มและลิงก์ต้องใหญ่พอและห่างกันพอ ให้นิ้วโป้งกดโดนอันที่ถูกต้อง
- ความสม่ำเสมอ คอมโพเนนต์เดียวกันต้องหน้าตาและพฤติกรรมเหมือนกันทุกที่ design system ช่วยบังคับเรื่องนี้
- การตอบกลับและสถานะ ทุกการกระทำต้องแสดงผลลัพธ์ เช่น ตัวบอกว่ากำลังโหลด ข้อความแจ้งว่าสำเร็จ หรือข้อความผิดพลาดใต้ช่องที่บอกว่าต้องแก้อะไร
- ฟอร์ม ขอเฉพาะข้อมูลที่จำเป็น วางป้ายชื่อไว้เหนือช่องกรอก ใช้คีย์บอร์ดมือถือที่ตรงประเภท เช่น แป้นตัวเลขสำหรับเบอร์โทร และแป้นอีเมลสำหรับอีเมล และห้ามล้างข้อมูลในฟอร์มทิ้งเมื่อตรวจสอบไม่ผ่าน
UX/UI ส่งผลต่อ conversion และ SEO อย่างไร (Core Web Vitals และ INP)
ผลต่อ conversion
Conversion rate คือสัดส่วนของผู้เข้าชมที่ทำเป้าหมายสำเร็จ UX และ UI ส่งผลต่อตัวเลขนี้ผ่านแรงเสียดทาน ป้ายชื่อที่ไม่ชัด ช่องกรอกที่เกินจำเป็น ค่าใช้จ่ายที่โผล่มาแบบไม่คาดคิด หรือการตอบสนองที่ช้า ล้วนเป็นจุดที่ผู้เข้าชมบางส่วนหยุด ตัวอย่างสมมติ ถ้ามีคน 1,000 คนมาถึงฟอร์มขอใบเสนอราคา และส่งฟอร์ม 30 คน อัตราจะเท่ากับ 3% หากการทดสอบ usability พบว่าคนทิ้งฟอร์มเพราะขั้นแรกขอเลขประจำตัวผู้เสียภาษีของบริษัท การย้ายช่องนั้นไปไว้ขั้นหลังคือการแก้ด้าน UX ที่วัดผลเทียบกับค่าฐานเดิมได้ ตัวเลขนี้เป็นเพียงตัวอย่าง ค่าฐานจริงต้องมาจาก analytics ของคุณเอง
วิธีเชื่อมงานออกแบบเข้ากับรายได้คือติดตั้งการวัดผลใน funnel ให้แต่ละขั้นตอนถูกบันทึกเป็น event แล้วดูว่าขั้นไหนเสียคนมากที่สุด ขั้นนั้นคือจุดที่ควรลงแรงออกแบบก่อน
ผลต่อ SEO
Google ใช้สัญญาณด้าน page experience ซึ่งรวมถึง Core Web Vitals เป็นส่วนหนึ่งของระบบจัดอันดับ แต่สัญญาณเหล่านี้ไม่ได้สำคัญกว่าความเกี่ยวข้องของเนื้อหา หน้าที่เร็วแต่เนื้อหาอ่อนจะไม่ชนะหน้าที่ช้ากว่าแต่ตอบคำค้นได้ดีกว่ามาก อย่างไรก็ตาม เมื่อหน้าที่แข่งกันมีคุณภาพใกล้เคียงกัน ประสบการณ์การใช้งานอาจสร้างความต่างได้ และหน้าที่ช้าหรือกระตุกก็เสียผู้เข้าชมที่มาจากการค้นหาไปด้วย Core Web Vitals วัดสามเรื่อง โดยประเมินที่เปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้าจากผู้ใช้จริง
- LCP (Largest Contentful Paint) ใช้เวลานานแค่ไหนกว่าองค์ประกอบที่ใหญ่ที่สุดที่มองเห็น ซึ่งมักเป็นภาพ hero หรือหัวข้อ จะแสดงผล ระดับดีคือไม่เกิน 2.5 วินาที
- INP (Interaction to Next Paint) หน้าตอบสนองทางภาพเร็วแค่ไหนหลังการแตะ คลิก หรือกดแป้นพิมพ์ โดยวัดตลอดการเข้าชม ระดับดีคือไม่เกิน 200 มิลลิวินาที INP เข้ามาแทน First Input Delay ในฐานะ Core Web Vital ตั้งแต่เดือนมีนาคม 2567
- CLS (Cumulative Layout Shift) เนื้อหากระโดดเลื่อนไปมาระหว่างโหลดมากแค่ไหน ระดับดีคือไม่เกิน 0.1
ตัวชี้วัดเหล่านี้เป็นผลจากการตัดสินใจด้าน UI และ front-end พอ ๆ กับฝั่งเซิร์ฟเวอร์ ภาพ hero ขนาดใหญ่ที่ไม่บีบอัดทำให้ LCP แย่ สคริปต์ carousel วิดเจ็ตแชท และแท็กติดตามหลายตัวที่แย่งกันใช้ main thread ทำให้ INP แย่ เพราะเบราว์เซอร์ตอบสนองการแตะไม่ได้ในขณะที่ยังรัน JavaScript อยู่ ภาพและพื้นที่โฆษณาที่ไม่ได้กำหนดขนาดไว้จะดันข้อความให้เลื่อนลง ทำให้ CLS แย่ นักออกแบบที่เข้าใจเรื่องนี้จะเลือกภาพ hero ที่เบากว่า ใช้วิดเจ็ตจากภายนอกน้อยลง และกำหนดสัดส่วนภาพไว้ตั้งแต่แรก
UX ยังส่งผลต่อ SEO ทางอ้อมผ่านโครงสร้างเว็บ Information architecture ที่ชัดเจนทำให้เกิดการลิงก์ภายในที่มีเหตุผลและหัวข้อที่สื่อความหมาย ซึ่งช่วยทั้งผู้ใช้และบอตของเสิร์ชเอนจินให้เข้าใจว่าแต่ละหน้าพูดถึงอะไร
| ตัวชี้วัดหรือจุดตรวจ | เกณฑ์ "ดี" หรือเป้าหมาย | สาเหตุด้าน UX/UI ที่พบบ่อยเมื่อไม่ผ่าน |
|---|---|---|
| LCP (Largest Contentful Paint) | ไม่เกิน 2.5 วินาที | ภาพ hero ใหญ่เกินไป ฟอนต์โหลดช้า สคริปต์ที่บล็อกการแสดงผล |
| INP (Interaction to Next Paint) | ไม่เกิน 200 มิลลิวินาที | JavaScript หนัก วิดเจ็ตจากภายนอกหลายตัว เมนูซับซ้อนที่สร้างด้วยสคริปต์ |
| CLS (Cumulative Layout Shift) | ไม่เกิน 0.1 | ภาพและแบนเนอร์ที่ไม่ได้กำหนดขนาด ป๊อปอัปที่โหลดทีหลัง |
| คอนทราสต์ข้อความ (WCAG 2) | 4.5:1 สำหรับข้อความปกติ 3:1 สำหรับข้อความขนาดใหญ่ | ตัวอักษรเทาอ่อนบนพื้นขาว ข้อความวางทับบนภาพถ่าย |
เช็กลิสต์ UX สำหรับเว็บไทย
ผู้ใช้ชาวไทยมีความต้องการด้านการใช้งานส่วนใหญ่เหมือนผู้ใช้ทั่วโลก แต่มีรายละเอียดเฉพาะท้องถิ่นบางอย่างที่มักถูกมองข้าม
- Mobile first อย่างจริงจัง ทดสอบบนมือถือ Android ระดับกลางผ่านเน็ตมือถือ ไม่ใช่แค่บนแล็ปท็อปใหม่ที่ต่อ Wi-Fi ในออฟฟิศ
- ตัวอักษรภาษาไทย เลือกเว็บฟอนต์ภาษาไทยที่แสดงวรรณยุกต์ได้สะอาด ให้ระยะห่างบรรทัดมากกว่าภาษาอังกฤษ และตรวจว่าการตัดบรรทัดไม่ตัดคำแปลก ๆ เพราะภาษาไทยไม่มีการเว้นวรรคระหว่างคำ
- LINE เป็นช่องทางติดต่อ ผู้ซื้อชาวไทยจำนวนมากอยากถามคำถามผ่าน LINE ก่อนกรอกฟอร์ม ปุ่ม "เพิ่มเพื่อน LINE" หรือปุ่มแชทที่มองเห็นชัดข้างฟอร์มคือการตัดสินใจด้าน UX ไม่ใช่ของตกแต่ง
- รูปแบบการชำระเงินและการติดต่อแบบท้องถิ่น มีช่องทางชำระเงินที่ผู้ซื้อของคุณใช้จริง เช่น QR พร้อมเพย์สำหรับการโอนในประเทศ และรับเบอร์โทรศัพท์ไทยได้โดยไม่บังคับให้ใส่รหัสประเทศ
- การสลับสองภาษา ปุ่มเปลี่ยนภาษาควรพาผู้ใช้ไปยังหน้าที่ตรงกันในอีกภาษา ไม่ใช่โยนกลับไปหน้าแรก
- วันที่และราคา ตัดสินใจว่าจะแสดงปี พ.ศ. หรือ ค.ศ. แล้วใช้ให้สม่ำเสมอ และแสดงให้ชัดว่าราคารวมหรือไม่รวม VAT
- สัญญาณความน่าเชื่อถือใกล้จุดตัดสินใจ ข้อมูลการจดทะเบียนบริษัท ที่อยู่ และช่องทางติดต่อจริงที่วางไว้ใกล้ฟอร์มหรือหน้าชำระเงิน ช่วยลดความลังเล
ข้อผิดพลาด UX/UI ที่พบบ่อยและสิ่งที่ต้องวัดผล
ข้อผิดพลาดที่เกิดซ้ำบ่อยคือ ออกแบบโดยดูจากจอเดสก์ท็อปในห้องประชุม ใส่สไลเดอร์และแอนิเมชันที่ทำให้ INP แย่โดยไม่ช่วยงานใดของผู้ใช้เลย ซ่อนราคาหรือรายละเอียดสำคัญไว้หลังฟอร์ม เขียนข้อความผิดพลาดว่า "ข้อมูลไม่ถูกต้อง" โดยไม่บอกว่าต้องแก้อะไร และรีดีไซน์ทุกอย่างพร้อมกันจนไม่มีใครบอกได้ว่าการเปลี่ยนแปลงไหนทำให้ตัวเลขขยับ
สิ่งที่ควรวัดหลังการเปลี่ยน UX/UI ทุกครั้ง ได้แก่ อัตราทำงานสำเร็จหรือ conversion rate ในแต่ละขั้นของ funnel การทิ้งฟอร์มแยกตามช่องกรอก rage click และ dead click หากเครื่องมือ analytics ของคุณบันทึกได้ รายงาน Core Web Vitals ใน Google Search Console สำหรับข้อมูลภาคสนามจากผู้ใช้จริง และคำค้นในเว็บที่ไม่มีผลลัพธ์ เปลี่ยนเรื่องใหญ่ทีละเรื่อง หรือทำการทดสอบแบบมีกลุ่มควบคุม เพื่อให้บอกได้ว่าผลลัพธ์มาจากอะไร
ข้อจำกัดที่ต้องยอมรับตามตรง UX/UI ที่ดีแก้ปัญหาสินค้าที่คนไม่ต้องการไม่ได้ แก้ราคาที่หลุดตลาดไม่ได้ และแก้ทราฟฟิกที่ไม่ใช่กลุ่มเป้าหมายตั้งแต่แรกไม่ได้ สิ่งที่มันทำคือลดแรงเสียดทานให้คนที่มีความตั้งใจอยู่แล้ว
ความหมายสำหรับธุรกิจในประเทศไทย
สำหรับธุรกิจไทยส่วนใหญ่ ลำดับที่ใช้ได้จริงคือ แก้เส้นทางบนมือถือสำหรับงานหนึ่งหรือสองงานที่สร้างรายได้ก่อน ทำให้ Core Web Vitals ของเทมเพลตหน้าเหล่านั้นอยู่ในระดับ "ดี" แล้วจึงค่อยลงทุนกับการขัดเกลาหน้าตา บรีฟรีดีไซน์ที่เริ่มด้วยคำว่า "ทำให้ดูทันสมัย" มักข้ามขั้นตอนการวิจัยไป ส่วนบรีฟที่เริ่มด้วย "คำขอใบเสนอราคาหลุดที่ขั้นที่สองบนมือถือ" ให้โจทย์ที่นักออกแบบแก้ได้และวัดผลได้
คำถามที่พบบ่อย (FAQ)
UX หรือ UI สำคัญกว่ากัน
ไม่มีอันไหนทำงานได้โดยไม่มีอีกอัน แต่ UX มาก่อนในลำดับการทำงาน เพราะเป็นตัวตัดสินว่าหน้านั้นต้องทำอะไร หน้าจอที่สวยงามบนเส้นทางที่ผิดก็ยังเสียผู้ใช้ และเส้นทางที่ถูกต้องแต่หน้าจออ่านไม่ออกก็เสียผู้ใช้เช่นกัน
ออกแบบ UX ต้องเขียนโค้ดเป็นไหม
ไม่จำเป็น งานออกแบบ UX ไม่ต้องเขียนโค้ด แต่การเข้าใจว่าอะไรสร้างยากและความเร็วหน้าเว็บทำงานอย่างไรจะช่วยได้มาก UI designer ยิ่งได้ประโยชน์จากการเข้าใจข้อจำกัดฝั่ง front-end เพราะการเลือกของเขาส่งผลโดยตรงต่อ LCP, INP และ CLS
Core Web Vitals มีผลต่ออันดับ Google โดยตรงไหม
มี Core Web Vitals เป็นส่วนหนึ่งของสัญญาณ page experience ที่ Google ใช้จัดอันดับ แต่ความเกี่ยวข้องและคุณภาพเนื้อหามีน้ำหนักมากกว่า ให้มองว่าเป็นตัวตัดสินเมื่อคะแนนใกล้กัน และเป็นวิธีรักษาผู้เข้าชมที่การค้นหาส่งมาให้แล้ว
ทดสอบ usability ต้องใช้ผู้ใช้กี่คน
การทดสอบรอบเล็กกับผู้ใช้ที่เป็นตัวแทนประมาณห้าคน มักเพียงพอที่จะเห็นปัญหาร้ายแรงที่สุดของงานหนึ่งงาน การทดสอบรอบเล็กหลายรอบโดยแก้ไขระหว่างรอบ ให้ผลดีกว่าการทำการศึกษาใหญ่ครั้งเดียวตอนท้าย
ถ้าเว็บของคุณมีทราฟฟิกแต่คนหลุดออกไปก่อนสอบถามหรือซื้อ การแก้ไขมักเริ่มที่เส้นทางของผู้ใช้ ไม่ใช่ที่สี Relevant Audience วางแผนและสร้างเว็บไซต์โดยยึดเส้นทางเหล่านั้นผ่านบริการออกแบบเว็บไซต์และพัฒนาเว็บไซต์แบบกำหนดเอง ออกแบบหน้าแคมเปญผ่านบริการออกแบบแลนดิ้งเพจ และปรับเส้นทางการซื้อของร้านออนไลน์ผ่านบริการเพิ่มประสบการณ์ลูกค้าในอีคอมเมิร์ซ
