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

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

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

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

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

الفوضى الخلاّقة: تشخيص مشكلة “الجزر المعزولة”

قبل ما نحكي عن الحل، خلينا نوصف المشكلة اللي كنا عايشينها (واللي يمكن كثير منكم بعيشها الآن). أعراض المرض كانت واضحة:

  • عدم الاتساق الكارثي: نفس الزر له 5 أشكال مختلفة عبر 3 تطبيقات. لوحة الألوان تتغير من صفحة لصفحة. تجربة المستخدم كانت زي اللي ماشي في مدينة ما فيها لافتات، كل شارع شكل.
  • هدر الوقت والجهد: كان المطورون يقضون ساعات في بناء مكونات (Components) تم بناؤها عشرات المرات من قبل. المصمم كان يسلم تصميم، والمطور “يجتهد” في تطبيقه، والنتيجة تطلع إشي ثالث خالص.
  • صعوبة الصيانة والتطوير: بدك تغير لون العلامة التجارية الأساسي؟ الله يعينك. لازم تلف على كل مشروع وكل ملف CSS وتغيره يدويًا، وتصلي إنه ما تكون نسيت إشي.
  • تجربة سيئة للمستخدم النهائي: المستخدم المسكين كان يضيع. يتوقع سلوك معين من عنصر معين، ليتفاجأ بسلوك مختلف تمامًا في مكان آخر بنفس التطبيق. هذا يقتل الثقة ويقلل من قابلية الاستخدام.

“باختصار، كنا شاطرين في بناء المنتجات، بس فاشلين في بناء هوية موحدة ومتماسكة لها.”

المنقذ: ما هو “نظام التصميم” ببساطة؟

لما طرحنا فكرة “نظام التصميم”، كثير ناس فكرتها مجرد “دليل ألوان وخطوط” (Style Guide) أو “مكتبة مكونات” (Component Library). لكن الحقيقة أعمق من هيك بكثير.

تخيل نظام التصميم كصندوق ليغو (LEGO) ضخم خاص بشركتك. الصندوق هذا ما فيه بس مكعبات ملونة، بل فيه:

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

إذًا، نظام التصميم هو المصدر الوحيد للحقيقة (Single Source of Truth) لكل ما يتعلق بواجهة المستخدم وتجربة المستخدم. هو لغة مشتركة بيفهمها المصمم والمطور ومدير المنتج وحتى قسم التسويق.

أركان نظام التصميم الأربعة

نظامنا اللي بنيناه، زي أي نظام تصميم محترم، ارتكز على أربعة أعمدة أساسية:

1. الأساسات: مبادئ التصميم وقواعده

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

2. لبنات البناء: مكتبة المكونات (Component Library)

هذا هو الجزء العملي والملموس. بدأنا بجرد كل المكونات في تطبيقاتنا (Buttons, Inputs, Modals, etc.) وقمنا بتوحيدها. كل مكون صار له “هوية” واضحة وحالات مختلفة (state) مثل `default`, `hover`, `disabled`, `active`.

نصيحة أبو عمر: لا تحاول بناء كل شيء من أول يوم. ابدأ بـ “الذرات” (Atoms) مثل الأزرار وحقول الإدخال، ثم انتقل للجزيئات (Molecules) مثل نماذج البحث (Search form) التي تتكون من حقل إدخال وزر.

على سبيل المثال، مكون الزر (Button) في مكتبتنا (اللي بنيناها باستخدام React) صار يستقبل `props` بسيطة لتغيير شكله وسلوكه:


// زر أساسي
<Button>اضغط هنا</Button>

// زر ثانوي بحجم كبير
<Button variant="secondary" size="large">معلومات إضافية</Button>

// زر معطل مع أيقونة
<Button disabled icon="save">جاري الحفظ...</Button>

لاحظ كيف بطل المطور محتاج يكتب CSS لكل زر. هو فقط يختار النوع اللي بده ياه من “صندوق الليغو”.

3. اللغة المشتركة: رموز التصميم (Design Tokens)

هذه هي النقلة النوعية الحقيقية. بدل ما نكتب الألوان والخطوط بشكل مباشر في الكود (Hardcoding)، مثل `#3498db` أو `16px`، قمنا بتعريفها كـ “رموز” أو متغيرات.

مثال على ملف رموز تصميم بسيط (بصيغة JSON):


{
  "color": {
    "primary": { "value": "#3498db" },
    "neutral": {
      "100": "#ffffff",
      "900": "#2c3e50"
    }
  },
  "font": {
    "size": {
      "base": { "value": "1rem" }, // 16px
      "large": { "value": "1.25rem" } // 20px
    }
  },
  "spacing": {
    "small": { "value": "8px" },
    "medium": { "value": "16px" }
  }
}

الجمال في هذا الأسلوب؟ لو قررت الإدارة فجأة إن اللون الأزرق الأساسي لازم يتغير، كل ما علينا فعله هو تغيير قيمة `color.primary.value` في مكان واحد فقط. بعدها، يتم تحديث اللون تلقائيًا في كل مكان: في تطبيقات الويب، تطبيقات الموبايل، وحتى في ملفات التصميم على Figma. سحر، مش هيك؟

4. دليل الاستخدام: التوثيق والإرشادات

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

في توثيقنا، لكل مكون صفحة خاصة تشرح:

  • ما هو: شرح بسيط للمكون.
  • متى يستخدم: استخدم الزر الأساسي (Primary) للإجراء الأهم في الصفحة فقط.
  • متى لا يستخدم: لا تستخدم 10 أزرار أساسية في نفس الشاشة.
  • خياراته (Props): قائمة بكل الخيارات المتاحة مع أمثلة.
  • إرشادات الوصولية (Accessibility): كيف نضمن أن المكون قابل للاستخدام من قبل الجميع، بما في ذلك ذوي الاحتياجات الخاصة.

النتائج بعد المعركة: جنة المطورين والمصممين

الرحلة ما كانت سهلة وأخذت وقت وجهد، ولكن النتائج كانت مذهلة وتستحق كل دقيقة تعب. اليوم، الوضع اختلف 180 درجة:

  • سرعة في الإنجاز: بناء صفحة جديدة صار يشبه تركيب الليغو. نسحب المكونات الجاهزة ونركبها، والتركيز كله صار على منطق العمل (Business Logic) بدل تضييع الوقت في الـ CSS.
  • اتساق وهوية قوية: كل تطبيقاتنا الآن تتحدث بنفس اللغة البصرية. المستخدم يشعر أنه في بيئة مألوفة وموثوقة بغض النظر عن المنتج الذي يستخدمه.
  • تعاون أفضل: المصمم والمطور صاروا يتكلموا نفس اللغة. بدل ما المصمم يقول “بدي زر لونه أزرق”، صار يقول “استخدم `Button` مع `variant=”primary”`”.
  • صيانة أسهل: تحديث أي جزء من الهوية البصرية يتم مركزيًا وبكبسة زر.

الخلاصة: لا تبنِ جزراً، ابنِ جسوراً! 🚀

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

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

تذكروا دائمًا، الهدف هو التوقف عن إعادة اختراع العجلة في كل مرة، والبدء في بناء سيارات ومركبات فضائية بتلك العجلة الموحدة. بالتوفيق!

أبو عمر

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

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

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

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

آخر المدونات

ذكاء اصطناعي

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

أنا أبو عمر، مطور برمجيات فلسطيني، وأشارككم اليوم قصة واقعية عن نموذج ذكاء اصطناعي كاد أن يفشل بسبب غموضه. سنتعمق في مفهوم "الصندوق الأسود" وكيف...

17 أبريل، 2026 قراءة المزيد
برمجة وقواعد بيانات

استعلاماتنا كانت تزحف كالسلحفاة: كيف أنقذتنا ‘فهرسة قواعد البيانات’ من جحيم البحث الشامل؟

أتذكر ليلة كاد فيها تطبيقنا أن ينهار بسبب بطء قاتل، والسبب؟ استعلام بسيط يستغرق دهراً. في هذه المقالة، أشارككم قصة كيف اكتشفنا عدو الأداء الصامت...

17 أبريل، 2026 قراءة المزيد
الشبكات والـ APIs

تطبيقاتنا كانت تستجدي البيانات أو تغرق فيها: كيف أنقذنا GraphQL من جحيم الـ Over-fetching والـ Under-fetching؟

أشارككم قصة حقيقية من تجربتي كمبرمج، وكيف عانينا من مشاكل الأداء بسبب الطريقة التقليدية لجلب البيانات في REST APIs. سأشرح لكم كيف كانت تقنية GraphQL...

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

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

بنيتنا التحتية كانت كمدينة أشباح، سيرفرات تعمل 24/7 بتكاليف باهظة واستخدام شبه معدوم. في هذه المقالة، أشارككم يا جماعة قصتنا مع الحوسبة بدون خوادم (Serverless)...

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

سيرتي الذاتية كانت مجرد حبر على ورق: كيف أنقذتني ‘المساهمات في المشاريع المفتوحة المصدر’ من جحيم إثبات مهاراتي؟

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

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

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

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

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

رحلة التحقق من الهوية: كيف أنقذنا الذكاء الاصطناعي من جحيم التسجيل اليدوي في عالم الـFintech

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

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