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

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

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

بلّشنا الشغل. سارة عدّلت اللون في تصميمها على Figma، وأعطتنا كود اللون الجديد (الـ Hex code). وهون بلشت المصيبة. يا جماعة، اللون الأزرق هذا كان موجود في كل مكان: الأزرار، العناوين، الأيقونات، خلفيات الهيدر، الروابط… والقائمة تطول. والمشكلة الأكبر إنه كان موجود في ثلاث قواعد كود مختلفة: للويب (React)، وللأندرويد (Kotlin)، وللـ iOS (Swift).

قعدنا أنا والشباب يومين كاملين واحنا بنعمل “بحث واستبدال” (Find and Replace) لكود اللون القديم. كل واحد فينا فاتح الكود تبعه وبيدوّر زي المجنون على #3498db عشان يغيرها لـ #2980b9. وطبعاً، زي ما توقعتوا، صارت كوارث. مرات كنا نغير لون مش لازم يتغير، ومرات ننسى أماكن، ومرات اللون ما يزبط على شاشة معينة. ضلينا أسبوع كامل بين تعديل وتجريب وإصلاح مشاكل (bugs) طلعت بسبب هالتغيير “البسيط”. يومها قلت لواحد من الشباب: “يا زلمة، أسبوع عشان نغير لون زر؟ شو هالحكي! أكيد في طريقة أحسن”.

وهذا الموقف، هذا “الجحيم” من التعديلات اليدوية، كان هو السبب اللي خلانا نبحث ونتعمق في عالم أنظمة التصميم، وهناك وجدنا الكنز المدفون: رموز التصميم (Design Tokens).

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

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

يمكن حدا يحكي: “طيب يا أبو عمر، هاي مجرد متغيرات (variables) زي اللي بنستخدمها في CSS أو Sass”. الجواب هو نعم ولا. هي متغيرات في شكلها، لكنها فلسفة في جوهرها. الفرق الرئيسي هو أنها تجريدية ومستقلة عن أي تقنية.

رمز التصميم لا يقول “أنا كود اللون #2980b9“. بل يقول “أنا اللون الأساسي للعلامة التجارية”. هذا الاسم التجريدي (Semantic name) هو سر القوة كلها.

هيكلية رموز التصميم: من العام إلى الخاص

لفهم قوتها، خلينا نشوف كيف تُبنى عادةً. أفضل الممارسات تقترح بنية من ثلاث طبقات:

1. الرموز العالمية (Global Tokens): هذه هي القيم الخام، بدون أي سياق. هي لوحة الألوان والخيارات الكاملة المتاحة لك.
   • مثال: blue-500: #2980b9، gray-100: #f8f9fa، font-size-16: 16px.
2. الرموز الدلالية (Alias/Semantic Tokens): هنا يبدأ السحر. هذه الرموز تأخذ رمزاً عالمياً وتُعطيه معنى أو وظيفة. هي التي تجيب على سؤال “لماذا؟” أو “ماذا يفعل هذا؟”.
   • مثال: color-primary: {blue-500}، color-background-body: {gray-100}، font-size-base: {font-size-16}.
3. رموز المكونات (Component-Specific Tokens): هذه هي الطبقة الأكثر تحديداً، وتصف خاصية في مكون معين.
   • مثال: button-primary-background-color: {color-primary}، card-background-color: {color-background-body}.

لماذا هذه الهيكلية مهمة؟ لأنها تسمح بمرونة خرافية. لو قرر العميل تغيير اللون الأساسي، أنت لا تغير آلاف الأسطر من الكود، بل تغير قيمة واحدة فقط في الرموز الدلالية:

color-primary: {new-brand-color-700}

وفجأة، كل شيء يستخدم color-primary (الأزرار، العناوين، …) سيتحدث تلقائياً في كل المنصات.

كيف تبدو رموز التصميم في الواقع؟

عادةً، تُكتب رموز التصميم في ملف محايد مثل JSON أو YAML. هذا الملف هو “المصدر الوحيد للحقيقة” الذي تحدثنا عنه. خلينا نأخذ مثال بسيط لملف JSON:

{
  "color": {
    "brand": {
      "primary": { "value": "#2980b9" },
      "secondary": { "value": "#8e44ad" }
    },
    "text": {
      "default": { "value": "#343a40" },
      "subtle": { "value": "#6c757d" }
    },
    "background": {
      "body": { "value": "#ffffff" },
      "surface": { "value": "#f8f9fa" }
    }
  },
  "font": {
    "size": {
      "base": { "value": "16px" },
      "large": { "value": "20px" }
    }
  },
  "spacing": {
    "small": { "value": "8px" },
    "medium": { "value": "16px" }
  }
}

هذا الملف البسيط هو قلب نظام التصميم. المصمم يستخدم هذه الأسماء في Figma، والمطور يستخدمها في الكود.

من JSON إلى كل المنصات: أداة التحويل

هنا يأتي دور أدوات مثل Style Dictionary (من أمازون) أو Theo (من Salesforce). هذه الأدوات تأخذ ملف الـ JSON كمُدخل، وتقوم بتحويله تلقائياً إلى أي صيغة تحتاجها:

• متغيرات CSS للموقع (--color-brand-primary: #2980b9;)
• متغيرات Sass/Less
• ملفات XML للأندرويد (<color name="color_brand_primary">#2980b9</color>)
• امتدادات ألوان (Color Extensions) لـ Swift في iOS
• متغيرات JavaScript/TypeScript

تخيل معي سير العمل الجديد: المصممة “سارة” تقرر تغيير لون. تذهب إلى ملف الـ JSON المركزي، تغير قيمة واحدة، وتعمل commit. بعدها، عملية بناء (build process) تلقائية تشتغل، تأخذ هذا التغيير وتُحدّث كل ملفات الستايل لكل المنصات. المطورين فقط يعملوا pull للتحديثات، وكل شيء يتغير بدون ما يكتبوا سطر كود واحد يتعلق بالستايل.

تخيل أن مشكلة الأسبوع التي واجهناها، الآن تُحل في خمس دقائق! هذا هو الفرق الذي تصنعه رموز التصميم.

الفوائد الحقيقية التي لمسناها على أرض الواقع

1. الاتساق (Consistency): انتهى عصر “درجات الأزرق الخمسين”. كل زر، كل عنوان، كل مسافة، أصبحت متطابقة 100% في كل مكان.
2. سرعة التطوير والصيانة: طلبات التعديل البصرية لم تعد كابوساً. أصبحنا نرحب بها لأنها لم تعد تستغرق وقتاً.
3. جسور التواصل بين التصميم والبرمجة: صار المصمم والمطور يتحدثون نفس اللغة. المصمم يقول “استخدم `color-brand-primary`” بدلاً من “استخدم #2980b9“. هذا يزيل الكثير من سوء الفهم.
4. القدرة على التوسع (Scalability): إضافة منصة جديدة (كتطبيق ديسكتوب مثلاً) أصبح أسهل بكثير. كل ما نحتاجه هو إضافة “مُحوّل” جديد لرموز التصميم.
5. دعم الثيمات (Theming) بسهولة: هل تريد إضافة وضع ليلي (Dark Mode)؟ الأمر في غاية السهولة. كل ما تحتاجه هو ملف رموز تصميم آخر للوضع الليلي، وتقوم بتبديل الملفات فقط.

   
   /* Light Mode Tokens */
   :root {
     --color-background-body: #ffffff;
     --color-text-default: #343a40;
   }
   
   /* Dark Mode Tokens */
   [data-theme="dark"] {
     --color-background-body: #121212;
     --color-text-default: #f8f9fa;
   }
           

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

• ابدأ صغيراً: لا تحاول بناء نظام رموز تصميم كامل من أول يوم. ابدأ بالألوان والخطوط فقط. هذه وحدها ستوفر عليك وقتاً هائلاً.
• الأسماء، ثم الأسماء، ثم الأسماء: أهم شيء في رموز التصميم هو تسميتها. ابتعد عن الأسماء الحرفية (red-color) واستخدم الأسماء الدلالية (color-danger, color-error-background). اسأل نفسك دائماً “ما هي وظيفة هذا الرمز؟” وليس “ما هي قيمته؟”.
• اجعلها المصدر الوحيد للحقيقة: يجب أن يكون هناك مكان واحد فقط لتعديل هذه الرموز. سواء كان ملف JSON في Git repo أو أداة متخصصة مثل Figma Tokens. لا تسمح بوجود قيم “سحرية” (magic numbers) مكتوبة مباشرة في الكود.
• الأتمتة هي صديقك: استثمر وقتاً في إعداد عملية بناء (build pipeline) تقوم بتحويل الرموز تلقائياً. هذا الاستثمار سيعود عليك بأضعاف مضاعفة في المستقبل.

الخلاصة ✨

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

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