Design system คืออะไรกันแน่
หลายคนเข้าใจว่า design system คือไฟล์ Figma ที่รวมปุ่มกับช่องกรอกข้อมูล จริงๆ แล้วนั่นเป็นแค่ส่วนที่มองเห็นง่ายที่สุด Design system คือชุดข้อตกลงที่ทั้งดีไซเนอร์และนักพัฒนาใช้ร่วมกัน ว่าสี ตัวอักษร ระยะห่าง และพฤติกรรมของหน้าจอควรเป็นอย่างไร พร้อมของจริงที่หยิบไปใช้ได้ทั้งในดีไซน์และในโค้ด
ลองนึกถึงภาษาของทีม ถ้าทุกคนใช้คำว่า "ปุ่มหลัก" แล้วหมายถึงสิ่งเดียวกัน การคุยงานจะเร็วขึ้นมาก ไม่ต้องไล่ถามว่าเฉดไหน ขอบมนเท่าไร Design system ทำหน้าที่เป็นพจนานุกรมของภาษานั้น
ระบบที่ดีไม่ได้ทำให้ทุกหน้าเหมือนกัน แต่ทำให้ความต่างเกิดขึ้นเพราะตั้งใจ ไม่ใช่เพราะบังเอิญ
องค์ประกอบหลัก 4 ส่วน
Design system ที่ใช้งานได้จริงมักมีสี่ชั้นซ้อนกัน ชั้นล่างสุดคือ design token ซึ่งเป็นค่าพื้นฐานที่ตั้งชื่อไว้ เช่น สีหลัก ขนาดตัวอักษร ระยะห่าง และความโค้งของมุม ชั้นถัดมาคือ component เช่น ปุ่ม ช่องกรอก และการ์ด ที่ประกอบจาก token
ชั้นที่สามคือ pattern หรือแบบแผนการใช้งาน เช่น หน้าฟอร์มสมัครสมาชิก การแสดง error หรือหน้าว่างที่ยังไม่มีข้อมูล ซึ่งบอกว่าจะเอา component หลายตัวมาประกอบกันอย่างไรในสถานการณ์ที่พบบ่อย ชั้นสุดท้ายคือเอกสาร ที่บอกว่าเมื่อไรควรใช้ เมื่อไรไม่ควรใช้ และตัวอย่างที่ถูกต้อง
- Token: สี ตัวอักษร ระยะห่าง เงา และมุมโค้ง ตั้งชื่อตามหน้าที่ เช่น "สีพื้นหลังหลัก" แทนที่จะเป็น "เทา 200"
- Component: ปุ่ม ช่องกรอก dropdown โมดัล พร้อมสถานะครบ ทั้งปกติ hover focus ปิดใช้งาน และ error
- Pattern: วิธีประกอบ component สำหรับงานที่พบซ้ำ เช่น ฟอร์ม ตาราง การค้นหา
- เอกสาร: หลักการใช้ ตัวอย่างที่ถูกและผิด และแนวทางด้านการเข้าถึง
ทำไมทีมที่โตขึ้นถึงเริ่มรู้สึกว่าขาด
สัญญาณที่พบบ่อยคือดีไซเนอร์ใช้เวลากับการวาดปุ่มและฟอร์มซ้ำๆ มากกว่าการคิดแก้ปัญหาผู้ใช้ นักพัฒนาก็เขียนโค้ดปุ่มใหม่ทุกครั้งที่ทำฟีเจอร์ใหม่ เพราะไม่แน่ใจว่าของเดิมอยู่ตรงไหน เมื่อเวลาผ่านไป หน้าจอจะเริ่มไม่ตรงกันและการแก้ทีละจุดก็เหนื่อยขึ้นเรื่อยๆ
ประโยชน์ที่ทีมมักรู้สึกได้เป็นเชิงคุณภาพมากกว่าตัวเลข คือ ส่งมอบงานระหว่างดีไซน์กับโค้ดสะดวกขึ้น คนใหม่เข้าใจงานได้เร็วขึ้น การรีวิวคุยกันเรื่องปัญหาผู้ใช้แทนที่จะเถียงเรื่องเฉดสี และเมื่อต้องการเปลี่ยนแบรนด์หรือเพิ่มโหมดมืด การแก้ที่ token ครั้งเดียวก็ไหลไปทุกหน้า
อีกข้อที่คนมักมองข้ามคือเรื่องการเข้าถึง ถ้า component ปุ่มหนึ่งตัวผ่านเกณฑ์คอนทราสต์และรองรับคีย์บอร์ดแล้ว ทุกหน้าที่ใช้ปุ่มนั้นก็ได้ประโยชน์ไปด้วย
เริ่มทำใน 5 ขั้นตอน
ข้อผิดพลาดที่พบบ่อยคือพยายามสร้างระบบสมบูรณ์แบบก่อนใช้งานจริง ซึ่งมักใช้เวลานานจนทีมหมดแรง วิธีที่ได้ผลกว่าคือค่อยๆ สกัดระบบออกมาจากงานที่ทำอยู่ แล้วขยายตามความต้องการจริง
ลำดับด้านล่างเหมาะกับทีมขนาดเล็กถึงกลาง และทำคู่ไปกับงานฟีเจอร์ปกติได้ ไม่ต้องหยุดโปรเจกต์
- ขั้นที่ 1 ตรวจของที่มีอยู่: จับภาพหน้าจอทุกหน้าหลัก แล้วจัดกลุ่มปุ่ม สี และตัวอักษรที่ซ้ำหรือเกือบซ้ำกัน จะเห็นทันทีว่าความไม่สม่ำเสมอเกิดตรงไหน
- ขั้นที่ 2 กำหนด token พื้นฐาน: เลือกชุดสี ขนาดตัวอักษร และระยะห่างที่จะใช้จริง ตั้งชื่อตามหน้าที่ แล้วเก็บเป็นตัวแปรทั้งในดีไซน์และโค้ด
- ขั้นที่ 3 ทำ component ที่ใช้บ่อยที่สุดก่อน: มักเป็นปุ่ม ช่องกรอก และการ์ด ทำให้ครบทุกสถานะและทดสอบกับคีย์บอร์ดตั้งแต่แรก
- ขั้นที่ 4 เขียนเอกสารสั้นๆ: บอกว่าใช้เมื่อไร ห้ามใช้เมื่อไร พร้อมตัวอย่าง เอกสารสั้นที่คนอ่านดีกว่าเอกสารยาวที่ไม่มีใครเปิด
- ขั้นที่ 5 ตั้งเจ้าของและกระบวนการปรับปรุง: ระบุว่าใครรับคำขอเพิ่ม component และตกลงกันว่าถ้าใครต้องการของใหม่ จะเสนอเข้าระบบอย่างไร
ข้อควรระวังและเรื่องภาษาไทย
Design system ต้องมีคนดูแล ถ้าไม่มีเจ้าของ มันจะค่อยๆ ล้าสมัยจนทีมกลับไปทำเองเหมือนเดิม และอย่ากำหนดกฎเข้มจนทีมรู้สึกว่าสร้างสรรค์อะไรไม่ได้ ควรเปิดช่องให้มีข้อยกเว้นที่มีเหตุผล แล้วย้อนกลับมาดูว่าข้อยกเว้นไหนควรกลายเป็นส่วนหนึ่งของระบบ
สำหรับผลิตภัณฑ์ที่ใช้ภาษาไทย ควรใส่เรื่องตัวอักษรไทยเข้าไปใน token ตั้งแต่ต้น เช่น ระยะบรรทัดที่เผื่อสระและวรรณยุกต์ และการทดสอบ component กับข้อความไทยที่ยาวจริง ไม่ใช่แค่ข้อความตัวอย่างภาษาอังกฤษ
สรุปสั้น ๆ
- Design system คือข้อตกลงร่วมของดีไซเนอร์และนักพัฒนา ไม่ใช่แค่ไฟล์ UI kit
- มี 4 ส่วนหลัก: token, component, pattern และเอกสาร
- เริ่มจากการสกัดจากงานที่มีอยู่ ไม่ต้องรอระบบสมบูรณ์แบบ
- ต้องมีเจ้าของและกระบวนการปรับปรุง ไม่อย่างนั้นระบบจะล้าสมัยเร็ว
- ใส่เรื่องการเข้าถึงและตัวอักษรไทยลงใน component ตั้งแต่ต้น จะได้ประโยชน์ทุกหน้า
คำถามที่พบบ่อย
บริการที่เกี่ยวข้อง
มีโปรเจกต์แบบนี้อยู่ในใจไหม
เล่าให้เราฟังว่าตอนนี้อยู่ตรงไหน เดี๋ยวเราแนะนำก้าวแรกที่เหมาะให้ โดยไม่มีข้อผูกมัด
คุยกับเรา
