كانت واجهاتنا خليطاً عجيباً: كيف أنقذتنا ‘رموز التصميم’ (Design Tokens) من فوضى التناقضات؟

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

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

كل تعديل بسيط على التصميم كان يعني جولة مكوكية على ثلاثة فرق مختلفة، وثلاث قواعد كود مختلفة، وعشرات الملفات اللي لازم تتعدل يدويًا. كانت عملية مرهقة، ومصدر لا ينتهي للأخطاء والتناقضات. ومن رحم هذه المعاناة، وجدنا الحل الذي أنقذنا: رموز التصميم (Design Tokens).

ما هي رموز التصميم (Design Tokens)؟ وليش هي مهمة؟

خليني أبسطها قد ما أقدر. رموز التصميم هي ببساطة “متغيرات” (Variables) لكن للتصميم. بدل ما تتعامل مع قيم ثابتة ومباشرة مثل كود لون الهيكس #0A74F0 أو حجم خط 16px، إنت بتعطي هاي القيم أسماء ذات معنى، أسماء بتوصف وظيفتها.

يعني بدل ما تقول “استخدم اللون الأزرق السماوي”، بتقول “استخدم color-brand-primary“. وبدل ما تقول “المسافة بين الفقرات 16 بكسل”، بتقول “استخدم spacing-medium“.

هذه الأسماء (الرموز) يتم تخزينها في مكان مركزي واحد. ومن هذا المكان، يتم توزيعها تلقائيًا على كل المنصات (ويب، iOS، أندرويد، إلخ). الفكرة هي إنشاء “مصدر حقيقة واحد” (Single Source of Truth) لكل القرارات التصميمية في مشروعك.

ببساطة، رموز التصميم هي اللغة المشتركة اللي بيتكلم فيها المصممين والمطورين لضمان إنه الكل “بغني على نفس اللحن”.

الفوضى قبل الرموز: قصة “الأزرق المفقود”

عشان تفهموا حجم المشكلة اللي كنا فيها، خلوني أشرحلكم سير العمل القديم (الكارثي):

  1. المصمم يختار لون أزرق جميل على برنامج Figma ويعطينا الكود: #0A74F0.
  2. مطور الويب يأخذ الكود ويضعه في ملف CSS: --brand-blue: #0A74F0;
  3. مطور iOS يفتحه على Xcode ويضعه في كود Swift: let brandBlue = UIColor(hex: "#0A74F0")
  4. مطور أندرويد يضعه في ملف XML: <color name="brand_blue">#0A74F0</color>

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

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

الحل السحري: كيف طبقنا رموز التصميم عملياً؟

بعد ما “أكلنا هوا” بما فيه الكفاية، قررنا نوقف ونعيد التفكير. جلسنا، مصممين ومطورين، وقررنا تبني نظام رموز التصميم. العملية مرت بثلاث مراحل رئيسية.

الخطوة الأولى: تحديد “الذرات” البصرية

أول شيء عملناه هو جرد كل العناصر الأساسية في تصميمنا. فتحنا التطبيقات وبدأنا ندوّن: ما هي الألوان التي نستخدمها؟ ما هي أحجام الخطوط؟ ما هي المسافات القياسية (4px, 8px, 16px)؟ ما هي أنماط الظل؟

هذه هي “الذرات” التي يتكون منها تصميمنا. اتفقنا على تسميتها بأسماء وظيفية. مثلاً:

  • #0A74F0 أصبح اسمه color.brand.primary (لون العلامة التجارية الأساسي).
  • #FFFFFF أصبح اسمه color.text.on-primary (لون النص فوق اللون الأساسي).
  • 16px أصبحت font.size.body.default (حجم خط النص الأساسي).
  • 8px أصبحت spacing.small (مسافة صغيرة).

الخطوة الثانية: إنشاء المصدر الموحد (Single Source of Truth)

بعد ما اتفقنا على الذرات وأسمائها، قمنا بإنشاء ملف مركزي واحد يحتوي على كل هذه التعريفات. أشهر صيغة مستخدمة لهذا الغرض هي JSON، لأنها سهلة القراءة للبشر والآلات على حد سواء.

أصبح لدينا ملف يشبه هذا:


{
  "color": {
    "brand": {
      "primary": { "value": "#0A74F0", "comment": "اللون الرئيسي للعلامة التجارية" }
    },
    "text": {
      "default": { "value": "#222222", "comment": "لون النص الافتراضي" },
      "on-primary": { "value": "#FFFFFF", "comment": "لون النص الذي يظهر فوق اللون الأساسي" }
    }
  },
  "spacing": {
    "small": { "value": "8px" },
    "medium": { "value": "16px" },
    "large": { "value": "32px" }
  },
  "font": {
    "size": {
      "body": {
        "default": { "value": "16px" }
      },
      "heading": {
        "h1": { "value": "32px" }
      }
    }
  }
}

الخطوة الثالثة: الأتمتة والتوزيع (هنا يكمن السحر)

هذا الملف المركزي (JSON) هو كنزنا، لكنه لا يفيد بشيء لوحده. هنا يأتي دور أدوات الأتمتة. أشهر أداة في هذا المجال هي Style Dictionary من أمازون، وهناك أدوات أخرى مثل Figma Tokens.

هذه الأدوات تقوم بقراءة ملف الـ JSON المركزي، وتقوم تلقائيًا بتوليد الملفات الخاصة بكل منصة.

  • للوeb: تقوم بتوليد ملف CSS Variables أو SCSS Variables.
    
    :root {
      --color-brand-primary: #0A74F0;
      --spacing-medium: 16px;
    }
        
  • للأندرويد: تقوم بتوليد ملف `colors.xml` و `dimens.xml`.
    
    <?xml version="1.0" encoding="utf-8"?>
    <resources>
      <color name="color_brand_primary">#0A74F0</color>
      <dimen name="spacing_medium">16dp</dimen>
    </resources>
        
  • للـ iOS: تقوم بتوليد ملف Swift يحتوي على ثوابت.
    
    import UIKit
    
    public class StyleDictionary {
      public static let colorBrandPrimary = UIColor(red: 0.039, green: 0.455, blue: 0.941, alpha: 1.000)
      public static let spacingMedium = CGFloat(16.00)
    }
        

والآن، إذا أردنا تغيير اللون الأساسي، كل ما علينا فعله هو تعديل قيمة color.brand.primary في ملف الـ JSON مرة واحدة فقط. ثم نقوم بتشغيل أمر بسيط في الطرفية (Terminal)، وفجأة، يتم تحديث كل الملفات على كل المنصات تلقائيًا. لا أخطاء بشرية، لا تناقضات، ولا “أزرق مفقود”.

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

من خبرتي في هذا المجال، حاب أعطيكم كم نصيحة عملية لو قررتوا تتبنوا هاي الطريقة:

  • ابدأ صغيراً: لا تحاول تحويل كل تصميمك لرموز في يوم وليلة. ابدأ بالأهم: الألوان والمسافات. ثم انتقل للخطوط، ثم الظلال، وهكذا. “حبة حبة بتطلع الدرج”.
  • التسمية هي كل شيء: فكر جيداً في بنية تسمية الرموز. القاعدة الذهبية هي أن تصف وظيفة الرمز وليس قيمته. لا تسمي الرمز red-500، بل سمه color.feedback.error (لون التنبيهات الخاصة بالخطأ). هذا يسهل عليك تغيير لون الخطأ في المستقبل من الأحمر إلى البرتقالي مثلاً، دون الحاجة لتغيير اسم الرمز.
  • التعاون مفتاح النجاح: رموز التصميم هي الجسر الذي يربط بين المصممين والمطورين. يجب أن تجلسوا معًا، “اشربوا فنجان قهوة واتفقوا” على الأسماء والبنية. هذا الملف المركزي هو عقد اتفاق بينكم.
  • استخدم أدوات مساعدة: لا تخترع العجلة. أدوات مثل Style Dictionary أو الإضافات المخصصة لـ Figma (مثل Figma Tokens) ستوفر عليك ساعات طويلة من العمل اليدوي.

الخلاصة: من الفوضى إلى النظام 🚀

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

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

بالتوفيق يا جماعة، وإن شاء الله دايماً شغلكم مرتب ومتناسق.

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

تجربة المستخدم والابداع البصري

كان تطبيقنا سجنًا رقميًا: كيف أنقذتنا ‘إمكانية الوصول’ (Accessibility) من جحيم استبعاد المستخدمين؟

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

14 مايو، 2026 قراءة المزيد
الحوسبة السحابية

كانت خوادمنا خاملة 90% من الوقت: كيف أنقذتنا ‘الحوسبة بدون خوادم’ (Serverless) من جحيم التكاليف المهدرة؟

أشارككم قصة حقيقية من تجربتي كمطور، كيف كنا ندفع مئات الدولارات على خوادم شبه نائمة، وكيف كانت معمارية "الحوسبة بدون خوادم" (Serverless) طوق النجاة الذي...

14 مايو، 2026 قراءة المزيد
التوظيف وبناء الهوية التقنية

كانت إجاباتي في المقابلات عشوائية: كيف أنقذتني منهجية STAR من جحيم أسئلة “حدثنا عن موقف…”؟

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

14 مايو، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

كيف أنقذ ‘موازن الحمل’ خادمنا الوحيد من الانهيار؟ قصة من قلب المعركة

هل يواجه تطبيقك بطئًا وتوقفًا مفاجئًا مع زيادة عدد المستخدمين؟ في هذه المقالة، أشارككم قصتي مع انهيار خادمنا الوحيد وكيف كان 'موازن الحمل' (Load Balancer)...

14 مايو، 2026 قراءة المزيد
التكنلوجيا المالية Fintech

من كشط الشاشة إلى الخدمات المصرفية المفتوحة: كيف أنقذت واجهات الـ API تطبيقاتنا المالية؟

أشارككم قصة من قلب المعركة التقنية، كيف انتقلنا في عالم التكنولوجيا المالية من جحيم "كشط الشاشة" الهش والمليء بالمخاطر، إلى نعيم واجهات الخدمات المصرفية المفتوحة...

14 مايو، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

وداعاً لـ `kubectl apply -f`: كيف حولنا إدارة Kubernetes إلى عملية آلية وموثوقة مع GitOps؟

في هذه المقالة، يشارككم أبو عمر، مطور برمجيات فلسطيني، قصة حقيقية حول مخاطر الإدارة اليدوية لـ Kubernetes وكيف أنقذنا مبدأ GitOps من كوارث محتملة. سنتعمق...

13 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

كانت الأفكار تموت في صمت: كيف أنقذتنا ‘السلامة النفسية’ من جحيم الخوف من الفشل؟

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

13 مايو، 2026 قراءة المزيد
البودكاست