💡 ทำไมถึงสำคัญ
ทีมดีไซน์มักมีปัญหาในการใช้งาน component library เมื่อมีจำนวน component ที่มากขึ้น → เพราะมองข้ามเรื่องพื้นฐานอย่างการตั้งชื่อ และการใส่ข้อมูลต่างๆ
การใส่ใจในเรื่องเหล่านี้มากขึ้น จะทำให้ทีม
- อ่านชื่อ component ได้ชัดเจน
- ค้นหา component เจอได้ง่ายๆ
- รู้ได้ว่าควรใช้ component นั้นๆ อย่างไร
🙂 ใครควรอ่าน
- ดีไซน์เนอร์ที่ต้องการจัดการ component library ของตัวเองให้มีประสิทธิภาพขึ้น
- เดฟ front end ที่ต้องทำ design system และกำลังหาวิธีในการต่องานกับดีไซน์เนอร์
ปัญหายอดฮิตของการสร้าง component library → ยิ่งมีของเยอะ ยิ่งใช้ยาก
ดีไซน์เนอร์มักจะสร้าง component library เอาไว้ใน Figma เพื่อให้ตัวเอง (และทีม) สามารถทำงานได้สบายขึ้น
แต่พอทำไปสักพัก component ก็ยิ่งเยอะ แทนที่จะทำงานเร็วขึ้น → กลายเป็นว่าเริ่มเกิดปัญหาแทนครับ!
- เจอ component ที่ตั้งชื่อประหลาดๆ งานดูไม่มีมาตราฐาน → อ่านยาก + งงว่าแบบไหนคือแบบที่ถูกต้องกันแน่
- หา component ไม่เจอ → ต้องคอยถามกันว่ามีมั้ย? อยู่ที่ไหน? แย่สุดคือ หาไม่เจอและสร้างใหม่มา
- หา component เจอ แต่ไม่รู้ว่าควรจะเอาไปใช้ยังไง → นำไปใช้แบบผิดๆ
ปัญหาข้อ (1) อาจดูเป็นเรื่องเล็กๆที่หงุดหงิดใจ แต่ปัญหาข้อ (2)(3) ทำให้ design system ของเรามีประสิทธิภาพที่ลดลงอย่างชัดเจนเลยครับ
ซึ่งเราสามารถลดปัญหาเหล่านี้ได้ง่ายๆ แค่เรา “ใส่ใจ” ในการสร้าง component ของเรามากขึ้นอีกนิดนึง ด้วยการ
- ตั้งชื่อให้ดี
- ใส่ description และ URL เพิ่มเข้าไป
✏️ Key idea 1: การตั้งชื่อ component ที่ดี → ทำให้อ่านง่าย และมีการจัดกลุ่มที่ชัดเจน
เมื่อเรากวาดสายตาดู component ต่างๆ → ทุกๆชิ้นควรมีรูปแบบชื่อที่เหมือนกันครับ
จากที่เคยลองทำมา (+อ่านเพิ่มเติมมาในเน็ต) ผมอยากจะแนะนำท่าเหล่านี้
ใช้ตัวพิมพ์ใหญ่เมื่อขึ้นต้นประโยค แล้วตามด้วยพิมพ์เล็กทั้งหมด
เช่น
- Input
- Tag
- Highlight banner
แต่ถ้าเป็นคำเฉพาะ หรือตัวอักษร ก็พิมพ์เป็นตัวใหญ่ได้ครับ (อ่านง่าย)
- Card A
- Card B
- Google Maps
ถ้าเป็น component ที่เริ่มซับซ้อนขึ้น เราอาจจะ group มันตามหน้าที่ หรือ option ต่างๆ เช่น
ถ้ามีพวก component พื้นฐานที่ใช้บ่อยๆ เราอาจจะกรุ๊ปเป็นประเภทเดียวกัน เช่น
- Foundation / Input
- Foundation / Text
- Foundation / Toggle
หรือถ้ามี component ที่มี option เยอะๆเราอาจจะตั้งเป็น
- Card / Card A
- Card / Card B
ถ้ายังคิดไม่ออกว่าจะกรุ๊ปยังไง ก็อย่าไปคิดมากครับ ลองทำออกมาเป็นตัวเดี่ยวไปก่อนแล้วค่อย evolve ภายหลังก็ได้
เช่น
ตอนแรกมี Card แค่แบบเดียว → เราสร้าง component ชื่อการ์ดขึ้นมาชื่อว่า “Card”
เวลาผ่านไป Card แบบใหม่เพิ่มขึ้นมา เราก็
- แก้ component เดิมจาก “Card” เป็น “Card / Card A”
- เพิ่ม component ใหม่อีกตัวชื่อ “Card / Card B”
** เน้นว่าอย่าลืมใส่ space ไปรอบๆ “/” ด้วย เพราะทำให้อ่านง่ายขึ้นมากเลย
- ✅ Card / Card A
- ❌ Card/Card A
✏️ Key idea 2: การใส่ description และ URL ของ component → ทำให้ component ถูกหาเจอง่ายขึ้น และ ถูกนำไปใช้ถูกจุดประสงค์ขึ้น
Description และ URL เป็นสิ่งที่มีประโยชน์มากๆแต่คนไม่ค่อยใส่กันครับ
การใส่ข้อมูลใน Description
Description เป็นพื้นที่ให้เราใส่ข้อมูลต่างๆเกี่ยวกับ component → โดยที่ข้อมูลเหล่านี้จะถูกค้นหาเมื่อเราทำการ search component ด้วย
ดังนั้นเราควรจะ
- ใส่คำอธิบายสั้นๆเกี่ยวกับ component → ให้ข้อมูลเพิ่มเติม
- ใส่ข้อมูลสั้นๆว่า ถูกใช้ที่หน้าไหนบ้าง (ใช้ตัวพิมพ์เล็กทั้งหมด – ถ้าไม่ใช่คำเฉพาะ) → ให้ข้อมูลเพิ่มเติม
- ใส่ keyword อื่นๆ (ใช้ตัวพิมพ์เล็กทั้งหมด – ถ้าไม่ใช่คำเฉพาะ) → ให้ search เจอ component ง่ายขึ้น
ตัวอย่าง
Component name:
- Foundation / Input
Description:
- Main component for getting data from users
- Used on: home page, contact page
- Keywords: text field, text box
จากตัวอย่างข้างต้น ถ้าคนค้นหาด้วยคำว่า `text field` ก็จะเจอ component นี้ แม้ว่าชื่อของ component จะเป็น `Foundation / Input` ก็ตาม
การใส่ข้อมูลใน URL
URL เป็นพื้นที่ให้เราใส่ link ต่างๆที่อยู่นอก Figma เพื่อให้คนกดไปอ่านเมื่ออยากได้ข้อมูลเพิ่มเติม
ดังนั้นหากเรามี design system document อยู่แล้ว ก็ใส่ไปตรงนี้ได้เลยครับ
…
🤩 มาดูกันว่า พอตั้งค่าเสร็จแล้วใช้ง่ายขึ้นยังไงบ้าง
เวลาเอามาวางข้างกันก็อ่านง่ายสบายตา
เวลาหา Assets ก็จะดูง่ายว่าอะไรอยู่ตรงไหน เพราะว่ามีการจัดกลุ่มที่ชัดเจน
หาด้วย keyword ได้ แม้จะไม่ตรงกับชื่อของ component
มีข้อมูลสำคัญๆใน description ให้อ่าน จะได้นำไปได้แบบไม่งง
ถ้าสงสัย? มีเอกสารแนบให้กดไปดูภาพเติม
⛰️ หนทางการจัดการ component library ให้ดีนั้น ยังอีกยาวไกล
ยังมีหลายๆอย่างที่เราสามารถทำได้ เพื่อให้ library ของเรา effective ขึ้นครับ
ยกตัวอย่างเช่น
- การตั้งชื่อ Layer ให้ดี เพื่อที่จะง่ายแก่การ maintain และสื่อสารกับ developer
- การทำ document สำหรับ onboarding เมื่อคนมาเริ่มใช้ library ของเรา
- การทำหน้ารวม Component library (อาจจะจัดกลุ่มตาม Journey ก็ได้)
- การคอยรีวิว component บ่อยๆกับทีม หรือพูดถึงกันบ่อยๆ
- การทำ Slack bot ที่คอยแนะนำ component ต่างๆให้กับทีมเป็นระยะๆ
สิ่งที่แนะนำให้ทำในบความนี้เป็นแค่จุดเริ่มต้นเล็กๆ ถ้าเอาไปลองใช้แล้วไม่เวิร์ค ลองปรับเปลี่ยนให้เหมาะกับทีมดูนะครับ!
💎 สรุป
- การใส่ใจในการตั้งชื่อและใส่ข้อมูลต่างให้กับ component ทำให้ใช้งานได้มีประสิทธิภาพมากขึ้น
- ควรตั้งมาตรฐานในการจัดการ component ของทีมให้ชัดเจน (ทุกคนต้องทำเหมือนกัน)
- ตั้งชื่อด้วยรูปแบบ `Component group / Component name` → จะได้อ่านง่าย และมีการจัดกลุ่มที่ชัดเจน
- ใส่ keywords (คำที่คนอาจจะ search) ไปใน description → จะได้ search เจอง่าย
- ใส่คำอธิบายการใช้งาน (ใช้เมื่อไร ที่หน้าไหน) → จะได้นำไปใช้ได้ถูกต้อง
- ใส่ URL ของ exernal document ไว้ให้ด้วย → จะได้มีข้อมูลละเอียดๆไว้ให้ดูเพิ่ม
- การตั้งชื่อเป็นจุดเริ่มต้นเท่านั้น ยังมีอีกหลายอย่างที่ทีมสามารถทำได้
