Claude Code กำลังเปลี่ยนกระบวนการออกแบบ

• ใช้ Claude Code เพื่อ สร้างโค้ดที่ทำงานได้ทันทีโดยไม่ต้องมีม็อกอัปขั้นกลาง ช่วยเพิ่มประสิทธิภาพในการออกแบบ
• การใช้งาน Figma ลดลงอย่างมาก และเมื่อแก้ไขฟีเจอร์ด้วย โค้ดที่ทำงานได้พร้อมข้อมูลจริง จุดที่ควรปรับปรุง UX จะปรากฏให้เห็นเร็วกว่าม็อกอัปแบบสแตติกมาก
• ฟีเจอร์ขนาดเล็กสามารถทำด้วย Claude Code ได้ทันทีโดยไม่ต้องใช้ Figma ส่วนฟีเจอร์ขนาดใหญ่จะทำงานค้นหาและนิยามปัญหาก่อน แล้วสร้าง อาร์ติแฟกต์แบบอินเทอร์แอ็กทีฟ เพื่อแชร์กับทีม
• เปลี่ยนเป็นกระบวนการที่ ทำจนถึงการส่ง PR ได้ด้วยตัวเอง โดยไม่ต้องมี handoff หรือผลลัพธ์ระหว่างทางที่สูญเปล่า
• ยังคงรักษาแนวคิดที่ยึดผู้ใช้เป็นศูนย์กลาง การสำรวจปัญหา และการปรับปรุงแบบวนซ้ำไว้ พร้อม คงหลักการสำคัญของงานออกแบบ และกำลังพัฒนาไปเป็น เวิร์กโฟลว์ใหม่ที่ลดเส้นแบ่งระหว่างการออกแบบกับการพัฒนา

---

การเปลี่ยนแปลงสำคัญ: งานออกแบบผ่าน Claude Code

• ใช้ Claude Code ทุกวัน และจำนวนคอมมิตที่เพิ่มขึ้นในกราฟ Git commit ของฉันแสดงให้เห็นถึงการหลอมรวมระหว่างงานออกแบบกับการพัฒนา
  • การใช้งาน Figma ลดลงอย่างมาก และเปลี่ยนไปสู่งานออกแบบที่อิงกับโค้ด
• หากอธิบายประสบการณ์ผู้ใช้ที่ต้องการไว้เป็น ภาษาธรรมชาติ เช่น use case, พฤติกรรมที่คาดหวัง, ทิศทางการพัฒนาฟีเจอร์ Claude Code จะเข้าใจวิธีนำไปสร้างได้
• วิธีนี้เหมือนกับการทำงานร่วมกับวิศวกรแบบเดิม แต่ดีไซเนอร์เป็นฝ่าย ถือการควบคุมโดยตรง
• ข้ามม็อกอัประดับความละเอียดปานกลาง (mid-fi) ไปทั้งหมด และใช้การ พรอมป์ต์ใน Claude Code เพื่อสร้างเวอร์ชันที่ใช้งานได้ ภายในไม่กี่นาที
• เมื่อแก้ไขบนเวอร์ชันที่ทำงานได้จริงและมีข้อมูลจริง ปัญหา UX อย่างการจัดเรียง การกรอง หรือความยาวของข้อมูลจะ สังเกตเห็นได้ทันที

กระบวนการออกแบบแบบใหม่

• ในช่วงไม่กี่เดือนที่ผ่านมา กระบวนการ เปลี่ยนไปมาก

• ฟีเจอร์ขนาดเล็กทำตรงใน Claude Code โดยไม่ใช้ Figma

  • ฟีเจอร์อย่างการปรับปรุง QoL หรือการเพิ่มช่องค้นหาในรายการ ซึ่งเป็น งานที่ใช้แพตเทิร์นและคอมโพเนนต์เดิม จะข้าม Figma ไปเลยและทำใน Claude Code ทันที
  • ไม่มีทั้ง wireframe และ handoff
  • Claude Code ใช้คอมโพเนนต์และแพตเทิร์นที่เหมาะสมได้ดี และโดยเฉพาะ Opus 4.6 สามารถเข้าใจโค้ดเบสและทำสิ่งที่ถูกต้องได้แม้ไม่มีคำสั่งที่ระบุอย่างชัดเจน

• ฟีเจอร์ขนาดใหญ่ยังคงต้องมีการสำรวจล่วงหน้าและนิยามปัญหา

  • เขียนปัญหา, use case, “รูปร่าง” ของโซลูชันที่ดี (เช่น “เร็วและลื่นไหลไร้แรงเสียดทาน”, “ไม่เพิ่มงานให้ผู้ใช้”), และแนวทางที่เป็นไปได้ ออกมาเป็นข้อความ
  • จากนั้นนำไปคุยในแชต Claude ปกติเพื่อขอไอเดียเพิ่มเติม ซึ่งจะได้ทั้ง ไอเดียที่น่าสนใจบางอย่าง และบางอย่างที่ไม่เข้ากับบริบท
  • สำหรับทิศทางที่ชอบ จะใช้ Claude เพื่อ สร้างอาร์ติแฟกต์แบบอินเทอร์แอ็กทีฟ เพื่อลองสัมผัสด้วยตัวเองและแชร์ให้ทีมเก็บฟีดแบ็ก
  • หากเร็วกว่าเขียนพรอมป์ต์ ก็อาจวาด wireframe แบบ lo-fi อย่างง่าย ใน Figma
  • หลังจากทำซ้ำ พูดคุยกับทีม และรับฟีดแบ็กจากผู้ใช้จนได้แนวทางที่ชัดเจนแล้ว ก็จะ สร้างและขัดเกลาในโค้ดโดยตรง ด้วย Claude Code

พื้นที่ที่ Figma ยังได้เปรียบ

• การสำรวจด้านภาพ (การจับคู่สี ตัวเลือก typography คอมโพเนนต์ใหม่) Figma ยังเหนือกว่า
• งานอย่างการเทียบกันแบบวางข้างกัน การซูมเข้าออก และการขยับองค์ประกอบ ทำในโค้ดได้ยาก
• แต่เนื่องจากงานส่วนใหญ่เป็นการทำบนผลิตภัณฑ์เดิมและระบบดีไซน์เดิม สัดส่วนของงานด้านนี้จึงลดลง

สิ่งที่ไม่เปลี่ยนไป

• แนวคิดที่ยึดผู้ใช้เป็นศูนย์กลาง การระบุความต้องการ การทำความเข้าใจปัญหา การสำรวจตัวเลือกที่หลากหลาย การทำซ้ำและการทดสอบ รวมถึง การขัดเกลาเพื่อเพิ่มความสมบูรณ์ของงาน ยังคงเหมือนเดิม
• เพียงแต่ ขั้นตอนกลางของกระบวนการย้ายมาอยู่ใน Claude Code เป็นหลัก และยังสามารถทำต่อไปจนถึงขั้นส่งโค้ดให้ผู้ใช้ได้เอง
• ผลลัพธ์คือ เส้นแบ่งระหว่างการออกแบบกับการพัฒนาลดลง และส่งมอบให้ผู้ใช้จริงได้เร็วขึ้น
• เป็นกระบวนการที่ ทำงานบนสื่อปลายทางจริงโดยตรง และส่ง PR ได้เลย โดยไม่มี handoff หรือผลลัพธ์ระหว่างทางที่สูญเปล่า
• แม้จะคาดเดาอนาคตไม่ได้ แต่ตอนนี้คือ ช่วงเวลาที่มีการทดลองกับเครื่องมือและวิธีทำงานใหม่อย่างคึกคัก

[tested]

ได้ยินมาว่าตอนนี้ถึงขั้นบอกว่านักพัฒนาต้องใช้ Claude Code ทำงานออกแบบด้วยแล้ว แบบนี้งานออกแบบไม่ต้องมีการรีวิว/ตรวจสอบคุณภาพเลยเหรอ?

[kuthia]

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