Handoff & ขั้นตอนต่อไป

คุณได้เรียนรู้วิธีที่ดีไซน์กลายเป็นโค้ดแล้ว ตอนนี้มาพูดถึงช่วงเวลาที่เชื่องาน ของคุณกับงานของนักพัฒนา: handoff handoff ที่ดีไม่ได้แค่แชร์ไฟล์ — แต่สื่อสารสเปคที่สมบูรณ์ที่นักพัฒนาสามารถ implement ได้โดยไม่ต้องถามคำถามเพิ่มเติม

อะไรทำให้ดีไซน์ “พร้อมสำหรับนักพัฒนา”

ก่อน handoff ดีไซน์ ตรวจสอบแต่ละข้อเหล่านี้:

Layers และ components ที่มีชื่อ ทุก layer ควรมีชื่อที่มีความหมาย — ไม่ใช่ Frame 47 หรือ Rectangle 12 ชื่อ layer กลายเป็นคำศัพท์ที่นักพัฒนาใช้เมื่อเขียนโค้ด Card, Navigation, Hero/CTA Button บอกนักพัฒนาว่ากำลัง build อะไรอยู่

Styles ที่ใช้ token สี ระยะห่าง และ type ควรมาจาก design token library (Figma Variables หรือ Styles) ไม่ใช่ local overrides แบบครั้งเดียว ดีไซน์ที่ใช้ token แปลเป็น CSS custom properties โดยตรง — ลดข้อผิดพลาดในการ implement

Component variants ที่ documented ครบ ถ้าปุ่มมี Default, Hover, Focused, Disabled และ Loading states ทั้งห้าต้องอยู่ในไฟล์ดีไซน์ นักพัฒนาจะ implement ทุก state — และถ้าคุณไม่ได้กำหนด นักพัฒนาจะสร้างเอง มักไม่สอดคล้องกัน

Auto-layout constraints ใช้ auto-layout สำหรับทุก component ที่จะขยายหรือหดตามเนื้อหา ตั้ง constraints (fixed/fill/hug) อย่างชัดเจน สิ่งนี้สื่อสารว่า component ควรตอบสนองอย่างไร ไม่ใช่แค่หน้าตาที่ขนาดหนึ่ง

Spacing จาก grid ค่า spacing ทั้งหมดควรอยู่ใน scale (ทวีคูณของ 4 หรือ 8) ค่านอก scale สื่อถึงความคลุมเครือและบังคับให้นักพัฒนาตัดสินใจว่าจะปัดขึ้นหรือลง

Figma Dev Mode ในฐานะสะพาน handoff

เมื่อคุณ toggle frame เป็น “Ready for development” ใน Figma นักพัฒนาจะสลับไป Dev Mode เพื่อตรวจสอบ:

ค่าพิกเซลที่แน่นอนสำหรับ padding, gap และ margins
Font properties: family, size, weight, line-height, letter-spacing
ค่าสีและชื่อ token ของตัวเอง
Border-radius, shadow และ opacity
Asset exports (icons, รูปภาพในรูปแบบและสเกลที่ถูกต้อง)

ทดลองใช้ Dev Mode เองก่อน handoff — ถ้ามีสิ่งผิดปกติหรือขาดหายไป นักพัฒนาจะเห็นปัญหาเดียวกัน

สิ่งที่ต้องสื่อสารด้วยคำพูด (หรือใน comments)

Dev Mode จัดการ static spec ส่วนเหล่านี้ต้องการการอธิบายจากมนุษย์:

Interaction states: hover animation ทำงานอย่างไร? อะไร trigger tooltip?
Edge cases: การ์ดมีหน้าตาอย่างไรเมื่อมีหัวข้อ 200 ตัวอักษร? เมื่อไม่มีรูปภาพ?
Error states: ฟอร์มมีหน้าตาอย่างไรเมื่อ validation ล้มเหลว?
Responsive behavior: อะไรเปลี่ยนระหว่าง 375px mobile และ 1440px desktop? อะไร reflow อะไรซ่อน?
Motion: duration, easing, trigger — animation specs ควรอยู่ในไฟล์ดีไซน์เป็น comments หรือ motion page แยก

เพิ่มสิ่งเหล่านี้เป็น Figma comments บน frames ที่เกี่ยวข้อง หรือเก็บเอกสาร spec สั้นๆ ควบคู่กับไฟล์

แหล่งเรียนรู้ต่อไป

คุณได้สร้างรากฐานที่แข็งแกร่ง นี่คือที่ที่จะไปต่อ:

แหล่งเรียนรู้	สิ่งที่จะพบ
MDN Web Docs (developer.mozilla.org)	Reference ที่เชื่อถือได้สำหรับทุก HTML element และ CSS property บันทึกไว้
web.dev (web.dev/learn)	หลักสูตรฟรีเกี่ยวกับ HTML, CSS, accessibility และ performance จากทีม Chrome
Figma Learn (help.figma.com/learn)	Tutorials ของ Figma เอง — เข้มแข็งเรื่อง variables, dev mode และ component best practices
CSS-Tricks (css-tricks.com)	บทความเชิงปฏิบัติลึกเกี่ยวกับ CSS layout, animations และ design system patterns
Kevin Powell บน YouTube	การสอน CSS ภาษาง่ายที่ดีที่สุดบนอินเทอร์เน็ต เริ่มด้วย series flexbox และ CSS variables ของเขา

ข้อผิดพลาดที่นักออกแบบเจอบ่อย

ส่งงานให้ developer โดยไม่ระบุ edge case (ข้อความยาวเกิน, ไม่มีรูป, list ว่าง)
ไม่ทำ redline/spec สำหรับ spacing ที่ developer ต้อง “เดา” เอาเอง

มุมมองของ developer

👨‍💻 สิ่งที่ developer เห็นจริง ๆ

Designer เห็น “งานจบแล้ว ส่งได้” แต่ developer เห็นว่ายังมีคำถามอีกมาก (states ไหนที่ยังไม่ได้ design, breakpoint ไหนที่ยังไม่เห็นภาพ, content ที่ยาวผิดปกติจะเป็นยังไง)

💡 ตัวอย่างจากของจริง

ทีม design ที่ Intercom ทำ “spec mode” ใน Figma แนบ note ระบุ edge case และ state ทุกอันไว้ในไฟล์ handoff โดยตรง ลดรอบถามตอบกับ developer ลงมาก