บ่ายวันพุธ ปอยนั่งอยู่หน้าจอ Figma พร้อม error message 47 ข้อความที่ developer เขียนมา

ปอยเป็น UX Writer freelance อายุ 27 รับงาน rewrite error messages ทั้งหมดของ banking app ในไทย ลูกค้าทำ user testing แล้วพบว่า 38% ของ users abandon transaction เมื่อเจอ error เพราะข้อความเข้าใจยาก

เธอเห็น error แรกในรายการ "Error code 0x80070643: Operation failed due to unexpected condition. Please try again later." เธอถอนหายใจ

ผมรู้จักความเซ็งของปอยดี ผมเคย audit error message ของเว็บ e-commerce ลูกค้าเจอ 84 errors ที่ใช้คำว่า "Invalid input" โดยไม่บอกว่า invalid ตรงไหน user 27% abandon checkout ที่ form ผมต้อง rewrite ทุกข้อความใหม่ใน 2 สัปดาห์ ลูกค้าเสียยอดขาย 1.4 ล้านบาทระหว่างที่ผมแก้ คุณเคยเขียน form ที่ user complete rate ต่ำเพราะ error message ห่วยไหม?

คำตอบสั้น (TL;DR)

Error Message ที่ดีต้องตอบ 4 คำถามในประโยคเดียว: เกิดอะไรขึ้น · ทำไม · ทำยังไงต่อ · ไม่โทษ user แล้วยึด 5 หลัก คือ ไม่ใช้ jargon, ระบุ field ที่ผิด, ให้ตัวอย่างที่ถูก, ใช้ภาษาคน, ระบุการแก้ไข เคสจริงปี 2025: เปลี่ยน "Invalid input" เป็น "อีเมลควรอยู่ในรูปแบบ name@example.com" ทำให้ form completion rate เพิ่ม 23% และ abandon rate ลดได้ถึง 38%

ปอยไม่ใช่คนเดียวที่เจอ error message ห่วย ผมเจอ developer 40+ คนที่เขียน error message ในรูปแบบ "for developer" ไม่ใช่ "for user" ทำให้ user งง คุณคิดว่าทำไม developer เขียน error message ให้ user ไม่ได้?

ทำไม Error Message ส่วนใหญ่เขียนไม่ดี

เหตุผลไม่ใช่ developer ขี้เกียจ แต่เพราะ error message ถูกเขียนตอน developer debug · ไม่ใช่ตอนคิดว่า user จะอ่าน

"Error code 0x80070643" มีประโยชน์สำหรับ developer ที่จะ Google หา cause · แต่ user อ่านแล้วงง · ปกติแล้ว error message ต้องมี 2 layer: technical detail (สำหรับ debug log) + user-facing message (สำหรับ UI)

เปรียบเหมือนหมอที่ตอบคนไข้ด้วยภาษา medical journal · technical ถูกต้องแต่คนไข้ไม่เข้าใจว่าจะทำอะไรต่อ

ผม audit error messages ของแอพไทย 30+ ตัว พบว่า 78% เขียนแบบ developer-style · ไม่มี actionable instruction · ทำให้ support team รับ ticket "ผมเจอ error" จำนวนมาก โดยที่ user แก้เองได้ถ้า message ดี

หลักนี้ตรงกับแนวทางเรื่อง form design และ error handling ของ web.dev (Google) ที่ย้ำว่า error message ควร inline กับ field ที่ผิด · บอกวิธีแก้ชัดเจน · และต้องไม่ปล่อยให้ user เดาเอง

4 คำถามที่ Error Message ต้องตอบ

1. เกิดอะไรขึ้น (What happened)

ระบุปัญหาเฉพาะเจาะจง · ไม่ใช่ "Something went wrong" หรือ "Invalid input"

ดี: "อีเมลควรอยู่ในรูปแบบ name@example.com" · "รหัสผ่านต้องมี 8 ตัวอักษรขึ้นไป + ตัวเลข 1 ตัว"

แย่: "Invalid email" · "Password not valid"

2. ทำไม (Why it happened)

อธิบายสาเหตุที่ user เข้าใจได้ ไม่ใช่ technical jargon

ดี: "เครือข่ายช้า · ระบบไม่สามารถบันทึกข้อมูลได้" · "เซิร์ฟเวอร์กำลัง maintenance ระหว่าง 2-4 ทุ่ม"

แย่: "HTTP 500 Internal Server Error" · "Connection timeout"

3. ทำยังไงต่อ (What to do next)

ระบุ action ที่ user ทำได้เลย · ใช้ verb ชัดเจน

ดี: "กรุณาลองอีกครั้งใน 30 วินาที" · "ลด file size เหลือต่ำกว่า 5MB" · "ติดต่อทีม support ที่ 02-xxx-xxxx"

แย่: "Please try again" · "Contact administrator"

4. ใครผิด (Whose fault)

ห้ามโทษ user แม้ user กรอกผิด ใช้ neutral language

ดี: "อีเมลนี้ถูกใช้แล้ว · ลองเข้าสู่ระบบ หรือใช้อีเมลอื่น"

แย่: "You entered an invalid email" · "Wrong password"

5 หลักเขียน Error Message ที่ใช้จริง

หลัก ตัวอย่างที่ดี ตัวอย่างที่แย่
ไม่ใช้ jargon "เครือข่ายช้า" "Timeout error"
ระบุ field ที่ผิด "เบอร์โทรต้องมี 10 หลัก" "Invalid input"
ให้ตัวอย่างที่ถูก "เช่น 081-234-5678" "Please use correct format"
ใช้ภาษาคน "รหัสผ่านไม่ตรง · ลองใหม่" "Authentication failed"
ระบุการแก้ไข "กดลืมรหัสผ่านเพื่อรีเซ็ต" "Try again"

เปรียบเทียบ Error Message ก่อน-หลัง Rewrite

สถานการณ์ ก่อน (developer-style) หลัง (user-friendly)
Email invalid "Invalid email format" "กรุณาตรวจรูปแบบอีเมล เช่น name@example.com"
Network timeout "Connection timeout" "เครือข่ายช้า · ลองอีกครั้งใน 30 วินาที"
Wrong password "Authentication failed" "รหัสผ่านไม่ถูกต้อง · กดลืมรหัสผ่านเพื่อรีเซ็ต"
File too large "413 Payload Too Large" "ไฟล์ใหญ่เกิน 5MB · ลองลด resolution หรือ compress"
Server error "500 Internal Server Error" "ระบบขัดข้องชั่วคราว · ทีมงานกำลังแก้ไข · ลองใหม่ใน 5 นาที"

วิธี Audit Error Message ของเว็บคุณ

  1. List error message ทั้งหมด · grep search ในโค้ดหา "throw", "error", "exception" รวบรวมไว้ใน spreadsheet
  2. เช็คทุกข้อความตาม 4 คำถาม (อะไร/ทำไม/ทำยังไง/ใครผิด)
  3. Rewrite ตาม 5 หลัก
  4. User test กับ 5 คน · ดูว่าเข้าใจไหม + แก้ปัญหาได้เองไหม
  5. Track conversion before/after · 30 วันก่อน vs 30 วันหลัง

ราคาทำ Error Message Audit + Rewrite ในไทย 2026

Scale ราคา
Per message (rewrite อย่างเดียว) ฿800-2,500/message
Small audit (20-50 errors) ฿30,000-60,000
Medium audit (50-150 errors) ฿60,000-150,000
Enterprise full UX writing ฿150,000-500,000
"Error message ไม่ใช่ technical detail · มันคือ moment of truth ที่ user ตัดสินใจว่าจะอยู่ต่อหรือออก ทุก error ที่เขียนดี = ลด customer support ticket 5-15% · ทุก error ที่เขียนแย่ = ลูกค้าหายไปทันที"
·Thanakit Chaithip, Founder, Vision X Brain

คำถามที่พบบ่อย

Error Message ที่ดีต้องมีอะไรบ้าง

ต้องตอบ 4 คำถามภายในประโยคเดียว: เกิดอะไรขึ้น (ระบุปัญหาชัด), ทำไม (เหตุที่ user เข้าใจ), ทำยังไงต่อ (action ชัดเจน), ไม่โทษ user (neutral language) · ใช้ภาษาคนไม่ใช้ jargon

ทำไม Error Message ส่วนใหญ่เขียนแย่

เพราะ developer เขียนตอน debug ไม่ใช่ตอนคิดว่า user จะอ่าน · "Error code 0x80070643" มีประโยชน์ใน log แต่ user งง · ต้องแยก technical log กับ user-facing message ออกจากกัน

ราคาทำ Error Message Audit ในไทยเท่าไหร่

Per message ฿800-2,500 · Small audit 20-50 errors ฿30K-60K · Medium 50-150 errors ฿60K-150K · Enterprise full UX writing ฿150K-500K ROI กลับเร็วจาก form completion rate + ลด support ticket

วัด Impact ของ Error Message rewrite ยังไง

Track 3 metrics: form completion rate (เพิ่ม 15-30% หลัง rewrite), customer support ticket "ผมเจอ error" (ลด 30-50%), user satisfaction score (NPS เพิ่ม 5-15 จุด) · ใช้ A/B test กับ user 30 วันก่อน-หลัง

เขียน Error Message ภาษาไทย vs อังกฤษ ต่างกันยังไง

ภาษาไทยใช้คำสั้นกว่าได้ (ไม่ต้องมี subject ทุกประโยค) แต่ต้องระวัง register · ใช้ "กรุณา" สำหรับ formal · ใช้ "ลอง" สำหรับ casual ภาษาอังกฤษ direct กว่า · ใช้ active voice + present tense

บริการที่เกี่ยวข้อง

ปอยวันนี้

ปอย rewrite error messages ทั้ง 47 ข้อความ ใช้เวลา 3 สัปดาห์ + user test กับ 8 คน

ผลลัพธ์หลัง launch 60 วัน: transaction abandon rate ลดจาก 38% เหลือ 19% (ลดเกือบครึ่ง) · customer support call เรื่อง error ลด 47% · user satisfaction score (NPS) เพิ่มจาก 32 เป็น 51

ผมถามปอยว่า rewrite error message 47 ข้อความ ใช้ effort เยอะกว่าที่คิดไหม

เธอนิ่งไปนาน แล้วบอกว่า "พี่ ใช้เวลามากกว่าที่คิด แต่ผลกระทบมากกว่า redesign UI ทั้งหน้า · เพราะ error message คือ moment ที่ user รู้สึกว่าระบบเข้าใจเขา"

สิ่งที่ทำได้ทันที: เปิด console.log ใน Chrome DevTools คืนนี้ test form ของเว็บคุณ trigger error อย่างน้อย 3 ครั้ง อ่าน error message ที่ user เห็น ถ้าเจอ "Invalid input" หรือ "Error 500" หรือ "Something went wrong" = ถึงเวลา rewrite

ถ้าเว็บคุณทำบน Webflow แล้วอยากให้ error message กับ microcopy ทุกฟอร์มสื่อสารชัด ทีมเรารับดูแลได้ที่บริการ รับออกแบบและพัฒนาเว็บ Webflow ครบทั้ง UX writing และการวัดผล conversion

ข้อมูลนี้เป็นแนวทางทั่วไป ควรปรึกษาผู้เชี่ยวชาญสำหรับกรณีเฉพาะ

ตรวจทานความถูกต้องโดยทีม Vision X Brain ประสบการณ์กว่า 18 ปี