เรื่อง Devๆ ที่ UX Designer ควรรู้ #1: เข้าใจการโค้ด UI เพื่อออกแบบให้เป๊ะยิ่งขึ้น
“Designer ควรโค้ดเป็นไหม?” เป็นประเด็นถกเถียงที่ได้ยินกันอยู่เสมอในวงการ UX สำหรับผมมองว่า Designer ไม่จำเป็นต้องโค้ดเป็น แต่อย่างน้อยควรเข้าใจว่าโค้ดทำงานอย่างไร และมีวิธีคิดในการสร้าง UI ขึ้นมาอย่างไร ถ้าให้เปรียบเทียบก็อาจจะคล้ายกับการที่สถาปนิกไม่ต้องรู้เรื่องงานวิศวกรรม 100% แต่ต้องรู้จักวัสดุและกระบวนการก่อสร้าง จึงจะออกแบบได้ดี ก่อสร้างได้จริง
สำหรับบทความนี้และในครั้งต่อๆ ไป ผมจึงอยากจะมาแชร์จากมุมของ UX Designer ที่มีพื้นเพด้าน Developer มาก่อน ให้ชาว Designer ได้เข้าใจเกี่ยวกับ “วัสดุก่อสร้าง” ของเราในการทำ Digital Product กันมากขึ้นครับ หวังว่าจะช่วยให้…
- ทีมคุยกันรู้เรื่องมากขึ้น ประหยัดเวลาและพลังงานในการสื่อสาร
- ได้ Product ที่ดีขึ้นภายใต้เวลาเท่าเดิม
- Designer สามารถชั่งน้ำหนักตัวเลือกต่างๆ ได้ดีขึ้นว่าส่วนไหนคุ้ม/ไม่คุ้มทำ และมีทางเลือกอื่นที่ง่ายกว่าไหม
Designer กับ Developer ทำ UI ต่างกันอย่างไร?
ในบทความแรกนี้ เราจะมาพูดถึงการทำ UI กันก่อนว่า Designer กับ Dev มอง UI ต่างกันอย่างไร? แล้วที่เราทำ Figma กันอยู่ทุกวันนี้ แบบไหนที่ Dev เอาไปทำต่อได้ง่ายหรือยาก โดยผมจะขอใช้ HTML/CSS สำหรับการทำเว็บในการยกตัวอย่างสำหรับฝั่งโค้ด ซึ่งหลักการส่วนใหญ่ก็นำไปประยุกต์ใช้กับงานที่เป็นแอปได้เช่นกัน
ขอออกตัวไว้ก่อนว่า บทความนี้ไม่ได้สอนเขียน CSS แต่จะเล่าแนวคิดในการสร้าง UI ด้วยโค้ดมากกว่าครับ
วาดจอด้วยโค้ด ทำยังไง?
โดยทั่วไปแล้ว เวลา Designer ทำงานใน Figma หรือโปรแกรมออกแบบอื่นๆ ก็จะเริ่มจาก “กระดานเปล่าสีขาว” ที่จะเริ่มวาดสี่เหลี่ยม วงกลม ฯลฯ ตรงไหนก็ได้บนกระดาน ทำให้สามารถจัดองค์ประกอบได้แม่นยำ ชัดเจน วางของทับกันได้ง่าย ไม่มีข้อจำกัดมากเรื่องการวางชิ้นส่วนต่างๆ บนหน้าจอ
แต่สำหรับ Front-end Developer นั้น “UI เกิดมาจากโค้ด” ซึ่งโค้ดก็คือการเขียนรูปแบบหนึ่ง ตามธรรมชาติของการเขียนก็จะต้องเขียนจากบนลงล่าง-ซ้ายไปขวา ระบบโค้ดสำหรับการทำ UI ก็มักจะออกแบบมาให้ชิ้นส่วน UI ที่เขียนโค้ดไว้ถูกวางจากบนลงล่าง ซ้ายไปขวาเช่นเดียวกัน โดยที่อาจจะมีซ้อนกันเป็นชั้นๆ ลึกลงไปเรื่อยๆ ได้ด้วย ตามตัวอย่าง HTML นี้
สำหรับ Designer ที่ไม่คุ้นเคยกับโค้ด HTML คำว่า <div> ข้างบนอาจจะแปลได้ง่ายๆ ว่าเป็น “กล่อง” กล่องหนึ่งครับ ผลที่ได้จากโค้ดด้านบนนี้ก็เหมือนกับเราทำ UI แล้วมีกล่องซ้อนกล่องตามภาพนั่นเอง
ซึ่งสำหรับคนที่ใช้ Figma “กล่อง” ที่ว่าก็ทำงานเหมือนกับ “Frame” ใน Figma ที่สามารถซ้อนสิ่งอื่นๆ เข้าไปด้านในได้ ดังนั้นสำหรับ Designer บางคนที่ใช้ Rectangle วาดปุ่มหรือวาดกล่องบนจออยู่นั้น…
ถ้าเปลี่ยนไปใช้ Frame แทน Rectangle ก็จะช่วยให้การจัดการโครงสร้างของ Design ทำได้ตรงกับการทำงานของ Developer มากขึ้น
แล้ว “กล่อง” แต่ละกล่องทำอะไรได้บ้าง?
เมื่อวางแต่ละกล่องลงบนจอแล้ว Developer ก็จะใช้ CSS เขียนสเป็คระบุลักษณะของแต่ละกล่อง แบบตัวอย่างด้านล่างนี้ที่บอกว่า “ให้ทุกกล่อง (*) มีสีเทา เว้นระยะขอบข้างใน 20px ด้านล่างอีก 20px และกล่อง <A> ใช้สีแดง บังคับความสูง 360px เว้นขอบด้านใน 40px” เป็นต้น
จะสังเกตได้ว่าวิธีคิดของ CSS จะคล้ายๆ กับเวลาเราพิมพ์ตัวเลขในแถบ Properties ในโปรแกรมออกแบบอย่าง Figma นั่นเองครับ
ทีนี้ถ้าให้เทียบ HTML/CSS กับ Figma แล้ว HTML ก็เหมือนแถบ Layers ด้านซ้ายที่บอกว่ามีอะไรบ้างอยู่ในจอ ส่วน CSS คือแถบ Design ด้านขวาที่บอกลักษณะหน้าตาของสิ่งต่างๆ ซึ่งเราก็สามารถสรุปความสัมพันธ์ระหว่าง HTML และ CSS ได้ว่า…
“HTML ใช้บอกว่ามีชิ้นส่วนอะไรบ้าง เรียงกันอย่างไร ซ้อนกันอย่างไร ส่วน CSS ใช้บอกว่าแต่ละชิ้นหน้าตาเป็นอย่างไร”
“กล่อง” ที่ว่า มีหลายแบบ
สำหรับ Designer ส่วนใหญ่ เวลาออกแบบใน Figma ไม่ว่าจะวาดปุ่ม วาด Textbox หรือวาด Card ก็จะวาดด้วย Frame หรือ Rectangle แต่จริงๆ แล้ว ตอนนำไปโค้ด Developer จะต้องเลือกว่า “กล่อง” ที่ว่าจะถูกสร้างขึ้นมาจากชิ้นส่วน UI (UI Element) แบบไหน เช่น <button>, <input>, <select>, <h1>, <h2>, <nav>, <section>, ฯลฯ ซึ่ง <div> ที่ยกตัวอย่างไป เป็น “กล่อง” แบบที่ไม่ได้มีความหมายในตัวเอง มีความอเนกประสงค์ที่สุด แต่ก็อาจทำงานได้ไม่ดีเท่าชิ้นส่วนอื่นๆ ที่ทำมาโดยเฉพาะสำหรับการใช้งานของมัน เช่น <input> สร้างมาเพื่อให้ User พิมพ์ข้อมูล ซึ่งถ้าอยากให้ <div> รองรับการพิมพ์ของ User ก็ทำได้เหมือนกัน แต่จะทำยากกว่ากันมาก
กล่องเฉพาะทางแต่ละชนิดที่ว่า ก็จะมี “State” ต่างๆ ของตัวเอง เช่น <input> ก็จะมี State เช่น Empty, Focused, Filled, Error, Disabled ถ้า Designer รู้จักชิ้นส่วนประเภทต่างๆ และเข้าใจว่าแต่ละแบบทำงานอย่างไร ก็จะช่วยให้ออกแบบ State ต่างๆ ได้ครบถ้วนยิ่งขึ้น ช่วยให้ Developer เข้าใจการนำ UI ของเราไปเขียนโค้ดต่อ และนอกจากนี้ การเลือกใช้ชิ้นส่วนถูกต้องจะช่วยให้ Product ของเรามี Accessibility ที่ดีขึ้นด้วย (ซึ่งในบทความนี้จะขอยังไม่ลงรายละเอียดเรื่อง State ของ UI ครับ)
ทีนี้ ในเชิงการจัดวางหน้าจอนั้น ก็มี CSS สำคัญที่อยากแนะนำให้ได้รู้จักกัน ได้แก่ Display และ Position นั่นเอง
เลือกว่ากล่องจะอยู่ในบรรทัดของตัวเอง หรือจะเรียงต่อจากข้อความด้วย “CSS Display”
นอกจากหน้าที่ที่แตกต่างกันของกล่องแต่ละแบบแล้ว ใน HTML/CSS ยังมีความแตกต่างเรื่องการจัดวางด้วย ใน CSS จะเรียกลักษณะการจัดเรียงนี้ว่า “Display” โดยจะสามารถตั้งค่า Display ได้หลักๆ 3 แบบ ได้แก่
- Block กล่องจะถูกเรียงจากบนลงล่าง ถ้าไม่ระบุความกว้างก็จะกินความกว้างจนเต็มหน้า
- Inline กล่องจะถูกมองเหมือนเป็นตัวหนังสือที่อยู่ในบรรทัด แม้จะระบุขนาดก็ไม่มีผล เพราะถือว่าอยู่แค่ในบรรทัด
- Inline-block กล่องจะแทรกอยู่ในบรรทัดเหมือน Inline แต่สามารถระบุขนาดได้
นอกจากนี้ก็ยังมี Display แบบพิเศษอื่นๆ อย่าง “Flex” “Grid” และ “Table-cell” อีกด้วย ซึ่งสำหรับ Designer ที่ทำงานบน Figma แล้ว อยากจะขอแนะนำให้รู้จัก “display: flex” หรือ Flexbox ไว้ว่ามันทำงานคล้ายๆ Auto Layout ของ Figma นั่นเองครับ ซึ่งนั่นก็แปลว่า…
ถ้าเราใช้ Auto Layout ใน Figma ทาง Developer ที่ใช้งาน Flex คล่องๆ ก็จะสามารถนำมาเขียนโค้ดต่อแบบตรงๆ ได้เลย
จะวางกล่องบนหน้าจอโดยอิงจากตำแหน่งไหน เลือกได้ด้วย “CSS Position”
จากเมื่อกี๊ จะเห็นว่าปกติมันเรียงบนลงล่าง/ซ้ายไปขวาตามบรรทัด แล้วถ้าอยากวาดตรงอื่นจะทำได้ไหม? คำตอบคือทำได้! ถ้าเป็น CSS จะสามารถปรับค่า “Position” เพื่อปรับวิธีการเรียงได้ระดับหนึ่ง โดยมีแบบที่มักใช้กันบ่อยๆ ดังนี้
- Static (Default) กล่องที่ตั้งค่า Position ไว้แบบนี้จะเรียงจากบนลงล่าง/ซ้ายไปขวาตามปกติ (เหมือนเวลาใช้ Auto Layout แนวตั้งใน Figma)
- Relative กล่องนี้จะเรียงตามปกติ แต่สามารถขยับออกมาจากจุดเดิมได้ (เช่น บอกว่าขยับขวาจากเดิม 10px)
- Absolute ให้กล่องนี้วางตรงไหนก็ได้ แค่ระบุว่าจะเริ่มนับจากมุมไหนของจอหรือ Element ที่ซ้อนอยู่ และระบุพิกัดว่าต้องการวางไว้ตรงไหน (เช่น เว้นซ้าย 10px นับจากมุมซ้ายบนของจอ)
(สำหรับใน Figma ถ้าจะใช้กับ Auto Layout ให้ลองใช้วิธีนี้) - Fixed คล้าย Absolute แต่จะไม่ไหลตามการ Scroll แม้ว่าจะ Scroll ก็จอผ่านไป กล่องนี้ก็จะยังค้างอยู่ตรงนั้น
(เหมือนกับการติ๊กช่อง “Fix Position When Scrolling” ใน Figma)
เมื่อ Developer รับ Design ของเราไปทำต่อ เขาก็จะต้องตัดสินใจว่าชิ้นส่วน UI แต่ละชิ้นจะต้องตั้งค่า Position เป็นแบบไหน เพื่อที่จะให้แอปจริงทำงานเหมือนกับที่เราออกแบบไปนั่นเอง
แต่พอเห็นแบบนี้แล้ว ไม่ใช่ว่าเราในฐานะ Designer จะวางกล่องไว้ที่ไหนตามใจก็ได้นะ เพราะว่าจริงๆ แล้ว “กระดาน” ของเราไม่ได้มีขนาดตายตัว!
กระดานขนาดคงที่ vs กระดานที่ขยับขยายเมื่อไหร่ก็ได้
ในโปรแกรมออกแบบส่วนใหญ่ เวลาจะวาดจอ ก็จะต้องกำหนดขนาดกระดานก่อนเสมอ และมักจะไม่ค่อยเปลี่ยนขนาดกระดานระหว่างทำงาน แต่สำหรับ Developer โดยเฉพาะคนทำเว็บ “กระดาน” ของเขาคือจอ Web Browser ที่อาจจะถูกขยับขยายเมื่อไหร่ก็ได้ แถมยังต้องรองรับการเปิดบนจอเล็ก จอใหญ่ แท็บเล็ต มือถือ หรือคนทำแอปก็ต้องทำให้แอปใช้งานได้กับมือถือหลายรุ่น ตั้งแต่จอขนาดเล็กๆ ไปจนถึงจอใหญ่ๆ ของมือถือจอพับด้วย
แปลว่าเวลาเราออกแบบ เราควรจะลองปรับขนาดจอเพื่อเช็ค Design ของเราให้ Responsive อยู่เสมอๆ เพราะ Responsive ไม่ใช่แค่เรื่องความแตกต่างระหว่าง Desktop/Tablet/Mobile เท่านั้น เช่น ถ้า User ใช้เว็บของเราบนจอคอม คงหลีกไม่พ้นจังหวะที่ User ขยับขยายหน้าต่างแอปไปที่ส่วนต่างๆ ของจอ บางที User อาจจะต้องเปิดเอกสารไว้เทียบข้างๆ หรือระหว่างทำงานก็อาจจะเปิดเว็บฟังเพลงข้างๆ ไปด้วย เราก็ต้องไม่ลืมที่จะเช็คว่า Design ของเราแสดงผลได้ดีบนจอเหล่านั้นหรือไม่
ควรจะทำ Design อย่างไรให้รองรับจอที่ยืดหดได้?
สำหรับโปรแกรมออกแบบ UI ในยุคนี้อย่าง Figma ก็มีเครื่องมือที่ใช้ตั้งค่าให้ชิ้นส่วนต่างๆ ภายใน Frame หนึ่งๆ ขยับขยายตาม Frame ที่ครอบอยู่ ช่วยให้เราทดสอบการย่อ/ขยายจอได้ง่ายๆ แค่ลองยืด/หด Frame ของจอในโปรแกรมดูอย่างภาพด้านล่างนี้
ถ้าเราเตรียมไฟล์สำหรับ Responsive มาดี เมื่อลองย่อ/ขยายกรอบ ก็ไม่ควรจะพังแบบภาพทางซ้าย แต่ควรจะออกมาสวยงามแบบภาพทางขวา ซึ่งการทดสอบ Responsive ในไฟล์ของเราจะเป็นการบังคับให้เราคิดเรื่องการยืดหดจอไปในตัว ช่วยให้เราคิด Design ของเราได้รอบคอบมากขึ้น ก่อนที่จะส่งให้ Developer ทำต่อ
แล้วจะทำอย่างไรให้มันขยับตามได้ดีๆ ล่ะ? ก็ต้อง…
- ใส่ใจกับ Constraints ว่าชิ้นส่วนบนจอแต่ละชิ้นจะยึดกับขอบซ้าย ขอบขวา อยู่ตรงกลาง หรือยืดตามทั้งสองข้าง? แล้วแนวตั้งทำอย่างไร?
(สำหรับคนที่ยังไม่คล่อง ลองดูวิธีใช้ Constraints ได้ที่นี่) - ซ้อน Frame ให้ถูกต้อง เพื่อให้ความสัมพันธ์ระหว่างชิ้นส่วน UI ต่างๆ ที่ซ้อนกันอยู่นั้นถูกต้อง เช่น ถ้ามีปุ่มอยู่ใน Card ก็ควรวาด Card ด้วย Frame และซ้อนปุ่มไว้ใน Frame นั้น ถ้าขยับขยาย Frame ปุ่มก็จะได้ขยับไปด้วยกัน
- ดูการตั้งค่า Auto Layout ดีๆ โดยเฉพาะการระบุขนาดอัตโนมัติแบบ Fixed, Fill, หรือ Hugs Content และอย่าลืมระวังเวลาตั้งค่า เพราะบางครั้งถ้าเราตั้งค่าให้ Frame ที่อยู่ลึกๆ มันจะกระทบกับ Frame ชั้นนอกด้วย
(สำหรับคนที่ยังไม่คล่อง ลองดูวิธีใช้ Auto Layout ได้ที่นี่)
แต่ Layout แบบเดียว ใช้ไม่ได้กับจอทุกขนาดแน่ๆ แล้วทำไงดี? Breakpoints คือคำตอบ
ปกติเวลาออกแบบสำหรับจอหลายขนาด เราจะแยกวาดจอสำหรับ Mobile กับ Desktop กันอยู่แล้ว พอมาถึงจุดนี้ บางคนอาจจะมีคำถามว่า “ย่อจอจากขนาด Desktop ลงไปเป็น Mobile เลยไม่เวิร์คหรอก” ซึ่งจริงครับ
แต่ผมอยากเล่าเพิ่มในมุมของ Developer สักเล็กน้อย ว่าใน CSS มีสิ่งที่เรียกว่า “Breakpoints” หรือ “Media Query” (ส่วนที่เขียนว่า @media ในโค้ด) มาช่วยให้เราสามารถเปลี่ยนวิธีจัดเรียงหน้าจอแยกตามขนาดจอต่างๆ ได้ ยกตัวอย่างง่ายๆ เช่นในภาพนี้ ในตัวอย่างนี้ผมขอยกตัวอย่างเป็นแค่การเปลี่ยนสีกล่องตามขนาดจอ แต่จริงๆ แล้วมันเปลี่ยนได้ทุกอย่างเลย ทั้งสี ขนาด การจัดเรียง การแสดงผล ฯลฯ
สังเกตว่า เวลาระบุ Breakpoint ในโค้ด จะไม่ใช่แค่บอกว่าเป็นจอของ “Mobile/Tablet/Desktop” แต่มักจะระบุเป็นช่วงขนาด Pixel (หรือจริงๆ สามารถระบุลักษณะอย่างอื่นของจอได้อีกด้วย เช่น จอแนวตั้ง/นอน จอทัช/ไม่ทัช แสดงผลบนจอหรือพิมพ์ใส่กระดาษ ฯลฯ)
ดังนั้นสำหรับ Designer เราต้องไม่ลืมว่า Layout ที่เราออกแบบสำหรับจอแต่ละแบบ จะต้องรองรับความกว้างตั้งแต่แคบที่สุดไปจนถึงกว้างที่สุดของแต่ละช่วง เช่น การออกแบบสำหรับ Mobile ไม่ได้แปลว่าแสดงผลบน iPhone 14 ได้แล้วจะจบ แต่จะต้องแสดงผลได้ดีตั้งแต่จอความกว้าง ~360px ไปจนถึง ~640px และ Layout แบบ Tablet จะต้องรองรับได้ตั้งแต่ 641px ขึ้นไปทันที ซึ่ง Designer สามารถระบุช่วง Breakpoint ได้ว่าอยากให้ Layout เปลี่ยนที่ความกว้างจอกี่ Pixel
แต่ถ้าจะให้ดี ควรลองคุยกับ Developer ดูก่อนครับ เพราะเครื่องมือบางอย่างที่ Developer ใช้จะคิดมาให้แล้วว่าจะใช้ Breakpoint ที่กี่ Pixel ถ้าเราใช้ตามนั้น ก็จะช่วยให้ Developer ทำงานได้ง่ายขึ้นอีกเล็กน้อย
วิธีการหนึ่งที่จะช่วยให้เราไม่ลืมเช็คเรื่องนี้ คือเวลาทำตัวอย่าง Responsive ให้ Developer ดู ให้ลองทำจอขนาดแคบสุด-กว้างสุด ของแต่ละช่วงไว้ด้วย เราในฐานะ Designer จะได้เช็คให้ครบถ้วนว่า Design ของเราดูดีบนจอทุกขนาดแล้วจริงๆ ไหมอย่างเช่นในรูปนี้ และเวลาที่ทำตรงนี้ก็จะช่วยเช็คตัวเราเองด้วยว่าเราทำ Responsive มาดีแล้วจริงหรือเปล่า
ยังมีอีกหลายอย่างที่ Figma ยังทำไม่ได้ แต่ HTML/CSS ทำได้
หลังจากที่เราได้เห็นแนวคิดในการโค้ด UI และเรื่อง Responsive เบื้องต้นกันมาแล้ว ผมอยากจะเล่าเพิ่มว่าจริงๆ แล้วยังมีอะไรอีกหลายอย่างในเชิงการทำ UI ที่โค้ดทำได้ แต่ Figma ทำไม่ได้ ถ้าเราเข้าใจประเด็นเหล่านี้ ก็จะใช้ประโยชน์จากมันได้ และสื่อสารกับ Developer ได้ชัดขึ้นว่าเราต้องการอะไร ซึ่งจะขอยกตัวอย่างสิ่งที่ HTML/CSS ทำได้ แต่ Figma ยังทำไม่ได้ไว้สัก 2 ตัวอย่าง ดังนี้
Max-width/Max-height
Max-width เป็นเครื่องมือที่ตอนผมทำเว็บเองจะใช้บ่อยมาก พอมาทำ Responsive Design บน Figma ก็รู้สึกอยากจะใช้อยู่บ่อยๆ แต่ใน Figma ไม่มี
กลไกการทำงานนั้นง่ายๆ คือการบอกว่ากล่องของเรากว้าง/สูงได้มากที่สุดเท่าไหร่ เช่น ในภาพด้านล่างนี้ที่เรากำหนด width: auto; (กว้างเท่าที่ทำได้) พร้อมกับ max-width: 500px; (กว้างสุดได้ 500px) ถ้าเราขยับจอจนกล่องนี้กว้างเกินกว่า 500px กล่องสีม่วงก็จะหยุดความกว้างไว้แค่ 500px นั่นเอง
Accessibility Labels
อีกหนึ่งประเด็นที่เครื่องมืออย่าง Figma ยังทำได้ไม่ดีนัก คือเรื่องการออกแบบเพื่อ Accessibility นั่นเอง ซึ่งเวลาออกแบบเพื่อ Accessibility จะมีกลุ่มผู้ที่มีปัญหาด้านการมองเห็น ที่ใช้เครื่องมือ Screen Reader เพื่อใช้งานเทคโนโลยีด้วย แต่เครื่องมืออย่าง Figma ยังไม่มี Feature รองรับการออกแบบเพื่อ Screen Reader มากนัก (ลองดูว่าผู้ใช้ Screen Reader ใช้โทรศัพท์กันอย่างไรได้ในบทความนี้)
เพื่อให้เครื่องอ่านได้ถูกต้อง เวลาที่ Developer เขียนโค้ด UI ก็จะต้องระบุวิธีการอ่านส่วนต่างๆ ของ UI เพิ่มเข้าไป เช่น ควรอ่านอะไรก่อน-หลัง รูปภาพนี้ต้องอ่านว่าอะไร หรือไอคอนที่มีคำประกบอยู่แล้วควรข้ามไป ไม่ต้องอ่าน เป็นต้น ซึ่งปกติจะต้องระบุในโค้ดด้วยวิธีต่างๆ เช่น การเลือกใช้ “กล่อง” ให้ถูกประเภท หรือใช้โค้ดพิเศษ เช่น “aria-label” มากำหนดการอ่านของ Screen Reader สมมติเราอาจจะอยากให้อ่านไอคอน “×” ว่า “ปิด” ไม่ใช่ “เอ็กซ์” ก็ต้องระบุไปในโค้ดด้วย ดังตัวอย่างด้านล่าง
<button aria-label="Close"> × </button>แล้วถ้าอยากใช้ฟีเจอร์พวกนี้ใน Design ของเรา ควรทำอย่างไร?
จริงๆ แล้วนอกจากตัวอย่าง 2 อันนี้ ก็ยังมีอีกหลายฟีเจอร์ที่ทำได้ด้วยโค้ด แต่เครื่องมือของ Designer ยังทำไม่ได้ เช่น หลายๆ ฟีเจอร์ของ Flexbox, CSS Grid, การวางชิ้นส่วน UI แบบ Inline และอื่นๆ ที่อยากชวนให้พวกเรา Designer ลองศึกษาเพิ่มกันดู เพื่อขยายกล่องเครื่องมือของเราครับ
และหลังจากเห็นตัวอย่างกันแล้ว บางคนอาจจะอยากใช้ฟีเจอร์พวกนี้ขึ้นมา ข่าวร้ายคือตอนนี้ Figma ยังไม่มีเครื่องมือให้ทำได้ในตัวมันเอง ทำให้เราระบุสิ่งเหล่านี้ใน Design ของเราตรงๆ ไม่ได้ (ในอนาคตอาจจะทำได้?) แล้วเราจะทำอย่างไรดีให้ Developer เข้าใจว่าเราอยากได้แบบนี้?
แน่นอนว่าเรื่องนี้ต้องอยู่ที่การสื่อสารระหว่าง Designer กับ Developer แล้วครับ ซึ่งเราอาจจะสื่อสารด้วยการพิมพ์เป็น Note ไว้ในไฟล์ Design หรือคุยปรึกษากับ Developer โดยตรงว่าทำแบบไหนได้บ้าง และพยายามทำความเข้าใจว่ามีฟีเจอร์อะไรให้เราใช้บ้าง และแต่ละฟีเจอร์ทำงานอย่างไรครับ
สรุป: ควรทำยังไงให้ UI ของเราใกล้เคียงกับการนำไปโค้ดต่อที่สุด?
มาถึงตรงนี้ หวังว่าจะเข้าใจการคิดของ Developer ในการทำ UI มากขึ้น ผมขอสรุปสิ่งที่เราในฐานะ Designer ควรรู้ไว้ดังนี้
- UI เกิดจากโค้ด วางกล่องจากบนลงล่างหรือซ้อนกันเป็นชั้นๆ เครื่องมือใน Figma ที่จะทำให้ Design ของเราใกล้เคียงกับวิธีคิดในโค้ดที่สุดคือการใช้ Frame และ Auto Layout
- UI แต่ละชิ้นเกิดจาก “กล่อง” มาเรียงและซ้อนกัน ซึ่งกล่องแต่ละแบบมีวิธีการเรียงและวางตำแหน่งต่างๆ กัน (Display และ Position)
- อย่าลืมทดสอบ Responsive ด้วยการลองยืดหดจอ ใส่ใจกับ Constraints การซ้อนกันของ Frame และการตั้งค่า Auto Layout และอย่าลืมคิดถึง Breakpoints
- อย่าคิดถึงแค่สิ่งที่ Figma ทำได้ อะไรที่ทำใน Figma ไม่ได้ แต่เราอยากได้ ให้ลองศึกษาเพิ่มเติม และปรึกษา Developer
ก่อนจากกันไป อยากจะทิ้งท้ายไว้เล็กน้อยครับว่าการที่ Designer รู้เรื่องการโค้ด UI นั้นไม่ใช่ว่าพอรู้แล้วจะคิดแทน Developer ได้หมด เพราะแต่ละ Product ก็มีข้อจำกัด ที่แตกต่างกัน อาจจะมีสิ่งที่ทำได้ ไม่ได้ ทำง่าย ทำยาก แตกต่างกันไป ดังนั้นสิ่งที่ดีที่สุดที่จะทำให้เราทำงานกับ Developer ได้ราบรื่น นอกจากความเข้าใจในหลักการโค้ด ก็คือการทำงานให้ใกล้ชิดกับ Developer และสื่อสารกันบ่อยๆ ด้วยนั่นเองครับ
สำหรับครั้งหน้า ถ้ามีโอกาสได้เจอกัน ผมอยากจะมาเล่าต่อเกี่ยวกับเรื่องการใช้ CSS Frameworks และ UI Components ต่างๆ ของ Developer และเรื่องอื่นๆ เช่น การทำงานของ API และการรองรับเคสต่างๆ ที่อาจเกิดขึ้น แล้วพบกันครับ 🙂
UPDATE: บทความตอนที่ 2 มาแล้วครับ สามารถตามเข้าไปอ่านได้ที่นี่
สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
