วิธีแปลงดีไซน์ 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> ซ้อนลึกๆ ที่ไม่มีป้ายกำกับใดๆ เช่น บล็อกของหน้าเว็บจะกลายเป็น <section>, แถบนำทางจะกลายเป็น <nav>, หัวข้อจะกลายเป็น <h1>–<h3> ตามลำดับที่ถูกต้อง, ย่อหน้าจะกลายเป็น <p>, ปุ่มจะกลายเป็น <button> หรือ <a> ขึ้นอยู่กับพฤติกรรมของมัน และรูปภาพจะกลายเป็น <img> พร้อม alt ส่วนคอนเทนเนอร์เลย์เอาต์ทั่วไปที่ไม่มีความหมายในตัวเองก็ยังคงเป็น <div> — ไม่ใช่ทุกเลเยอร์ของ Figma ที่จะมีแท็กเชิงความหมายสำเร็จรูปรออยู่ การเลือกแท็กที่เหมาะสมขึ้นอยู่กับความหมายจริงของเนื้อหา ไม่ใช่ตารางเทียบค่าตายตัว

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

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

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

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

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

การจัดการ responsive: ไม่ใช่แค่การคัดลอกค่าพิกเซลจากเดสก์ท็อป

เฟรมของ Figma มักแทนความกว้างค่าใดค่าหนึ่งโดยเฉพาะ — เช่น เฟรมเดสก์ท็อปขนาด 1440px อาจมีเฟรมมือถือแยกต่างหากวางคู่กัน นั่นไม่ได้แปลว่าคุณควร hardcode ความกว้างนั้นลงใน CSS แล้วย่อทั้งหน้าเว็บด้วย transform: scale() Figma ไม่ได้สร้าง CSS แบบ responsive ให้เองโดยอัตโนมัติ — มันให้เพียงสัญญาณ (signal) เท่านั้น ส่วนการแปลงสัญญาณเหล่านั้นให้เป็นพฤติกรรม responsive จริงยังคงเป็นหน้าที่ของนักพัฒนาหรือระบบแปลง:

• การตั้งค่า hug / fill / fixed ของ Auto Layout บอกว่าองค์ประกอบควรหดตามเนื้อหาหรือขยายเต็มคอนเทนเนอร์ — นี่คือพื้นฐานในการเลือกใช้ width: auto, width: 100% / flex: 1 หรือ max-width แบบตายตัว
• Constraints (ปักซ้าย/ขวา, ปรับตามคอนเทนเนอร์...) เพิ่มพฤติกรรมให้กับองค์ประกอบที่ Auto Layout ไม่ได้จัดการ
• Media query ยังคงจำเป็น ในทุกความกว้างที่เลย์เอาต์เปลี่ยนรูปแบบจริงๆ เช่น คอลัมน์ที่วางเรียงกันเปลี่ยนมาซ้อนกันเป็นคอลัมน์เดียว หรือเมนูนำทางที่ยุบตัวลง เพราะเฟรมของ Figma จับภาพได้แค่ viewport ขนาดคงที่บางค่าเท่านั้น ไม่ครอบคลุมทุกความกว้างระหว่างนั้น

เป้าหมายคือการจำลองพฤติกรรม responsive ที่ดีไซน์ตั้งใจไว้ให้ครบทุกขนาดหน้าจอ ไม่ใช่การคัดลอกค่าพิกเซลตายตัวจากเฟรมใดเฟรมหนึ่งที่คุณเปิดอยู่

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

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

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

ประเด็นสุดท้ายนี้สำคัญกว่าที่คิด เพราะมาร์กอัปที่เบราว์เซอร์และ crawler แกะได้ง่าย ก็เป็นมาร์กอัปที่นักพัฒนาคนต่อไปอ่านได้ง่ายเช่นกัน นี่คือรากฐานเชิงโครงสร้างส่วนใหญ่ที่การเข้าถึงได้ (accessibility) ต้องพึ่งพาด้วยเช่นกัน ดูสิ่งที่ยังต้องตรวจสอบด้วยตนเองนอกเหนือจากแท็กเชิงความหมาย — ARIA ฟอร์ม คอนทราสต์ การนำทางด้วยคีย์บอร์ด — ได้ที่ จาก Figma สู่ HTML ที่เข้าถึงได้: คู่มือปฏิบัติจริง

ตัวอย่างเล็กๆ: จาก Auto Layout สู่มาร์กอัปจริง

ลองดูการ์ดง่ายๆ อันหนึ่ง — มีไอคอน หัวข้อ และลิงก์ "Learn more" จัดวางด้วย Auto Layout (แนวตั้ง, gap 16px, padding 24px) ถ้าสร้างใหม่ด้วยมือ ก็ง่ายที่จะหยิบกอง <div> ที่ไม่มีป้ายกำกับมาใช้ แต่เมื่อแปลงจากโครงสร้างจริงของเฟรม การ์ดเดียวกันนี้จะออกมาเป็น:

<article class="feature-card">
  <img src="/icons/rocket.svg" alt="" class="feature-card__icon" />
  <h3 class="feature-card__title">Fast setup</h3>
  <a href="/docs/getting-started" class="feature-card__link">Learn more</a>
</article>

.feature-card {
  display: flex;
  flex-direction: column;
  gap: 16px;
  padding: 24px;
}

มีรายละเอียดไม่กี่อย่างที่ควรสังเกต: การ์ดนี้เป็น <article> ไม่ใช่ wrapper ทั่วไป เพราะมันเป็นเนื้อหาที่จบในตัวเอง ไอคอนได้ alt="" เพราะเป็นการตกแต่ง — ข้อความหัวข้อสื่อความหมายของการ์ดอยู่แล้ว "Learn more" เป็น <a href> จริง ไม่ใช่ <div> ที่มี click handler เพราะมันนำทางไปยังหน้าอื่น ทิศทาง vertical และ gap 16px ของ Auto Layout จะ map ตรงไปเป็น flex-direction: column และ gap: 16px — โดยไม่ต้องกะด้วยสายตาเลย นี่คือรูปแบบการ map ที่พบบ่อยที่สุด แต่ยังมีรายละเอียดอื่นที่ต้องทำให้ถูกต้องอีก (padding, การจัดตำแหน่ง, การกำหนดขนาดแบบ hug/fill, Auto Layout ที่ซ้อนกัน) ดูFigma Auto Layout สู่ CSS: แม็ปไปเป็น Flexbox อย่างไร (และเมื่อไหร่ควรใช้ Grid) เพื่อดูการแม็ปแบบละเอียดยิ่งขึ้น

ข้อผิดพลาดที่พบบ่อยเมื่อแปลง Figma เป็น HTML

มีข้อผิดพลาดบางอย่างที่มักเกิดขึ้นซ้ำๆ เมื่อแปลงดีไซน์ Figma เป็นโค้ดด้วยมือ:

• แปลงทุกเลเยอร์ให้เป็น <div>. การมองข้ามว่าเนื้อหานั้นคืออะไรจริงๆ (การนำทาง, หัวข้อ, ปุ่ม...) ทำให้มาร์กอัปยากต่อการทำความเข้าใจทั้งสำหรับโปรแกรมอ่านหน้าจอและเสิร์ชเอนจิน
• ใช้ position: absolute มากเกินไป วิธีนี้จำลองตำแหน่งพิกเซลที่แน่นอนจาก canvas ของ Figma ได้ก็จริง แต่จะพังทันทีที่เนื้อหาหรือขนาดหน้าจอเปลี่ยนไป
• มองข้าม Auto Layout แล้วกะระยะห่างด้วยสายตาเอง มีโอกาสผิดพลาดสูงกว่าและดูแลรักษายากกว่าการแปลตรงจากค่าที่กำหนดไว้แล้วในไฟล์ดีไซน์
• Hardcode ขนาดเดสก์ท็อป แล้วปล่อยให้ responsive เป็นเรื่องคิดทีหลัง แทนที่จะสร้างเลย์เอาต์ที่ยืดหยุ่นตั้งแต่แรก
• ลำดับชั้นหัวข้อที่ยุ่งเหยิง — เลือกขนาดฟอนต์ตามหน้าตาที่ต้องการ แทนที่จะใช้ลำดับ h1 → h2 → h3 ที่ถูกต้อง
• <div> ที่ห่อหุ้มโดยไม่จำเป็น รอบองค์ประกอบที่มีความหมายอยู่แล้วในตัวเอง หรือสับสนระหว่าง "หน้าตาเหมือนกัน" กับ "ความหมายเชิงความหมายเดียวกัน"

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

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

FAQ

แปลง Figma เป็น HTML ได้อย่างไร? เลือกเฟรมที่ต้องการแปลง อ่านโครงสร้างเลเยอร์และค่า Auto Layout ของมัน จากนั้นแปลงสิ่งเหล่านั้นให้เป็น HTML เชิงความหมายและ CSS ที่สอดคล้องกัน — Auto Layout จะกลายเป็น Flexbox ส่วน constraints จะกลายเป็นพฤติกรรม responsive คุณสามารถทำเองด้วยมือ หรือใช้เครื่องมืออัตโนมัติอย่าง MarkupGen เพื่อตัดขั้นตอนการแปลที่ซ้ำซากออกไป

แปลง Figma เป็น HTML และ CSS แบบ responsive ได้ไหม? ได้ แต่ไม่ใช่แบบอัตโนมัติทั้งหมด Auto Layout และ constraints ให้สัญญาณเกี่ยวกับพฤติกรรมการปรับขนาด (หด, ขยายเต็ม, ค่าคงที่) แต่การตัดสินใจเรื่อง breakpoint ที่เจาะจงและการตรวจสอบเลย์เอาต์ในทุกขนาดหน้าจอยังคงต้องอาศัยการตีความจากคนหรือระบบแปลง

Auto Layout ของ Figma แม็ปไปเป็นอะไรใน CSS? ส่วนใหญ่คือ CSS Flexbox: ทิศทางแม็ปไปเป็น flex-direction, gap แม็ปไปเป็น gap, padding แม็ปไปเป็น padding, การจัดตำแหน่งแม็ปไปเป็น justify-content/align-items ดูFigma Auto Layout สู่ CSS เพื่อดูการแม็ปแบบละเอียดยิ่งขึ้น รวมถึงกรณีที่ควรใช้ CSS Grid แทน Flexbox

ควรใช้ semantic HTML เมื่อแปลง Figma เป็น HTML หรือไม่? ควร Semantic HTML (nav, article, button, ลำดับชั้นหัวข้อที่ถูกต้อง...) ช่วยให้โปรแกรมอ่านหน้าจอและเสิร์ชเอนจินเข้าใจโครงสร้างของหน้าเว็บได้อย่างถูกต้อง ไม่ใช่แค่เรื่องความสวยงามของโค้ดเท่านั้น

การแปลง Figma เป็น HTML สามารถทำแบบอัตโนมัติได้หรือไม่? ทำได้เป็นส่วนใหญ่ — การอ่านโครงสร้างเลเยอร์ การแม็ป Auto Layout ไปเป็น Flexbox การสร้าง breakpoint จาก constraints — แต่การตรวจสอบขั้นสุดท้าย (เนื้อหา, กรณีขอบ, การรวมเข้ากับโค้ดเบส) ยังคงต้องอาศัยคนตรวจอยู่ดี

อยากข้ามไปแปลงดีไซน์ของคุณเองเลยไหม? แปลงดีไซน์ Figma ของคุณเป็น HTML/CSS ด้วย MarkupGen →