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

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

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

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

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

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

ما هو “نظام التصميم” (Design System) وليش هو مهم؟

لما تسمع مصطلح “نظام تصميم”، يمكن تفكر إنه مجرد ملف فيه شوية ألوان وخطوط، أو مكتبة مكونات جاهزة (UI Kit). لكن الحقيقة أعمق من هيك بكثير. نظام التصميم هو “المصدر الوحيد للحقيقة” (Single Source of Truth) لكل ما يتعلق بواجهة وتجربة المستخدم في منتجك.

مش مجرد ألوان وأزرار!

تخيل نظام التصميم كأنه صندوق قطع “ليغو” LEGO مخصص لمشروعك. هذا الصندوق لا يحتوي فقط على القطع (المكونات)، بل يحتوي أيضاً على كتيّب الإرشادات الذي يشرح:

  • المبادئ الأساسية (Principles): الفلسفة وراء تصميمك. هل هو تصميم بسيط؟ احترافي؟ مرح؟ هذه المبادئ توجه كل قرار تصميمي.
  • الإرشادات (Guidelines): قواعد واضحة لكيفية استخدام المكونات. متى تستخدم الزر الأساسي (Primary) ومتى تستخدم الثانوي (Secondary)؟ كيف تكون المسافات بين العناصر؟
  • مكتبة المكونات (Component Library): مجموعة المكونات البرمجية الجاهزة للاستخدام (أزرار، حقول إدخال، بطاقات، إلخ) والتي يمكن للمطورين سحبها واستخدامها مباشرة.
  • الأصول التصميمية (Design Assets): ملفات التصميم التي يستخدمها المصممون (على برامج مثل Figma أو Sketch) والتي تكون متطابقة 100% مع المكونات البرمجية.

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

فوائد ما بتنعدّش

لماذا كل هذا الجهد؟ لأن الفوائد عظيمة وتستحق كل دقيقة تقضيها في بناء هذا النظام:

  1. الاتساق (Consistency): وداعاً لمشكلة الـ 5 أنواع مختلفة من الأزرار. كل شاشات تطبيقك ستبدو وكأنها جزء من عائلة واحدة، مما يعزز ثقة المستخدم ويحسن تجربته.
  2. السرعة والكفاءة (Speed & Efficiency): بدلًا من بناء زر من الصفر في كل مرة، المطور يسحب المكون الجاهز من المكتبة. هذا يسرّع عملية التطوير بشكل هائل ويسمح للفريق بالتركيز على حل المشاكل الحقيقية بدلاً من تضييع الوقت في تفاصيل الـ CSS.
  3. قابلية التوسع (Scalability): عندما ينمو فريقك أو تطبيقك، يصبح وجود نظام تصميم أمراً حيوياً. يمكن لأي مطور جديد الانضمام والبدء في الإنتاج بسرعة لأنه يمتلك كل الأدوات والإرشادات التي يحتاجها.
  4. صيانة أسهل: هل تريد تغيير لون علامتك التجارية؟ بدلاً من تعديل 50 ملف CSS، كل ما عليك فعله هو تعديل متغير اللون الأساسي في نظام التصميم، وسيتغير في كل مكان في التطبيق. سحر!

كيف تبني نظام التصميم الخاص فيك؟ (خطوة بخطوة)

بناء نظام تصميم قد يبدو مهمة ضخمة، لكن يمكنك البدء بخطوات صغيرة وعملية. هذه هي الطريقة التي أتبعها عادةً:

الخطوة الأولى: الجرد البصري (Visual Audit)

قبل أن تبني أي شيء جديد، عليك أن تعرف ما لديك حالياً. افتح تطبيقك وقم بأخذ لقطات شاشة لكل مكون فريد تراه:

  • الأزرار بكل أنواعها وأحجامها.
  • حقول الإدخال.
  • القوائم المنسدلة.
  • البطاقات (Cards).
  • الألوان المستخدمة.
  • الخطوط وأحجامها.

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

الخطوة الثانية: وضع الأساسيات (Design Tokens)

هذه هي الخطوة التقنية الأولى والأكثر أهمية. الـ Design Tokens هي متغيرات تحمل القيم الأساسية لتصميمك. بدلاً من كتابة اللون #3498db في كل مكان، ستستخدم متغيراً اسمه --color-primary.

يمكنك تعريف هذه المتغيرات في ملف JSON أو مباشرة في CSS:


/* In a central CSS file, e.g., tokens.css */
:root {
  /* Colors */
  --color-primary: #0066CC;
  --color-secondary: #6c757d;
  --color-success: #28a745;
  --color-danger: #dc3545;
  --color-text-default: #212529;
  --color-background-light: #f8f9fa;

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

  /* Fonts */
  --font-family-base: 'Cairo', sans-serif;
  --font-size-base: 16px;
  --font-weight-normal: 400;
  --font-weight-bold: 700;

  /* Borders */
  --border-radius-sm: 0.2rem;
  --border-radius-md: 0.4rem;
}

الآن، في أي مكان في الكود، يمكنك استخدام هذه المتغيرات. مثال: background-color: var(--color-primary);. هذا يجعل التعديلات المستقبلية سهلة جداً.

الخطوة الثالثة: بناء مكتبة المكونات (Component Library)

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

  • الذرات (Atoms): أصغر الوحدات البنائية التي لا يمكن تقسيمها، مثل الأزرار (Buttons)، حقول الإدخال (Inputs)، العناوين (Headings).
  • الجزيئات (Molecules): مجموعة من الذرات تعمل معًا كوحدة واحدة، مثل حقل بحث (حقل إدخال + زر بحث).
  • الكائنات (Organisms): مكونات أكثر تعقيدًا تتكون من جزيئات وذرات، مثل شريط التنقل العلوي (شعار + قائمة روابط + حقل بحث).

لنأخذ مثالاً عملياً لبناء مكون “زر” في React يستخدم الـ Tokens التي عرفناها:


// Button.jsx
// Assuming you have imported your CSS with tokens

import React from 'react';
import './Button.css'; // Let's create a CSS file for the button

const Button = ({ children, variant = 'primary', size = 'md', onClick }) => {
  // We construct the CSS class names based on props
  const className = `btn btn--${variant} btn--${size}`;

  return (
    <button className={className} onClick={onClick}>
      {children}
    </button>
  );
};

export default Button;

والآن ملف الـ CSS الخاص بالزر (Button.css):


/* Button.css */
.btn {
  font-family: var(--font-family-base);
  font-weight: var(--font-weight-bold);
  border: 1px solid transparent;
  cursor: pointer;
  transition: all 0.2s ease-in-out;
}

/* Variants */
.btn--primary {
  background-color: var(--color-primary);
  color: white;
}
.btn--primary:hover {
  opacity: 0.9;
}

.btn--secondary {
  background-color: var(--color-secondary);
  color: white;
}

/* Sizes */
.btn--md {
  padding: var(--space-sm) var(--space-md);
  font-size: var(--font-size-base);
  border-radius: var(--border-radius-md);
}

.btn--lg {
  padding: var(--space-md) var(--space-lg);
  font-size: calc(var(--font-size-base) * 1.2);
  border-radius: var(--border-radius-md);
}

الآن، أصبح لديك مكون زر قوي وقابل لإعادة الاستخدام. يمكن لأي مطور استخدامه هكذا: <Button variant="primary" size="lg">اضغط هنا</Button> وسيبدو بنفس الشكل في كل مكان.

الخطوة الرابعة: التوثيق (Documentation)

“إذا لم يكن موثقاً، فهو غير موجود.”

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

التوثيق الجيد يجيب على أسئلة مثل:

  • ما هي الخصائص التي يقبلها هذا المكون؟
  • ما هي الحالات المختلفة للمكون (default, hover, disabled, error)؟
  • أمثلة للاستخدام الصحيح (Do’s) والخاطئ (Don’ts).

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

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

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

الخلاصة: استثمر في أساسك 💡

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

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

يلا شدوا حيلكم، وابنوا أساس شغلكم صح! 💪

أبو عمر

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

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

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

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

آخر المدونات

​معمارية البرمجيات

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

أشارككم قصتي مع نظام برمجي كاد أن ينهار بسبب التشابك والاقتران المحكم بين خدماته. اكتشفوا كيف كانت المعمارية الموجهة بالأحداث (EDA) طوق النجاة الذي حوّل...

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

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

أشارككم قصتي مع استعلام SQL استغرق دقائق ليُنفّذ، وكيف تحول إلى أجزاء من الثانية بفضل الفهارس (Indexes). سنغوص في عالم فهارس قواعد البيانات، من هي؟...

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

خدماتي المصغرة كانت فوضى: كيف أنقذتني ‘بوابة الواجهات البرمجية’ (API Gateway) من جحيم الإدارة؟

أشارككم تجربتي الشخصية مع فوضى إدارة الخدمات المصغرة (Microservices) وكيف كانت بوابة الواجهات البرمجية (API Gateway) هي المنقذ الذي أعاد النظام والمنطق إلى بنيتي التحتية....

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

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

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

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

ملفي الشخصي كان مجرد مستودع أكواد صامت: كيف حوّلني ‘GitHub Profile README’ إلى مغناطيس للفرص؟

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

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

مستخدم واحد كان يشلّ خدمتي بأكملها: كيف أنقذني ‘تحديد مُعدل الطلبات’ (Rate Limiting) من جحيم هجمات الاستنزاف؟

قصة حقيقية عن ليلة كادت أن تنهار فيها خدمتي بسبب مستخدم واحد فقط، وكيف كانت تقنية 'تحديد معدل الطلبات' (Rate Limiting) هي طوق النجاة. في...

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

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

أشارككم تجربتي المريرة مع تقارير الامتثال اليدوية التي كادت أن تدمر شركتنا الناشئة، وكيف كانت التقنية التنظيمية (RegTech) طوق النجاة الذي أنقذنا من دوامة الأوراق...

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