Design tokens ในเครื่องมือ UI แบบ no-code เพื่อธีมที่สม่ำเสมอ

ทำไมทีมมักมี UI ที่ไม่สอดคล้อง\n\nUI ที่ไม่สม่ำเสมอมักไม่เริ่มจาก "ปัญหาดีไซน์" แต่เริ่มจากปัญหาเวลา ใครบางคนต้องการปุ่มตอนนี้ จึงคัดลอกจากหน้าหนึ่งแล้วปรับเล็กน้อยให้พอใช้ได้\n\nนั่นคือที่มาของความต่างเล็กๆ: สีน้ำเงินสองตัวที่เกือบเหมือนกัน รัศมีมุมจาก 6 เป็น 8 ตัวพาดหัวที่ดู “ค่อนข้างหนา” และช่องวางที่ขึ้นอยู่กับคนสร้างหน้าจอ ในเครื่องมือ no-code ยิ่งง่ายที่จะทำการแก้ไขครั้งเดียว เพราะคอนโทรลอยู่ตรงหน้าและการเปลี่ยนแปลงดูเหมือนไม่เป็นอันตราย\n\nเมื่อผลิตภัณฑ์เติบโต การ drift เร่งขึ้น หน้ามากขึ้นหมายถึงรูปแบบที่ซ้ำกันมากขึ้น ผู้สร้างมากขึ้นหมายถึงรสนิยมส่วนตัวมากขึ้น และเพื่อนร่วมทีมมากขึ้นหมายถึงการแก้ปัญหาแบบ "ด่วน" ที่ทำแยกกัน หากคนหนึ่งสร้างพอร์ทัลลูกค้าและอีกคนสร้างแผงแอดมิน จะได้การตีความแบรนด์คนละแบบ\n\nการ “ตัดสินด้วยสายตา” ปรากฏในงานประจำวัน: เลือกสีจนมัน “ดูถูกต้อง” ขยับ spacing ไปไม่กี่พิกเซลเพราะหน้าจอรู้สึก “อึดอัด” สร้างสไตล์ปุ่มใหม่แทนการใช้แบบที่มีอยู่ ผสมขนาดฟอนต์เพราะค่าดีฟอลต์ “เล็กไปหน่อย” หรือแก้หน้าจอหนึ่งโดยไม่เช็กที่เหลือ\n\nค่าใช้จ่ายจะปรากฏทีหลัง การรีวิวช้าลงเพราะคำติชมกลายเป็นเชิงความเห็น (“ให้รู้สึกเหมือนหน้าที่แล้ว”) งานแก้ซ้ำเพิ่มขึ้นเพราะการเปลี่ยนยากจะทำให้ทั่วทั้งระบบ เว็บกับมือถือแตกต่างกันเพราะคนต่างกันทำทางเลือกที่คล้ายกันแต่ไม่เหมือนกัน\n\nDesign tokens แก้ปัญหานี้ด้วยการแทนที่การตัดสินใจแบบ “พอได้” ด้วยค่าที่แชร์ร่วมกัน UI จะคงที่แม้ทีมและแอปจะขยายตัว\n\n## Design tokens แบบเข้าใจง่าย\n\nDesign tokens คือการตั้งชื่อการตัดสินใจด้าน UI แทนที่จะบอกว่า “ใช้สีน้ำเงินนี้” หรือ “ทำให้ปุ่มดูกว้าง” คุณให้ชื่อนั้นที่ใครก็ใช้ซ้ำได้\n\nโทเคนไม่ใช่ค่าดิบ ค่าดิบอาจเป็น 16px, #2563EB, หรือ 600 (น้ำหนักฟอนต์) ส่วนโทเคนคือป้ายที่อธิบายความหมายของค่านั้นในผลิตภัณฑ์ เช่น space-4, color-primary, หรือ font-weight-semibold\n\nการเปลี่ยนมุมมองนี้หยุดปัญหาการตัดสินด้วยสายตา เมื่อคนเลือกค่าด้วยความรู้สึก คุณจะสะสมสีน้ำเงินห้าตัว ข้อความหัวข้อที่ต่างกันสามแบบ และ spacing ที่เปลี่ยนไปตามหน้าจอ\n\nโทเคนทำงานได้ดีที่สุดเมื่อเป็นแหล่งความจริงเดียว หากทุกหน้าจอและคอมโพเนนต์อ้างอิงชุดชื่อเดียวกัน คุณสามารถเปลี่ยนรูปลักษณ์ทั่วทั้งแอปได้ด้วยการอัปเดตค่าบางโทเคน ไม่ใช่การไล่ค้นหน้าจอกว่าร้อยหน้า\n\nโทเคนยังเชื่อมดีไซน์กับการสร้างงาน ดีไซเนอร์ใช้ชื่อโทเคนในสเปก และผู้สร้างใน no-code UI builder ก็ใช้ชื่อนั้นเช่นกัน ทำให้ดีไซน์รอดจากการส่งมอบ\n\nชุดโทเคนส่วนใหญ่แบ่งเป็นหมวดหมู่ไม่กี่อย่าง: บทบาทสี (primary, background, text, danger), แบบอักษร (ฟอนต์ ขนาด น้ำหนัก ระยะบรรทัด), ขั้นบันไดของ spacing (padding, margin, gap), รูปร่างและความลึก (radius, ขอบ, เงา) และบางครั้ง motion (ระยะเวลาและ easing)\n\n## ชุดโทเคนที่ผลิตภัณฑ์ส่วนใหญ่ต้องการจริงๆ\n\nทีมส่วนมากไม่ต้องการไลบรารีโทเคนขนาดใหญ่ พวกเขาต้องการชุดเล็กชัดเจนที่ครอบคลุมหน้าจอส่วนใหญ่เพื่อหยุดการเดาค่า เรื่องนี้สำคัญยิ่งขึ้นในเครื่องมือ no-code ที่การแก้ไข "แค่ครั้งเดียว" กระจายอย่างรวดเร็ว\n\nชุดเริ่มต้นที่ใช้งานได้จริงครอบคลุมห้ากลุ่ม:\n\n- สี: บทบาทแบรนด์ไม่กี่ตัว (primary, secondary), ชุดสีกลาง (text, background, border), และบทบาทสถานะ (success, warning, error). เพิ่มบทบาท hover และ disabled หากใช้บ่อย\n- แบบอักษร: ฟอนต์หนึ่งตัว (สองตัวสูงสุด), สเกลขนาดเล็ก (เช่น 12/14/16/20/24/32), น้ำหนักที่ใช้จริง, และระยะบรรทัดที่สอดคล้องกัน\n- spacing: บันไดง่าย ๆ (เช่น 4/8/12/16/24/32) สำหรับ padding และ gap\n- รูปทรงและเอฟเฟกต์: รัศมีไม่กี่ค่า (none/sm/md/lg), ความกว้างขอบ, และชุดเงาเล็กๆ (0–3)\n- การเคลื่อนไหว (ไม่บังคับ): ถ้าแอปใช้อนิเมชัน ให้มี 2–3 ระยะเวลาและ 1–2 ชื่อ easing\n\nกฎหนึ่งทำให้ไลบรารีจัดการได้: ถ้าค่าปรากฏในสามที่หรือมากกว่า ให้ทำเป็นโทเคน ถ้าปรากฏครั้งเดียว ให้พิจารณาก่อนจะปล่อยให้กลายเป็นมาตรฐานใหม่\n\n## กฎการตั้งชื่อที่ป้องกันความยุ่งเหยิงของโทเคน\n\nชื่อโทเคนที่ดีป้องกันการโต้แย้งก่อนจะเกิดขึ้น หากคนสามารถเดาชื่อโทเคนโดยไม่ต้องค้นหา พวกเขาจะใช้ซ้ำ ถ้าทำไม่ได้ พวกเขาจะสร้างใหม่ และธีมของคุณจะแยกออก\n\n### ใช้ชื่อเชิงความหมายก่อน (ไม่ใช่สี)\n\nให้ชื่อตั้งตามงานที่ค่านั้นทำใน UI แทนที่จะบอกว่ามันดูอย่างไร text-primary บอกว่าควรใช้เมื่อไหร่ ในขณะที่ blue-600 แค่บอกสี\n\nรูปแบบที่เป็นประโยชน์คือสองชั้น:\n\n- Base tokens: บล็อกพื้นฐาน เช่น color-blue-600, space-16, font-14\n- Semantic tokens: บทบาท UI เช่น text-primary, bg-surface, border-muted\n\nใน no-code UI builder, semantic tokens คือสิ่งที่ช่วยให้คนที่ไม่ใช่ดีไซเนอร์เลือกค่าได้เร็วโดยไม่ต้องเดาด้วยสายตา\n\n### กฎการเพิ่มโทเคนใหม่\n\nไลบรารีโทเคนมักยุ่งเพราะการสร้าง "ใหม่" กลายเป็นค่าเริ่มต้น ให้การ "ใช้ซ้ำ" เป็นค่าเริ่มต้น\n\nเก็บกฎให้ง่าย:\n\n- เพิ่มโทเคนเมื่อมันถูกใช้ใน 2+ ที่ หรือรองรับสถานะจริง (hover, disabled, error)\n- ถ้าเป็นหนึ่งครั้ง ให้เก็บไว้ท้องถิ่นกับคอมโพเนนต์\n- ถ้าโทเคนสองตัวต่างกันเพียงเล็กน้อย ให้เลือกตัวเดียวแล้วลบอีกตัว\n- ถ้าคุณอธิบายจุดประสงค์โทเคนไม่ได้ในประโยคเดียว ไม่ต้องเพิ่ม\n\nจากนั้นมาตรฐานการตั้งชื่อ: เลือกรูปแบบตัวสะกดหนึ่งแบบ (kebab-case ใช้งานได้ดี), ใช้ prefix คงที่ (text-, bg-, border-, icon-, space-), และให้สเกลตัวเลขสอดคล้อง (space-4, space-8, space-12, space-16)\n\n## ขั้นตอนทีละขั้น: กำหนดโทเคนจากสิ่งที่คุณใช้อยู่แล้ว\n\nถือ UI ปัจจุบันของคุณเป็นหลักฐาน ก่อนจะสร้างอะไรใหม่ ให้ทำ inventory สั้นๆ: รวบรวมสกรีนช็อต ตรวจสอบสไตล์ และจดค่าทุกค่าสี ขนาดฟอนต์ และ spacing ที่เห็นจริงในโปรดักชัน (รวมค่า "ครั้งเดียว" ด้วย)\n\nต่อมา ลดความซ้ำโดยตั้งใจ คุณมักจะพบสีเทาเดียวกันในหลายค่า hex ที่ต่างกันเล็กน้อย หรือ spacing ที่กระโดดระหว่าง 14, 15, 16 เลือกค่าหนึ่งค่าที่จะเก็บไว้ แล้วแม็ปค่าที่เก่าไปยังค่านั้น นี่คือที่โทเคนมีประโยชน์: คุณหยุดถกเถียงเรื่องรสนิยมและเริ่มตกลงชุดตัวเลือกเล็กๆ ที่ใช้ร่วมกัน\n\nเวอร์ชันแรกที่แข็งแรงทำได้ในการผ่านเดียว:\n\n- โทเคนพาเลต: สีดิบ (แบรนด์, neutrals, สีสถานะ)\n- โทเคนเชิงความหมาย: สีที่มีความหมายในการใช้งาน (text, background, border, success, warning)\n- สเกลแบบอักษร: 6–8 ขนาดที่มีบทบาทชัดเจน (body, label, H1–H3)\n- สเกล spacing: 6–10 ขั้นที่ใช้ซ้ำได้ทุกที่\n- พื้นฐานคอมโพเนนต์: รัศมีและเงามาตรฐานไม่กี่ค่า\n\nสำหรับแต่ละโทเคน ให้เพิ่มคำแนะนำสั้นๆ หนึ่งประโยค: ใช้ที่ไหนและไม่ควรใช้ที่ไหน ตัวอย่าง: “text-muted ใช้กับข้อความช่วยเหลือ ไม่ใช่ปุ่มหลัก”\n\nสุดท้าย กำหนดความเป็นเจ้าของ ชื่อคนหนึ่งหรือทีมเล็กๆ ให้อนุมัติการเปลี่ยน โดยกฎง่ายๆ: “เพิ่มโทเคนใหม่เมื่อโทเคนที่มีอยู่ไม่สามารถใช้ได้” นี่ช่วยให้ระบบคงที่เมื่อผลิตภัณฑ์เติบโต\n\n## วิธีนำโทเคนไปใช้ใน no-code UI builder\n\nเริ่มจากดีฟอลต์ที่ทุกหน้าจอจะสืบทอด: สไตล์ตัวอักษรเบส (ฟอนต์, ขนาด, line height, สี), สไตล์หัวเรื่อง (H1–H3), และกฎ spacing พื้นฐานเล็กๆ เพื่อให้หน้าไม่รู้สึกกระจัดกระจาย\n\nถัดมา แม็ปโทเคนไปยังสิ่งที่เครื่องมือเรียกว่าการตั้งค่าธีม: ตัวแปรธีม, global styles, style presets หรือ design system settings เป้าหมายคือการเลือก “Primary” หรือ “Space/16” จะเลือกโทเคน ไม่ใช่ค่าหนึ่งครั้ง\n\nเก็บสไตล์ที่ใช้ซ้ำไว้เน้นลายแพทเทิร์นที่ใช้ทุกวัน ชุดเริ่มต้นอาจรวมสไตล์การ์ด (background, border, radius, padding, shadow), สไตล์ฟิลด์ฟอร์ม (label, input, help text), สไตล์ปุ่ม และความหนาแน่นแถวตารางและสถานะ hover\n\nสถานะเป็นที่ที่ความไม่สอดคล้องแอบแฝง ดังนั้นกำหนดพวกมันตั้งแต่ต้น แต่ละคอมโพเนนต์เชิงโต้ตอบควรมีค่าที่ขับเคลื่อนด้วยโทเคนสำหรับ hover, focus, disabled และ error. focus ควรใช้สีวงแหวนและความหนาเดียวกันทุกที่. error ควรใช้คู่สี border และ text เดียวกัน\n\nสุดท้าย วางแผนการแชร์ หาก workspace ของคุณรองรับเทมเพลตหรือโมดูลที่ใช้ซ้ำ ให้วางโทเคนและสไตล์เบสใน “starter app” ให้โปรเจกต์ใหม่คัดลอกมา เพื่อหน้าจอใหม่เริ่มสอดคล้องโดยดีฟอลต์\n\n## ตัวแปรคอมโพเนนต์ที่คงที่\n\nVariants คือจุดที่ระบบ UI จะกลายเป็นสงบและคาดเดาได้ หรือล้มเป็นกองของการแก้ไขครั้งเดียว Variants ทำงานได้ดีเมื่อเป็นเลเยอร์บางๆ ที่แม็ปไปยังโทเคนสำหรับสี แบบอักษร และ spacing\n\nเริ่มจากคอมโพเนนต์สำคัญที่ใช้ทั่วไป: ปุ่ม, อินพุต, แบ็ดจ์, อัลเลิร์ต และการ์ด ให้แต่ละคอมโพเนนต์มีสองมิติของการเลือก: ขนาด และ ความหมาย/เจตนา Size ควรเป็นเชิงกลไก (ฟอนต์และ spacing). Intent ควรเป็นเชิงความหมาย (สีเชิง semantic)\n\n### ขนาดและเจตนาโดยไม่ต้องเดา\n\nขนาดจะคงที่เมื่อเปลี่ยนแค่คุณสมบัติตามโทเคนไม่กี่อย่าง: ขนาดฟอนต์, padding, และ border radius. Intent ควรเปลี่ยนบทบาทสีเชิง semantic (background, text, border) และไม่เปลี่ยน spacing แบบเงียบๆ\n\nชุดที่ครอบคลุมส่วนใหญ่ของผลิตภัณฑ์:\n\n- ขนาด: sm, md, lg\n- เจตนา: primary, secondary, danger\n- สถานะ: default, hover, focus, disabled\n\n### กฎการโต้ตอบที่ทีมควรปฏิบัติ\n\nกำหนดกฎสถานะที่ใช้กับทุกคอมโพเนนต์ ไม่ใช่แค่ปุ่ม เช่น: focus แสดงวงแหวนที่มองเห็นได้เสมอ, hover เพิ่มคอนทราสต์ในแบบเดียวกันทั่วทั้งระบบ, disabled ใช้ออพาซิตี้และบล็อกคลิกแบบเดียวกัน\n\nเพิ่ม variant ใหม่เมื่อมันแสดงความหมายที่เกิดซ้ำจริง (เช่น “danger”). ถ้าเป็นความต้องการเลย์เอาต์ครั้งเดียว มันมักเป็นคอมโพเนนต์ใหม่หรือ wrapper ไม่ใช่ variant ที่ทุกคนจะใช้ผิดในภายหลัง\n\n## รักษาธีมเว็บและมือถือให้สอดคล้อง\n\nเมื่อผลิตภัณฑ์ออกบนเว็บและมือถือ “แบรนด์เดียวกัน” ไม่ได้แปลว่า “พิกเซลเหมือนกัน” เป้าหมายคือทำให้หน้าจอรู้สึกเป็นครอบครัวเดียวกัน แม้แพลตฟอร์มจะมีดีฟอลต์ต่างกัน\n\nเริ่มจากโทเคนเชิงความหมายที่ขนย้ายได้ดี: บทบาทสี (background, surface, text, primary, danger), สเกลแบบอักษร (ขนาดและน้ำหนัก), และโทเคน spacing (4, 8, 12, 16, 24). สิ่งเหล่านี้จะลดการเดาและทำให้อัปเดตคาดเดาได้\n\nจากนั้นยอมรับความต่างที่แท้จริง มือถือต้องการ touch target ที่ใหญ่กว่าและมัก spacing มากกว่า เว็บต้องการตารางหนาแน่น sidebars และเลย์เอาต์หลายคอลัมน์ ฟอนต์อาจต่างกันด้วย: อาจใช้ฟอนต์แบรนด์บนเว็บ แต่เลือกฟอนต์แพลตฟอร์มบน iOS/Android เพื่อความอ่านง่ายและประสิทธิภาพ\n\nแนวทางปฏิบัติเป็นสองชั้น: โทเคนระดับโลกที่กำหนดความหมาย และโทเคนเฉพาะแพลตฟอร์มที่กำหนดการเรนเดอร์ความหมายนั้น\n\n- Global: color.text, color.primary, space.md, radius.sm, type.body\n- Web-only: type.family.web, control.height.web, space.tableRow\n- Mobile-only: type.family.mobile, control.height.mobile, space.touch\n\nรักษาชื่อคอมโพเนนต์ให้ตรงกัน (Button/Primary) แม้ขนาดจะแตกต่างกัน บังคับให้ตรวจสอบความคอนทราสต์ทั้งสองธีมก่อนปล่อย\n\n## Governance: ทำอย่างไรให้โทเคนแข็งแรงระยะยาว\n\nโทเคนจะทำงานได้เมื่อมันคงที่และเข้าใจง่าย หากไม่มีการกำกับดูแลแบบเบา ทีมจะค่อยๆ เพิ่ม “สีน้ำเงินอีกหนึ่งตัว” หรือ “padding อีกหนึ่งค่า” และคุณกลับไปที่การตัดสินด้วยสายตา\n\n### กระบวนการเปลี่ยนโทเคนแบบเบาๆ\n\nรักษากระบวนการให้เล็กแต่น่าเชื่อถือ:\n\n- ขอ: ใครก็ขอเพิ่มหรือเปลี่ยนโทเคนได้ โดยแนบสกรีนช็อตและเหตุผล\n- ตรวจ: ดีไซเนอร์หนึ่งคนและผู้สร้างหนึ่งคนตรวจผลกระทบข้ามหน้าจอหลัก\n- อนุมัติ: ยืนยันการตั้งชื่อ การเข้าถึง (contrast, tap size) และว่ามันเป็นของใหม่จริงหรือไม่\n- ปล่อย: เผยแพร่การอัปเดตเป็นรอบ (รายสัปดาห์หรือทุกสปรินต์) ไม่ใช่แบบ ad hoc\n- สื่อสาร: แจ้งว่ามีการเปลี่ยนอะไรและควรใช้ตัวไหนแทน\n\nรักษา changelog ง่ายๆ พร้อมการ deprecated หากโทเคนเก่ากำลังถูกแทน ให้บอกว่าควรใช้ตัวไหนแทน เก็บไว้ทำงานสักระยะ และติดป้ายให้ชัดเจนเพื่อไม่ให้หน้าจอใหม่หยิบไปใช้\n\nการ cleanup เป็นส่วนหนึ่งของงาน ทำทุกเดือนเพื่อลบโทเคนหรือ variant ที่ไม่ถูกใช้ (หรืออย่างน้อยก็ติดป้าย)\n\n### ทำให้โทเคนใช้งานได้สำหรับทุกคน\n\nคนที่ไม่ใช่ดีไซเนอร์ต้องการตัวอย่าง ไม่ใช่ทฤษฎี\n\nทำ: ใช้บันได spacing สำหรับช่องว่าง และใช้ Primary Button variant สำหรับการกระทำหลัก\n\nอย่า: ตั้ง padding เป็น “13px เพราะมันดูถูกต้อง” หรือสร้างสไตล์ปุ่มใหม่เพื่อให้ตรงกับหน้าจอหนึ่งหน้า\n\nผูกงานโทเคนกับความสำคัญของสินค้า: ฟีเจอร์ใหม่, รีแบรนด์, และการปรับปรุงการเข้าถึง ควรเป็นตัวขับเคลื่อนการอัปเดตโทเคน ไม่ใช่รสนิยมส่วนบุคคล\n\n## ความผิดพลาดและกับดักที่พบบ่อย\n\nวิธีที่เร็วที่สุดจะสูญเสียประโยชน์ของโทเคนคือการใช้มันเป็นที่เก็บขยะ เริ่มด้วยเจตนาดี แต่การแก้ไขด่วนสะสม ทีมก็กลับไปตัดสินด้วยสายตาอีกครั้ง\n\nกับดักทั่วไปคือสร้างโทเคนมากเกินไปตั้งแต่ต้น หากทุกหน้าจอมีโทเคนสีหรือ spacing ของตัวเอง คุณไม่ได้สร้างระบบ แต่แค่บันทึกข้อยกเว้นเท่านั้น เพิ่มโทเคนใหม่ก็ต่อเมื่อคุณชี้ให้เห็นสองที่ที่จะใช้มัน\n\nปัญหาเงียบๆ อีกอย่างคือปล่อยค่าดิบหลุดเข้าไปในคอมโพเนนต์ ใครบางคนตั้ง padding ปุ่มเป็น 14px “แค่ครั้งนี้” หรือใช้สี hex โดยตรงในการ์ด สัปดาห์ต่อมา ไม่มีใครจำได้ว่าทำไมมันต่าง ทำให้เป็นนิสัย: ถ้ามันมองเห็นได้และทำซ้ำได้ มันควรเป็นโทเคน\n\nระวังการผสมประเภทโทเคนด้วย Base tokens (เช่น gray-900 หรือ space-4) อธิบายค่าดิบ ในขณะที่ Semantic tokens (เช่น text-primary หรือ surface-muted) อธิบายความหมาย ปัญหาเกิดเมื่อคอมโพเนนต์หนึ่งใช้ base token และอีกคอมโพเนนต์ใช้ semantic token สำหรับบทบาทเดียวกัน\n\nสถานะเป็นอีกปัญหาที่มาทีหลัง ทีมมักกำหนดสไตล์ปกติ แล้วแพตช์ focus, hover, disabled, error ก่อนปล่อย นั่นคือเหตุผลที่คุณพบวงแหวน focus ไม่สอดคล้องและสี error สามแบบ\n\nก่อนจะขยาย ขึ้นทำ trap check สั้นๆ:\n\n- จำกัดโทเคนใหม่ให้เป็นความต้องการร่วม ไม่ใช่หน้าจอครั้งเดียว\n- หลีกเลี่ยงค่านิยมดิบในคอมโพเนนต์เท่าที่จะทำได้\n- แยก base vs semantic tokens และใช้ให้สอดคล้องกัน\n- กำหนดสถานะ (focus, error, disabled) ตั้งแต่ต้น\n- เผื่อที่ว่างสำหรับโหมดมืดหรือรีแบรนด์ในอนาคตโดยการสลับ semantic tokens ไม่ใช่การเขียนคอมโพเนนต์ใหม่\n\n## เช็คลิสต์ด่วนก่อนขยายทีม\n\nก่อนจะขยาย UI ไปยังหน้าจอ ทีม หรือผลิตภัณฑ์อื่น ให้เช็กว่ารากฐานชัดพอที่คัดลอกได้โดยไม่ต้องเดา\n\n- บทบาทสีเป็นเชิงความหมาย. โทเคนครอบคลุม text (default, muted, inverse), surfaces (page, card), borders (default, focus), และสถานะ (success, warning, danger).\n- แบบอักษรแม็ปกับสเกลเล็ก. ชุดสไตล์ข้อความสั้นๆ (H1–H3, body, small) พร้อมขนาด น้ำหนัก และ line height กำหนดชัดเจน\n- spacing ใช้ขั้นที่จำง่าย. padding และ gap ทั่วไปมาจากบันไดแน่น (4, 8, 12, 16, 24). ถ้า “14” ปรากฏบ่อย แปลว่าบันไดของคุณต้องปรับ\n- คอมโพเนนต์หลักมี variants. คอมโพเนนต์ที่ใช้มากสุดมีขนาด (sm/md/lg) และเจตนา (primary/secondary/danger) ที่ตรงกับบทบาทโทเคน\n- ความเป็นเจ้าของชัดเจน. คนหนึ่งคนหรือทีมเล็กอนุมัติการเปลี่ยน ด้วยกิจวัตรน้ำหนักเบา: ทำไม, ผลกระทบ, และเมื่อไหร่จะปล่อย\n\n## ตัวอย่าง: หยุด UI drift ในพอร์ทัลและแผงแอดมิน\n\nทีมเล็กกำลังสร้างสองแอปพร้อมกัน: พอร์ทัลลูกค้าและแผงแอดมิน คนต่างกันแตะแตกต่างกันและสร้างอย่างรวดเร็วใน no-code UI builder หลังจากไม่กี่สัปดาห์ UI เริ่มรู้สึก "แปลก" แม้ไม่มีใครชี้ปัญหาเป็นข้อๆ\n\nก่อนมีโทเคน ความเห็นรีวิวสะสม: ปุ่มคล้ายกันแต่ไม่เท่ากัน spacing กระโดด ฟิลด์ฟอร์มไม่ตรง และพอร์ทัลรู้สึก "เป็นมิตร" ในขณะที่แผงแอดมินบังเอิญดู "เข้มงวด"\n\nพวกเขาแก้โดยแนะนำชุดโทเคนเล็กๆ ที่ใช้งานได้จริง กำหนดสีเชิงความหมาย (Primary, Success, Danger, TextMuted), สเกล spacing (4, 8, 12, 16, 24), และ variant ปุ่ม (Primary, Secondary, Ghost) พร้อมรัศมีเดียวและสถานะที่สอดคล้อง\n\nตอนนี้ผู้ร่วมงานหยุดเลือกค่า hex และขนาดฟอนต์แบบสุ่ม พวกเขาเลือกโทเคนและ variants ดังนั้นหน้าจอใหม่ทุกหน้าได้รับการตัดสินใจเดียวกันโดยค่าเริ่มต้น\n\nการสร้างเร็วขึ้นเพราะตัวเลือกถูกตัดสินแล้ว การรีวิวเปลี่ยนจากการแก้จุดเล็กๆ เป็นประเด็น UX จริง “เปลี่ยนปุ่มนี้เป็น variant primary” แทนที่จะเป็น “ช่วยทำให้มันสีน้ำเงินขึ้นแล้วสูงขึ้นหน่อยได้ไหม”\n\nแล้วเกิดรีแบรนด์เล็กๆ: สี primary เปลี่ยนและสเกลฟอนต์กระชับ ด้วยโทเคน ทีมอัปเดตค่าไม่กี่จุดครั้งเดียว ทั้งพอร์ทัลและแผงแอดมินก็รีเฟรชพร้อมกัน\n\n## ขั้นตอนถัดไป: เริ่มเล็ก แล้วมาตรฐานให้กว้างขึ้น\n\nเลือกฟลูว์หนึ่งที่คนใช้บ่อยและมี drift ชัดเจน เช่น onboarding, หน้าการตั้งค่า, หรือฟอร์มง่าย การแปลงฟลูว์เดียวคือวิธีที่เร็วที่สุดในการพิสูจน์แนวคิดและหยุดการตัดสินด้วยสายตา\n\nเริ่มด้วยชุดโทเคนปลอดภัยและเล็ก: primary/background/text/border/danger, สเกลแบบอักษรสั้น, บันได spacing, และรัศมีกับระดับเงา 2–3 ค่า แล้วสร้างชุดคอมโพเนนต์จิ๋วที่ใช้เฉพาะโทเคน: ปุ่มหนึ่งแบบ, อินพุตหนึ่งแบบ, การ์ดหนึ่งแบบ, อัลเลิร์ตหนึ่งแบบ เพิ่ม variants ก็ต่อเมื่อแก้ปัญหาจริง\n\nทำการรีวิวสั้นๆ กับทีมโดยใช้สกรีนช็อตสองภาพ: หน้าก่อนที่มี padding และฟอนต์ไม่สอดคล้อง กับหน้าหลังที่สร้างจากโทเคนและ variants ตกลงกฎสองสามข้อ (เช่น “ห้ามสี hard-coded” และ “spacing ต้องเป็นโทเคน”) และแก้จุดไม่สอดคล้องที่สำคัญก่อน\n\nสำหรับการปล่อย ให้แปลงหน้าจอใหม่ก่อน แล้วค่อยปรับหน้าจอเก่าตามที่คุณแก้ไข เมื่อฝ่ายซัพพอร์ตขอฟิลเตอร์แอดมินใหม่ ให้สร้างแผงนั้นด้วยคอมโพเนนต์พื้นฐานที่ใช้โทเคนและแทนที่เฉพาะสิ่งที่คุณแก้ไข\n\nถ้าคุณสร้างผลิตภัณฑ์ครบวงจร (backend, web, และ mobile) ใน AppMaster จะช่วยได้ถ้ากำหนดโทเคนและสไตล์ UI ที่ใช้ซ้ำตั้งแต่ต้น เพื่อหน้าจอใหม่สืบทอดการตัดสินใจเดียวกัน วิธีนี้ความสอดคล้องด้านภาพและตรรกะของแอปจะเดินหน้าไปพร้อมกันโดยไม่ต้องทำความสะอาดซ้ำทีหลัง\n