วิธีแปลงดีไซน์ Figma เป็น HTML และ CSS ที่สะอาด (คู่มือทีละขั้นตอน)

การส่งไฟล์ Figma ให้นักพัฒนามักหมายความว่าต้องมีใครสักคนนั่งสร้างทุกเฟรมใหม่ด้วยมือใน HTML และ CSS ทั้งวัดระยะห่าง เดาว่าจุด breakpoint ควรอยู่ตรงไหน แล้วก็หวังว่าหน้าเว็บสุดท้ายจะยังตรงกับดีไซน์หลังผ่านการตัดสินใจเล็กๆ นับสิบครั้ง คู่มือนี้จะพาไปดูวิธีที่เร็วกว่านั้น นั่นคือการไปจากดีไซน์ Figma ที่เสร็จสมบูรณ์สู่มาร์กอัปที่สะอาดและมีความหมายเชิงความหมาย (semantic) โดยตรง

ทำไมการส่งงานจาก Figma ไป HTML ด้วยมือถึงช้า

เวลาส่วนใหญ่ที่ใช้ในการส่งงานไม่ใช่งานสร้างสรรค์ แต่เป็นงาน "แปล":

• อ่านค่า Auto Layout แล้วนำมาสร้างใหม่เป็นกฎ Flexbox ด้วยมือ
• วัด padding, gap และขนาดฟอนต์ซ้ำ ทั้งที่ค่าพวกนี้ถูกกำหนดไว้แล้วในไฟล์ Figma
• ตัดสินใจว่าจุด breakpoint สำหรับ responsive ควรอยู่ตรงไหน เพราะเฟรมของ Figma มักมีความกว้างคงที่เพียงค่าเดียว
• จัดระเบียบมาร์กอัปไม่ให้กลายเป็นแท็ก <div> ซ้อนกันสิบชั้นโดยไม่มีความหมายเชิงความหมายใดๆ

งานเหล่านี้ไม่ได้ยาก แต่เป็นงานซ้ำๆ และงานมือที่ซ้ำๆ นี่แหละคือจุดที่ความผิดพลาดและความไม่สอดคล้องกันมักแอบแฝงเข้ามา

ขั้นตอนที่ 1: ส่งออกเฟรมจาก Figma

แทนที่จะส่งออกเป็นภาพนิ่งหรือคัดลอกสไตล์ทีละเลเยอร์ ให้เลือกเฟรมที่ต้องการแปลง แล้วใช้ปลั๊กอิน Figma ของ MarkupGen เพื่อส่งเฟรมนั้นเข้าไปยังพื้นที่ทำงาน (workspace) ของคุณ ปลั๊กอินจะจับโครงสร้าง สไตล์ และรูปภาพของเฟรมไปพร้อมกันทั้งหมด จึงไม่ต้องมาสร้างอะไรใหม่ตั้งแต่ต้น

ขั้นตอนที่ 2: ปล่อยให้โครงสร้างแปลงเป็นโค้ดเอง

นี่คือจุดที่งานมือส่วนใหญ่หายไป ตัวอย่างสิ่งที่ถูกแปลงให้อัตโนมัติ ได้แก่:

• Auto Layout → Flexbox คุณสมบัติ Auto Layout ของ Figma (ทิศทาง, gap, padding, การจัดตำแหน่ง) จะถูกแปลงตรงไปเป็นโครงสร้าง CSS Flexbox ที่เทียบเท่ากัน แทนที่จะต้องกะด้วยสายตา
• Constraints → จุด breakpoint สำหรับ responsive ข้อจำกัดในการปรับขนาดของเลย์เอาต์จะถูกแปลงเป็นกฎ responsive ที่ยืดหยุ่น แทนที่จะเป็นหน้าเว็บความกว้างคงที่เพียงค่าเดียว
• เลเยอร์ → HTML เชิงความหมาย ผลลัพธ์ที่ได้จะเน้นองค์ประกอบที่มีความหมาย แทนที่จะเป็น <div> ซ้อนลึกๆ ที่ไม่มีป้ายกำกับใดๆ ซึ่งใกล้เคียงกับสิ่งที่คุณจะเขียนด้วยมือเองสำหรับโปรเจกต์จริง

ขั้นตอนที่ 3: เลือกรูปแบบผลลัพธ์ที่ต้องการ

ไม่ใช่ทุกโปรเจกต์ที่ต้องการโค้ดแบบเดียวกัน ขึ้นอยู่กับสแตกที่คุณกำลังใช้งาน คุณสามารถส่งออกเป็น:

• HTML/CSS แบบพื้นฐาน (Vanilla) — สำหรับเว็บไซต์แบบสถิตหรือโปรเจกต์ที่ไม่มีขั้นตอน build
• Tailwind CSS — คลาส utility ที่สร้างขึ้นจากค่า spacing, สี และ typography token จริงของดีไซน์
• React — คอมโพเนนต์ที่สามารถนำไปวางในแอปที่มีอยู่แล้วได้ทันที

ขั้นตอนที่ 4: ปรับแต่งก่อนส่งออก

การแปลงอัตโนมัติช่วยให้งานเสร็จไปเกือบหมดแล้ว แต่การแปลงจากดีไซน์เป็นโค้ดแทบไม่มีทางเป็นกลไกล้วนๆ 100% เนื้อหาอาจต้องปรับแก้เล็กน้อย หรือบางส่วนอาจต้องปรับเลย์เอาต์ด้วยมือ ตัวแก้ไข (editor) ช่วยให้คุณปรับแต่งเนื้อหา ฟอนต์ และเลย์เอาต์แบบเห็นภาพจริงก่อนสร้างแพ็กเกจสุดท้าย และในแต่ละครั้งที่ส่งออก ระบบจะให้คะแนนอัตโนมัติ เพื่อให้คุณเห็นได้ทันทีว่าผลลัพธ์พร้อมใช้งานจริงหรือยัง

คำว่า "สะอาด" ในที่นี้หมายถึงอะไรกันแน่

"โค้ดที่สะอาด" ไม่ใช่แค่คำโฆษณา แต่เป็นคุณสมบัติที่เจาะจงและตรวจสอบได้:

1. ไม่มี <div> ที่ห่อหุ้มโดยไม่จำเป็นรอบองค์ประกอบเดียว
2. มีลำดับชั้นหัวข้อ (heading hierarchy) ที่ถูกต้อง (h1 → h2 → h3) แทนที่จะทำให้ทุกอย่างดูเหมือนหัวข้อไปหมด
3. ใช้แท็กเชิงความหมายในจุดที่เหมาะสม ซึ่งบังเอิญเป็นสิ่งเดียวกับที่เสิร์ชเอนจินและโปรแกรมอ่านหน้าจอ (screen reader) ต้องการเพื่อทำความเข้าใจหน้าเว็บ

ประเด็นสุดท้ายนี้สำคัญกว่าที่คิด เพราะมาร์กอัปที่เบราว์เซอร์และ crawler แกะได้ง่าย ก็เป็นมาร์กอัปที่นักพัฒนาคนต่อไปอ่านได้ง่ายเช่นกัน

จุดที่กระบวนการนี้เข้ามาเสริมในเวิร์กโฟลว์จริง

กระบวนการนี้ไม่ได้มีไว้เพื่อแทนที่วิจารณญาณของนักพัฒนา แต่เป็นการตัดขั้นตอนการแปลที่เป็นกลไกออกไป เพื่อให้วิจารณญาณนั้นถูกนำไปใช้กับส่วนที่ต้องการจริงๆ ได้แก่ รายละเอียดของการโต้ตอบ (interaction), กรณีขอบ (edge case) และการรวมหน้าเว็บเข้ากับโค้ดเบสที่ใหญ่ขึ้น หากคุณอยากเห็นกระบวนการทั้งสี่ขั้นตอนแบบเต็ม — ส่งออก, สร้าง, ปรับแต่ง, ส่งออก — ในตัวผลิตภัณฑ์จริง คุณสามารถทดลองใช้ฟรีกับไฟล์ Figma ของคุณเอง