كانت تصاميمنا تتحطم عند التسليم: كيف أنقذتنا ‘رموز التصميم’ (Design Tokens) من جحيم الهوة بين المصمم والمطور؟

يا جماعة الخير، السلام عليكم ورحمة الله. معكم أخوكم أبو عمر.

بدي أحكيلكم قصة صارت معي قبل كم سنة، قصة كانت تتكرر في كل مشروع تقريباً لدرجة إنها صارت كابوس. كنا في فريق، مصممين شاطرين ومطورين “حريقة”، وبنشتغل على تطبيق مهم لعميل كبير. المصمم، خلينا نسميه “خالد”، سلّمنا تصميم خرافي على Figma. ألوان متناسقة، مسافات دقيقة، كل شيء “عالسنقة عشرة”.

أنا وفريقي من المطورين أخذنا التصميم وبدأنا الشغل. وبعد أسابيع من الكود والتعب، جينا يوم العرض… يا لطيف! التطبيق اللي على الشاشة كان إشي، والتصميم اللي سلمه خالد إشي ثاني تماماً. درجة اللون الأزرق الرئيسي مختلفة شوي، المسافات بين العناصر “مش ولا بد”، حجم الخط في مكان أكبر من مكان… خالد طلع فيي بنظرة “مش هيك اتفقنا يا أبو عمر!”. وأنا أطلع فيه وأنا بدافع “يا زلمة والله هيك شفتها بالتصميم، الألوان أخذتها بالـ color picker!”.

صار كل واحد يرمي الحق على الثاني، والعميل قاعد بالنص مش فاهم إشي. هاي اللحظة، اللي بسميها “جحيم الهوة بين المصمم والمطور”، كانت نقطة التحول. يومها قررنا إنه لازم نلاقي حل جذري، حل يخلينا نحكي لغة وحدة. وهون كانت البداية مع عالم “رموز التصميم” أو الـ Design Tokens.

ما هي هذه الفوضى؟ ولماذا تحدث؟

قبل ما نغوص في الحل، خلينا نفصّل المشكلة اللي كنا (ويمكن انتوا كمان) واقعين فيها. المشكلة ببساطة هي غياب “مصدر الحقيقة الواحد” (Single Source of Truth) للقيم البصرية.

• المصمم: يستخدم في تصميمه قيم محددة (مثلاً لون أزرق #0A74F2، مسافة 16px).
• المطور (Web): يفتح التصميم، وبأحسن الأحوال ينسخ القيمة ويكتبها في ملف الـ CSS كـ background-color: #0A74F2;.
• مطور (iOS): يعمل نفس الشيء لكن بلغة Swift.
• مطور (Android): يعمل نفس الشيء لكن في ملفات XML.

هل ترون المشكلة؟ نفس القيمة البصرية “اللون الأزرق الرئيسي” تكررت كتابتها يدوياً في 3 أماكن مختلفة على الأقل. الآن تخيلوا لو قررنا نغير درجة هذا اللون الأزرق! سيتوجب على كل مطور في كل منصة أن يرجع ويبحث عن كل مكان استخدم فيه هذا اللون ويغيره يدوياً. هذا هو تعريف الفوضى والكفاءة المعدومة.

المنقذ وصل: مرحباً بـ ‘رموز التصميم’ (Design Tokens)

رموز التصميم هي الحل الأنيق لهذه الفوضى. هي ليست تقنية معقدة أو إطار عمل جديد، بل هي مجرد مفهوم بسيط وقوي جداً.

ايش هي رموز التصميم يا أبو عمر؟

بكل بساطة، رموز التصميم هي “متغيرات” تحمل القيم الأولية لنظام التصميم الخاص بك. فكر فيها كأسماء صغيرة وذات معنى لكل القرارات البصرية في منتجك. بدلاً من أن نقول “استخدم اللون الأزرق السداسي #0A74F2“، نقول “استخدم color-brand-primary“.

هذه الرموز لا تقتصر على الألوان، بل تشمل كل شيء:

• الألوان: (color-background-page, color-text-caption)
• الخطوط: (font-size-heading-1, font-weight-bold)
• المسافات: (spacing-small, spacing-large)
• الأبعاد: (size-icon-medium)
• الظلال: (shadow-deep)
• أنصاف الأقطار (Border Radius): (border-radius-sharp, border-radius-pill)

بالمختصر، رموز التصميم هي الذرات التي يتكون منها نظام التصميم الخاص بك. هي لغة مشتركة وموحدة يفهمها المصمم والمطور على حد سواء.

كيف تعمل هذه الرموز؟

الجمال يكمن في آلية العمل. العملية تتم على ثلاث مراحل رئيسية:

1. التعريف (Define): يتم تعريف جميع الرموز في مكان مركزي واحد، غالباً ملف بصيغة JSON أو YAML. هذا الملف هو “مصدر الحقيقة الواحد”.
2. التحويل (Transform): نستخدم أداة متخصصة (مثل Style Dictionary) لتقرأ هذا الملف المركزي وتحوّله تلقائياً إلى الصيغ التي تحتاجها كل منصة (CSS Variables, Swift code, Android XML, etc.).
3. الاستهلاك (Consume): يستخدم المطورون هذه الملفات المُحوَّلة مباشرة في مشاريعهم.

بهذه الطريقة، عندما يحتاج المصمم لتغيير اللون الرئيسي، كل ما عليه فعله هو تحديث القيمة في ملف الـ JSON المركزي. وبكبسة زر، يتم تحويل الرموز من جديد وتحديثها في كل المشاريع والتطبيقات تلقائياً. انتهى زمن البحث والاستبدال اليدوي!

لنطبق عملياً: من الفكرة إلى الكود

الكلام النظري جميل، لكن “الحكي ببلاش”. خلينا نشوف كيف ممكن نطبق هذا بشكل عملي.

المرحلة الأولى: تعريف الرموز (ملف JSON)

لنفترض أننا سنقوم بتعريف بعض الألوان والمسافات الأساسية. سننشئ ملفاً اسمه tokens.json.

{
  "color": {
    "brand": {
      "primary": { "value": "#0D6EFD", "comment": "اللون الرئيسي للعلامة التجارية" },
      "secondary": { "value": "#6C757D", "comment": "اللون الثانوي للعلامة التجارية" }
    },
    "feedback": {
      "success": { "value": "#198754" },
      "error": { "value": "#DC3545" }
    },
    "text": {
      "default": { "value": "#212529" }
    }
  },
  "spacing": {
    "base": { "value": "4px" },
    "small": { "value": "{spacing.base.value} * 2" },
    "medium": { "value": "{spacing.base.value} * 4" },
    "large": { "value": "{spacing.base.value} * 6" }
  },
  "font": {
    "size": {
      "base": { "value": "16px" },
      "h1": { "value": "{font.size.base.value} * 2.5" }
    }
  }
}

نصيحة من أبو عمر: لاحظوا كيف استخدمنا أسماء ذات معنى (Semantic Naming) مثل color.brand.primary بدلاً من blue-500. هذا يجعل النظام أكثر مرونة، فلو قررنا مستقبلاً أن اللون الرئيسي للعلامة التجارية هو الأخضر، سيبقى اسم الرمز كما هو، فقط نغير قيمته. ولاحظوا أيضاً كيف يمكن لرمز أن يعتمد على رمز آخر (مثل المسافات التي تعتمد على spacing.base)، هذا يضمن التناسق الرياضي في التصميم.

المرحلة الثانية: تحويل الرموز (باستخدام Style Dictionary)

Style Dictionary هي أداة رائعة من أمازون تقوم بهذا العمل. تقوم بتثبيتها، وتعطيها ملف الـ JSON، وتحدد لها المخرجات التي تريدها.

بعد تشغيل الأداة، ستحصل على ملفات مثل:

لـ Web (CSS Variables):

:root {
  --color-brand-primary: #0D6EFD;
  --color-brand-secondary: #6C757D;
  --color-feedback-success: #198754;
  --spacing-medium: 16px;
  --font-size-h1: 40px;
}

لـ Android (dimens.xml & colors.xml):

<?xml version="1.0" encoding="UTF-8"?>
<resources>
  <color name="color_brand_primary">#0D6EFD</color>
  <color name="color_brand_secondary">#6C757D</color>
  <dimen name="spacing_medium">16dp</dimen>
  <dimen name="font_size_h1">40sp</dimen>
</resources>

المرحلة الثالثة: استخدام الرموز في الكود

الآن، بدلاً من القيم الثابتة، يستخدم المطورون هذه المتغيرات (الرموز).

مثلاً، في ملف CSS لتصميم زر:

.button-primary {
  /* BAD: قيم ثابتة */
  background-color: #0D6EFD;
  padding: 16px;
}

.button-primary-new {
  /* GOOD: استخدام رموز التصميم */
  background-color: var(--color-brand-primary);
  padding: var(--spacing-medium);
  color: white;
}

الآن، إذا طلب المصمم تغيير اللون الرئيسي إلى لون آخر، ببساطة نحدث قيمة color.brand.primary في ملف الـ JSON، نعيد تشغيل أداة التحويل، وكل المكونات التي تستخدم --color-brand-primary في كل المنصات ستتحدث تلقائياً. سحر، أليس كذلك؟

نصائح من خبرة أبو عمر

• التسمية، ثم التسمية، ثم التسمية: استثمروا وقتاً في وضع نظام تسمية جيد وواضح. قسموا الرموز إلى طبقات: طبقة أساسية (blue-500)، وطبقة دلالية (color-brand-primary)، وطبقة خاصة بالمكون (button-primary-background-color). هذا يسهل التعامل مع الوضع الليلي (Dark Mode) والثيمات المختلفة.
• ابدأ صغيراً: لا تحاول بناء نظام رموز كامل من اليوم الأول. ابدأ بالألوان والمسافات والخطوط. هذه هي الأساسيات التي ستعطيك 80% من الفائدة.
• الأتمتة هي صديقك: اربط عملية تحويل الرموز بنظام الـ CI/CD. اجعلها عملية تلقائية تحدث عند كل تحديث لملف الرموز الرئيسي.
• التعاون هو المفتاح: رموز التصميم ليست أداة للمطورين فقط. يجب أن تكون جزءاً من حوار مستمر مع المصممين. استخدموا أدوات مثل Figma Tokens plugin التي تسمح للمصممين باستخدام واستهلاك نفس الرموز مباشرة داخل Figma.

الخلاصة: جسر من الثقة بدلاً من هوة من الجحيم 😅

تبني رموز التصميم ليس مجرد تحسين تقني، بل هو تحول ثقافي في طريقة عمل الفريق. هو استثمار في بناء لغة مشتركة، وتقليل الاحتكاك، وزيادة الكفاءة بشكل هائل.

لقد أنقذتنا رموز التصميم من اجتماعات لا تنتهي من “ليش اللون مختلف؟” و “المسافة مش مزبوطة”، وحوّلت طاقتنا من تصحيح الأخطاء البصرية إلى التركيز على بناء تجربة مستخدم أفضل. هي الجسر الذي بنيناه فوق تلك الهوة المزعجة بين التصميم والتطوير، وهو جسر مبني من الثقة والكفاءة والاتساق.

نصيحتي الأخيرة لكم: توقفوا عن لعبة إلقاء اللوم، وابدأوا ببناء جسر الرموز الخاص بكم. مستقبلكم ومستقبل فرقكم سيشكركم على هذا القرار. يلا، شدوا حيلكم! 💪