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

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

قبل كم سنة، كنت شغال على مشروع لشركة ناشئة طموحة. كان عنا تطبيق على الويب، وتطبيق لأجهزة أندرويد، وآخر لـ iOS. فريق صغير، أحلام كبيرة، وضغط شغل، زي ما بحكوها، “للرُكب”. كنت أنا وفريقي الصغير مسؤولين عن الجانب التقني، وكان معنا مصمم واحد شاطر جدًا، بس قلبه طيب زيادة عن اللزوم.

المشكلة بدأت تظهر شوي شوي. المصمم يسلمنا التصميم على Figma، وكل شي تمام. لكن لما نيجي نطبق، تبدأ المأساة. مطور الـ iOS ياخذ لون الأزرار الأزرق بقطّارة الألوان (Eyedropper) ويطلع معه الكود #0A84FF. مطور الأندرويد، اللي وصله وصف “أزرق سماوي”، يختار من عنده لون قريب وبيطلع #007BFF. أما أنا، على الويب، فكنت أستخدم متغير CSS قديم كان بالمشروع وقيمته #0069D9.

النتيجة؟ ثلاث درجات مختلفة من اللون الأزرق لنفس الزر في نفس التطبيق! ولما يجي مدير التسويق ويفتح التطبيق على ثلاث أجهزة جنب بعض، كان يلف علي ويحكيلي بنبرة كلها عتب: “يا أبو عمر، شو هالحكي؟ ليش كل تطبيق شكل؟ كأنهم ثلاث شركات مختلفة!”. كنا عايشين في جحيم، كل منصة كانت جزيرة معزولة، والتواصل بين الجزر كان أشبه بالصراخ في وادٍ سحيق. كل تعديل بسيط على لون أو حجم خط كان يحتاج اجتماعات وتذاكر على Jira ومتابعة مع ثلاث مطورين مختلفين. كانت فوضى… حتى اهتدينا إلى الحل: رموز التصميم (Design Tokens).

ما هي “رموز التصميم”؟ ببساطة، هي لغة مشتركة

لما تسمع مصطلح “رموز التصميم” أو “Design Tokens”، لا تفكر إنه شي معقد من عالم الفضاء. الفكرة أبسط من هيك بكثير. تخيلها كـ “متغيرات” (Variables) بس للتصميم. هي عبارة عن وحدات صغيرة جدًا من قرارات التصميم، يتم تخزينها في مكان مركزي واحد.

هذه الرموز لا تمثل فقط الألوان، بل كل شيء تقريبًا في نظام التصميم:

• الألوان: اللون الأساسي للعلامة التجارية، لون النصوص، لون الخلفيات، ألوان التنبيهات (نجاح، خطأ، تحذير).
• الطباعة (Typography): عائلة الخط، أحجام الخطوط (H1, H2, Body)، وزن الخط (عادي، عريض)، ارتفاع السطر.
• المسافات (Spacing): الهوامش الداخلية والخارجية (padding, margin). بدل ما تحكي “حط مسافة صغيرة”، بتحكي “استخدم spacing-small اللي قيمته 8px”.
• الأبعاد (Sizing): عرض الأزرار، ارتفاع شريط التنقل.
• الظلال (Shadows): قيم الظل للعناصر المختلفة.
• زوايا الحواف (Border Radius): درجة استدارة الزوايا للبطاقات والأزرار.

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

كيف كنا نشتغل “قبل”، وكيف صرنا نشتغل “بعد”

عشان تتضح الصورة أكثر، خليني أفرجيكم الفرق الشاسع بين عالم الجزر المعزولة وعالم القارة الموحدة اللي بنته رموز التصميم.

قبل: جحيم الجزر المعزولة

1. المصمم: يصمم واجهة جميلة في Figma ويستخدم اللون الأزرق #007AFF.
2. التسليم: يرسل التصميم للمطورين ويقول “هذا هو اللون الأزرق المعتمد”.
3. مطور الويب: يفتح التصميم، ينسخ الكود #007AFF ويضعه في ملف CSS الخاص به.
4. مطور الأندرويد: يفتح نفس التصميم، لكن يمكن ينسخ الكود غلط أو يقرّب القيمة ويكتب #017BFF في ملف colors.xml.
5. مطور iOS: يفتح التصميم ويستخدم أداة القطارة في Xcode، وبسبب معايرة الشاشة المختلفة، يحصل على #0079FA.

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

بعد: أرض الميعاد مع رموز التصميم

1. المصمم وفريق العمل: يتفقون على إنشاء “رمز” لهذا اللون. مثلاً، color.brand.primary.
2. التخزين المركزي: يتم تخزين هذا الرمز وقيمته في ملف مركزي واحد، غالبًا ما يكون بصيغة JSON.
   

   { "color": { "brand": { "primary": { "value": "#007AFF" } } } }

3. الأتمتة السحرية: باستخدام أداة مثل Style Dictionary أو Figma Tokens، يتم تشغيل سكربت يقوم بتحويل هذا الملف المركزي تلقائيًا إلى الصيغ التي تفهمها كل منصة.
4. النتيجة:
   • الويب يحصل على ملف CSS: :root { --color-brand-primary: #007AFF; }
   • الأندرويد يحصل على ملف XML: <color name="color_brand_primary">#007AFF</color>
   • iOS يحصل على ملف Swift: static let colorBrandPrimary = UIColor(...)

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

مثال عملي من مطبخ أبو عمر

خلونا نغوص في التفاصيل التقنية شوي. الحكي بينا، الكلام النظري ما بطعمي خبز. لنبني نظام رموز تصميم صغير مع بعض.

أولاً: المصدر الوحيد للحقيقة (ملف JSON)

سنقوم بإنشاء ملفات JSON بسيطة لتحديد قراراتنا التصميمية. يفضل تقسيمها حسب النوع لسهولة الإدارة.

ملف للألوان (tokens/color.json):

{
  "color": {
    "brand": {
      "primary": { "value": "#007AFF", "comment": "اللون الأساسي للعلامة التجارية" },
      "secondary": { "value": "#FF9500", "comment": "اللون الثانوي" }
    },
    "text": {
      "base": { "value": "#1D1D1F", "comment": "لون النص الأساسي" },
      "subtle": { "value": "#6E6E73", "comment": "لون النص الثانوي الباهت" }
    }
  }
}

ملف للأحجام والمسافات (tokens/size.json):

{
  "size": {
    "font": {
      "base": { "value": "16px" },
      "large": { "value": "20px" },
      "small": { "value": "14px" }
    },
    "spacing": {
      "xs": { "value": "4px" },
      "sm": { "value": "8px" },
      "md": { "value": "16px" }
    }
  }
}

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

أداة Style Dictionary هي أداة من أمازون، مفتوحة المصدر، وظيفتها أخذ ملفات JSON هذه وتحويلها لصيغ مختلفة. الإعداد بسيط نسبيًا.

في ملف الإعدادات (config.json)، نحدد المصدر والمخرجات المطلوبة:

{
  "source": ["tokens/**/*.json"],
  "platforms": {
    "css": {
      "transformGroup": "css",
      "buildPath": "build/css/",
      "files": [{
        "destination": "variables.css",
        "format": "css/variables"
      }]
    },
    "android": {
      "transformGroup": "android",
      "buildPath": "build/android/src/main/res/values/",
      "files": [{
        "destination": "style_dictionary_colors.xml",
        "format": "android/colors"
      }, {
        "destination": "style_dictionary_dimens.xml",
        "format": "android/dimens"
      }]
    },
    "ios-swift": {
      "transformGroup": "ios-swift",
      "buildPath": "build/ios-swift/",
      "files": [{
        "destination": "StyleDictionary.swift",
        "format": "ios-swift/class.swift",
        "className": "StyleDictionary"
      }]
    }
  }
}

الآن، كل ما عليك هو تشغيل أمر في الـ Terminal: style-dictionary build

ثالثاً: النتائج لكل منصة

بعد تشغيل الأمر، ستقوم الأداة بإنشاء الملفات التالية تلقائيًا:

للويب (CSS):

build/css/variables.css

:root {
  --color-brand-primary: #007aff;
  --color-brand-secondary: #ff9500;
  --size-font-base: 16px;
  --size-spacing-md: 16px;
  /* ... and so on */
}

للأندرويد (XML):

build/android/src/main/res/values/style_dictionary_colors.xml

<?xml version="1.0" encoding="UTF-8"?>
<resources>
  <color name="color_brand_primary">#007AFF</color>
  <color name="color_brand_secondary">#FF9500</color>
  <!-- ... -->
</resources>

لـ iOS (Swift):

build/ios-swift/StyleDictionary.swift

//
// StyleDictionary.swift
//

import UIKit

public class StyleDictionary {
  public static let colorBrandPrimary = UIColor(red: 0.000, green: 0.478, blue: 1.000, alpha: 1.000)
  public static let colorBrandSecondary = UIColor(red: 1.000, green: 0.584, blue: 0.000, alpha: 1.000)
  public static let sizeFontBase = CGFloat(16)
  // ...
}

وهكذا، بلمسة زر، أصبح لدى كل فريق ملفات محدثة وجاهزة للاستخدام، كلها من نفس المصدر. هذا هو التناغم والاتساق الذي كنا نحلم به.

نصائح أبو عمر الذهبية

بعد ما خضنا هذه التجربة، تعلمت كم درس مهم حابب أشارككم إياها:

1. ابدأ صغيراً ولكن فكر كبيراً: لا تحاول تحويل كل شيء في تصميمك إلى رموز دفعة واحدة. ابدأ بالألوان والخطوط، فهي الأكثر تأثيرًا. لكن أثناء عملك، ضع بنية تسمية قابلة للتوسع.
2. التسمية هي كل شيء: هذه أهم نصيحة. لا تسمي الرمز red-500، بل سمه color.feedback.error.default. لماذا؟ لأن التسمية الأولى تصف القيمة (“أحمر”)، بينما الثانية تصف الوظيفة (“لون الخطأ”). لو قررت في المستقبل أن لون الخطأ يجب أن يكون برتقاليًا، ستغير القيمة فقط، ويبقى اسم الرمز منطقيًا.
3. فرّق بين الخيارات والقرارات:
   • الخيارات (Choices): هي مجموعة الألوان المتاحة لك، مثل blue-100, blue-200… blue-900. هذه رموز خام.
   • القرارات (Decisions): هي كيف ستستخدم هذه الخيارات. مثلاً: color.interactive.default = blue-400. هنا أنت قررت أن اللون التفاعلي الافتراضي هو درجة الأزرق 400. هذا الفصل يجعل النظام مرنًا للغاية.
4. الأتمتة صديقك الوفي: لا تعتمد على التحديث اليدوي. اربط عملية بناء الرموز بنظام الـ CI/CD. عندما يتم دمج تغيير على ملفات JSON في الفرع الرئيسي، يجب أن يتم بناء الرموز الجديدة وتوزيعها على المشاريع المختلفة تلقائيًا.

الخلاصة يا جماعة الخير

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

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

بالتوفيق في رحلتكم من الفوضى إلى النظام! 🚀