أذكر جيدًا كيف كنا نقوم بتصميم واجهات الاستخدام عبر الفوتوشوب كانت الأمور بسيطة جدًا، ولكن في وقتنا الحالي الأمور تغيرت هناك مفاهيم كثيرة ظهرت، أهمها نظام التصميم Design System والذي تكلمنا عنه سابقًا بشكل عام، والآن لنقوم بتشريحه حيث تعتبر رموز التصميم Design Tokens الجزئية الأساس التي تبني عليها كل شيء لاحقًا.
الفكرة وراء رموز التصميم بسيطة: بدل أن تُكرِّر كتابة اللون أو المسافة في كل عنصر، تحفظ القيمة باسم واضح كمتغير وتربط العناصر بهذا المتغير. وعندما تحتاج إلى القيمة تقوم بتعديل القيمة داخل المتغير فقط، أي يصبح لديك مرجع تعرف من خلاله أين تُستخدَم القيمة وما الذي سيتأثّر بتغييرها.
تظهر أهمية هذا التنظيم مع توسّع المشروع والعمل عليه بين أكثر من مُصمِّم ومُطوِّر. فالتصميم يحتوي على قرارات متكررة تخصّ الألوان والخطوط والمسافات، ويحتاج الفريق إلى طريقة مشتركة لحفظها واستخدامها في ملفات التصميم والكود. هنا يأتي دور رموز التصميم (Design Tokens)، وسنشرح كيف تُنظِّمها وتُطبِّقها، مع أمثلة من أنظمة تصميم فعلية.
ما الذي يحتويه رمز التصميم Design Tokens؟
رمز التصميم هو اسم يرتبط بقيمة تُستخدَم في الواجهة معبر عنه ضمن Figma باسم المتغير Variable. مثلًا، يمكن أن نُسمّي لون النص الأساسي color.text.primary، ونُحدِّد قيمته باللون #202342. الاسم يُوضِّح المقصود، بينما تُحدِّد القيمة اللون الذي سيظهر للمُستخدِم، تذكر أن استخدام الاسم هنا هدفهم مساعدة المصمم أو المطور على معرفة مكان استخدام هذا اللون في التصميم فهذا مهم جدًا.
يمكن كذلك أن يمثّل الرمز حجم خط أو مسافة أو نصف قطر الزوايا أو مدة حركة. ولتسهيل استخدامه، نُوضِّح نوع القيمة ونكتب وصفًا قصيرًا عند الحاجة. فالاسم space.card.padding قد يشير إلى المسافة الداخلية للبطاقة، ويُوضِّح وصفه إن كانت تُطبَّق على جميع الجهات.
عندما تربط عدة بطاقات بهذا الرمز، يصبح تعديل المسافة ممكنًا من مرجع مشترك. لكن كتابة الاسم بجوار البطاقة لا تكفي؛ يجب ربط الخاصية به فعلًا داخل أداة التصميم، واستخدام القيمة المقابلة له في الكود.
وهذا يشرح علاقة الرموز بـنظام التصميم: الرموز تحفظ القِيَم، والمُكوِّنات تستخدمها، والتوثيق يشرح متى نستخدم هذه المُكوِّنات وكيف تتصرّف. مثلًا، رمز لون الخطأ يُحدِّد اللون، بينما توثيق حقل الإدخال يشرح متى تظهر رسالة الخطأ وما الذي تقوله.
لماذا نُسمّي الاستخدام بدل اللون؟
سنستخدم مثالًا تعليميًا لمتجر يعتمد الأخضر لونًا للإجراء الرئيسي. يظهر هذا اللون في زر «إضافة إلى السلة»، ويظهر الأخضر أيضًا في رسالة نجاح الدفع. تشابه اللونين في هذه المرحلة لا يعني أن وظيفتهما واحدة.
إذا ربطت الزر ورسالة النجاح برمز اسمه green.600، ثم غيّرت قيمته إلى الأزرق لمواكبة هوية جديدة، فسيتغيّران معًا. وسيبقى اسم الرمز يقول «أخضر» رغم أن قيمته أصبحت زرقاء.
الأفضل أن تحتفظ بدرجات الألوان كما هي، وتُضيف أسماء تُعبِّر عن الاستخدام. مثلًا، color.action.primary للإجراء الرئيسي، وcolor.feedback.success للدلالة على النجاح. يمكن أن يشيرا إلى الدرجة الخضراء نفسها الآن، مع إمكانية تغيير أحدهما باستقلال لاحقًا.
عندما تتغيّر الهوية، تربط رمز الإجراء الرئيسي بدرجة زرقاء، وتترك رمز النجاح مرتبطًا بالأخضر. بهذه الطريقة، يكون التعديل مرتبطًا بقرار مفهوم: نُغيِّر لون الإجراءات الرئيسية، ونعرف أي عناصر تتبع هذا القرار.

مستويات الرموز وعلاقتها ببعضها
ستجد تسميات مختلفة للمستويات بين الأنظمة. المهم أن تفهم وظيفة كل مستوى، ثم تختار التنظيم الذي يحتاجه مشروعك.
الرموز الأساسية
الرموز الأساسية (Primitive Tokens) تحفظ القِيَم المتاحة، مثل green.600 لدرجة خضراء، وblue.600 لدرجة زرقاء، وspace.4 لمسافة نختار قيمتها في مثالنا لتكون 16px.
هذا المستوى يشبه قائمة القِيَم التي يستطيع النظام الاعتماد عليها. والرقم في الاسم جزء من طريقة التسمية؛ space.4 لا يعني بالضرورة 4px، كما أن الرقم 600 لا يشرح استخدام اللون. لذلك يجب توثيق معنى الأرقام والمحافظة على اتّساقها.
الرموز الدلالية
الرموز الدلالية (Semantic Tokens) تربط القيمة بوظيفة في الواجهة. مثلًا، color.text.primary للنص الأساسي، وcolor.border.error لحدود حقل يحتوي على خطأ.
يمكن أن يأخذ الرمز الدلالي قيمته من رمز أساسي. هذا الربط يُسمّى إحالة (Alias)؛ أي أن الرمز يرجع إلى رمز آخر للحصول على قيمته. وهنا نحتفظ بالعلاقة بين الاسمين، بدل نسخ قيمة اللون في مكان جديد وفصلها عن أصلها.

رموز المُكوِّنات
يمكن إضافة رمز يخصّ مُكوِّنًا معيّنًا، مثل button.primary.background لخلفية الزر الرئيسي. في مثال المتجر، نربطه برمز الإجراء الرئيسي، الذي يرجع بدوره إلى الدرجة الخضراء:
button.primary.background
→ color.action.primary
→ green.600تُقرأ العلاقة هكذا: خلفية الزر تأخذ لون الإجراء الرئيسي، ولون الإجراء الرئيسي يأخذ الدرجة الخضراء المُحدَّدة. إذا احتجت تغيير جميع الإجراءات الرئيسية، تراجع الرمز الأوسط. وإذا كان التغيير يخصّ الزر وحده، تراجع رمزه الخاص.
هذا المستوى مفيد عندما تحتاج المُكوِّنات إلى تعديل مستقل، لكنه ليس شرطًا لكل مشروع. يمكنك ربط الزر مباشرةً بالرمز الدلالي عندما يكون ذلك كافيًا؛ كثرة المستويات لا تُحسِّن النظام إذا جعلت الوصول إلى القيمة أصعب.
كيف تختار أسماء مفهومة؟
ابدأ بما يصفه الرمز، ثم الخاصية والاستخدام عند الحاجة. اسم مثل color.text.error يخبر زميلك أنه لون لنص الخطأ. أما red-2 فيُحدِّد درجة ضمن لوحة الألوان، لكنه لا يشرح أين ينبغي استخدامها.
يستخدم نظام Atlassian مثالًا واضحًا هو color.icon.success: لون أيقونة النجاح. ويشرح دليل رموز التصميم لدى Atlassian ضرورة اختيار الرمز بحسب استخدامه، لأن تطابق لون رمزين في سمة واحدة لا يضمن تطابقهما في بقية السمات.

اتّفق مع الفريق على طريقة تسمية واحدة، واكتب وصفًا للرموز التي قد يلتبس استخدامها. مثلًا، وضِّح الفرق بين النص الأساسي والنص الثانوي، أو بين لون الإجراء الرئيسي ولون العنصر المُحدَّد.
ولا تجعل الاسم مرتبطًا بصفحة واحدة إذا كان الاستخدام مشتركًا. اسم مثل «لون زر صفحة الدفع» يصبح مُربكًا عند استخدام القرار نفسه في صفحة أخرى. في المقابل، إذا كان الاستثناء يخصّ مُكوِّنًا بعينه، فاسم المُكوِّن يساعد على توضيح ذلك.
الرموز والوضع الفاتح والداكن
السمة (Theme) هي مجموعة قِيَم تمنح الواجهة مظهرًا معيّنًا. عند الانتقال إلى الوضع الداكن، يبقى دور النص الأساسي كما هو، بينما تتغيّر قيمته لتناسب الخلفية الجديدة.
يوضّح Carbon من IBM هذا عمليًا: الرمز $text-primary يأخذ درجة Gray 100 الداكنة في سمة White، ودرجة Gray 10 الفاتحة في سمة Gray 100. ويتغيّر $background من الأبيض إلى Gray 100. يمكنك مراجعة هذه العلاقة في توثيق السمات في Carbon.

بالنسبة للمُصمِّم، يظل العنوان مرتبطًا برمز النص الأساسي في الحالتين. لا تحتاج إلى استبدال ارتباطه يدويًا كل مرة؛ السمة المُطبَّقة هي التي تُحدِّد القيمة المناسبة.
والأمر يشمل الخلفيات والحدود والأيقونات وحالات التفاعل أيضًا. لذلك يحتاج الوضع الداكن إلى مجموعة قِيَم تُراجَع معًا، مع فحص التباين ووضوح الحالات. تغيير خلفية الصفحة وحدها سيترك أجزاء أخرى بقِيَم صُمِّمت للوضع الفاتح.

يمكن استخدام الفكرة نفسها لدعم أكثر من علامة تجارية، أو لتوفير واجهة بمسافات أوسع وأخرى أكثر كثافة. تظل القِيَم مرتبطة بأدوار معروفة، وتتغيّر المجموعة المُطبَّقة بحسب السياق الذي يدعمه المُنتَج.
المسافات والخطوط لها رموز أيضًا
في نظام التصميم الأمريكي USWDS، يقابل رمز المسافة 1 قيمة مستهدفة قدرها 8px، والرمز 2 قيمة 16px، والرمز 3 قيمة 24px. هذه أمثلة من سُلَّم المسافات في النظام، وليست قاعدة يجب نقلها إلى كل مشروع.
استخدام مجموعة مسافات مشتركة يجعل اختيار المسافة بين العناصر أكثر اتّساقًا. لكن تساوي المسافة الداخلية للبطاقة مع المسافة بين قسمين اليوم لا يعني وجوب ربطهما برمز دلالي واحد؛ قد تحتاج إلى تعديل أحد الاستخدامين لاحقًا.

وينطبق ذلك على النصوص: يمكن تنظيم عائلة الخط وحجمه ووزنه وارتفاع السطر، ثم جمع القِيَم المناسبة في نمط للعناوين أو النصوص. الاختيار الصحيح يعتمد على وضوح المحتوى، وليس على وجود اسم منظّم للقيمة فقط.
انتبه أيضًا إلى الوحدات. يعرض USWDS قِيَمًا مستهدفة بالبكسل، لكنه يُخرِج المسافات الموجبة الأكبر من 2px بوحدة REM. لذلك اتّفق مع المُطوِّر على طريقة تمثيل القِيَم، ويمكنك مراجعة الفرق بين PX وEM وREM لفهم أثر الوحدة في التنفيذ.
تطبيق عملي داخل Figma
المُتغيِّرات (Variables) هي إحدى وسائل تطبيق رموز التصميم داخل Figma. يمكن للمُتغيِّر الاحتفاظ بقيمة أو الرجوع إلى مُتغيِّر آخر من النوع نفسه. وتُنظَّم المُتغيِّرات داخل مجموعات (Collections)، كما يشرح توثيق Figma.

لتطبيق مثال المتجر، جرِّب الآتي:
أنشئ مجموعة للقِيَم الأساسية باسم
Primitives، وأضف اللونينgreen/600وblue/600.أنشئ مجموعة باسم
Semantic، وأضف مُتغيِّرًا للإجراء الرئيسي باسمcolor/action/primary.اربط قيمته بـ
green/600باستخدام Alias، ثم اربط به تعبئة الزر.أنشئ
color/feedback/successواربطه بالدرجة الخضراء أيضًا، ثم استخدمه لعنصر النجاح.غيِّر إحالة الإجراء الرئيسي إلى
blue/600، وراقب تغيّر الزر وبقاء عنصر النجاح أخضر.
استخدم الأوضاع (Modes) عندما تحتاج إلى قِيَم مختلفة للرمز نفسه، مثل Light وDark. حدِّد قِيَم النصوص والخلفيات لكل وضع، ثم طبِّق الوضع على الإطار. يشرح دليل الأوضاع في Figma كيفية تغيير السياق الذي تستخدمه العناصر.
وتبقى الأنماط (Styles) مفيدة لجمع خصائص متعددة، مثل حجم الخط ووزنه وارتفاع السطر، مع إمكانية استخدام المُتغيِّرات ضمن الخصائص المدعومة. وللتطبيق بصورة أوسع، تتناول دورة متقدمة في Figma المُتغيِّرات وأنظمة التصميم وتنظيم المكتبات.
كيف تصل الرموز إلى الكود؟
وجود المُتغيِّرات في ملف Figma لا يُحدِّث الموقع تلقائيًا. يحتاج الفريق إلى طريقة لنقل القِيَم والعلاقات نفسها إلى المشروع البرمجي، ومراجعة التغييرات قبل اعتمادها.
في CSS، يمكن تمثيل جزء من المثال السابق بهذه الصورة التعليمية:
:root {
--green-600: #15803d;
--blue-600: #2563eb;
--color-action-primary: var(--green-600);
--color-feedback-success: var(--green-600);
}
.button-primary {
background-color: var(--color-action-primary);
}
.success-icon {
color: var(--color-feedback-success);
}الزر يطلب لون الإجراء الرئيسي، والأيقونة تطلب لون النجاح. لتغيير الإجراء إلى الأزرق، نُعدِّل إحالة --color-action-primary إلى var(--blue-600). ويبقى رمز النجاح مرتبطًا بالأخضر. هذه القِيَم للتوضيح، والمثال لا يشمل بقية حالات الزر.
وفي المشاريع الأكبر، يمكن حفظ الرموز في ملفات منظّمة ثم تحويلها إلى الصيغ التي تحتاجها المنصات المختلفة. تُحدِّد مواصفة DTCG تنسيقًا لتبادل الرموز بين الأدوات، يشمل أنواع القِيَم والإحالات. ويدعم Figma استيراد رموز متوافقة وتصدير الأوضاع إلى JSON، ضمن الأنواع والقيود الموضّحة في دليله.
المهم هو تحديد المصدر الذي تُعتمَد فيه التغييرات، وكيف تصل إلى التصميم والكود، ومن يراجعها. إذا كان كل طرف يُعدِّل نسخته بصورة منفصلة، ستختلف القِيَم حتى لو بقيت الأسماء متطابقة.
كيف تبدأ دون تعقيد المشروع؟
ابدأ بجزء تستخدمه كثيرًا، مثل الأزرار والحقول والبطاقات. راجِع القِيَم الموجودة، وحدِّد ما يحتاج إلى توحيد وما ينبغي أن يبقى مستقلًا. ثم أنشئ الرموز المطلوبة وطبِّقها على شاشة واحدة قبل تعميمها.
افحص حالات المُكوِّن أيضًا. ربط لون الزر العادي وترك لون المرور بالمُؤشِّر مكتوبًا يدويًا قد يُنتِج زرًا تتغيّر بعض حالاته وتبقى الأخرى قديمة. وبعد تعديل المسافات، راجِع النصوص الطويلة وأحجام الشاشات المختلفة.
وإذا احتجت تغيير اسم رمز أو حذفه، حدِّد البديل وانقل استخداماته قبل الاستغناء عنه. فهذه الأسماء تصبح جزءًا من العمل الذي يعتمد عليه زملاؤك.
جرِّب تعديلًا صغيرًا مع المُطوِّر، وتحقّقا من وصوله إلى العناصر المقصودة في التصميم والتنفيذ. نجاح هذه الخطوة يعطيك أساسًا واضحًا للتوسّع، بدل البدء بمئات الرموز التي لم تُختبَر في واجهة فعلية.
المصادر
تاريخ النشر
20 أكتوبر 2026
آخر تعديل
20 أكتوبر 2026



