เขียนบทความด้วย AI แปลด้วย AI แก้ลิงก์ด้วย AI สรุปยอดผู้เข้าชมด้วย AI ถาม AI ว่า “ตรงนี้ไม่ค่อยเข้าใจง่ายใช่ไหม” แล้วก็ให้ AI แก้อีกรอบ
พอมาถึงจุดนี้ มักจะเจอปัญหาอย่างหนึ่ง
ทุกคนรู้จักเว็บนี้ดีเกินไป
คนทำรู้ว่าปุ่มนี้แปลว่าอะไร AI อ่านสเปกแล้วก็เข้าใจว่า “ปุ่มนี้คือบทความที่เกี่ยวข้อง” ส่วนเจ้าของเว็บก็เปิดดูมาเป็นร้อยรอบ ต่อให้มีอะไรแปลกนิดหน่อย สมองก็เติมช่องว่างให้เองโดยอัตโนมัติ
แต่คนที่เข้ามาครั้งแรกไม่เป็นแบบนั้น
“นี่คืออะไร” “ต้องกดตรงไหน” “ทำไมตรงนี้ถึงเป็นภาษาอังกฤษอยู่ที่เดียว” “กลับไปไม่ได้” “อ่านข้อความออกนะ แต่รู้สึกขัดๆ ยังไงไม่รู้”
ผมอยากได้ “ยังไงไม่รู้” นี่แหละ
ความคิดที่ผุดขึ้นมาในที่สุดก็ค่อนข้างขำ
ในที่สุด ผมก็จะจ้างคนจริงๆ มาทำขั้นตอนดีบั๊กแทน
แถมจ่ายข้อละ 1 เยน คนละไม่เกิน 1,000 เยน
ยุคที่มนุษย์แย่งงาน AI มาถึงแล้ว งานที่รับผิดชอบคือ “ความรู้สึกแปลกๆ”
1. สิ่งที่อยากจ้างไม่ใช่การรีวิวโค้ด แต่คือ “จุดที่สะดุดตอนเห็นครั้งแรก”
สิ่งที่ต้องการครั้งนี้ ไม่ใช่การตรวจสอบครั้งใหญ่โดยผู้เชี่ยวชาญ
- ไม่เข้าใจว่าปุ่มนี้แปลว่าอะไร
- ไม่รู้ว่าต้องไปไหนต่อ
- หัวข้อแปลกๆ
- บนมือถือกดยาก
- ลิงก์พาไปหน้าที่เป็นภาษาอื่น
- กดอะไรสักอย่างแล้วหน้าจอขาวโพลน
- ประโยคถูกหลักภาษา แต่คนอ่านแล้วรู้สึกแปลก
- ตรงนี้ถ้ามีฟีเจอร์นี้น่าจะสะดวกดี
ประมาณนี้
Digital.gov เว็บไซต์แนวทางของรัฐบาลสหรัฐฯ อธิบายว่าการทดสอบการใช้งาน (usability testing) คือวิธีสังเกตผู้ใช้จริงขณะที่พวกเขาพยายามใช้ผลิตภัณฑ์หรือบริการ [1] GOV.UK ของรัฐบาลอังกฤษก็บอกว่าการดูผู้ใช้จริงลงมือใช้งาน ช่วยให้เจอปัญหาเฉพาะเจาะจง เช่น เรื่องภาษาและเลย์เอาต์ [2]
พูดอีกอย่างคือ “ให้คนมาลองจับสักครั้ง” ไม่ใช่พิธีกรรมลึกลับที่เพิ่งโผล่มาในยุค AI
มันคือการทดสอบการใช้งานแบบเดิม ที่ กลับมาหาเว็บที่ใช้ AI ผลิตและแก้ไขได้เป็นจำนวนมาก เท่านั้นเอง
2. บางครั้ง เจ้าของเว็บเองนี่แหละที่ทดสอบได้แย่ที่สุด
เปิดเว็บของตัวเองดูอย่างละเอียดทุกวัน
พูดง่าย แต่พอบทความเพิ่ม ภาษาเพิ่ม ฟีเจอร์เพิ่ม ก็ทำไม่ไหวเป็นเรื่องธรรมดา
แถม “คนทำเป็นคนดูเอง” ยังมีปัญหาอีกอย่าง
รู้ว่าช่องค้นหาอยู่ตรงไหน รู้ว่าบทความที่เกี่ยวข้องจะโผล่ตรงไหน รู้ว่าการสลับภาษาทำงานยังไง ต่อให้แปลกนิดหน่อยก็ผ่านไปเฉยๆ เพราะคิดว่า “มันก็เป็นแบบนี้แหละ”
และที่สำคัญที่สุดคือ การเปิดดูมันน่าเบื่อ
ข้อนี้สำคัญกว่าที่คิด
ถ้าเอาแต่ใช้กำลังใจสู้กับความขี้เกียจ ตั้งเป้าว่า “ทุกวันจะเช็ก 100 หน้า” วิธีนี้ก็อยู่ได้ไม่นาน งั้นก็แยกขั้นตอนที่น่าเบื่อนั้นออกมาเสียเลย
เจ้าของเว็บไม่จำเป็นต้องเป็นคนที่ดูทุกอย่าง
แต่เป็น คนที่กำหนดว่าควรดูอะไร แล้วสร้างระบบมาแก้ความผิดปกติที่รวบรวมได้
ก็พอแล้ว
3. 1 เยนต่อ 1 ข้อ ไม่ได้ซื้อ “ไอเดีย” แต่ซื้อสายตาที่เพิ่งเคยเห็นครั้งแรก
ถ้าดูแค่ตัวเลข 1 เยนต่อ 1 ข้อ ถูกมากจริงๆ
แต่สิ่งที่อยากซื้อตรงนี้ ไม่ใช่เอกสารที่ปรึกษาสวยหรู
แต่คือ ข้อเท็จจริงที่ว่า สายตาคนที่เห็นเป็นครั้งแรกสะดุดตรงนี้หนึ่งครั้ง
ถ้าคนหนึ่งส่งมา 1,000 ข้อ ก็ได้ 1,000 เยน แต่ถ้าเป็นเรื่องเดียวกันที่แค่เปลี่ยนคำพูด ก็นับเป็น 1 ข้อ และค่าตอบแทนสูงสุดต่อคนคือ 1,000 เยน
เพดานนี้สำคัญมาก
พอพูดว่า “อยากได้เยอะๆ” โลกก็จะรีบวิ่งไปทาง “งั้นให้ AI คิดจุดปรับปรุงหมื่นข้อ ก็ได้หมื่นเยนสิ?” ทันที
ดังนั้น นอกจากค่าตอบแทนตามจำนวนข้อ ก็ต้องตั้งเงื่อนไขเหล่านี้ไปพร้อมกัน
- ต้องเปิดดูเว็บจริง
- ต้องเขียนเรื่องที่มีอยู่จริงและพฤติกรรมที่เกิดขึ้นจริง
- ห้ามเอาข้อเดิมมาเปลี่ยนคำพูดเพื่อเพิ่มจำนวน
- ต้องมีเพดาน
อีกอย่าง 1 เยนต่อ 1 ข้อ เป็นเพียงการออกแบบสำหรับการทดลองครั้งนี้ ไม่ใช่ค่าตอบแทนที่เหมาะสมสำหรับทุกกรณี ถ้าจะขอให้ทำงานนานหรือประเมินในเชิงเชี่ยวชาญ ก็ต้องปรับเงื่อนไขให้เหมาะกับเวลาและความยาก
4. ศัตรูตัวใหญ่ที่สุดคือ “ให้ AI คิดจุดปรับปรุงมาหนึ่งหมื่นข้อแล้ว”
ไม่จำเป็นต้องห้ามใช้ AI
ปัญหาคือ ข้อเสนอปรับปรุงที่เขียนโดยไม่เคยเปิดดูเว็บเลยสักครั้ง
“โดยทั่วไป เว็บไซต์ควรทำให้การนำทางเข้าใจง่าย” “มาปรับปรุงการเข้าถึงกันเถอะ” “มาปรับให้รองรับหน้าจอหลายขนาดให้ดีที่สุดกันเถอะ”
ถูกทั้งหมด
และไม่มีข้อไหนเป็นสิ่งที่ต้องการครั้งนี้เลย
สิ่งที่ต้องการคือข้อสังเกตแบบนี้
“หน้านี้ ปุ่มนี้ กดแล้วจะเกิดอะไรขึ้นไม่รู้เลย” “หลังหัวข้อนี้ เรื่องกระโดดไปเฉยๆ” “เฉพาะเวอร์ชันภาษานี้ บทความที่เกี่ยวข้องลิงก์ไปภาษาอื่น”
AI ใช้ช่วยย่อข้อสังเกตเหล่านี้ให้สั้น และรวมข้อที่ซ้ำกันได้
คนเป็นผู้ค้นพบ AI เป็นผู้จัดระเบียบ
สำคัญตรงที่ห้ามสลับลำดับ
5. ถ้าส่งมาทีละข้อทางแชต คนที่ขอให้ช่วยจะตายก่อน
ถ้าอยากให้จำนวนรายงานเพิ่ม ก็ต้องออกแบบวิธีส่งด้วย
แบบที่ทรมานที่สุดคือ
“ข้อที่ 1 ค่ะ” “ข้อที่ 2 ค่ะ” “อ๋อ ลืมไป ข้อที่ 3” “เพิ่มอีก ข้อที่ 4”
แชตยาวไปไม่มีที่สิ้นสุด
แบบนี้จ้างคนดีบั๊กแล้วแท้ๆ กลับเกิด งานมือใหม่คือการรวบรวมรายงาน ขึ้นมาอีก
ดังนั้นให้ส่งรวดเดียว
- Excel
- สเปรดชีต
- ไฟล์ txt
- รายการที่มีเลขกำกับ
- ข้อความที่คัดลอกไปวางได้
แบบไหนก็ได้
สกรีนช็อตก็ไม่จำเป็นโดยหลักการ รูปภาพดูง่ายก็จริง แต่ภายหลังเวลาค้นหา ตัดข้อซ้ำ หรือให้ AI ประมวลผล จะติดขัดมาก
คู่มือวิจัยผู้ใช้ของ GOV.UK ก็บอกว่าโน้ตที่พิมพ์เก็บและวิเคราะห์ย้อนหลังได้ง่าย และการแยกข้อสังเกตหนึ่งอย่างเป็นหนึ่งรายการ ทำให้เรียงลำดับและวิเคราะห์ง่ายขึ้น [3]
รูปแบบง่ายๆ ก็พอ
ตำแหน่ง / ตอนนี้เป็นอย่างไร / ทำแบบไหนน่าจะดีขึ้น
ถ้าเป็นบั๊ก
ตำแหน่ง / ทำอะไรไป / เกิดอะไรขึ้น
แค่นี้ AI ขั้นถัดไปก็ทำงานได้เยอะแล้ว
6. ในเว็บหลายภาษา “แปลเสร็จแล้ว” กับ “คนอ่านได้” เป็นคนละเรื่อง
เว็บหลายภาษายิ่งน่าสนใจ
ในมุมของเครื่อง ทั้ง 12 ภาษาสร้างสำเร็จหมด บิลด์สำเร็จ HTTP 200 ลิงก์ก็มีอยู่
แต่พอคนมาดู ก็ยังมีจุดแปลกๆ ได้เป็นปกติ
- มีบางส่วนที่ยังเป็นภาษาต้นฉบับ
- มีแค่ปุ่มที่แปลแปลกๆ
- ประโยคพอเข้าใจความหมาย แต่เจ้าของภาษาอ่านแล้วไม่เป็นธรรมชาติ
- ข้อความยาวขึ้นจนเลย์เอาต์พัง
- หลังสลับภาษา มีแค่บทความที่เกี่ยวข้องที่กลับไปเป็นภาษาต้นฉบับ
- ควรเป็นบทความเดียวกัน แต่ขาดไปบางส่วน
ตรงนี้ให้เฉพาะคนที่อ่านภาษานั้นได้เป็นคนดู
คนที่อ่านภาษาอังกฤษได้ดูภาษาอังกฤษ คนที่อ่านภาษาเกาหลีได้ดูภาษาเกาหลี ภาษาจีน สเปน โปรตุเกส อินโดนีเซีย ไทย เวียดนาม ฝรั่งเศส เยอรมัน ก็เหมือนกัน
ไม่จำเป็นต้องให้ทุกคนดูทุกภาษา
เครื่องยืนยันว่า “สร้างได้แล้ว” คนยืนยันว่า “อ่านแล้วดูปกติไหม”
หน้าที่ต่างกัน
7. ข้อซ้ำนับเป็น 1 ข้อในแง่ค่าตอบแทน แต่ในแง่วิเคราะห์สำคัญมาก
ถ้าคนเดียวกันเขียนว่า
“ปุ่มเข้าใจยาก” “ไม่รู้ว่าปุ่มนี้แปลว่าอะไร” “ปุ่มนี้คืออะไร”
สามครั้ง ก็นับเป็น 1 ข้อพอ
แต่ถ้าสามคนที่ต่างกัน ต่างคนต่างสะดุดที่ปุ่มเดียวกัน เรื่องก็เปลี่ยนไป
นั่นไม่ใช่แค่ข้อซ้ำ แต่คือ แรงเสียดทานที่เกิดซ้ำได้
ดังนั้นตอนรวบรวมจึงแยกเป็น
- เปลี่ยนคำพูดภายในคนเดียวกัน → รวมเป็นข้อเดียว
- ข้อสังเกตเดียวกันที่คนต่างกันเสนออย่างเป็นอิสระ → เก็บไว้เป็นความถี่
“สามคนหลงตรงจุดเดียวกัน” หนักแน่นกว่ารสนิยมของเจ้าของเว็บ
GOV.UK ยังกำหนดไว้ในมาตรฐานบริการว่า ให้ตรวจสอบการใช้งานกับผู้ใช้จริงหรือผู้ใช้ที่คาดว่าจะใช้บ่อยๆ และทดสอบบนอุปกรณ์ที่สะท้อนพฤติกรรมของผู้ใช้ [4]
ความหมายของการเพิ่มจำนวนคนไม่ใช่ “โหวตความเห็น” แต่คือ การดูว่าแรงเสียดทานแบบเดียวกันเกิดกับคนอื่นด้วยหรือไม่
8. รูปแบบสมบูรณ์คือ AI → คน → AI โดยคนทำหน้าที่เป็นเซนเซอร์
ขั้นตอนสุดท้ายเรียบร้อยดีทีเดียว
- AI สร้างบทความ
- AI แปล
- AI ตรวจลิงก์ โครงสร้าง และการแสดงผล
- AI แก้ปัญหาที่รู้อยู่แล้ว
- คนอ่าน กด และหลงทางจริงๆ
- คนเขียนคำว่า “แปลกๆ” ออกมาเป็นข้อความ
- AI รวมข้อที่ซ้ำกัน
- AI จัดประเภทตามความรุนแรง การเกิดซ้ำได้ และต้นทุนการแก้ไข
- AI ร่างแนวทางแก้ไข
- หลังแก้ไข กลับไปตรวจด้วยเครื่องและให้คนตรวจซ้ำอีกครั้ง
ในที่สุด แม้แต่คนก็กลายเป็นหนึ่งขั้นตอนในสายพาน
แต่งานที่เหลือให้คนไม่ใช่งานง่ายๆ
คือ การจับแรงเสียดทานที่มีแต่คนเท่านั้นที่รู้สึกได้
ออกจะเหมือนการเลื่อนตำแหน่งมากกว่า
ให้เครื่องดูว่า “ลิงก์เป็น 404 ไหม” และให้คนดูว่า “ไม่ใช่ 404 แต่ไม่เข้าใจว่าทำไมถึงถูกพามาตรงนี้”
ให้เครื่องดูว่า “มีข้อความแปลอยู่ไหม” และให้คนดูว่า “มีอยู่ แต่คนทั่วไปไม่พูดแบบนี้”
แบ่งงานแบบนี้เป็นธรรมชาติกว่า
9. ถ้าผู้ทดสอบเข้าดู ยอดเข้าชมก็เพิ่มด้วย แต่ไม่ได้ตั้งเป็นเป้าหมาย
แน่นอนว่าถ้าให้ดูหลายสิบหน้า ยอดเข้าชมก็เพิ่ม
ถ้าเป็นเว็บที่มีโฆษณา โฆษณาก็อาจแสดงตามการเข้าชมปกติ
แต่นี่เป็นเพียงผลพลอยได้ล้วนๆ
ถ้าออกแบบให้กดโฆษณา หรือตั้งการเพิ่มการแสดงโฆษณาเป็นเงื่อนไขของงาน จะเป็นอีกเรื่องหนึ่งเลย
สิ่งที่ซื้อไม่ใช่ยอดเข้าชม
แต่คือ ข้อสังเกตที่เหลืออยู่หลังจากที่คนได้ดูหน้าเว็บ
ถ้าพลอยได้ยอดเข้าชมเพิ่มนิดหน่อย ก็คิดว่า “ทำการทดสอบผู้ใช้อยู่ ลิ้นชักเก็บเงินก็ดังกริ๊งเบาๆ” กำลังดี
10. ปลายทางของระบบอัตโนมัติ ไม่ใช่ “ไม่มีคนเลย”
พอเริ่มใช้ AI ก็อดคิดไม่ได้ว่าจะตัดคนออกได้แค่ไหน
แต่เมื่อผลักดันระบบอัตโนมัติจริงๆ บางครั้งกลับได้ข้อสรุปตรงข้าม
ไม่จำเป็นต้องตัดคนออกทั้งหมด
แค่ย้ายคนไปยังที่ที่มีแต่คนเท่านั้นที่สร้างคุณค่าได้
ร่างบทความ การแปล จัดการข้อซ้ำ ตรวจลิงก์ จัดประเภท สรุปยอด ข้อเสนอแก้ไข
ส่วนนี้ให้เครื่องทำ
แล้วสุดท้าย
“เพิ่งเคยเห็นครั้งแรก ไม่เข้าใจเลย” “ไม่ชอบตรงนี้” “แปลกๆ ยังไงไม่รู้” “อันนี้สะดวกดี”
ซื้อแค่นี้จากคน
สิ่งที่ซื้อด้วย 1 เยนต่อ 1 ข้อ ไม่ใช่ข้อความหนึ่งบรรทัด
แต่คือความรู้สึกแปลกๆ ชั่วขณะของคนอีกคน ซึ่งทั้งผมและ AI ไม่มี
เมื่อผลักดันระบบอัตโนมัติไปจนสุด คนก็กลับมา
แถมแผนกที่รับผิดชอบคือ “แปลกๆ ยังไงไม่รู้”
เป็นมนุษย์สุดๆ
เอกสารอ้างอิง (4 รายการ)
- Digital.gov, “Usability testing digital.gov
- GOV.UK Service Manual, “Using moderated usability testing gov.uk
- GOV.UK Service Manual, “Taking notes and recording user research sessions gov.uk
- GOV.UK Service Manual, “4. Make the service simple to use gov.uk
