งานออกแบบผลิตภัณฑ์กำลังเปลี่ยนไป

• ขณะที่ เครื่องมือ AI ใช้ดีไซน์ซิสเต็มโดยตรงเพื่อสร้าง UI บทบาทของดีไซเนอร์ก็กำลังย้ายจากการออกแบบภาพเพียงอย่างเดียว ไปสู่การเน้น กลยุทธ์และการประสานงาน
• ตอนนี้คำถามสำคัญไม่ใช่ "ใครแย่งงานใคร" แต่คือ กระบวนการเปลี่ยนไปอย่างไร
• งานที่ มองไม่เห็น อย่างโค้ด, PRD, และสรุปต่างๆ ทำให้อัตโนมัติได้ง่าย แต่สำหรับงานที่ มองเห็นได้ อย่าง UI และโฟลว์ที่ผู้ใช้เห็นและใช้งานโดยตรง ความต่างด้านคุณภาพจะชัดมาก ทำให้ความเร็วของระบบอัตโนมัติด้านดีไซน์ยังตามงานวิศวกรรมไม่ทัน
• เดิมทีขั้นตอนแปล Figma mockup ไปเป็นโค้ดคือคอขวดที่ใหญ่ที่สุด แต่ถ้าดีไซเนอร์ ออกแบบในสภาพแวดล้อมโค้ดโดยตรง ก็สามารถตัดความสูญเปล่าจากการ handoff นี้ได้ทั้งหมด
• คุณค่าหลักของดีไซเนอร์ในยุค AI ไม่ใช่งานจัดวางพิกเซล แต่คือ ความสามารถในการ orchestration: การตัดสินใจว่าจะสร้างอะไร การประเมินผลลัพธ์จาก AI อย่างวิพากษ์วิจารณ์ และการกำกับงานทั้งหมด
• บริษัทที่ลงทุนกับทีมขนาดเล็กแบบ empowered และ ดีไซน์ซิสเต็มที่เครื่องอ่านเข้าใจได้ จะเหนือกว่าองค์กรแบบ feature factory ขนาดใหญ่

---

เบื้องหลังการเปลี่ยนแปลงของงานออกแบบผลิตภัณฑ์

• ตั้งแต่สร้างเว็บไซต์แรกด้วย Dreamweaver ในปี 1999 ผู้เขียนทำงานในรูปแบบออกแบบด้วย Photoshop, Sketch, Figma แล้วส่งต่อให้นักพัฒนา
• ไม่นานมานี้ ผู้เขียนเชื่อม Claude Code เข้ากับดีไซน์ซิสเต็มของบริษัท และ สร้าง UI ที่ใช้งานได้จริงด้วยเพียงสามพรอมป์ต์ โดยข้ามขั้นตอนออกแบบภาพแบบเดิมไป
• ประสบการณ์นี้ยืนยันว่า คุณค่าของดีไซเนอร์กำลังย้ายจากความสามารถในการลงมือทำ ไปสู่ 'รสนิยมและการตัดสินใจเชิงกลยุทธ์'
• เมื่อ AI ใช้ดีไซน์ซิสเต็มเป็นฐานเพื่อทำให้เกิดโฟลว์แบบ 'prompt → generate → deploy' การเปลี่ยนแปลงเชิงรากฐานของงานออกแบบผลิตภัณฑ์จึงกำลังเกิดขึ้น

ข้อถกเถียงที่ผิดจุด: ไม่ใช่เรื่องจำนวนคน แต่เป็นการเปลี่ยนของกระบวนการ

• วาทกรรมปัจจุบันเกี่ยวกับ AI และสายงานโปรดักต์ยังคงติดอยู่กับการแย่งพื้นที่กันแบบ ยึดจำนวนคนเป็นศูนย์กลาง เช่น "ดีไซเนอร์จะตกงานไหม" หรือ "วิศวกรจะถูกแทนที่ไหม"
• คำถามที่แท้จริงเกี่ยวกับ กระบวนการ ไม่ใช่ว่า AI จะลบหน้าที่เหล่านี้หรือไม่ แต่คือใครจะทำ เร็วแค่ไหน และคอขวดจะย้ายไปอยู่ตรงไหน
• งานที่ มองไม่เห็น (invisible work) อย่างการเขียนโค้ด, เขียน PRD, และวิเคราะห์ข้อมูล ทำให้อัตโนมัติได้ง่าย เพราะช่องว่างด้านคุณภาพถูกซ่อนอยู่หลัง UI
  • ต่อให้โค้ดจะรก ถ้าแอปใช้งานได้ก็แทบไม่มีใครสนใจ และถึง PRD จะสร้างโดย AI ถ้าการนิยามปัญหาถูกต้องก็ไม่เป็นไร
• ตรงกันข้าม งานที่ มองเห็นได้ (visible work) อย่างส่วนติดต่อผู้ใช้, โฟลว์, และประสบการณ์ จะเผยให้เห็นความต่างด้านคุณภาพทันที และผู้ใช้รับรู้ได้โดยตรง
• เมื่อการ build เร็วขึ้นและถูกลง ปัญหาที่ยากที่สุดจะไม่ใช่ "จะสร้างอย่างไร" แต่เป็น "อะไรที่คุ้มค่าพอจะสร้าง"
• ความเร็วที่เพิ่มขึ้นของงานออกแบบที่มี AI ช่วย จึงหลีกเลี่ยงไม่ได้ที่จะตามหลังงานวิศวกรรม และ ความไม่สมมาตร นี้จะเปลี่ยนโฉมทั้งกระบวนการพัฒนาผลิตภัณฑ์และวิธีจัดทีม

งานที่มองเห็นได้: ดีไซน์ไม่ใช่สิ่งหลังผนัง แต่คือตัวผนังเอง

• งานวิศวกรรมเปรียบได้กับ ระบบประปา — ซ่อนอยู่หลังผนัง และถ้าน้ำไหลออกจากก๊อกได้ โครงสร้างภายในก็ไม่สำคัญนัก
  • Boris Cherny ใช้ coding agent 4~5 ตัวพร้อมกัน และเพิ่มความเร็วได้มากกว่า 400% ขณะที่วิศวกรใน Silicon Valley กำลังเปลี่ยนจากการเขียนโค้ดเอง ไปสู่การ orchestrate ทีมของเอเจนต์แทน
• แต่การออกแบบซอฟต์แวร์คือตัวผนังเอง เป็นทั้งก๊อกน้ำและที่จับ ดังนั้นถึง AI จะเป็นคนสร้าง ผู้ใช้ก็ยังไวต่อรูปลักษณ์และความรู้สึกในการใช้งาน
• AI อาจทำตาม มาตรฐานและแพตเทิร์น ที่มีในข้อมูลฝึกได้ แต่การตัดสินใจบนฐาน งานวิจัยผู้ใช้ จำนวนมาก เช่น บทสัมภาษณ์ผู้ใช้หลายสิบครั้ง ผลสำรวจ การวิเคราะห์การใช้งาน และการ audit คู่แข่ง มีคอนเท็กซ์ใหญ่เกินกว่าจะจัดการได้ง่าย
• ยังมีคอขวดที่เรียกว่า ปัญหาการรับเข้า (ingestion problem) — ต่อให้ AI สร้างโค้ดจำนวนมากหรือสรุปประชุมออกมาได้ มนุษย์ก็ยังต้องอ่าน ทำความเข้าใจ และประเมินอย่างวิพากษ์วิจารณ์ จึงจะสนทนาและตัดสินใจเชิงปัญญาได้
  • การรีวิวโค้ดกำลังกลายเป็นคอขวดจริง และนี่คือ ข้อจำกัดของความเร็วมนุษย์ ที่ไม่มีโมเดลใดเลี่ยงได้
• AI เก่งเรื่อง การสร้างและสรุปคอนเทนต์ แต่ความสามารถในการสร้างสิ่งใหม่จริงๆ หรือมีรสนิยม (taste) ยังไม่ถูกพิสูจน์

ออกแบบในโค้ด ไม่ใช่ใน Figma

• คอขวดที่ใหญ่ที่สุดของการพัฒนาผลิตภัณฑ์คือขั้นตอน handoff ระหว่างดีไซเนอร์กับนักพัฒนาในการ แปล Figma mockup ไปเป็นโค้ด production
  • มี ความไร้ประสิทธิภาพมหาศาล จากการวาดภาพของซอฟต์แวร์ ขัดเกลาพิกเซล ส่งต่อให้วิศวกร แล้วให้ QA ตรวจเทียบโค้ดกับ mockup และตีกลับ PR เพราะตัวอักษรหรือ spacing ไม่ตรง
• AI ช่วยคลี่คลายคอขวดนี้ได้ แต่จะเกิดขึ้นได้ก็ต่อเมื่อดีไซเนอร์ ออกแบบในสภาพแวดล้อมโค้ดโดยตรง
• ดีไซเนอร์บางส่วนเริ่มยกเลิก Figma subscription จริงและย้ายไปใช้เครื่องมือ AI โดยให้เหตุผลสำคัญว่า mockup ไม่ใช่ตัวผลิตภัณฑ์ แต่เป็นเพียง ผลลัพธ์คู่ขนานที่ต้องแปล ทบทวน และปรับแก้
  • ทุกพิกเซลที่ถูกผลักออกจาก Figma คือคำมั่นที่วิศวกรต้องรักษาในสื่อที่ต่างออกไปโดยสิ้นเชิง และยิ่งเครื่องมือออกแบบห่างจากโค้ด production มากเท่าไร ความสูญเปล่าจาก handoff ก็ยิ่งมากขึ้น
• การทดลองที่ชี้ Claude Code ไปยัง repo ของดีไซน์ซิสเต็มแล้วสร้าง UI ที่ทำงานได้ด้วยสามพรอมป์ต์ ยืนยันเรื่องนี้
  • เพื่อให้เชื่อถือได้ในระดับสเกล ยังต้องมี เอกสารที่แข็งแรง กฎที่ชัดเจน และ agent orchestration แต่รากฐานได้ถูกวางไว้แล้ว
• กรณีของทีมวิศวกรรม Monday.com: ในการลองครั้งแรกโดยนำลิงก์ Figma ไปวางใน Cursor โค้ดที่สร้างขึ้นไม่ได้ใช้คอมโพเนนต์ของดีไซน์ซิสเต็ม, มีการ hardcode สี, และ override typography ค่าเริ่มต้นของระบบ
  • ทางออกคือสร้าง ดีไซน์ซิสเต็ม MCP (Model Context Protocol) — ทำให้คอมโพเนนต์ โทเค็น กฎการเข้าถึง และรูปแบบการใช้งาน อยู่ในรูปแบบที่เครื่องอ่านเข้าใจได้ และใช้ agentic workflow 11 โหนดเพื่อประกอบคอนเท็กซ์แบบมีโครงสร้างให้โมเดล
  • เป็นแนวทางแบบ "orchestration ไม่ใช่เวทมนตร์" โดยไม่ได้ให้เอเจนต์เขียนโค้ดตรงๆ แต่สร้างความเข้าใจว่าโค้ดที่ดีควรเป็นอย่างไร แล้วส่งต่อให้นักพัฒนาหรือ coding agent ของนักพัฒนา
• ดีไซเนอร์ของ Anthropic กำลัง ส่ง pull request ด้วยตนเอง ไปยัง Claude Code และผลิตภัณฑ์คอนโซล พร้อม deploy สู่ production แล้ว — ณ เดือนกุมภาพันธ์ 2026 เรื่องนี้เป็นความจริงไปแล้ว

สิ่งที่ยังเป็นของมนุษย์: orchestration และการตัดสินใจ

• หาก AI สามารถเขียนโค้ด เขียน PRD สรุปงานวิจัย และทำ prototype อินเทอร์เฟซได้ทั้งหมด สิ่งที่ยังเหลือให้มนุษย์ทำคือ orchestration
  • โมเดลมีความสามารถเพียงพอแล้ว และคอขวดคือคนหน้าคีย์บอร์ด — ความสามารถสำคัญคือรู้ว่าจะขออะไร แบ่งงานอย่างไร และเมื่อไรควรปฏิเสธผลลัพธ์ของโมเดล
• Kyle Zantos เป็นดีไซเนอร์ที่ใช้เวลาทำงาน 70% อยู่ในเทอร์มินัล และย้ำว่าเพราะคำแนะนำเมื่อ 4 เดือนก่อนยังล้าสมัยได้ จึงควรเรียนรู้ ปรัชญาและแนวทาง มากกว่าการยึดติดกับการตั้งค่าเครื่องมือแบบเฉพาะเจาะจง
• Arin Bhowmick, Chief Design Officer ของ SAP กล่าวว่าอินเทอร์เฟซที่ดูสวยและขัดเกลา อาจ ปกปิดปัญหาลึกกว่าเดิม เช่น ผลลัพธ์ที่ไม่น่าเชื่อถือ การตัดสินใจที่ไม่โปร่งใส และการทำงานที่เปราะบางใน edge case
  • ผู้นำด้านดีไซน์จึงต้องมอง ความเชื่อถือได้ ความชัดเจน และความน่าไว้วางใจ เป็นผลลัพธ์การออกแบบชั้นหนึ่ง ไม่ใช่แค่คุณภาพผิวเผิน
• ตามที่ Vlad Derdeicea ระบุ เวลาราว 80% ของ design lead ถูกใช้ไปกับการสื่อสาร การทำให้สอดคล้อง และการให้เหตุผล ส่วนงานออกแบบแบบลงมือทำจริงมีเพียง 20%
  • ทุกการตัดสินใจด้านดีไซน์มี "ภาษีของการให้เหตุผล" (justification tax) — เวลาที่ต้องใช้เพื่ออธิบาย จดบันทึก และปกป้องตัวเลือก ซึ่งในสายงานอื่นอาจจบได้ด้วยบทสนทนาสั้นๆ
  • AI จึงควรเล็งไปที่ 80% นี้ ไม่ใช่งานทำ mockup: การสังเคราะห์บันทึกประชุม ร่างการสื่อสารกับผู้มีส่วนได้ส่วนเสีย สรุปงานวิจัย และสร้าง prototype อย่างรวดเร็วเพื่อปิดข้อถกเถียงด้วยข้อมูลแทนความเห็น
• กรอบคิดของ Jan Tegze คือ อย่าพยายามทำงานเดิมให้ดีขึ้นเท่านั้น แต่ให้มองหา ข้อจำกัดในโดเมนที่เกิดจากข้อจำกัดของมนุษย์ แล้วใช้เอเจนต์ลบมันออก — ไม่ใช่แค่เร่งงานเดิม แต่ทำสิ่งที่ก่อนหน้านี้เป็นไปไม่ได้
  • "ไม่ใช่แข่งขันกับเอเจนต์ แต่สร้างขีดความสามารถใหม่ที่ต้องอาศัยทั้งตัวเราและเอเจนต์"
• ดีไซเนอร์จูเนียร์ที่มีประสบการณ์ไม่เกิน 5 ปี มีความเสี่ยงมากกว่า เพราะยังขาดวิจารณญาณในการประเมินผลลัพธ์ AI และประสบการณ์ในการจับความผิดพลาดของโมเดล ส่งผลให้เพดานขั้นต่ำของทักษะกำลังสูงขึ้น

ทีมเล็ก คานงัดใหญ่

• บริษัทซอฟต์แวร์ส่วนใหญ่ยังมีโครงสร้างที่ไม่เหมาะกับบริบทปัจจุบัน — เป็น feature factory ที่มี PM มากเกินไป โดยวาง PM ไว้ทุกสควอดไม่ว่าทีมนั้นจะมีงานดีไซน์เฉพาะหรือไม่
  • สาเหตุที่ PM เพิ่มจำนวนมากในยุค ZIRP เพราะบทบาทนี้ใกล้รายได้และจำนวนคนขยายตามความซับซ้อนขององค์กร
  • Marty Cagan เรียกสิ่งนี้ว่า "product management theater" — การมี PM ที่ไม่มีประสิทธิภาพจำนวนมาก ซึ่งแทบไม่ต่างจากผู้จัดการโปรเจกต์เงินเดือนสูงที่ทำแค่สร้างโรดแมปและรัน standup
• Andrew Ng คาดการณ์ที่ Davos ว่าเมื่อ AI ระเบิด productivity ด้านวิศวกรรม สัดส่วน PM ต่อวิศวกรจะกลับทิศจาก 1:8 ไปทาง 1:1
  • เมื่อ AI agent เขียนโค้ด production ส่วนใหญ่ ฐานวิศวกรรมขนาดใหญ่ก็จะหดลง และ สเปกกับการตัดสินใจ จะกลายเป็นทรัพยากรที่หายาก
• Airbnb รวม product management กับ product marketing ให้เป็นบทบาท "full-stack" เดียว
  • Brian Chesky กล่าวว่า "ถ้าคุณไม่รู้ว่าจะเล่าเรื่องของผลิตภัณฑ์อย่างไร คุณก็พัฒนาผลิตภัณฑ์ไม่ได้" — เป็นการยกระดับการเล่าเรื่องและการสื่อสารภายนอกให้เป็นองค์ประกอบชั้นหนึ่งของงาน PM
  • ยกระดับดีไซเนอร์ให้เป็น "สถาปนิก" ที่นำผลิตภัณฑ์ร่วมกับวิศวกร แทนที่จะเป็นเพียงบริการปลายน้ำที่รับตั๋วงานมาทำ
  • งานประสานงานที่เคยทำให้จำนวน PM พองตัว ถูกย้ายไปให้ program manager โดยเฉพาะ
• โมเดลนี้คล้ายโครงสร้างแบบ functional ของ Apple: ผู้เชี่ยวชาญนำผู้เชี่ยวชาญ และ CEO เป็นจุดรวมการบูรณาการ โดยไม่มี PM ในบทบาท "mini CEO" ที่ดูแลหน่วยธุรกิจ
• ทีมในอุดมคติของยุค AI คือทีมขนาดเล็กแบบ empowered ที่มี วิศวกร 2~3 คน, PM 1 คน, และดีไซเนอร์ 1 คน
  • ดีไซน์ซิสเต็มจะกลายเป็น โครงสร้างพื้นฐานหลัก และหากไม่มีดีไซน์ซิสเต็มในโค้ดพร้อมเอกสารกำกับ AI ก็จะตัดสินใจผิดเกี่ยวกับ UI และการ implement
  • บริษัทที่ลงทุนกับดีไซน์ซิสเต็มแบบเครื่องอ่านได้และทีมเล็กแบบ empowered จะเหนือกว่าบริษัทที่ยังยึดติดกับสควอด 15 คนและการอนุมัติ 3 ชั้น

ผลของดอกเบี้ยทบต้น: ช่องว่างระหว่าง orchestrator กับ pixel pusher

• หลังการทดลองสร้างหน้าจอที่ทำงานได้จากดีไซน์ซิสเต็มด้วย Claude Code ผู้เขียนก็ยัง ปรับปรุงต่อเนื่อง ด้วยเอกสารที่ดีขึ้น กฎคอมโพเนนต์ที่เข้มขึ้น และแนวทางการประกอบใช้งานที่ชัดขึ้น
  • ในแต่ละรอบ ทุกอย่างเร็วขึ้นและเข้าใกล้ production-ready มากขึ้น โดยทั้งความก้าวหน้าของโมเดล การขัดเกลาทักษะ และความสามารถในการกำกับ ล้วน สะสมแบบทบต้น
• ภายใน 12 เดือน ช่องว่างระหว่าง "ดีไซเนอร์ที่ orchestrate AI" กับ "ดีไซเนอร์ที่ขยับพิกเซลใน Figma" จะมหาศาล
  • ไม่ใช่เพราะ pixel pusher ขาดความสามารถ แต่เพราะ orchestrator ทำงานอยู่บนความเร็วและขอบเขตที่ต่างกันโดยสิ้นเชิง — ในขณะที่คนอื่นยังส่ง mockup ไปใช้ในประชุม handoff พวกเขากำลัง deploy UI ที่ใช้งานได้จริง
• ผู้เขียนกำลังสอนแนวทางนี้ให้ทีม ไม่ใช่เพราะอาชีพจะหายไป แต่เพราะมันกำลังเปลี่ยนเป็นอาชีพที่ รสนิยม วิจารณญาณ และความสามารถในการกำกับงาน สำคัญกว่าความสามารถในการวาดภาพ