🛑 เมื่อ AI วาดหน้าจอได้ในไม่กี่วินาที สิ่งที่กำลังตายอาจไม่ใช่ “นักออกแบบ” แต่คืองานบางส่วนที่เราเคยเรียกว่า “Design”
(เมื่อการผลิตหน้าจอ Wireframe และ Prototype มีราคาถูกลงอย่างรวดเร็ว คุณค่าของ Designer จึงต้องขยับจาก “คนทำ Artifact” ไปสู่คนที่รู้ว่าอะไรควรถูกสร้าง ทำไมต้องสร้าง และบางครั้งสามารถพามันไปถึง Working Product ได้ด้วยตัวเอง?)
“ช่วยออกแบบแอปจองตั๋วให้หน่อยครับ ขอ Minimal มี Dark Mode แล้วทำ Flow ตั้งแต่เลือกเที่ยวจนจ่ายเงินให้ครบ” ~ นี่คือ prompt ล่าสุดที่ผมใช้กับ AI ในงานโปรเจค low-code ส่วนตัว ซึ่งเมื่อก่อน นี่แทบจะต้องเกาะโต๊ะง้อคนที่ทำตำแหน่งที่ชื่อ Graphic Designer หรือ UX/UI เลย…
เมื่อก่อนคำขอแบบนี้อาจต้องเริ่มจาก Workshop, Wireframe, Mockup และ Prototype หลายรอบ วันนี้เครื่องมืออย่าง Figma Make, Stitch เป็นต้น สามารถสร้าง Interface, Interaction และ Code จาก Natural-language Prompt ได้
ขณะที่ v0 ของ Vercel ก็สร้าง UI และ Application จากคำอธิบายภาษาคนได้เช่นกัน หรือถ้า All-in เครื่องมือแบบ Loveable ก็ตอบโจทย์มาก สั่งงานแล้วก็นับ credit กันไป?
แน่นอนครับ สิ่งที่ได้จาก Prompt แรกยังไม่ใช่ Product ที่สมบูรณ์ Figma เองยอมรับว่า First Draft ที่ AI สร้างอาจดูดี แต่ยังไม่ได้ใช้ Design System จริง Copy อาจเป็น Placeholder และ Edge Case สำคัญยังตกหล่นได้ แต่ต่อให้หัก Discount ตรงนี้ออก ภาพใหญ่ก็ยังชัดอยู่ดีว่า ต้นทุนของการ “ผลิตหน้าจอ” กำลังลดลงอย่างรวดเร็ว และทุกครั้งที่ต้นทุนของ Skill ใดลดลง คำถามสำคัญจะไม่ใช่เพียง “AI ทำแทนเราได้หรือยัง?” แต่คือ
“ถ้างานส่วนนี้ไม่ได้แพงเหมือนเดิมแล้ว คุณค่าที่เหลือของเราคืออะไร?”
⸻
🎨 บางทีเราอาจเอา “เครื่องมือของ Design” ไปเท่ากับ “Design” มานานเกินไป
เวลาเราพูดว่า Designer เก่ง เรามักนึกถึงคนที่ทำ Layout สวย ใช้ Auto Layout คล่อง สร้าง Component เป็น หรือทำ Prototype ลื่น ทั้งหมดสำคัญครับ แต่สิ่งเหล่านี้คือ วิธีที่ Designer แสดงความคิดออกมา ไม่ใช่ความคิดทั้งหมดของ Design
ย้อนกลับไปตั้งแต่ปี 1982 Nigel Cross ตีพิมพ์ Designerly Ways of Knowing ในวารสาร Design Studies และเสนอว่า Design มีวิธีคิดและแก้ปัญหาที่มีลักษณะเฉพาะ ไม่ใช่เพียงทักษะการใช้เครื่องมือ งานของ Cross และงานด้าน Design Cognition ที่ตามมาให้ภาพของ Designer ว่าเป็นคนที่รับมือกับปัญหาที่นิยามไม่สมบูรณ์ คิดผ่านการสร้าง Solution และปล่อยให้ความเข้าใจ Problem กับ Solution พัฒนาไปพร้อมกัน
ไม่มีแก่นข้อไหนบอกว่า Designer คือคนที่ “ลาก Rectangle ได้เร็วที่สุด”
ดังนั้น ถ้า AI ลาก Rectangle ได้เร็วกว่าเรา ผมไม่คิดว่านั่นคือจุดจบของ Design แต่มันอาจเป็นจุดจบของช่วงเวลาที่องค์กรเคย จ่ายเงินแพงเพื่อให้มนุษย์ผลิต Design Artifact
⸻
📉 สิ่งที่เสี่ยงกว่าคือบทบาท “Human Middleware”
Workflow แบบคลาสสิกของ Product Development คือ Business หรือ Product Manager ไปคุยกับลูกค้าแล้วเขียน Requirement จากนั้น Designer แปลง Requirement เป็นหน้าจอ ก่อนส่งให้ Developer แปลงหน้าจอเป็น Code
มนุษย์สามกลุ่มส่ง Artifact ต่อกันเหมือนสายพานโรงงาน รูปแบบนี้เคยสมเหตุสมผล เพราะแต่ละขั้นต้องใช้ Skill เฉพาะและมีต้นทุนสูง แต่ AI กำลังลด Translation Cost เหล่านี้ลงอย่างรวดเร็ว
Product Manager ทำ Prototype เองได้ Designer Generate Code ได้ Developer Generate UI ได้ และ Business User สามารถสร้าง Application รุ่นแรกได้
Figma 2026 AI Report สะท้อนเรื่องนี้ค่อนข้างชัด โดยสัดส่วน Designer ที่เข้าไปมีส่วนร่วมใน Development เพิ่มจาก 21% เป็น 41% ภายในหนึ่งปี ขณะที่ Developer ที่เข้าไปทำ Design เพิ่มจาก 44% เป็น 60%
นี่ไม่ใช่แค่เรื่อง Tool ใหม่ครับ แต่มันคือ Division of Labor เดิมกำลังบางลง ดังนั้น ถ้าหน้าที่หลักของ Designer ยังเป็น “รับ Requirement แล้ววาดให้สวย” ผมคิดว่าเก้าอี้ตัวนั้นกำลังสั่นจริง เพราะคำตอบว่า “องค์กรยังต้องรอ Designer เพราะ Designer ใช้ Figma เก่งกว่า” จะมีพลังลดลงเรื่อยๆ
สิ่งที่ตลาดจะเริ่มถามแทนคือ
“แล้ว Judgment ของคุณเพิ่มอะไรเข้าไป?”
⸻
🧠 AI ไม่ได้ทำให้ Design สำคัญน้อยลง แต่มันย้ายจุดที่ Design มีราคา
สิ่งที่น่าสนใจจาก Figma 2026 AI Report คือ แม้ AI จะสร้าง Design ได้มากขึ้น ผู้ตอบถึง 90% ยังมองว่า Design มีความสำคัญอย่างน้อยเท่าเดิมเมื่อเทียบกับก่อนยุค AI และเกือบ 6 ใน 10 มองว่าสำคัญขึ้น
ฟังดูย้อนแย้งไหมครับ?
“AI ทำ Design ได้มากขึ้น แต่ Design กลับสำคัญขึ้น?”
ผมคิดว่าคำตอบอยู่ที่การแยก Production of Design ออกจาก Design Judgment เมื่อการสร้าง Layout ถูกลง เราสามารถ Generate 20 Direction แทนที่จะมีเวลาทำเพียง 3 Direction ปัญหาใหม่จึงไม่ใช่ “เราสร้างทางเลือกได้ไหม?” แต่เป็น “ทางเลือกไหนควรชนะ?”
AI ทำ Landing Page ได้ 50 แบบ แต่ใครตัดสินว่าแบบไหนสะท้อน Brand จริง? AI ทำ Checkout Flow ได้ 10 แบบ แต่ใครรู้ว่า Friction ตรงไหนผู้ใช้ยอมรับได้? AI สร้าง Feature ได้ไม่รู้จบ แต่ใครกล้าพูดว่า “Feature นี้ไม่ควรถูกสร้างตั้งแต่แรก”
เมื่อ Generation ถูกลง Taste, Judgment และ Direction จะยิ่งแพงขึ้น?
⸻
🧬 Designer ต้องขยับจาก “How should it look?” ไปสู่ “What should exist?”
Designer แบบเดิมอาจได้รับโจทย์ว่า “ช่วยออกแบบหน้าจอ Loyalty Program ให้หน่อย” แล้วเริ่มจาก User Flow และ UI
แต่ Designer ที่มีคุณค่าในยุคต่อไปควรถามย้อนกลับได้ว่า ทำไมเราต้องมี Loyalty Program? ปัญหาคือ Retention หรือ Frequency? ถ้าทำ Feature นี้ Customer Behavior จะเปลี่ยนอย่างไร? ต้องเป็นหน้าจอใหม่จริงหรือไม่? แก้ด้วย Service, Policy หรือ Process ได้ไหม?
นี่คือสิ่งที่ผมเรียกว่า Strategic Design
ไม่ใช่เพราะ Designer ทุกคนต้องกลายเป็น Consultant แต่เพราะเมื่อ Cost ของ “How” ลดลง Value จะไหลขึ้นไปหา “What” และ “Why” มากขึ้นตามธรรมชาติ
นี่อาจเป็นการกลับไปหาแก่นเดิมของ Design ด้วยซ้ำครับ Designer ไม่ควรมีหน้าที่เพียงตกแต่ง Solution ที่คนอื่นคิดเสร็จแล้ว แต่ควรมีส่วนในการกำหนดว่า Problem คืออะไร และ Solution แบบไหนสมควรเกิดขึ้น
⸻
🚀 แล้ว Designer จะกลายเป็น Product Builder หรือไม่?
ผมคิดว่า “บางคนจะกลายเป็น และแนวโน้มนี้จะเพิ่มขึ้น”
แต่ไม่ได้หมายความว่า Designer ทุกคนต้องกลายเป็น Full-stack Developer
“Product Builder” ในความหมายที่ผมใช้ คือคนที่สามารถเดินทางได้ไกลขึ้นตลอดเส้นจาก
Problem → Idea → Prototype → Validation → Working Product
โดยไม่ต้องหยุดทันทีเมื่อชนขอบเขต Job Description แบบเดิม
Figma เองวันนี้ใช้คำว่า AI Product Builder กับ Figma Make ซึ่งสามารถเปลี่ยน Product Vision เป็น Functional Prototype ผ่าน Natural Language เชื่อม Design System และข้อมูลจริงเพื่อทดสอบ Flow ได้ และในรายงานปี 2026 Figma ระบุด้วยว่าสัดส่วน Product Builder ที่สร้าง Interactive Prototype เพิ่มขึ้นอย่างมาก
ดังนั้น Designer บางคนอาจไปทาง Strategic Product Design บางคนเป็น Design Engineer หรือ Product Builder และบางคนเน้น Design System หรือ AI Experience
สิ่งที่เหมือนกันคือ ขอบเขตความรับผิดชอบจะกว้างกว่า “ส่งไฟล์ Design ให้ Dev”
แต่ต้องไม่ตีความเกินไปว่า “AI เขียน Code ให้แล้ว จึงไม่ต้องมี Engineer” เพราะคำว่า สร้างได้ กับ เป็นเจ้าของ Software Lifecycle ได้ ยังเป็นคนละเรื่อง Production ยังมี Security, Privacy, Architecture, Testing, Observability, Scalability และ Maintenance
AI ไม่ได้กำลังลบ Expertise ครับ…มันกำลังลด Handoff ที่ไม่จำเป็น
⸻
🔄 เมื่อทุกคนสร้างได้ ความได้เปรียบจะย้ายจาก Creation ไปสู่ Selection
ถ้าเมื่อก่อน Designer มีเวลาสร้าง 3 Concept วันนี้ AI ช่วยสร้าง 30 Concept ได้ ฟังดู Productivity เพิ่มสิบเท่า แต่บริษัทไม่ได้ต้องการ 30 หน้าจอครับ
สุดท้ายต้องเลือกหนึ่ง?
ดังนั้น Bottleneck จะค่อยๆ ย้ายจาก Creation → Selection, แบบไหนเหมาะกับ User? แบบไหนสร้าง Business Value? อะไรสอดคล้องกับ Brand? Trade-off ไหนยอมรับได้? อะไร Build และ Maintain ได้จริง? และอะไรแตกต่างพอที่จะไม่กลายเป็น Product หน้าตา Generic เหมือน AI Template อีกพันตัว?
นี่คือเหตุผลที่คำว่า Taste จะกลับมาแพงขึ้น
Taste ไม่ใช่แค่ “ฉันชอบสีนี้” แต่คือความสามารถในการเห็นว่าอะไร Generic อะไรมี Character อะไรเหมาะกับ Context และเมื่อไรเราควรหยุด Polish เพราะสิ่งที่กำลังขัดเงาอยู่นั้นไม่ได้แก้ปัญหาหลัก
AI ไม่ได้ทำให้ Craft หายไป มันกำลัง ย้าย Craft จากมือ ไปอยู่ที่สายตาและ Judgment มากขึ้น
⸻
👑 และไม่ใช่เฉพาะ Designer ที่ถูกบีบให้ขยับขึ้น
ถ้า Product Manager อ่านมาถึงตรงนี้แล้วคิดว่า “ดี ต่อไปผมวาดเองได้ ไม่ต้องมี Designer” ผมขอเบรกนิดหนึ่งครับ
เพราะ Logic เดียวกันใช้กับ PM และ Engineer เช่นกัน
* ถ้าคุณค่าของ PM คือเขียน PRD, ทำ Roadmap, สรุป Meeting และสร้าง User Story —> AI ก็กำลังกิน Operational Work เหล่านั้น
* ถ้าคุณค่าของ Engineer คือแปลง Design เป็น Code —> AI ก็ลดต้นทุนงานส่วนนี้เหมือนกัน
ดังนั้นเรื่องนี้ไม่ใช่ “Designer กำลังถูก AI แทน” แต่มันคือ Product Development ทั้งสายกำลังถูกบีบให้ขยับจาก Artifact Production ไปสู่ Judgment และ Outcome
PM ต้องเก่ง Problem และ Direction มากขึ้น Designer ต้องเก่ง Product, Behavior และ Business มากขึ้น Engineer ต้องเก่ง Architecture, Reliability และ Technical Judgment มากขึ้น
คนที่เสี่ยงที่สุดจึงไม่ใช่ Role ไหน แต่คือคนที่ยังนิยามคุณค่าตัวเองด้วย Artifact ที่ตัวเองเคยเป็นคนเดียวที่ทำได้
⸻
🏭 องค์กรเองก็ต้องเลิกใช้ Designer เป็นโรงงานผลิตหน้าจอได้แล้วจากนี้?
ถ้าบริษัทบอก Designer ว่า “อยากให้คิด Strategic มากขึ้น” แต่ Calendar ของเขายังเต็มไปด้วย Ticket แก้ Pixel, Resize Banner, ทำ Screen ตาม Requirement และส่ง Asset ให้ Dev ปัญหาไม่ได้อยู่ที่ Designer ไม่ Strategic ครับ
องค์กรกำลังใช้คนผิดแล้วนะครับในยุคนี้!!!
AI เปิดโอกาสให้เรารื้อ Operating Model ตรงนี้ได้ งาน Production Design ที่เป็น Pattern เดิมควรถูก Automation มากขึ้น Design System ควรรับภาระ Consistency มากขึ้น Business และ Product สามารถสร้าง First Draft เองได้มากขึ้น และ Designer ไม่จำเป็นต้องเป็น Tollgate ที่ทุก Pixel ต้องผ่าน
เวลาที่ได้คืนมาควรถูกใช้กับ Research, Problem Framing, Concept Exploration, Behavior, Service Design, Experimentation และ Strategic Product Decision
เพราะถ้าเราสอน AI ให้ Designer แล้วเอากลับมาทำงานเดิม สิ่งที่องค์กรได้คือ “โรงงานผลิตหน้าจอเดิมที่เดินเร็วขึ้น” ไม่ใช่ Transformation
⸻
✨ อย่าตกหลุมรักหน้าจอ จงตกหลุมรักปัญหา!!!
ถ้าวันนี้คุณเป็น UX/UI Designer ผมไม่คิดว่าคุณควรกลัวเพราะ AI สร้างหน้าจอได้ครับ
ผมจะเริ่มกังวลก็ต่อเมื่อสิ่งที่คุณขายให้ตลาดมีเพียง “ความสามารถในการสร้างหน้าจอ” เพราะ Supply ของสิ่งนั้นกำลังเพิ่มขึ้นอย่างรวดเร็ว
“โลกไม่ได้ขาดหน้าจอ ไม่ได้ขาด Dashboard ไม่ได้ขาด Application และแน่นอนว่าไม่ได้ขาดปุ่มสวยๆ อีกหนึ่งปุ่ม”
สิ่งที่เรายังขาดคือคนที่เข้าใจว่า มนุษย์กำลังพยายามทำอะไร? Pain จริงอยู่ตรงไหน? Business Model ต้องการอะไร? Trade-off ใดควรถูกเลือก? อะไรควรถูก Simplify? และสิ่งไหน ไม่ควรถูกสร้างขึ้นมาตั้งแต่แรก?
นี่เป็นเหตุผลที่ผมคิดว่า Design ไม่ได้กำลังตายครับ ตรงกันข้าม
“Design กำลังถูกบังคับให้กลับไปเป็น Design อีกครั้ง”
หลังจากเราใช้เวลาหลายปีทำให้มันกลายเป็นโรงงานผลิต Screen
“ถ้า AI วาดหน้าจอแทนเราได้ ก็ดีครับ…ปล่อยให้มันวาด…แล้วเอาเวลาของเรากลับไปทำสิ่งที่แพงกว่า คือ เข้าใจมนุษย์ เลือกปัญหา Challenge Assumption ตัดสิน Trade-off สร้าง Direction และพา Solution ไปให้ไกลกว่าไฟล์ Design?”
เพราะในโลกที่ใครๆ ก็สร้างหน้าจอได้ คุณค่าของ Designer จะไม่ได้อยู่ที่ว่า “คุณวาดอะไรได้” มากเท่ากับว่า “คุณรู้ได้อย่างไรว่ามันควรถูกวาดขึ้นมาตั้งแต่แรก”
#วันละเรื่องสองเรื่อง #ExecutiveMindset #UXUI #ProductDesign #ProductBuilder #AITransformation #FutureOfWork #ProductManagement #DesignLeadership #OrganizationalDesign
⸻
📚 Source / Reference
* Nigel Cross — “Designerly Ways of Knowing,” Design Studies, Vol. 3, Issue 4 (1982): ใช้เป็นฐานแนวคิดว่า Design มีวิธีคิดและแก้ปัญหาที่มีลักษณะเฉพาะ ไม่ควรถูกลดเหลือเพียงทักษะการใช้เครื่องมือ
* Nigel Cross — Designerly Ways of Knowing and Thinking, 2nd Edition (Springer, 2025): ใช้ประกอบพัฒนาการของงานด้าน Design Cognition เช่น Problem Formulation, Solution Generation, Co-evolution ของ Problem/Solution และความแตกต่างระหว่าง Novice กับ Expert Designer
* Figma — 2026 AI Report (24 June 2026): งานวิจัยของ Figma จาก Designers, Developers และ Product Managers หลายประเทศ พบว่า Designer ที่เข้า Development เพิ่มจาก 21% เป็น 41%, Developer ที่ทำ Design เพิ่มจาก 44% เป็น 60% และ 90% มองว่า Design สำคัญอย่างน้อยเท่าเดิมในยุค AI ทั้งนี้ควรอ่านในฐานะ Research จากผู้ผลิต Platform ไม่ใช่งานวิจัยอิสระเชิงสาเหตุ
* Figma Make / AI Product Builder (2026): ใช้เป็นบริบทเทคโนโลยีปัจจุบันว่า Product Teams สามารถสร้าง Interactive Prototype, Interface, Logic และ Code จาก Natural-language Prompt ได้มากขึ้น รวมถึงเชื่อม Design System และข้อมูลจริงเพื่อทดลอง Product Direction ได้เร็วขึ้น
* Figma — “Build with more context and more control in Figma Make” (2 April 2026): ใช้เป็นข้อจำกัดสำคัญของ Generative UI โดย Figma ระบุว่า AI สามารถสร้าง UI ได้รวดเร็ว แต่ First Draft อาจยังไม่ใช้ Components จริง ใช้ Placeholder Copy และพลาด Edge Cases จึงไม่ควรตีความว่า Prompt-to-UI เท่ากับ Production-ready โดยอัตโนมัติ
* Vercel — v0 / Generative UI and the new v0: ใช้เป็นบริบทการพัฒนาจาก Generative UI ไปสู่ AI Builder ที่สามารถช่วยสร้างและ Deploy Application ได้มากขึ้น พร้อมข้อควรระวังเรื่อง Security, Shadow IT และ Governance เมื่อ AI-generated Software ถูกนำเข้าสู่ Enterprise Production
* กรอบ “Production of Design → Design Judgment”, Strategic Design, Product Builder, Human Middleware, Creation → Selection และหลัก “อย่าตกหลุมรักหน้าจอ จงตกหลุมรักปัญหา” — เป็นการสังเคราะห์ของผู้เขียนเพื่อวิเคราะห์การเปลี่ยนแปลงของ Product Development Operating Model ในยุค AI ไม่ได้นำเสนอในฐานะ Framework จากแหล่งวิจัยภายนอก
- 1
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
