معمارية متغيرات Figma: كيف تبني نظام Tokens ينجو في الإنتاج

معظم الفرق التي تستخدم متغيرات Figma تبني على نموذج ذهني خاص بالـ styles، وهنا المشكلة. المتغيرات بلا معمارية ليست سوى styles بنقرات إضافية.

الفرق التي تُحسن العمل تتعامل مع متغيرات Figma كطبقة design tokens حقيقية: منظمة، ومترابطة بالـ alias، ومحددة النطاق، وقابلة للتصدير. أما الفرق التي تخطئ فهي على بعد طلب واحد لـ الوضع الداكن من إعادة بناء كاملة. هذه هي المعمارية التي تنجو في الإنتاج.

المتغيرات ليست styles، إنها طبقة الـ tokens

الـ styles في Figma هي إعدادات مسبقة. تعرّف لونًا أو نمط نص أو تأثيرًا، ثم تطبّقه مباشرة على طبقة. هذا يصلح لملف بعلامة واحدة ووضع واحد ودون متطلبات تسليم للمطورين. ويتوقف عن الصلاحية لحظة يتغير أي شيء.

متغيرات Figma هي tokens. المتغير يحمل قيمة، لكنه يستطيع أيضًا أن يحمل مرجعًا إلى متغير آخر. سلسلة المراجع هذه، مع القدرة على تبديل مجموعات كاملة من القيم المحلولة عبر الـ modes، هي ما يجعل المتغيرات مختلفة معماريًا عن الـ styles. الفرق ليس تجميليًا. إنه الفرق بين نظام إعدادات مسبقة ونظام tokens.

معمارية الـ tokens ثلاثية الطبقات

Primitives وsemantic وcomponent. كل نظام متغيرات يعمل يملك هذه الطبقات الثلاث. تخطي الطبقة الدلالية هو الخطأ المعماري الأكثر شيوعًا في ملفات Figma اليوم.

تتوزع الطبقات الثلاث على ثلاث مهام: الـ primitives تحمل القيم الخام، والـ semantic tokens تحمل المعنى، والـ component tokens تنحصر في عائلة مكوّن واحدة. كل طبقة تتحدث فقط مع الطبقة التي تحتها. لا تخطي ولا اختصارات.

الطبقات الثلاث ليست اختيارية حسب حجم المشروع. نظام صغير بخمسة مكونات ما زال يحتاج الطبقات الثلاث، وإلا فإن أول طلب لثيم سيفجّره.

الطبقة الأولى: primitives

الـ primitives هي القيم الخام. blue-500 وgray-900 وspace-4 وradius-md. إنها اللوحة والمقياس والأساس. لا تُرفق أبدًا مباشرة بـ طبقة مكوّن.

مهمة الـ primitive أن توجد، وأن تُشار إليها من الأعلى، وأن تبقى بعيدة عن الطريق. إذا كان المصمم يمدّ يده إلى blue-500 ليطبقه على زر، فالمعمارية مكسورة أصلًا. مكان الـ primitives هو collection الـ primitives ولا مكان آخر.

اصطلاح التسمية مهم هنا. يجب أن تكون أسماء الـ primitives قائمة على المقياس أو اللوحة، لا على الدلالة أبدًا. blue-500 صحيح. أما button-blue كـ primitive فهو خطأ تصنيفي يسبب ألمًا عند التوسع.

الطبقة الثانية: semantic

الـ semantic tokens تحمل المعنى. surface وsurface-elevated وtext-primary وtext-muted وborder-default وborder-focus. هي تجيب عن سؤال "لأي غرض هذا اللون؟" لا "ما هذا اللون؟"

الـ semantic tokens تشير بـ alias إلى الـ primitives. هذه هي العلاقة الوحيدة لها. الـ alias من semantic إلى semantic يخلق غموضًا حول مكان القيمة ويجعل تجاوزات الـ modes غير موثوقة.

في هذه الطبقة تعيش modes الفاتح والداكن والعلامة. الـ semantic token يُحل إلى primitive مختلف بحسب الـ mode النشط، وهكذا يعمل الـ theming فعليًا. الـ primitive blue-500 لا يتغير. الـ semantic token text-link هو الذي يغيّر ما يُحل إليه بحسب الـ mode.

الطبقة الثالثة: component

الـ component tokens تنحصر في عائلة مكوّن واحدة. button-bg وbutton-text وbutton-border وcard-surface وcard-border وinput-bg. تشير بـ alias إلى semantic tokens، ولا تشير أبدًا إلى primitives.

مهمة الـ component token هي التخصيص دون ارتباط. button-bg يُحل إلى surface-action، الذي يُحل إلى blue-500. عندما تتغير العلامة، تحدّث الطبقة الدلالية فيتحدث الزر معها. الـ component token لم يُمس.

اعتراض شائع أن هذا يبدو tokens إضافية بلا سبب. السبب أن button-bg وsurface-action قد يفترقان. في لحظة ما، سيتطلب قرار منتج أن يستخدم الزر سطحًا مختلفًا قليلًا. الـ component tokens تمنحك نقطة التجاوز دون المساس بالنظام الدلالي.

Modes مقابل collections: شجرة القرار

الـ modes تبدّل القيم داخل collection. الـ collections تفصل الاهتمامات. الأمران ليسا نفس الشيء، والخلط بينهما مصدر معظم الارتباك المعماري في إعدادات متغيرات Figma.

القاعدة: collection واحد لكل اهتمام، وmodes لتنويعات الاهتمام نفسه. اللون اهتمام واحد. المسافات اهتمام واحد. الفاتح والداكن ليسا اهتمامين منفصلين. إنهما modes لاهتمام اللون نفسه.

متى تستخدم mode ومتى تنشئ collection جديدًا:

• قيمة مختلفة للشيء نفسه؟ Mode.
• شيء مختلف تمامًا؟ Collection.
• التبديل بين الفاتح والداكن؟ Mode داخل collection الألوان.
• التبديل بين مسافات مدمجة ومريحة؟ Mode داخل collection المسافات.
• إضافة علامة تجارية؟ Mode داخل الطبقة الدلالية، لا collection جديد.

قواعد النطاق الأربع

نطاق المتغير (scoping) يتحكم في الأماكن التي يمكن تطبيق المتغير عليها في Figma. إذا أخطأت هنا، سيمد المصممون أيديهم عن غير قصد إلى الـ primitives بدل الـ semantic tokens، وينهار الانضباط المعماري عند نقطة الاستخدام.

القواعد الأربع غير قابلة للتفاوض:

1. اجعل نطاق الـ primitives لا شيء. يجب ألا تكون الـ primitives قابلة للتطبيق في أي مكان. هي قيم داخلية لا tokens موجهة للمستهلك. أخفِها من قائمة التطبيق تمامًا.
2. اجعل نطاق الـ semantic tokens بحسب نوعها. الـ semantic token للون يُحصر في fills وstrokes. وtoken المسافات يُحصر في حقول gap وpadding والحجم. أبقِ النطاق ضيقًا.
3. اجعل نطاق الـ component tokens بحسب عائلتها. يجب ألا يكون token الزر قابلًا للتطبيق على بطاقة. إذا كان النطاق واسعًا جدًا، تفقد حدود المكوّن معناها.
4. لا تكشف الـ primitives للمستهلكين أبدًا. إذا كان مصمم أو مطور يطبق primitive على طبقة، فقد فشل النظام في طبقة النطاق. هذا فشل في العملية، لا فشل من المستخدم.

سلسلة الـ alias التي تجعل الثيمات ممكنة

الثيم العامل هو سلسلة من الـ aliases: الـ component يشير إلى semantic، والـ semantic يشير إلى primitive، والـ primitive يحمل القيمة. طول السلسلة ثلاثة، دائمًا ثلاثة.

سلسلة من اثنين (component إلى primitive) تتخطى طبقة الترجمة وتجعل الـ modes مستحيلة دون تجاوزات يدوية على كل component token. وسلسلة من أربعة تخلق غموضًا حول أي طبقة دلالية تحمل الـ mode، ويتحول تدقيقها إلى تمرين في تصحيح الأخطاء بدل أن يكون مجرد بحث.

button-bg → surface-action → blue-500 → #0066FF

Copy

هذه السلسلة تنجو من الوضع الداكن بتحديث surface-action ليشير إلى blue-300 في الـ mode الداكن لـ collection الدلالي. يتحدث token button-bg تلقائيًا. والـ primitive blue-500 ما زال يُحل إلى #0066FF. لا شيء آخر يحتاج إلى تغيير.

أوضاع الفاتح والداكن والعلامة

الـ modes الثلاثة التي يحتاجها معظم أنظمة المتغيرات هي الفاتح والداكن والعلامة. الطبقة الدلالية وحدها تحملها. لا طبقة الـ primitives أبدًا.

تطبيق الـ modes على الـ primitives خطأ تصنيفي. blue-500 هو دائمًا #0066FF. إنه primitive. ليس له نسخة فاتحة أو داكنة لأنه لا يحمل معنى. أما الـ semantic token text-link فله نسخة فاتحة وداكنة لأنه يحمل معنى يُحل بشكل مختلف في سياقات مختلفة.

أوضاع العلامة تعمل بالطريقة نفسها. العلامة الثانية لا تحتاج لوحة primitives ثانية إلا إذا كانت تستخدم قيمًا خام مختلفة فعلًا. في أغلب الأحيان، الخيار الصحيح هو mode علامة في الطبقة الدلالية يشير إلى مجموعة فرعية مختلفة من الـ primitives الموجودة. collectionان كاملان للـ primitives لعلامتين مبالغة في الغالب. ولمعرفة كيف تشكّل قرارات اللون في المراحل الأولى هذا الأمر، يستحق مقال نظام ألوان الوضع الداكن القراءة قبل تثبيت بنية طبقتك الدلالية.

متغيرات الأرقام والنصوص والـ boolean

متغيرات Figma ليست ألوانًا فقط. متغيرات الأرقام تتحكم في المسافات والأحجام والـ radius. متغيرات النصوص تتحكم في المحتوى داخل ملفات التصميم. ومتغيرات الـ boolean تتحكم في ظهور الطبقات، وهذا يقابل الـ props في المكونات مباشرة.

هذا هو الجزء من نظام المتغيرات الذي لا تستخدمه معظم الفرق، وهو الجزء الذي يسد الفجوة بين التصميم والكود بأقوى شكل. مقياس مسافات معرّف كمتغيرات أرقام ومطبّق على فجوات auto-layout يعني أن تغيير المسافة في المتغير يحدّث كل مكوّن يستخدم ذلك الـ token. هذا ما يفعله نظام tokens حقيقي.

متغيرات النصوص مع modes اللغة تتيح للمصممين قلب الملف بين الإنجليزية والعربية ومشاهدة التخطيط وهو ينكسر لحظيًا. ومتغيرات الـ boolean المربوطة بـ props المكوّن تعني أن مكوّن Figma ومكوّن الكود بينهما علاقة props واحد لواحد، مما يجعل تسليم المطورين قابلًا للمراجعة بدل أن يكون قابلًا للتأويل.

التسليم إلى الكود: النمط الذي يعمل

نظام المتغيرات بجودة تصديره فقط. نمط التسليم الذي يعمل هو Tokens Studio أو Figma Variables REST API، زائد خط تحويل (transform pipeline)، زائد سكربت استيراد في جهة الكود.

يصدّر Tokens Studio مجموعات المتغيرات إلى صيغة JSON منظمة متوافقة مع Style Dictionary. ويحوّل Style Dictionary ذلك الـ JSON إلى أي مخرجات تحتاجها قاعدة الكود: CSS custom properties أو Swift color sets أو ملفات موارد Kotlin أو إعدادات Tailwind. خطوة التحويل هي المكان الذي تُوحَّد فيه اصطلاحات التسمية وتُنظَّف فيه أي تسميات خاصة بـ Figma لا تتوافق مع اصطلاحات الكود.

يجب أن يعمل الـ pipeline عند كل تحديث للمتغيرات، لا يدويًا. GitHub Action يُشغَّل عند push من Tokens Studio أو webhook من Figma يُطلق عند تغيّر المتغيرات يُبقي الـ tokens في جهة الكود متزامنة دون أن يتذكر أحد التصدير. هذا هو النمط الذي تشغّله Stripe وAtlassian على نطاق واسع، وهو قابل للتحقيق في أي قاعدة كود لديها خطوة build. أما بخصوص قرارات الصيغة لـ color tokens في تلك المخرجات، فمقال لون OKLCH يستحق القراءة قبل أن تثبّت قيم CSS custom properties.

---

تريد نظام متغيرات Figma ينجو من الـ modes والعلامات وتسليم المطورين دون إعادة كتابة؟ Brainy تصمم معماريات tokens جاهزة للإنتاج في Figma بالنموذج ثلاثي الطبقات وسلسلة الـ alias وخط التصدير الذي يندمج بسلاسة في قاعدة الكود عندك. وظّف Brainy

---

سبعة أخطاء شائعة تكسر أنظمة المتغيرات

معظم هذه الأخطاء تشترك في جذر واحد: التعامل مع لوحة المتغيرات كلوحة styles أفضل بدل التعامل معها كطبقة معمارية. تغيير النموذج الذهني هو الحل. وكل شيء آخر يتبعه.

تدقيق نظام المتغيرات

شغّل هذا التدقيق على أي نظام متغيرات في Figma وستلتقط الدين المعماري قبل أن يُشحن.

البنية

• ثلاث collections كحد أدنى: primitives وsemantic وcomponent (أو تسمية مكافئة)
• كل collection له اهتمام واحد واضح
• لا collection يخلط الأنواع (اللون والمسافات في collection واحد فشل)

سلسلة الـ alias

• كل component token يشير إلى semantic token، لا إلى primitive
• كل semantic token يشير إلى primitive، لا إلى semantic token آخر
• لا token يحمل قيمة خام عدا الـ primitives
• طول سلسلة الـ alias ثلاثة بالضبط لكل color tokens

الـ Modes

• الفاتح والداكن modes في collection الدلالي، لا collections منفصلة
• تنويعات العلامة modes في collection الدلالي، لا ملفات منفصلة
• collection الـ primitives بلا modes

النطاق

• متغيرات الـ primitives نطاقها لا شيء (غير قابلة للتطبيق في أي مكان)
• المتغيرات الدلالية نطاقها بحسب نوعها (اللون إلى fills/strokes، والمسافات إلى حقول التخطيط)
• متغيرات الـ component نطاقها عائلة المكوّن

التسليم

• المتغيرات قابلة للتصدير عبر Tokens Studio أو REST API
• خط التحويل موجود ومؤتمت
• الـ tokens في جهة الكود تطابق اصطلاح تسمية متغيرات Figma مع استثناءات موثقة

إذا فشل أكثر من ثلاثة من هذه، فالنظام يحتاج إعادة بناء لا ترقيعًا. يغطي لوحة ألوان العلامة قرارات اللون في المراحل الأولى التي تغذي طبقة الـ primitives، إذا كان هذا هو المكان الذي كشف فيه التدقيق أكبر قدر من الدين.

الأسئلة الشائعة

ما الفرق بين متغيرات Figma وstyles في Figma؟

الـ styles إعدادات مسبقة تُطبق مباشرة على الطبقات. المتغيرات هي tokens يمكنها الإشارة إلى بعضها وتبديل القيم عبر الـ modes. المتغيرات تفعل كل ما تفعله الـ styles، إضافة إلى الـ theming، إضافة إلى التسليم للمطورين عبر التصدير. بالنسبة إلى نظام تصميم جديد، المتغيرات هي الخيار الصحيح. أما لملف قائم بنظام styles ناضج، فخطة الترحيل تستحق أن تُكتب قبل التبديل.

كم collection يجب أن يملك نظام متغيرات Figma؟

من ثلاثة إلى خمسة لمعظم الأنظمة: primitives وsemantic وcomponent، واختياريًا collections منفصلة للمسافات والطباعة إذا كانت تلك المقاييس معقدة بما يكفي لتستحق قواعد نطاق خاصة. أكثر من خمس collections غالبًا علامة على أن الاهتمامات لا تُجمَّع بشكل صحيح.

هل يمكن لمتغيرات Figma أن تحل محل Tokens Studio؟

للإنشاء والتحرير داخل Figma، نعم. لوحة المتغيرات الأصلية تتولى معظم ما كان يفعله Tokens Studio قبل صدور variables API. أما للتصدير والتحويل، فما زال Tokens Studio يضيف قيمة لأن لديه pipeline ناضجًا إلى Style Dictionary ويتعامل مع حالات حدّية لا يتعامل معها التصدير الأصلي. الأداتان متكاملتان الآن، لا متنافستان.

ماذا يحدث إذا جعلت semantic token يشير بـ alias إلى semantic token آخر؟

يصبح حل الـ mode غامضًا. إذا كان text-secondary يشير إلى text-primary وبدّلت إلى الوضع الداكن، فإن Figma يحل السلسلة وقد لا يطبق تجاوز الوضع الداكن حيث تتوقع. كما أن الـ alias من semantic إلى semantic يجعل تدقيق النظام شبه مستحيل على نطاق واسع. القاعدة صارمة: الـ semantic tokens تشير إلى الـ primitives فقط.

كيف أتعامل مع علامة ثالثة دون إعادة بناء النظام؟

أضف mode ثالثًا إلى collection الدلالي. collection الـ primitives مشترك بين العلامات إلا إذا كانت العلامات تستخدم قيمًا خام مختلفة فعلًا. mode علامة في الطبقة الدلالية يشير إلى مجموعة فرعية مختلفة من الـ primitives هو المعمارية الصحيحة. وإذا كانت العلامات مختلفة لدرجة أن لوحات الـ primitives لديها لا تتقاطع، فالحل الاحتياطي هو collectionان للـ primitives مع بنية دلالية مشتركة.

هل النموذج ثلاثي الطبقات ضروري للمشاريع الصغيرة؟

نعم، لكن حجم كل طبقة يتقلص. قد يملك مشروع صغير خمسة عشر primitive وثمانية semantic tokens واثنين من component tokens لكل مكوّن. تبقى المعمارية ثلاث طبقات. إغراء تخطي الطبقة الدلالية في المشاريع الصغيرة هو سبب تحول كثير من المشاريع الصغيرة إلى دين معماري لحظة ظهور مصمم ثانٍ أو طلب وضع داكن. ولمعرفة موقع معمارية الـ tokens ضمن قرار الـ stack الأوسع، يقدم مقال Framer vs Webflow vs Next.js سياقًا.

التحول الذي تفتحه متغيرات Figma فعلًا

نظام متغيرات حقيقي في Figma هو أقرب ما وصل إليه جانبا التصميم والتطوير من مصدر واحد للحقيقة. ليس مستند تسليم. ليس رابط Zeplin. بل طبقة tokens حية وقابلة للتصدير ومنظمة يقرأ منها الجانبان من التعريفات نفسها.

الفرق التي تتعامل مع المتغيرات كمعمارية تخفض دين نظام التصميم إلى النصف، لا لأن المتغيرات سحر، بل لأن الانضباط المعماري الذي يتطلبه نظام متغيرات جيد يفرض أيضًا القرارات التي ظلت أنظمة التصميم تؤجلها. ماذا يعني هذا الـ token؟ إلى ماذا يمكنه أن يشير؟ من يملك الـ primitive؟ هذه الأسئلة لها إجابات الآن، والإجابات تعيش في الملف.

المتغيرات بلا معمارية ليست سوى styles بنقرات إضافية. أما المتغيرات مع النموذج ثلاثي الطبقات وسلسلة الـ alias وقواعد النطاق وخط التصدير فهي نظام تصميم يستطيع أن ينجو من علامة ثانية ووضع داكن ومطور لم يفتح Figma في حياته.

ابنِ المعمارية، لا الـ tokens فقط.