Design Tokens: كيف تحافظ أنظمة التصميم الحقيقية على الاتساق
ما هي Design Tokens، ونموذج الثلاث طبقات الذي تستخدمه الأنظمة الحقيقية (Shopify Polaris وIBM Carbon وGitHub Primer)، وكيفية تسميتها، والـ theming للوضع الداكن، ومتى تكون الـ tokens مبالغة.
Design Tokens: كيف تحافظ أنظمة التصميم الحقيقية على الاتساق
كود الألوان hex هو قيمة. الـ token هو قرار له اسم. أنظمة التصميم مبنية من قرارات، لا من قيم.
هذا الفارق هو جوهر الموضوع بأكمله. اكتب #0EA5E9 مباشرةً في أربعة عشر مكوناً في Figma، ثم يُطلب منك الوضع الداكن، وستجد نفسك أمام أسبوع من البحث والاستبدال. سمِّها color-interactive-primary وستغير قيمة واحدة فيما تُحدَّث كل الأسطح. هذا ليس سحراً، مجرد قرارات مسماة.
ما هو الـ design token فعلاً
الـ design token هو متغير مُسمى يُخزّن قرار تصميم. يمكنه استيعاب لون، أو قيمة مسافة، أو حجم خط، أو نصف قطر حدود، أو ظل، أو مدة زمنية. الاسم هو العقد. القيمة وراء الاسم يمكن أن تتغير دون كسر أي شيء يستخدم الـ token.
النهج الكلاسيكي بدون tokens يبدأ حين يختار المصمم #1D4ED8 للأزرار الأساسية، ويضعه مباشرة في مكون الزر، ثم ينسخ هذا الـ hex إلى البطاقة والشارة والرابط. بعد ستة أشهر، تتحدث الهوية البصرية. الآن أمامك مشكلة صيانة تكبر مع كل مكون شحنته.
الـ tokens تقلب المعادلة. تُسمّي القرار (color-action-default)، تُعيّن القيمة مرة واحدة، وكل شيء يُشير إلى الـ token يبقى متزامناً. القيمة هي تفصيل تقني. الاسم هو النظام.
الطبقات الثلاث التي تجعل الـ tokens تعمل
الـ tokens الخام مجرد متغيرات. ما يجعل نظام الـ tokens مفيداً فعلاً هو التسلسل الهرمي. كل نظام إنتاجي يستحق الدراسة يستخدم ثلاث طبقات.
| الطبقة | تُعرف أيضاً | ما تُخزّنه | مثال |
|---|---|---|---|
| البدائية | عامة، أساسية | قيم خام بلا معنى | color.blue.500 = #3B82F6 |
| الدلالية | مستعارة، الدور | أدوار مسماة مربوطة بالبدائيات | color.interactive.default = color.blue.500 |
| المكون | محددة | قرارات مرتبطة بمكون بعينه | button.background.default = color.interactive.default |
البدائيات هي لوحة الألوان. كل أزرق، وكل خطوة مسافة، وكل نصف قطر يعيش هنا كقيمة مُسماة بلا رأي حول أين تُستخدم. لا تستهلك البدائيات مباشرة في المكونات.
الـ tokens الدلالية تربط الأدوار بالبدائيات. الـ token color-surface-default قد يُشير إلى لون قريب من الأبيض في الوضع الفاتح وقريب من الأسود في الوضع الداكن، والمكون لا يعرف أبداً القيمة الخام التي يحصل عليها. يعرف الدور فقط.
الـ tokens على مستوى المكون هي الأكثر تحديداً. توجد حين يحتاج المكون قراراً مختلفاً متعمداً عن الافتراضي الدلالي. زر الخطر يُشير بخلفيته إلى دور التغذية الراجعة الحرجة بدلاً من الدور التفاعلي الافتراضي. معظم المكونات لا تحتاج tokens خاصة بها؛ تستهلك الـ tokens الدلالية مباشرة.
لماذا الـ tokens تتفوق على القيم المُشفّرة مباشرةً
سرعة التغيير هي الحجة الواضحة، لكنها ليست الحقيقية. الحجة الحقيقية هي الدقة.
حين يُسلّم مصمم ملفاً مليئاً بأكواد hex خام، لا يعرف المطور أيها مقصود وأيها عرضي. هل #1A1A2E هو الخلفية، أم أن أحدهم استخدم أداة قطارة اللون على الطبقة الخاطئة؟ الـ tokens تُزيل الغموض. اسم الـ token الدلالي هو توثيق يسير مع القيمة.
الـ tokens هي أيضاً عقد التسليم بين أدوات التصميم والكود في 2026. متغيرات Figma تُعيّن مباشرة على CSS custom properties. الـ token المُعرَّف في ملف Figma يمكن تصديره والتزام به واستهلاكه في الكود دون خطوة يدوية واحدة. تضيق الفجوة بين التصميم والتنفيذ حين يتحدث الطرفان بنفس أسماء الـ tokens.
للفرق التي تعمل على أعمال إمكانية الوصول، تُضيف الـ tokens طبقة أمان إضافية. تُراجع اللوحة الدلالية في مكان واحد وتضمن أن color-text-default يتجاوز دائماً تباين 4.5:1 مقابل color-surface-default، بصرف النظر عن الثيم النشط.
كيف تُهيكل أنظمة التصميم الحقيقية الـ tokens
ثلاثة أنظمة تستحق المعرفة: Shopify Polaris وIBM Carbon وGitHub Primer. تتعامل مع نموذج الثلاث طبقات بطرق مختلفة، والاختلافات تعليمية.
Shopify Polaris يحتفظ بالبدائيات في مقياس ألوان (color-sky-100 إلى color-sky-900) ويُعيّنها لأدوار دلالية مثل --p-color-bg-fill-active. الـ tokens على مستوى المكون نادرة، لذا معظم المكونات تستهلك الـ tokens الدلالية. الاصطلاح هو الدور-ثم-الحالة، وهو يُقرأ بشكل طبيعي في الكود، إذ تعرف ما bg-fill-disabled موجود لأجله دون سياق إضافي.
اطلع عليه مباشرةً على polaris.shopify.com
IBM Carbon يتعمق في الطبقات الدلالية. مجموعة الألوان تتضمن tokens للتغذية الراجعة الصريحة مثل support-error وsupport-success، وtokens لحالات التفاعل، وtokens للطبقات للأسطح المتداخلة (مكون على لوحة على صفحة، كل منها يحتاج قيمة سطح مختلفة). إنه أكثر تعقيداً، لكن IBM تُشحن برامج مؤسسية حيث كل حالة متداخلة مهمة.
اطلع عليه مباشرةً على carbondesignsystem.com
GitHub Primer يكشف طبقته البدائية باسم "primitives" وطبقته الدلالية باسم "functional tokens"، موثقة بشكل عام على primer.style. يتيح الـ theming في Primer لـ GitHub شحن الوضع الفاتح والداكن والتباين العالي الفاتح والداكن الخافت من مجموعة مكونات واحدة. كل ثيم هو تعيين قيم مختلف لنفس أسماء الـ tokens.
النمط عبر الأنظمة الثلاثة متسق: البدائيات كمقياس، والـ tokens الدلالية كأسماء أدوار، والـ theming كتبديل قيم على الطبقة الدلالية. المكونات تبقى دون تغيير.
Brainy تساعد المصممين على بناء أنظمة تتوسع، لا شاشات فردية. اطلع على ما نبنيه للمبدعين على /creators.
تسمية الـ tokens دون الجنون
تسمية الـ tokens تُفرق الفرق. شديدة العمومية والأسماء لا تحمل معلومات. شديدة التحديد وتكتب token جديداً لكل مكون.
اصطلاح التسمية الذي يعمل يُسمي أربعة أجزاء: الفئة، والدور، والمتغير، والحالة. لن تستخدم الأربعة في كل مرة، لكن البنية تمنع الفوضى العشوائية.
| الجزء | ما يُمثّل | أمثلة |
|---|---|---|
| الفئة | خاصية التصميم | color، spacing، radius، shadow، font |
| الدور | الغرض الدلالي | surface، text، border، interactive، feedback |
| المتغير | دور فرعي أو معدّل | primary، secondary، danger، subtle |
| الحالة | الحالة التفاعلية | default، hover، active، disabled، focus |
أمثلة عملية، مكتوبة كـ CSS custom properties يستهلكها المطور فعلاً:
color-surface-defaultيُعيّن الخلفية الافتراضية للصفحةcolor-text-subtleهو النص الثانوي بتباين أقلcolor-interactive-primary-hoverهو حالة hover للإجراء الأساسيspacing-component-mdهو الـ padding الداخلي المتوسط للمكوناتradius-interactiveهو نصف قطر الزوايا للعناصر القابلة للنقر
قاعدتان توفران أكثر النقاشات. لا تُشفّر القيمة الخام في الاسم أبداً، لأن color-blue-500 لا يُخبرك بشيء عن الدور. لا تُسمّ بالمكون في الطبقة الدلالية أبداً، لأن button-primary-color في الطبقة الدلالية يعني أنك تخطيت الطبقة الدلالية كلياً.
لـ أنظمة الطباعة التي تتوسع، ينطبق الاصطلاح ذاته، وfont-size-body-lg يتفوق على text-18px في كل مرة.
مجموعة tokens واحدة، الوضع الفاتح والداكن
الوضع الداكن هو حيث تُثمر أنظمة الـ tokens بشكل أوضح. إن سمّيت الـ tokens خاصتك بالدور، فالوضع الداكن هو تبديل قيم، لا إعادة تصميم.
اطلع عليه مباشرةً على primer.style
الآلية مباشرة. الـ token الدلالي color-surface-default يُشير إلى بدائي قريب من الأبيض في الوضع الفاتح وقريب من الأسود في الوضع الداكن. المكون الذي يستهلكه لا يتغير أبداً. تُبدّل الثيمات بتبديل تعيين القيم على الطبقة الدلالية.
CSS custom properties تجعل هذا ميكانيكياً:
:root {
--color-surface-default: #ffffff;
--color-text-primary: #111827;
}
[data-theme="dark"] {
--color-surface-default: #0f172a;
--color-text-primary: #f8fafc;
}
كل مكون يُشير إلى var(--color-surface-default) يستجيب الآن لسمة الثيم بصفر كود إضافي. Shopify Polaris وGitHub Primer وIBM Carbon تستخدم جميعها هذا النمط على نطاق الإنتاج.
نمط الفشل هو خلط الـ tokens الدلالية والبدائية في المكونات. حين يُشير مكون إلى color-blue-600 مباشرةً بدلاً من color-interactive-primary، يتوقف ذلك المكون عن الاستجابة للـ theming. إشارة بدائية واحدة غير مبالية تكسر النموذج بأكمله. قواعد Lint التي تُعلم عن استهلاك البدائيات المباشر في كود المكون تستحق وقت الإعداد.
فهم كيف تُحدث اختيارات الألوان تأثيرها يمنحك الأساس المفاهيمي، والـ tokens تمنحك البنية للتصرف بناءً عليه عبر كل ثيم.
متى تكون الـ design tokens مبالغة
الـ tokens تُضيف عدم مباشرة. عدم المباشرة له تكاليف. كن صادقاً حول متى تستحق هذه التكاليف الدفع.
| الحالة | الـ tokens؟ | السبب |
|---|---|---|
| نظام تصميم يخدم 3+ منتجات | نعم | الـ tokens المشتركة تُعوّض تكلفتها فوراً |
| منتج واحد، 5+ مصممين | نعم | يمنع انجراف اللوحة عبر الفريق |
| منتج واحد، 1-2 مصممين، تكرار نشط | ربما | الطبقة الدلالية فقط، تخطّ الـ tokens على مستوى المكون |
| موقع تسويقي، بلا مكتبة مكونات | لا | stylesheet واحد أسرع في التغيير |
| نموذج أولي أو MVP أقل من 3 أشهر | لا | جرّد بعد استقرار التصميم |
| إضافة الوضع الداكن لنظام موجود | نعم | هذا بالضبط ما الـ tokens موجودة لأجله |
الفرق الصغيرة تتحرك أسرع بدون tokens. شركة ناشئة من ثلاثة أشخاص تسعى لتحقيق product-market fit لا تحتاج تسلسلاً هرمياً بثلاث طبقات. حين تغير اتجاهك البصري كل أسبوعين، مكتبة Figma styles واحدة تكفي.
النمط المضاد الذي يجب تجنبه هو التسمية الدلالية المتسرعة. الـ tokens المُسماة color-blue وcolor-gray تُضيف عدم مباشرة بلا معنى. إما سمّ بالدور مع color-surface وcolor-text، أو ابقَ مع البدائيات حتى يكون لديك ما يكفي من المكونات لتعرف ما هي الأدوار فعلاً.
التسمية السيئة للـ tokens أسوأ من لا tokens على الإطلاق. الـ token المُسمى button-color-for-the-checkout-page في الطبقة الدلالية هو فخ صيانة. انضباط التسمية ليس اختيارياً، إنه السبب في أن الـ tokens تعمل أصلاً.
أسئلة شائعة
هل تحل الـ design tokens محل Figma styles؟
لا، لكنها تُوسّعها. متغيرات Figma، التي أُصدرت في 2023، هي أقرب مكافئ طبيعي داخل Figma، وتُعيّن على الـ tokens البرمجية حين تشترك في اصطلاحات التسمية بين الجانبين. Figma styles تتعامل مع الطباعة وتعبئات الألوان، بينما تتعامل المتغيرات مع التسلسل الهرمي الكامل للـ tokens بما في ذلك الحالات والقرارات على مستوى المكون.
هل تعمل الـ tokens بدون نظام تصميم؟
الـ tokens ذات قيمة أكبر داخل نظام التصميم، لكن حتى منتج واحد يستفيد من التسمية الدلالية على مستوى CSS custom property. لا تحتاج نظاماً رسمياً لتتوقف عن تشفير قيم hex مباشرةً.
ما الأداة التي يجب استخدامها لإدارة الـ tokens؟
للفرق الصغيرة، متغيرات Figma مع تصدير JSON تكفي. للفرق الأكبر، Style Dictionary (مفتوح المصدر، من Amazon) هو أداة البناء القياسية. يأخذ بنية JSON للـ tokens ويُخرج CSS custom properties وثوابت iOS Swift وملفات Android XML. Tokens Studio for Figma هو مكوّن الإضافة الشهير بين Figma وStyle Dictionary.
ما مقدار التفصيل الذي يجب أن تمتلكه الـ tokens على مستوى المكون؟
بالقدر الذي تحتاجه فقط. معظم المكونات يمكنها استهلاك الـ tokens الدلالية مباشرةً. الـ tokens على مستوى المكون منطقية حين ينحرف مكون عن الطبقة الدلالية عمداً، كزر إجراء تدميري أو بانر بسطح غير معتاد. في حالة الشك، استهلك الدلالية وأنشئ الـ tokens على مستوى المكون فقط حين تجد نفسك تكتب استثناءات.
هل يمكن للـ tokens التعامل مع المسافات والطباعة، أم الألوان فقط؟
تعمل الـ tokens لأي شيء بقيمة محددة: اللون، والمسافة، والطباعة، ونصف قطر الحدود، وظل الصندوق، ومدة الحركة، وتخفيف الحركة، والـ z-index. الأنظمة الأكثر نضجاً، مثل IBM Carbon ونظام Atlassian Design System، تمتلك tokens لكل هذه الخصائص. ابدأ بالألوان والمسافات، ثم أضف غيرها كلما نضج النظام.
توقف عن تشفير القيم مباشرةً
المسار العملي ليس معقداً:
- سمّ البدائيات كمقياس
- عيّن تلك البدائيات لأدوار دلالية
- اجعل كل مكون يستهلك الـ tokens الدلالية، لا البدائيات أبداً
- صدّر قيم الـ tokens من مصدر واحد (متغيرات Figma، ملف JSON، أو حزمة نظام تصميم) ودع أدوات البناء توزعها على CSS وiOS وAndroid
لا تحتاج هجرة لمدة ثلاثة أشهر للبدء. اختر مكوناً واحداً، سمّ قراراته، وأحسّ بالفارق حين تغير قيمة واحدة وتشاهد كل شيء يُحدَّث. تلك التجربة هي الحجة بحد ذاتها.
لمزيد من الكتابة حول أنظمة التصميم، اطلع على ما تغطيه Brainy على /paper.
Brainy helps designers build systems that scale, not one-off screens. See what we are building for creators.
Get Started
