ดีไซเนอร์จำนวนมากมอง Claude Code ผ่านๆ เพราะคิดว่ามันคือเครื่องมือ "ให้ AI ออกแบบงานในจอ" ซึ่งทั้งช้าและกินเงินถ้าต้องใช้ทุกวันใน Figma พอเห็นว่าทั้งแพงและนาน หลายคนเลยเลือกเมินมันไปเลย ช่อง UI Collective เปิดคลิป "Claude Code for Designers: All the Ways to Use It" ด้วยประโยคที่ชนเป้าตรงๆ ว่า "Designers are sleeping on Claude Code because you can use it for more than just AI design" แล้วชี้ว่าการเมินทั้งหมดคือการพลาดจุดที่คุ้มที่สุด
ประเด็นของคลิปไม่ได้เชียร์ให้เอา AI ไปแทนการออกแบบ แต่ชี้ไปที่งานอีกกลุ่มหนึ่งที่ ทำซ้ำได้ · เจาะจง · ไม่ใช่งานออกแบบ (non-designing) UI Collective ระบุว่างานแบบนี้ "คุ้มทั้งเวลาและ token เสมอ" เพราะเป็นการเอา Claude Code ไปจัดการงานน่าเบื่อซ้ำๆ ที่กินเวลา ไม่ใช่งานที่ต้องใช้ความเข้าใจแบรนด์ บทความนี้สรุป 6 วิธีที่คลิปไล่ให้ดูจริง พร้อมข้อควรระวังของแต่ละวิธี และปิดท้ายด้วยแก่นที่สำคัญกว่าตัวเครื่องมือ นั่นคือเส้นแบ่งระหว่าง "AI ทำได้" กับ "ควรให้ AI ทำ"
หมายเหตุ: บทความนี้สรุปจากคลิปเดียวของช่อง UI Collective ตัวเลขและคำเคลมทั้งหมด (เช่น "5 ชั่วโมงเหลือ 10 นาที") เป็นคำพูดของผู้พูดในคลิป ไม่ใช่ผลทดสอบกลางของเพจ คำศัพท์เทคนิคของงาน design system (Figma, MCP, Skill, Routine, WCAG, variables, tokens) จึงคงไว้เป็นภาษาอังกฤษตามต้นทาง
รู้จักศัพท์ 3 ตัวก่อน: Skill · Routine · Figma MCP
ก่อนเข้า 6 วิธี มีศัพท์ 3 ตัวที่วนซ้ำตลอดทั้งคลิป และเป็นกุญแจที่ทำให้ทุกอย่างเชื่อมกันได้ ผู้อ่านที่ไม่ได้อยู่สาย design system ล้วนๆ ควรเข้าใจคร่าวๆ ก่อน
- Skill คือชุดความสามารถที่สอนให้ Claude ทำงานเฉพาะอย่างได้ตามมาตรฐานที่กำหนด ในคลิปใช้ Skill เพื่อ "ร่างเอกสารชุดแรก" ให้ออกมาในรูปแบบเดียวกันทุกครั้ง
- Routine คืองานที่ตั้งไว้ให้ Claude ทำซ้ำตามคำสั่งเดิม ในคลิปใช้ Routine เพื่อ "อัปเดตเอกสารเมื่อดีไซน์เปลี่ยน"
- Figma MCP คือสะพานที่ต่อ Claude เข้ากับ canvas ใน Figma ทำให้ Claude อ่านและค้นหา component กับ variables ในไฟล์ได้โดยตรง
UI Collective ยังย้ำกรอบสำคัญตั้งแต่ต้นว่า workflow ทั้งหมดนี้ใช้ได้ ไม่ว่าจะทำงานกับ design system หรือไม่ ถ้าทำงานกับ component ก็ใช้กับ component ถ้าทำงานกับหน้า dashboard ก็ใช้กับหน้านั้น แค่ปรับสิ่งที่ใส่เข้าไปให้เหมาะกับงานตรงหน้า
วิธีที่ 1: เอกสาร spec และ handoff ที่ "อัปเดตตัวเองตามดีไซน์"
ทุกดีไซน์หรือทุก component ควรมีเอกสาร 2 ชุด ชุดแรกคือ component/design spec สำหรับดีไซเนอร์ ใช้อธิบายว่า component นี้ควรใช้ยังไง อีกชุดคือ handoff notes สำหรับ developer ปัญหาคลาสสิกที่ UI Collective ตั้งข้อสังเกตคือ เอกสารพวกนี้มักถูกเขียนครั้งเดียวตอน build เสร็จ แล้วไม่มีใครแตะอีก พอผ่านไปสัก 6 เดือน component เปลี่ยนไปแล้ว แต่เอกสารยังเป็นของเก่า กลายเป็น technical debt และสาเหตุก็มีแค่ข้อเดียว คือ "เราอยากออกแบบ ไม่อยากนั่งเขียนเอกสาร"
workflow ที่คลิปโชว์คือใช้ Skill สร้างร่างเอกสารชุดแรก แล้วใช้ Routine คอยอัปเดตเมื่อ component เปลี่ยน งานนี้เลือกใช้ Claude Opus 4.7 เพราะเป็นงานที่ทำนานๆ ครั้ง จึงอยากให้ถูกตั้งแต่ครั้งแรก และเป็นโมเดลที่เก่งเรื่องคิดงานใหญ่ เช่น มองออกว่าอะไรเปลี่ยนแล้ววางแผนอัปเดตได้ ขั้นตอนสร้าง Skill คือสั่งให้ Claude ลิสต์หัวข้อที่ spec ต้องมี ได้แก่ มันคืออะไร เมื่อไหร่ควรใช้ เมื่อไหร่ไม่ควรใช้ variants states anatomy properties usage rules accessibility notes และ atom component ที่เกี่ยวข้อง
จุดที่ UI Collective ชอบเป็นพิเศษคือ Opus 4.7 ไม่ได้คืนมาแค่ไฟล์ skill.md แต่แถม fill-in template กับตัวอย่างที่ทำเสร็จแล้ว 2 ชุด (ปุ่มกับช่องกรอกข้อความ) มาให้ด้วย ผู้พูดมองว่านี่คือการ "ล็อก quality bar" ให้ผลลัพธ์ครั้งต่อไปคงเส้นคงวา แทนที่จะต้องนั่งโต้ตอบกับ AI ไปมาไม่จบ
รายละเอียดสำคัญที่คลิปย้ำคือ ตั้ง Routine เป็น manual ไม่ใช่ตั้งเวลาให้รันเอง เหตุผลคือ "design is an iterative process" งานออกแบบต้องปรับไปปรับมาตลอด ถ้าตั้งให้รันอัตโนมัติ ทุกครั้งที่ขยับของเล็กน้อยมันจะ generate เอกสารใหม่ทั้งชุด กลายเป็นเสียเวลาเปล่า คำสั่งใน Routine คือใช้ Figma MCP หาและอ่าน component ในไฟล์ที่ระบุลิงก์ไว้ จากนั้นหาเฟรมเอกสารของ component นั้น ระบุว่าอะไรเปลี่ยนไปบ้าง (variant ใหม่ property อัปเดต state ใหม่ หรือ token ที่เปลี่ยนชื่อ) แล้วร่าง entry ใหม่ในรูปแบบเดิม
ข้อควรระวังที่ผู้พูดเน้นหนักที่สุดในวิธีนี้ คือคำสั่งใน Routine ต้องเขียนชัดว่า "Do not edit anything in Figma. Put the draft for my review only" Routine มีหน้าที่แค่ร่างมาให้รีวิว ไม่ใช่ลงมือแก้ Figma เอง ต้องให้คนอนุมัติก่อน แล้วค่อยอัปเดตของจริง นอกจากนี้คลิปยังทำ Skill กับ Routine แยกเป็น 2 ชุด คือชุดสำหรับดีไซเนอร์กับชุดสำหรับ dev handoff เพราะผู้อ่านและข้อมูลคนละแบบ โดยเน้นว่าต้องตั้งชื่อให้ต่างกันชัดเจน ไม่งั้น Routine อาจหยิบ Skill ผิดตัวมาใช้ ส่วนชุด dev handoff จะลงลึกเรื่อง parts, sizing, tokens, states, behavior, accessibility, responsive rules และ edge cases และเหมาะเอาไปทดสอบกับ component ที่ซับซ้อน เช่น menu ที่มี list item ซ้อน checkbox หรือ radio มากกว่าปุ่มเดี่ยวๆ
ข้อควรรู้: ทุกงานที่เกี่ยวกับฝั่ง dev UI Collective ย้ำว่าให้ "have a convo with your developers" สิ่งที่โชว์ในคลิปเป็นแค่ template ตั้งต้น ไม่ใช่สูตรที่ใช้ได้กับทุกทีม และ Figma มักไม่ใช่แหล่งข้อมูลหลักแหล่งเดียว (หลายทีมใช้ Supernova หรือ Zeroheight) จึงควรใช้ Figma เป็นจุดเริ่มต้น แล้วเอาเนื้อหาไปอัปเดตที่อื่นต่อ
วิธีที่ 2: Design audit เพื่อความสม่ำเสมอ
วิธีที่สองคือให้ Claude Code ตรวจว่าดีไซน์ สม่ำเสมอ (consistent) หรือไม่ จุดนี้ต้องเน้นว่าเป็นการตรวจความสม่ำเสมอ ไม่ใช่ตรวจว่า UX/UI ดีหรือไม่ดี นี่คือจุดที่ UI Collective บอกว่าเจอคุณค่าเยอะที่สุด ถึงขั้นใช้คำว่า "winner winner chicken dinner"
workflow คือใช้ audit-design-system skill ซึ่งเป็น Figma skill ที่ติดตั้งไว้ตั้งแต่ต้นคลิป มันจับได้ว่า variable ไหนยังไม่ได้ apply, component ไหนไม่ได้ใช้ และเฟรมดิบไหนใช้ค่า hex แบบ hardcode แทน instance ที่ถูกต้อง วิธีใช้ง่ายมาก แค่วางลิงก์หน้า Figma แล้วสั่งให้ Claude Code audit หน้านั้น Claude จะเรียก skill ขึ้นมาเองอัตโนมัติ ผลลัพธ์ที่ได้คือ verdict พร้อมระดับความมั่นใจ (ในตัวอย่างคือราว 85%) ตามด้วย findings ที่เรียงตามลำดับความสำคัญ และข้อเสนอแนะ ผู้พูดมองว่าผลลัพธ์ระดับนี้คือ "the kind of output that a senior or design lead would give you" และเคลมว่ามันย่นงานที่ปกติใช้เวลาราว 5 ชั่วโมงให้เหลือ "10 นาที ถ้าจะให้พูด"
จุดที่ทำให้วิธีนี้น่าเชื่อถือ ไม่ได้อยู่ที่ "ทำได้" แต่อยู่ที่ผู้พูดยอมตอบตรงๆ ว่ามี 2 งานคล้ายๆ กันที่ AI ทำได้แต่ไม่คุ้มจะให้ทำ งานแรกคือ progress audit หรือให้ AI สรุปความคืบหน้าของโปรเจกต์ คลิปบอกว่าทำได้ แต่ "just write it out on its own" เขียนเองสัก 10 นาทีคุ้มกว่า เพราะ AI ไม่เห็นงานที่อยู่ในไฟล์อื่น งานที่สองคือ accidental-change detection หรือตรวจว่ามีใครแก้ดีไซน์โดยไม่ตั้งใจหรือไม่ คลิปบอกว่าทำได้เหมือนกัน แต่ "just lock your Figma layers, guys" ดีไซเนอร์ที่ทำงานเป็นทีมควรล็อก layer ของงานที่ mark for dev ไว้อยู่แล้ว เพราะเป็นเรื่องพื้นฐานที่ไม่ต้องพึ่ง AI
ส่วนการเอา AI มาตรวจ UX/UI feedback ผู้พูดมองว่าเป็นวิธีที่ไม่ดีเลย เพราะ AI ไม่มี context ของโปรเจกต์ และจะวนเป็นวงจรไม่จบ คือขอ feedback แล้วแก้ตาม พอพบว่าผิดก็กลับไปขอ feedback ใหม่ งานแบบนี้ควรให้เพื่อนร่วมทีมหรือ community ดีไซน์ที่เข้าใจงาน (เช่น UI Collective เอง) ช่วยดูจะดีกว่า
วิธีที่ 3: Accessibility check เรื่อง WCAG color contrast
วิธีที่สามคือตรวจ accessibility โดยโฟกัสที่ WCAG color contrast เป็นหลัก UI Collective ระบุว่า Anthropic มี design plugin ที่มี accessibility-review skill มาให้ในตัว วิธีใช้คือวางลิงก์เฟรม แล้วสั่ง "check for accessibility" จากนั้นจะได้ report ผลตรวจ color contrast กลับมา ผู้พูดถึงกับเคลมว่า "we no longer need to use Figma's WCAG 2.1 color contrast tool" เพราะ AI ทำงานนี้แทนได้
แต่ประเด็นที่สำคัญกว่า workflow คือสิ่งที่ผู้พูดเลือก ไม่ ใช้ ใน design plugin ของ Anthropic มี skill หลายตัว ทั้ง dev-handoff, usability และ research-synthesis แต่ UI Collective บอกตรงๆ ว่าเชื่อใจแค่ accessibility-review skill ตัวเดียว เพราะ color contrast เป็นมาตรฐานกลางที่ตรวจได้แน่นอน ส่วน skill อื่นต้องการ context เรื่องแบรนด์ที่ AI ไม่มี เช่น การ generate dev handoff ที่แต่ละบริษัทอยากคุมเองว่าอะไรควรอยู่ในนั้น
ข้อควรรู้: ผลตรวจ accessibility มี false positive ได้ เช่น เตือนว่า contrast ไม่ผ่านบนพื้นเข้ม ทั้งที่ในงานจริงจะไม่มีวันวางบนพื้นเข้ม หรือเตือนว่าไม่มี pressed/loading state ทั้งที่ตั้งใจไม่ทำ UI Collective จึงเตือนว่า การที่มันขึ้น flag ไม่ได้แปลว่าผิดเสมอไป ถึงอย่างนั้นคุณภาพโดยรวมของ report ก็ยังอยู่ในระดับ senior designer หรือ accessibility expert
วิธีที่ 4: สร้าง type scale และ type styles
วิธีที่สี่คือสร้าง type scale, type styles และผูก variables เข้ากับ styles UI Collective บอกว่านี่เป็นงานน่าเบื่อที่สุดงานหนึ่งของการเริ่มโปรเจกต์ใหม่ เพราะต้องทำซ้ำทั้งเวอร์ชัน desktop, mobile และ tablet workflow ที่คลิปโชว์เริ่มจากนิยาม type scale ที่ต้องการก่อน (hero, H1 ถึง H6, paragraph ขนาดต่างๆ พร้อมระบุ font แต่ละตัว) แล้วให้ Claude สร้างขึ้นมาดูใน local เพื่อเช็ก look and feel จากนั้นค่อย push เข้า Figma โดยสั่งให้ build variables ก่อน แล้วจึง build type styles พร้อมกำกับว่า "ensure variables linked inside styles" และต้องนิยาม collections ให้ชัด (brand, alias, map, responsive) ไม่งั้นจะพลาด
ผู้พูดเคลมว่างานสร้าง variables ที่ปกติเป็น "งานน่าเบื่อที่สุดงานหนึ่งของการ build design system" นี้ ใช้เวลาแค่ "9 หรือ 10 นาทีอย่างมาก" และย้ำว่าเหมาะมากตอนเริ่มงานกับ client ใหม่ที่ยังไม่มีแบรนด์เดิม
ทิป: เคล็ดลับทองจากคลิปคือสั่งให้ "keep all font attributes to a multiple of 4" หรือคุมค่าของ font ทุกตัวให้เป็นพหุคูณของ 4 เสมอ เพื่อกันไม่ให้ Claude แทรกค่าที่เป็นพหุคูณของ 3 ซึ่งไม่เข้ากับระบบที่วางไว้ วิธีนี้เหมาะเฉพาะตอนเริ่มโปรเจกต์ใหม่หรือ client ใหม่ที่ยังไม่มีแบรนด์เท่านั้น
วิธีที่ 5: สร้าง variable library ทั้งชุด — "Claude ทำได้ แต่ควรไหม?"
วิธีที่ห้าคือให้ Claude สร้าง variable library เต็มชุด ตั้งแต่ brand (ค่า hex ดิบ) ไปจนถึง alias (จัดเป็น primary, secondary, error, success) และ map (จัดเป็นกลุ่ม surface, text, icon, border) workflow ตรงไปตรงมา สั่งว่า "build the rest of the variable library" พร้อมระบุการจัดกลุ่ม แล้ว Claude ก็คืน library มาครบทุกหมวด
แต่นี่คือจุดที่เป็นหัวใจของการ myth-busting ทั้งคลิป เพราะหลังจากโชว์ว่า "ทำได้" UI Collective ก็ตั้งคำถามกลับทันทีว่า "can Claude code build variable libraries? Yes, it can. But why would you want it to?" และคำตอบของผู้พูดคือ ไม่ควร
เหตุผลคือ Claude ไม่รู้จักแบรนด์ของแต่ละคน ไม่รู้ naming convention ที่ทีมใช้ และไม่รู้ว่าเมื่อไหร่ควรใช้ surface-subtle กับเมื่อไหร่ควรใช้ surface-muted เมื่อไหร่ใช้ success กับเมื่อไหร่ใช้ success-subtle ประเด็นที่คมที่สุดคือ แม้แต่คนที่เพิ่งเริ่มจากศูนย์ ก็ "you don't know what you don't know" ยังไม่รู้ด้วยซ้ำว่าตัวเองขาดอะไร แล้ว AI จะไปรู้ได้ยังไง ผลคือจะต้องเสียเวลานั่ง reverse-engineer library ที่ AI สร้างมา มากกว่าสร้างเองตั้งแต่แรก ทั้งที่ถ้าสร้างเอง จะกลายเป็นคนที่เข้าใจ variable library ของตัวเองอย่างถ่องแท้ และมันจะวนเป็นวงจรไม่จบเหมือนเคส UX feedback คือใช้แล้วพบว่าผิด ขอแก้ แล้วก็ผิดอีก
วิธีที่ 6: สร้างไฟล์ token (JSON) ให้ developer
วิธีสุดท้ายคือ generate ไฟล์ token แบบ JSON จาก variable library ใน Figma เพื่อส่งต่อให้ developer workflow เริ่มจากวางลิงก์ variable library แล้วสั่งประมาณว่า "study all the Figma variables แล้ว generate ไฟล์ JSON ที่แชร์ให้ dev ได้" จากนั้น Claude ก็จะคืนไฟล์ JSON ก้อนใหญ่กลับมา
แต่จุดยืนของวิธีนี้ไม่ได้อยู่ที่ตัวไฟล์ JSON เพราะ UI Collective ระบุว่า point จริงคือการ "educate developers" ว่า Claude Code กับ Figma MCP ทำสิ่งนี้ได้ dev อาจรู้ว่านำเข้าดีไซน์หรือ component ได้ แต่อาจไม่รู้ว่า Claude อ่าน variable library ดิบทั้งชุดได้ ผู้พูดถึงกับยอมรับเองว่า prompt ที่โชว์เป็น "horrible/basic prompt" ที่เขียนแบบขอไปที เพื่อโชว์แค่ว่าทำได้เท่านั้น เพราะทุกบริษัทอยากจัดโครงสร้าง variables ไม่เหมือนกัน บทสรุปของวิธีนี้จึงวนกลับไปที่คำเดิมคือ "have the convo with your developers around how they want it structured" มันเป็นเรื่องของการคุยและการให้ความรู้ มากกว่าตัว output ที่ได้
แก่นจริงของคลิป: "AI ทำได้" ไม่ได้แปลว่า "ควรให้ AI ทำ"
ถ้าจะมีบทเรียนเดียวที่ติดตัวกลับไปจากคลิปนี้ บทเรียนนั้นไม่ใช่ workflow ทั้ง 6 แต่เป็นกรอบความคิดที่วนซ้ำตลอด นั่นคือ "AI ทำได้ ไม่ได้แปลว่าควรให้ AI ทำ" UI Collective ใช้กรอบนี้ชัดที่สุดตอนตอบเรื่อง variable library ด้วยประโยค "can Claude code build variable libraries? Yes, it can. But why would you want it to?" และซ้ำอีกครั้งตอนตอบเรื่อง progress audit กับ accidental-change check ทุกครั้งที่คำตอบคือ "ทำได้" ผู้พูดจะตามด้วยเหตุผลว่าทำไมถึง "ไม่คุ้ม" หรือ "ไม่ควร"
เส้นแบ่งที่ชัดจากทั้งคลิปคือ งานที่ คุ้มจะให้ AI ทำ มักเป็นงานน่าเบื่อ ทำซ้ำ มีมาตรฐานกลางชัด และตัดสินถูกผิดได้ด้วยกฎ เช่น ร่างเอกสาร spec, audit ความสม่ำเสมอ, ตรวจ color contrast, สร้าง type scale ตอนเริ่มโปรเจกต์ ส่วนงานที่ ไม่ควรโยนให้ AI คืองานที่ต้องใช้ความเข้าใจแบรนด์และ context ของโปรเจกต์ เช่น variable library ทั้งชุด, UX/UI feedback และการตัดสินใจเชิงดีไซน์ที่ขึ้นกับบริบทเฉพาะของทีม
อีกบทเรียนที่ผู้พูดเน้นหนักไม่แพ้กันคือ ให้ รู้ WHY เบื้องหลัง skill อย่า outsource ความเข้าใจของตัวเอง คลิประบุว่า "you need to know the why behind the skills, not just installing a skill and hoping it does everything ... that's what's going to separate the good designers from the great designers" การติดตั้ง skill แล้วหวังให้มันทำทุกอย่างให้ คือทางที่ทำให้ดีไซเนอร์หยุดเข้าใจงานของตัวเอง เพราะถ้าวันหนึ่ง AI ทำพลาด คนที่ไม่รู้ขั้นตอนเบื้องหลังจะแก้ไม่เป็น นี่เป็นเหตุผลเดียวกับที่ผู้พูดเลือกเชื่อแค่ accessibility-review skill ตัวเดียว และไม่เชื่อ skill ที่ต้องการ context แบรนด์แบบ out-of-the-box
สำหรับคนไทยที่เริ่มเบื่อคอนเทนต์ AI แบบเชียร์ให้ใช้ทุกอย่าง สาระจริงของคลิปนี้จึงไม่ใช่ "Claude ทำได้กี่อย่าง" แต่เป็นวิธีคิดในการเลือกว่า "งานไหนควรโยนให้มัน งานไหนต้องลงมือเอง" ให้ AI รับงานน่าเบื่อซ้ำๆ ที่กินเวลา แล้วเก็บงานที่ต้องใช้ความเข้าใจไว้กับตัว เพราะความเข้าใจนั่นแหละคือสิ่งที่แยกดีไซเนอร์ที่ดีออกจากดีไซเนอร์ที่เก่งจริง
ที่มา: สรุปจากคลิป "Claude Code for Designers: All the Ways to Use It" ของช่อง UI Collective — ตัวเลขและคำเคลมทั้งหมดในบทความเป็นคำพูดของผู้พูดในคลิป ดูคลิปเต็มเพื่อชมขั้นตอนจริงทุกวิธี
