บทความนี้เป็น เนื้อหาเรียบเรียง talk ที่เกี่ยวกับดีไซน์เนอร์ที่เขียนโค้ด จากงาน Config 2022 ถ้าสนใจจะเข้าไปดู talk เต็มๆในแต่ละหัวข้อจากต้นฉบับ สามารถไปตามดูได้ที่ reference ท้ายบทความครับ (แนบ slide ให้แล้ว จะได้อ่านง่าย)

งาน Config 2022 คืองานที่จัดโดย Figma โดยจะเอาคนเก่งๆมาพูดในมุมต่างๆ (+ Figma ประชาสัมพันธ์ฟีเจอร์ต่างๆของตัวเองนิดหน่อย) ซึ่งจะมี themes ที่ตรงกับดีไซน์เนอร์เขียนโค้ดมากๆ คือ Design system กับ Development

บอกไว้ก่อนว่า ผมเรียบเรียงไว้แต่ Talk ที่ผมสนใจ (ที่เกี่ยวกับ development และ design) นะครับ (คลั่งไคล้ด้านนี้น่ะ)

ถ้าพร้อมแล้ว ก็เริ่มอ่านกันได้เลย!

…

เข้าใจ Dev มากขึ้น – งานของทั้งทีมจะเร็วและมีคุณภาพมากขึ้น

เนื่องจาก designer และ dev มีวิธีการคิด การทำงาน และ tool ที่ต่างกัน ความท้าทายคือจังหวะ hand-off ที่ designer ต้องส่งต่อความคิดของตัวเอง ให้กับ dev เพื่อสร้างของออกมา

สิ่งที่ dev ต้องการจาก designer คือ สร้างตามได้แบบไม่ต้องปวดหัวคิด ซึ่งเรามีวิธีการทำได้ตามนี้

ทำ structured design เพื่อให้ dev เข้าใจง่ายขึ้น

Structured design คือ concept ของการงานเราเรียบร้อย และมีโครงสร้างคล้ายกับโค้ดจริง (ที่ dev กำลังจะไปสร้าง)

• มี design token ที่ชัดเจน (พวก font styling, color ต่างๆ)
• ตั้งชื่อ Layer ให้ชัดเจน และสัมพันธ์กับ ชื่อใน element ต่างๆของ code
• เน้นการจัดการ element ให้คล้ายกับวิธีจัดการ dev (เช่น ใช้ padding, ใช้ auto-layout ) หลีกเลี่ยงการวางของแบบ manual ถ้าเป็นไปได้
• ใช้ variant component ในการจัดการ state ต่างๆ ให้ใกล้เคียงกับวิธีการสร้างของ dev

Image source: How to create design loved by developers – By Kazuya Seki

Image source: Design to production in a snap & how you can do it too? – Tushar Debnath

บทความที่แนะนำให้อ่านเพิ่มเติมคือ Crafting API component, Together – Nathan Curtis (ถ้ามีใครสนใจให้ผมอธิบายเพิ่มเติม ทักมาได้นะครับ)

แน่นอนว่าหลายๆคนอ่านมาถึงตอนนี้ต้องรู้สึกว่า “เยอะจัง” ฉันเป็น designer นะ ไม่ใช่ dev ก็ขอให้อ่านต่อในหัวข้อถัดไป

เริ่มทำ structured design ตอนจะเข้า hand-off phase ก็พอ

หน้าที่ของ designer มี 2 ส่วนคือ

1. หา solution ที่เรารู้สึกว่าเวิร์ค (design phase)
2. ทำให้เรียบร้อยเพื่อให้ dev ต่องานได้ (hand-off phase)

ถ้าตอนหา solution อยู่ต้องมา structure ให้ dev ตลอดเวลาก็เป็นการเสียเวลาโดยใช่เหตุ

ถ้าพึ่งเริ่มต้น แนะนำให้เริ่มทำ structured design ตอนจะส่งต่อให้ dev เพื่อลดเวลาในขณะที่เรากำลัง explore solution ใน design phase

แต่ถ้าใครสามารถคิดแบบ dev ได้ตลอดเวลา ในบางครั้งก็จะทำกึ่ง structured design ไปได้เลยใน design phase

คุยกันเพิ่มเติมเพื่อเคลียร์คำถามที่ยังเหลืออยู่

พยามแค่ไหนก็ไม่มีทางที่เราจะรู้ทุกเรื่อง หน้าที่ของเราคือ พยามเข้าใจให้ dev และเตรียมงานให้ดีที่สุด แล้วก็ไปคุยและปรับไปด้วยกัน

• เอา dev มาดูตั้งแต่เนิ่นๆ (ตอนเริ่มทำ structured design)
• ไม่ต้องยัดทุกอย่างลงใน design spec บางอย่างอาจจะต้องพูดเอา
• ทำ hand-off meeting (ถ้า dev อยากได้) เพื่อทำความเข้าใจร่วมกัน

…

ถ้า Designer ขี้เกียจ ก็จะทำให้ทีมมีประสิทธิภาพขึ้น

“Automate so we can focus on important tasks” เป็นหัวใจของดีไซน์เนอร์เขียนโค้ด

นั่นก็คือ ใช้พลังของการ code มาช่วยเพื่อทำให้ตัวเอง (และทีม) ไม่ต้องทำงานถึก (ซ้ำๆ ไม่ต้องคิดอะไรใหม่) เพื่อลดเวลาและความผิดพลาด (human error) เช่น

ทำให้งานเรียบร้อย และ scale ได้ ผ่าน Design system (live version)

การทำ design system แบบ live คือ เป็นเว็บไซต์ (ไม่ใช่ใน Figma เฉยๆ) นั้นมีประโยชน์หลายอย่าง

• เป็น single source of truth คือ เป็นแหล่งอ้างอิงเดียวเลย ทุกคนจะเข้าใจตรงกันไม่ว่าจะเป็น designer, developer หรือ product manager (เช่น เข้ามาลองกดเลยว่า element ต่างๆมี interaction แบบไหน) ไม่ต้องพูดเยอะ
• dev สามารถดู code บนนี้ได้เลย เวลาสร้างของก็นำไปใช้ได้แบบเร็วๆ ไม่ต้องคอยคิดใหม่ทำใหม่
• คนที่พึ่งมาเข้า team ใหม่ สามารถใช้สิ่งนี้เพื่อ onboard ตัวเองเข้าโปรเจคได้อย่างรวดเร็ว (กว่าที่จะต้องไปไล่หาตามไฟล์เอง)

ซึ่งการจะทำให้เกิดขึ้นได้ ก็ผ่านการทำงานด้วยกันแบบใกล้ชิดของ design และ development ทีม และมี process ที่ชัดเจน

สำคัญคือ design system ไม่ใช่แค่ทำแล้วจบ ต้องมีกระบวนการต่างๆเพื่อ maintain ต่อ

• ผู้ใช้ (designer, dev, …) ส่ง requests / issues เข้ามา
• มีกระบวนการการรีวิวที่ชัดเจน เวลาจะเพิ่มหรืออัพเดทอะไร
• มีการทำ versioning ที่ชัดเจน (เวอร์ชั่นไหนแล้ว อัพเดทเมื่อไร อัพอะไรไปบ้าง)
• มีการสื่อสาร แนะนำ และสอน ให้ทุกคนในทีมได้เข้าใจและใช้จริง

สร้าง Plugin เพื่อลดระยะเวลาการทำงาน

plugin คือสิ่งที่มาช่วยชีวิตดีไซน์เนอร์ลดงานถึก ยกตัวอย่างเช่น

• Google Sheets Sync – ดึง data จาก Google sheet มาใส่ใน component แบบอัตโนมัติ
• Spectrum – ไว้สุ่มการลองใช้ color pallete บน element ของเรา
• Morph – ไว้สร้าง graphic สวยๆ แนว Skeuomorph, Neon, Glitch, Reflection, Glass, Gradientแบบรวดเร็ว
• Cover Generator – ไว้สร้างและอัพเดท cover แบบไวๆ

สร้าง Snippet kit เพื่อออกแบบในสิ่งที่ซ้ำๆ

บางครั้ง designer ต้องสร้าง design ที่มีรูปแบบซ้ำๆ เช่น ทำหน้า campaign หรือ หน้า landing page (ให้กับทีม marketing)

• รูปแบบ element เดิม แต่ว่าอาจจะมีสลับตำแหน่ง
• รูปแบบ element เดิม แต่เปลี่ยน content เช่น รูป และ คำต่างๆ

เราสามารถทำสิ่งเหล่านี้เป็น component ที่ชัดเจน แล้วใช้ auto layout ในการประกอบหน้าขึ้นมาได้แบบรวดเร็ว (drag & drop ใส่เลย)​ ถ้าล้ำๆหน่อยก็สอนวิธีการใช้ให้ marketing ประกอบหน้าเองได้เลย

…

ทำ Plugin ไม่ยากอย่างที่คิด

ทุกคนน่าจะรู้ว่า plugin ของ Figma คือคลังเครื่องมือแห่งการจัดการงานถึก มีหลายครั้งที่ผมเจองานที่ต้องใช้เวลานานในการทำ ก็เลยไปไล่หา plugin มาใช้เพื่อประหยัดเวลาตัวเอง (รู้สึกขอบคุณกับทุกคนที่สร้าง plugin ขึ้นมามากๆ)

แต่สิ่งที่ทุกคนอาจจะไม่รู้คือ ถ้าเรามีพื้นฐาน HTML CSS​ JavaScript เราก็สามารถสร้าง plugin ด้วยตัวเองได้แล้ว!

ก่อนจะสร้าง Plugin จริง มาลอง code เล่นๆกันก่อน

ก่อนที่จะสร้าง plugin นั้น เราต้องมีการ setup เครื่องเราให้พร้อม (ที่แอบวุ่นวาย) ซึ่ง designer อย่างเราๆอาจจะตายตั้งแต่ก่อนเริ่มได้เริ่มเขียน plugin จริง

วิธีที่ง่ายสุดคือ ไม่ต้อง setup plugin แต่เขียน code ลงไปใน Figma โดยตรงเลย โดยวิธีการคือ

• เปิด Figma
• เมื่อโหลดหน้าจอเสร็จ กด (Command-Option-i) ⌘⌥I
• พอเห็น inspector tool ไปที่ console tab
• แล้วเริ่มโค้ดได้เลย เช่น พิมพ์ `figma.notify(“Hiyaaaaaaa”)
• จะเห็นว่ามีบางอย่างเกิดขึ้นใน Figma แล้ว!

การทำวิธีนี้ทำให้เราสามารถลองเล่น Figma API (โค้ดที่เอาไว้บอกให้ Figma ทำงานให้เรา) ได้อย่างรวดเร็ว โดยไม่ต้อง setup อะไรเลย

ใช้ Scripter ในการ run

พอเราเริ่มเข้าใจหลักการ เราอาจจะเริ่มสร้างอะไรเล็กๆที่มีประโยชน์และเก็บไว้ใช้ซ้ำๆได้ (ใครจะมานั่งพิมพ์ลงไปในกล่อง console ทุกครั้ง!)

มี plugin ที่ชื่อ Scripter ที่จะทำหน้าที่เป็นคลัง script ของเรา อยากใช้อะไรก็เรียกมันขึ้นมา

พอเราเริ่มเห็น pattern ของ solution แล้ว เราก็เอามันไปสร้าง plugin ต่อ

แม้ว่าในงาน Config ยังไม่ workshop ที่เขาเริ่มให้ลงมือทำ plugin แบบจริงจัง (แต่ละ talk มันแค่ประมาณ 25 นาที) แต่โลกนี้ยังมีบทความแบบจับมือทำ ที่จะช่วยให้เราคลอด plugin ออกมาได้ในที่สุด 👉 Getting started with Figma plugins – Danial Hollick

…

กล้าที่จะลงมือ และพาคนอื่นไปด้วยกัน

ดีไซน์เนอร์ที่โค้ด เป็นอะไรที่ยังไม่ค่อย mainstream ในไทยเท่าไร

• เรายังไม่เห็น job post เกี่ยวกับ design technologist, ux engineer, design engineer, front-end designer ในไทย
• เราเลยยังไม่เห็น resources หรือ materials อะไรที่สอนเราโดยตรง เช่น UX/UI Bootcamp คอร์สต่างๆ หรือ community ของคนที่ทำสายนี้

แต่ถ้าเราชอบด้านนี้ หรือ อยากลอง ก็เป็นโอกาสดีที่เราจะพา concept นี้เข้า mainstream!

เรียนรู้ผ่านการลงมือให้คนอื่นเห็น (Learning/building in public)

ทั้งโลกแห่งการ design และ code ก็ล้วนเต็มไปด้วยสิ่งที่น่าสนใจให้เราเรียนรู้และทดลอง พอรวมสองอย่างนี้เข้าด้วยกันก็เหมือนกับ ความเป็นไปได้อันมหาศาลแบบพหุอนันต์อัศจรรย์ใจใช่เลยเธอ 🤣

แทนที่เราจะเรียนอยู่เงียบๆคนเดียว เราอาจจะเริ่มนำมาใช้จริงในงานของเรา, บอกคนรอบข้างเรา, เริ่มเขียน blog, หรือกระทั่ง Live streaming ตอนเราเรียนหรือสร้างให้คนอื่นได้สนุกไปด้วยกัน (ซึ่งแน่นอนว่า ทุกอย่างที่เราทำมันจะไม่ได้ลื่นไหลหรอก ก็จะผิดตรงโน้นบ้างตรงนี้บ้าง ก็ถือเป็นการเรียนรู้และพัฒนาตัวเองไปเรื่อยๆ)

เผลอๆอาจจะได้ งานเสริม, ได้ invitation ไป talk, และที่สำคัญ ได้เพื่อนใหม่ๆที่มี passion ในอะไรๆเหมือนๆกัน

เริ่มเล็กๆ แล้วค่อยๆเล่นใหญ่ขึ้นไปเรื่อยๆ

เป็น advocate ในสิ่งที่เราเชื่อถือ ทำให้ทุกคนเข้าถึงได้ง่ายขึ้น (accessible for everyone)

• แลกเปลี่ยนกับ department อื่น เช่น จัดให้ความรู้เกี่ยวกับ design หรือ นำกระบวนการออกแบบไปแก้ปัญหาให้เค้า
• แลกเปลี่ยนกับ บริษัท อื่น หรือประเทศอื่นๆ เช่น จัด workshop, ร่วม workshop หรือคุยกันใน community ที่เกี่ยวกับดีไซน์เนอร์​ (เช่น UX Thailand)
• การสอนผ่านช่องทางต่างๆ ไม่ว่าจะเป็น blog หรือ social หรืองาน talk ต่างๆ

การที่เราค่อยๆเล่นใหญ่ขึ้นเรื่อยๆ จะทำให้เราค่อยๆพัฒนาตัวเอง + พัฒนาคนอื่นโดยไม่รู้ตัว จนทำให้ทุกคนที่สนใจในด้านนี้เก่งขึ้นกันหมด

…

สรุป

• การร่วมมือกันของ ดีไซน์ (design) และ โค้ด (development) เป็นสิ่งที่สำคัญมาแต่ไหนแต่ไร และเริ่มที่จะได้รับการสนใจมากขึ้น
• ถ้า designer เข้าใจ development จะทำให้การทำงานร่วมกันง่ายขึ้น ลีนขึ้น คือ ใช้เวลาน้อยลงแต่ได้ประสิทธิภาพมากขึ้น
• ถ้า designer พอโค้ดได้ ก็จะสามารถสร้าง plugin ต่างๆมาช่วยประหยัดเวลาให้ทีมได้
• การเริ่มทำ plugin นั้นไม่ยาก ทุกคนเริ่มทำได้เลยแค่มีความรู้พื้นฐาน HTML/CSS/JS
• ถ้า designer อยากพัฒนาตัวเอง เราสามารถทั้งเรียนรู้และแนะนำคนอื่นไปพร้อมๆกันได้

อ่านจบแล้ว ยังไงต่อ?

• ลองเปิด Figma ขึ้นมาแล้วทำตามแล้วลองเขียนโค้ดเล่นๆดู (5-10 นาทีก็พอ ให้พอเก๊ทฟีล)
• ลองคุยกับคนอื่นที่อยากทำงานสายนี้เหมือนๆกัน ผ่านช่องทางไหนก็ได้ เช่น DM ไป หรือ คุยใน community
• ยิ้มให้กับตัวเองซักทีที่อ่านมาถึงตรงนี้ และลองนั่งคิดเล่นๆดูว่าเราอยากเป็นดีไซน์เนอร์สายโค้ดมั้ย :)

อ้างอิง

สามารถดูสไลด์ของ talk ต่างๆที่ผมนำมาเรียบเรียงได้ที่ link ด้านล่างนี้ (14/05/22 Figma ยังไม่แชร์วีดีโอที่อัดไว้ ถ้าแชร์แล้วจะมาแปะให้เพิ่มครับ)

• The real plugins were the friends we made along the way – Tru Narla
• Design to production in a snap and how you can do it too? – Tushar Debnath
• Using Figma above and beyond in design teams – Milan Maheshwari
• Figma Hacks and Workflow Enhancements with Plugins – Hiroki Tani
• How to create Figma designs loved by developers – Kazuya Seki
• One design system for multiple brands – Ryo Fukushima
• Demystifying plugin development – Gavin McFarland
• Building a Design System using Figma & Sanity Headless CMS to Document It – Apostolos Christodoulou, Stuart Wainstock , Lexa Gallery
• Multi-platform design system at Booking.com – Nicole Saidy, Oleksii Drozdenko