ช่วงนี้ผมทำคอร์สอยู่บน LearnAI ครับ แล้วมีเคสเล็กๆ ที่คนข้างนอกอาจมองว่าไม่ใช่เรื่องใหญ่ แต่สำหรับคนทำโปรดักต์จริง มันกวนใจมาก คือคอร์สผมมีบทโบนัสบทนึงที่ตั้งใจให้เป็น ข้อความล้วน ไม่ใช่วิดีโอ เพราะอยากใช้เป็นโบนัสหลังลูกค้ารีวิว แต่ระบบเรียนที่ผมมีอยู่ดันคิดว่า "บทเรียน = ต้องมีวิดีโอเสมอ" พอเปิดบทนั้นเลยขึ้นกล่องประมาณว่ายังไม่ได้อัปโหลดวิดีโอ ทั้งที่จริงผมไม่ได้อยากอัปอะไรเลย 555

เรื่องนี้เลยกลายเป็นอีกเคสที่ชัดมากว่า เวลาเรามี AI Agent ที่ลงมือแก้ระบบจริงให้เรา มันไม่ได้ช่วยแค่เรื่องใหญ่ๆ อย่าง deploy หรือ debug หนักๆ นะครับ บางทีมันช่วยเก็บเศษงานเล็กๆ ที่ถ้าปล่อยไว้ ลูกค้าจะรู้สึกว่าโปรดักต์ดูไม่เรียบร้อยทันที

ที่มา — คอร์สมีทั้งบทวิดีโอ และบทที่ควรเป็นข้อความ

คอร์สที่ผมเพิ่งปล่อยมีวิดีโอเป็นหลักครับ ซึ่งก่อนหน้านี้ผมก็เพิ่งเล่าไปว่า ทิมช่วยผมไล่บั๊ก player จนเลิกใช้ iframe หนักๆ แล้วเขียนเครื่องเล่นเองด้วย hls.js อันนั้นคือฝั่ง "ทำให้บทวิดีโอเล่นดีขึ้น"

แต่พอคอร์สเริ่มเป็นของจริง มันไม่ได้มีแค่วิดีโออย่างเดียวครับ มันมีบทประเภทอื่นด้วย โดยเฉพาะบทโบนัสหรือ resource page บางอัน จริงๆ แล้วควรเป็นข้อความล้วนมากกว่า เช่น instructions, link, checklist, หรือเงื่อนไขรับโบนัส ถ้าผมฝืนทำเป็นวิดีโอ แปลว่าต้องอัดคลิปเพื่อพูดเรื่องที่คนอ่านเองใน 30 วินาทีก็เข้าใจแล้ว มันเสียเวลาโดยไม่จำเป็น

ปัญหาคือระบบ LearnAI เวอร์ชันตอนนั้นผูกโครงสร้างไว้ว่า 1 บท = มี video embed ไม่ก็แสดงกล่อง placeholder ว่า "ยังไม่ได้อัปโหลด" คือตรรกะมันไม่ได้เผื่อโลกที่บทเรียนอาจเป็น text-only เลย

อาการที่เห็น — ระบบไม่ได้พัง แต่ UX มันโกหก

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

  • คอร์สนี้ยังทำไม่เสร็จหรือเปล่า
  • ผมกดมาเจอบทที่เสียหรือเปล่า
  • เจ้าของคอร์สลืมอัปโหลดของให้หรือเปล่า

ทั้งที่ความจริงคือบทนั้น "เสร็จแล้ว" ครับ แค่มันไม่ใช่วิดีโอเท่านั้นเอง มันเลยเป็นปัญหาประเภทที่โค้ดไม่ได้ error, server ไม่ล่ม, log ไม่แดง แต่ UX กำลังสื่อสารผิดจากความจริง ซึ่งผมว่าปัญหาแบบนี้แหละโหด เพราะคนทำระบบอาจมองข้าม แต่ลูกค้าเห็นแล้วรู้สึกได้ทันที

มันคล้ายๆ กับหลายเคสที่ผมชอบเล่าในบล็อกนี้ คือระบบอาจไม่ได้พังแบบมี stack trace แต่รายละเอียดเล็กๆ ทำให้ประสบการณ์ใช้งานดูไม่เนียน เหมือนตอนที่ ข้อความไทยยาวโดน input buffer 1KB ตัดหายเงียบๆ หรือเคสที่ ลูกค้า Newton เห็นแค่ purchase failed ทั้งที่ root cause จริงอยู่ลึกกว่าหน้าจอมาก

วิธีคิดที่สำคัญ — อย่าฝืนใช้วิดีโอ ถ้ารูปแบบเนื้อหาไม่ใช่วิดีโอ

ทางแก้แบบขอไปทีก็มีครับ เช่น ผมอาจอัปวิดีโอหลอกๆ ความยาว 10 วินาที เป็นภาพนิ่งเขียนว่า "อ่านข้างล่างนะครับ" แล้วหลอกระบบให้ผ่านก็ได้ แต่นั่นคือการแก้ที่ปลายเหตุชัดๆ และจะสร้างหนี้เทคนิคไว้เต็มๆ ในอนาคต

ผมเลยให้ทิมมองโจทย์ใหม่ว่า บทเรียนควรเก็บ "เนื้อหา" ไม่ใช่เก็บ "วิดีโอ" เป็นศูนย์กลาง ถ้าวันไหนบทนั้นเป็นวิดีโอ ก็แสดง player ถ้าวันไหนเป็นข้อความ ก็แสดงข้อความ ถ้าวันไหนมีทั้งสองอย่าง ค่อยว่ากันอีกที แต่ระบบพื้นฐานต้องยอมรับก่อนว่า "บทเรียน" มีได้หลายรูปแบบ

อันนี้แหละที่ผมว่ามันต่างระหว่าง AI ที่ช่วยคิดเชิงผลิตภัณฑ์ กับ AI ที่แค่ตอบโค้ด snippet เพราะมันไม่ได้ถามแค่ว่า "จะแก้ div นี้ยังไง" แต่มันถอยออกมาดู model ของข้อมูลเลยว่าตกลงเรากำลังนิยาม lesson ผิดอยู่หรือเปล่า

สิ่งที่ทิมแก้จริง — เพิ่ม field ให้บทเรียนมี body ของตัวเอง

สุดท้ายทิมเสนอทางที่ตรงสุดครับ คือเพิ่ม field ใหม่ในตารางบทเรียนชื่อประมาณ lessons.body เพื่อให้แต่ละบทมีเนื้อหาข้อความของตัวเองได้ ไม่ต้องบังคับว่าทุกอย่างต้องวิ่งผ่านวิดีโอ

พอมี field นี้แล้ว logic ฝั่งหน้าเรียนก็เปลี่ยนตามไปด้วย:

  • ถ้ามีวิดีโอ ก็ render player ตามปกติ
  • ถ้าไม่มีวิดีโอ แต่มี body ก็ render เนื้อหาข้อความแทน
  • ถ้าไม่มีทั้งสองอย่าง ค่อยแสดงสถานะว่ายังไม่พร้อมจริงๆ

ฟังดูเหมือนเล็กนะครับ แต่จริงๆ มันคือการเปลี่ยนจากระบบที่ "เดาจาก media type เดียว" ไปเป็นระบบที่ "ดูจากข้อมูลจริงของบทเรียน" ซึ่งแข็งแรงกว่าเยอะ

พูดแบบบ้านๆ เดิมระบบผมเหมือนพนักงานที่ถามคำเดียวว่า "มีไฟล์วิดีโอไหม?" ถ้าไม่มีก็ตีตราทันทีว่า "งานยังไม่เสร็จ" ทั้งที่ความจริงอาจเป็นเอกสารพร้อมอ่านครบแล้ว ทิมเลยเปลี่ยนวิธีคิดให้มันดูงานทั้งแฟ้ม ไม่ใช่ดูแค่ไฟล์เดียว

สิ่งที่ผมชอบ — มันไม่ได้แก้แค่ฐานข้อมูล แต่แก้ template ด้วย

เรื่องที่คนชอบมองข้ามเวลาบอกว่า "เพิ่ม field ก็จบ" คือจริงๆ มันไม่จบครับ เพราะ data layer เปลี่ยนอย่างเดียวไม่ได้ ถ้า template ยังคิดแบบเดิม หน้าเว็บก็ยังหลอก user เหมือนเดิม

ทิมเลยไปต่อให้ครบชั้นเลย คือฝั่ง player page ถ้าไม่มีวิดีโอแล้วมี body มันต้อง render เนื้อหาตัวนั้นออกมาให้อ่านได้จริง ไม่ใช่โยน raw text กองๆ ลงหน้าเว็บ และไม่ใช่ไปโชว์กล่อง error เดิมที่ไม่เกี่ยวกับสถานะจริงของบทเรียนแล้ว

นี่คือสิ่งที่ผมชอบมากเวลาใช้ AI Agent แบบเต็มตัว มันไม่ได้ fix แค่ schema แล้วบอกว่า "ที่เหลือคุณไปต่อเองนะ" แต่มันไล่ต่อให้ครบว่าของจริง user จะเห็นอะไร ตั้งแต่ฐานข้อมูลไปจนถึงหน้าสุดท้ายที่ลูกค้ากดอ่าน

แนวคิดเดียวกันนี้แหละครับที่ผมใช้กับงานอื่นด้วย เช่นตอนทำ ระบบอีเมลที่ไม่ได้จบแค่ส่งเมลออก แต่ต้องมี flow จริงทั้ง subscribe, confirm, notify หรือเคสที่ แก้วิดีโอค้างแล้วไม่ได้หยุดที่เปลี่ยน player แต่ต้องวัดด้วยเบราว์เซอร์จริง

ผลลัพธ์หลังแก้ — บทโบนัสดูเป็นบทเรียนจริง ไม่ใช่เหมือนของขาด

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

และสิ่งที่ผมว่าคุ้มมากคือ ต่อไปผมมี freedom เพิ่มขึ้นทันที ถ้าจะทำบท checklist, bonus instructions, template download, หรือ note สั้นๆ ที่ไม่จำเป็นต้องเป็นวิดีโอ ผมทำได้เลย ไม่ต้องอัดคลิปหลอกระบบอีก

นี่คือประโยชน์ของการแก้ที่ model ครับ มันไม่ได้แก้แค่เคสเดียว แต่เปิดทางให้ use case อื่นตามมาเอง โดยไม่ต้องเขียน workaround ใหม่ทุกครั้ง

บทเรียนที่ผมได้ — โปรดักต์ดีไม่ได้วัดแค่ feature ใหญ่ แต่รวมถึงการไม่ฝืน user ให้ใช้รูปแบบผิดๆ

ผมว่าหลายคนเวลาทำโปรดักต์จะตื่นเต้นกับ feature ใหญ่ครับ AI นี้, automation นั้น, dashboard อะไรเต็มไปหมด แต่สิ่งที่ทำให้คนรู้สึกว่า "ระบบนี้ดี" บ่อยครั้งกลับเป็นของเล็กๆ แบบนี้แหละ คือมันไม่ฝืนให้ user ทำในสิ่งที่ไม่ควรต้องทำ

ถ้าบทโบนัสควรเป็นข้อความ ก็ให้มันเป็นข้อความ ถ้าวิดีโอควรเล่นไว ก็ทำให้มันเล่นไว ถ้าข้อความไทยยาวควรส่งถึง AI ครบ ก็ต้องส่งให้ครบ ฟังดูพื้นฐานมาก แต่ของจริงในโลกโปรดักต์ คนแพ้กันที่ตรงนี้เยอะครับ

และยิ่งผมทำงานกับ AI มากขึ้น ผมยิ่งรู้ว่า AI ที่เก่งจริงสำหรับเจ้าของธุรกิจ ไม่ใช่ AI ที่พูดฉลาดอย่างเดียว แต่คือ AI ที่เห็น friction เล็กๆ แบบนี้แล้วลงไปแก้ให้ของจริงลื่นขึ้นทีละจุด

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

LMS ที่ดีควรรองรับบทเรียนแบบ text-only ได้ไหม?

ควรครับ เพราะเนื้อหาไม่ได้มีแค่วิดีโอ บทโบนัส, checklist, instructions, หรือ resource page มักเหมาะกับข้อความมากกว่า ถ้า LMS บังคับให้ทุกบทต้องมีวิดีโอ เจ้าของคอร์สก็ต้องอัดคลิปหลอกๆ เพื่อผ่านระบบ ซึ่งเสียเวลาโดยไม่จำเป็นและทำให้ประสบการณ์แย่ลง

ทำไม UX ที่ "โกหก" ถึงแย่กว่า UX ที่พัง?

เพราะ UX ที่พังจะมี error message บอกทันทีว่ามีอะไรผิดพลาดครับ แต่ UX ที่โกหก เช่น แสดงว่า "ยังไม่ได้อัปโหลด" ทั้งที่บทเรียนเสร็จแล้ว ทำให้ผู้ใช้ตีความผิด เชื่อว่า product ยังไม่เสร็จหรือเจ้าของลืมทำ ซึ่งทำลายความเชื่อมั่นได้ทันทีโดยที่ไม่มี error จริงๆ เกิดขึ้นเลย

การแก้ที่ "model" ของข้อมูลดีกว่าการ workaround ยังไง?

การ workaround เช่น อัปวิดีโอหลอก 10 วินาทีเพื่อผ่านระบบ แก้ได้แค่เคสนั้นครับ แต่สร้างหนี้เทคนิคสะสม ส่วนการแก้ที่ model เช่น เพิ่ม field lessons.body เพื่อให้บทเรียนมีได้หลายรูปแบบ ทำให้ use case อื่นๆ ในอนาคตทำได้เลยโดยไม่ต้องเขียน workaround ใหม่ทุกครั้ง

เมื่อแก้ database schema แล้ว template ต้องอัปเดตตามด้วยเสมอไหม?

ต้องครับ เพราะ data layer เปลี่ยนอย่างเดียวไม่ได้ ถ้า template ยังคิดแบบเดิมก็จะยังแสดงผลผิดเหมือนเดิม ทั้ง schema และ presentation layer ต้องสอดคล้องกัน — เพิ่ม field ใน DB แล้วก็ต้อง render field นั้นออกมาให้ user เห็นด้วยครับ

Newton — ถ้าคุณอยากมี AI ที่ลงไปขัดเกลาระบบจริงของคุณแบบนี้

เหตุผลที่ผมพาเรื่องเล็กๆ แบบนี้มาเล่า ก็เพราะมันสะท้อนสิ่งที่ Newton ทำให้ผมทุกวันครับ มันไม่ใช่แค่หน้าแชทไว้ถามคำถาม แต่เป็น AI Agent ที่นั่งอยู่บน server ของผมจริงๆ รู้ทั้งโค้ด, โครงสร้างข้อมูล, หน้าเว็บ, และ flow ธุรกิจ เลยช่วยผมเก็บทั้งงานใหญ่และงานจุกจิกที่คนใช้สัมผัสได้ทันที

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

— ปอนด์