مكوناتنا كانت فوضى: كيف أنقذنا “نظام التصميم” من جحيم عدم الاتساق؟

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

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

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

الجحيم اللي كنا عايشين فيه: فوضى ما إلها آخر

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

أزرار بألف لون وشكل

الزر، أبسط مكون في أي واجهة مستخدم، كان عنا متحف فنون حديثة. كل مطور كان يصنع زره الخاص. شوفوا مثلاً هالكودين اللي بيعملوا (نظرياً) نفس الأشي: زر أساسي.

الزر الأول (من كود المطور “أ”):

<button style="background-color: #007bff; color: white; padding: 10px 20px; border-radius: 5px; border: none;">
  إضافة للسلة
</button>

الزر الثاني (من كود المطور “ب”):

.primary-button {
  background: #007acc;
  color: #FFF;
  padding: 12px 18px;
  border-radius: 8px;
  border: 1px solid #005c99;
  font-weight: bold;
}

النتيجة؟ زرين مختلفين في الحجم، اللون، الحواف، وحتى في طريقة الكتابة (inline style vs class). ولما كان يجي تعديل على تصميم الأزرار، كنا نحتاج نلف على المشروع كله ونعدّل في عشرات الأماكن، وغالباً كنا ننسى كم واحد منهم.

رحلة البحث عن اللون “الأزرق الصح”

مشكلة الألوان كانت قصة لحالها. في ملفات الـ CSS تبعتنا، كنت تلاقي مهرجان ألوان:

  • color: #337ab7;
  • background-color: blue;
  • border-color: rgb(51, 122, 183);
  • $primary-color: #337ab7; (في ملف Sass)
  • --main-blue: #337AB7; (في ملف CSS آخر)

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

“وين الكود تبع البطاقة؟” – التكرار القاتل

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

بناء سفينة النجاة: خطواتنا لإنشاء نظام التصميم

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

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

وقررنا نبني سفينة النجاة الخاصة فينا. هاي هي الخطوات اللي اتبعناها:

المرحلة الأولى: الجرد والتوثيق (The UI Audit)

أول خطوة كانت أشبه بعملية “تنقيب أثري”. قمنا بجرد كل المكونات الموجودة في التطبيق. فتحنا كل الشاشات وأخذنا لقطات شاشة لكل الأزرار، حقول الإدخال، البطاقات، القوائم، وكل شي. جمعناهم في مكان واحد (استخدمنا أداة زي Figma) وبلشنا نشوف حجم الكارثة. كان عنا 15 نوع زر مختلف، و8 أنواع بطاقات، وعدد لا نهائي من درجات اللون الرمادي.

المرحلة الثانية: وضع المبادئ والأساسات (The Foundations)

بعد ما عرفنا شو عنا، كان لازم نقرر شو بدنا. قعد المصممون مع المطورين لوضع الأساسات. هاي الأساسات هي الـ DNA تبع نظامنا الجديد:

  • الرموز التصميمية (Design Tokens): هاي كانت أهم خطوة تقنية. بدل ما نستخدم قيم ثابتة (hard-coded) زي #007bff أو 16px، قمنا بتعريف “رموز” أو متغيرات لكل شي. هاي الرموز هي قيم مجردة بتمثل خيارات التصميم.

مثال على ملف رموز للألوان باستخدام متغيرات CSS:

:root {
  /* Colors */
  --color-primary-500: #007bff;
  --color-primary-600: #0069d9;
  --color-neutral-100: #f8f9fa;
  --color-neutral-900: #212529;

  /* Spacing */
  --space-xs: 4px;
  --space-sm: 8px;
  --space-md: 16px;
  --space-lg: 32px;

  /* Fonts */
  --font-size-body: 16px;
  --font-size-h1: 32px;
}

هيك، بدل ما أكتب color: #007bff، صرت أكتب color: var(--color-primary-500). لو حبينا نغير اللون الأساسي في المستقبل، بنغيره في مكان واحد بس!

  • سلم الخطوط (Typography Scale): حددنا أحجام وخطوط ثابتة لكل العناوين والنصوص (h1, h2, body, caption).
  • لوحة الألوان (Color Palette): اعتمدنا لوحة ألوان واضحة ومحددة: لون أساسي، ثانوي، لون للنجاح، لون للخطأ، ودرجات من اللون الرمادي.

المرحلة الثالثة: بناء مكتبة المكونات (The Component Library)

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

  1. الذرات (Atoms): بنينا أصغر الوحدات زي الزر (Button)، حقل الإدخال (Input)، الأيقونة (Icon).
  2. الجزيئات (Molecules): ركبنا الذرات مع بعض لنعمل مكونات أعقد، زي حقل بحث (مكون من حقل إدخال وزر بحث).
  3. الكائنات (Organisms): جمعنا الجزيئات لنعمل أجزاء أكبر من الواجهة، زي الهيدر (Header) أو قائمة المنتجات.

شوفوا مثلاً كيف صار شكل مكون “الزر” الجديد (مثال باستخدام React):

// Button.jsx
// بنستخدم مكتبة زي classnames عشان ندمج الكلاسات بسهولة
import cx from 'classnames'; 
import './Button.css'; // ملف الـ CSS اللي بيستخدم الـ Design Tokens

const Button = ({ children, variant = 'primary', size = 'medium', disabled = false, ...props }) => {
  const buttonClasses = cx(
    'btn', // الكلاس الأساسي
    `btn--${variant}`, // btn--primary, btn--secondary
    `btn--${size}`, // btn--small, btn--medium
    { 'btn--disabled': disabled }
  );

  return (
    <button className={buttonClasses} disabled={disabled} {...props}>
      {children}
    </button>
  );
};

export default Button;

الآن، أي مطور بده زر، بيستخدم هذا المكون. ما في مجال للاجتهاد الشخصي. بده زر كبير أخضر؟ بسيطة: <Button variant="success" size="large">تأكيد</Button>. الكل بيستخدم نفس اللغة ونفس الكود.

المرحلة الرابعة: التوثيق والنشر (Documentation & Publishing)

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

أرض الميعاد: الفوائد اللي حصدناها

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

سرعة خرافية في التطوير 🚀

بناء صفحة جديدة صار يشبه اللعب بالمكعبات (LEGO). بدل ما نبني كل مكون من الصفر، صرنا نسحب المكونات الجاهزة من المكتبة ونركبها. مهمة كانت تاخذ يومين، صارت تاخذ 3 ساعات.

اتساق يريح العين والقلب

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

صيانة أسهل، وصداع أقل 🤕

لما قررنا نعدّل على شكل الحواف في كل الأزرار ونخليها أكثر دائرية، التعديل أخذ 5 دقائق بالضبط. غيرنا قيمة متغير واحد في ملف الـ Design Tokens، وكل شي تحدث تلقائياً. لا بحث ولا تكرار ولا وجع راس.

لغة مشتركة بين المطورين والمصممين

صار في لغة موحدة. المصمم ما عاد يقول “بدي زر أزرق”، صار يقول “استخدم Button--primary“. المطور فاهم عليه بالضبط. النقاشات صارت أسرع وأكثر فعالية.

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

إذا كنتم بتفكروا تبنوا نظام تصميم خاص فيكم، اسمحولي أقدملكم كم نصيحة من القلب، من خبرتي في الميدان:

  • ابدأوا صغاراً: ما تحاولوا تبنوا كل شي مرة واحدة. ابدأوا بأهم 3-5 مكونات (الزر، حقل الإدخال، الألوان، الخطوط). بعدين توسعوا شوي شوي.
  • الكل لازم يشارك: نظام التصميم مش مسؤولية المطورين لحالهم أو المصممين لحالهم. هو مسؤولية مشتركة. لازم الكل يقتنع بالفكرة ويشارك في بنائها.
  • اعتبروه منتجاً، وليس مشروعاً جانبياً: نظام التصميم هو منتج داخلي له مستخدمين (المطورين والمصممين)، ولازم يكون له مسؤول، وخطة عمل، وتحديثات مستمرة.
  • التوثيق ثم التوثيق ثم التوثيق: استثمروا في أدوات توثيق جيدة زي Storybook أو Zeroheight. التوثيق هو اللي بيخلي النظام حي وقابل للاستخدام.

الخلاصة ✨

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

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

ويلا، شدّوا حيلكم! 💪

أبو عمر

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

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

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

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

آخر المدونات

أتمتة العمليات

إشعاراتنا كانت ضجيجاً والمهام تتطلب التنقل بين ألف شاشة: كيف أنقذنا ChatOps من جحيم الفوضى التشغيلية؟

أشارككم تجربتي كـ"أبو عمر"، مبرمج فلسطيني، في تحويل فوضى الإشعارات والتنقل بين الأنظمة إلى بيئة عمل منظمة وفعالة باستخدام ChatOps. اكتشفوا كيف أتمتنا عملياتنا، ووفرنا...

12 أبريل، 2026 قراءة المزيد
نصائح برمجية

شروطنا المتشعبة كانت متاهة: كيف أنقذتنا ‘شروط الحماية’ (Guard Clauses) من جحيم الـ if-else المتداخل؟

هل تعاني من تداخل الشروط في الكود؟ أشاركك قصة حقيقية وكيف غيّرت 'شروط الحماية' (Guard Clauses) طريقة كتابتي للكود، محولةً المتاهات المعقدة إلى مسارات واضحة...

12 أبريل، 2026 قراءة المزيد
​معمارية البرمجيات

خدماتنا كانت متشابكة كخيوط العنكبوت: كيف أنقذتنا ‘المعمارية الموجهة بالأحداث’ (EDA) من جحيم الاعتمادية المباشرة؟

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

12 أبريل، 2026 قراءة المزيد
ذكاء اصطناعي

قرارات نموذجنا كانت صندوقاً أسود: كيف أنقذتنا تقنيات التفسير (XAI) من جحيم التنبؤات الغامضة؟

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

12 أبريل، 2026 قراءة المزيد
خوارزميات

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

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

12 أبريل، 2026 قراءة المزيد
تجربة المستخدم والابداع البصري

تطبيقنا كان حصناً منيعاً: كيف أنقذتنا ‘معايير الوصول الرقمي (WCAG)’ من جحيم الإقصاء الرقمي؟

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

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