واجهاتنا كانت فوضى: كيف أنقذني ‘نظام التصميم’ (Design System) من كابوس عدم الاتساق؟

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

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

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

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

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

ما هو “نظام التصميم”؟ وليش هو مش مجرد “مكتبة واجهة مستخدم”؟

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

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

إذًا، نظام التصميم ليس مجرد مكتبة مكونات (UI Kit)، بل هو منظومة متكاملة تشمل:

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

باختصار، هو “المصدر الوحيد للحقيقة” (Single Source of Truth) لكل ما يتعلق بواجهة وتجربة المستخدم في مشروعك.

الكابوس بالتفصيل: أعراض غياب نظام التصميم

قبل ما ننتقل للحل، مهم نعرف حجم المشكلة اللي كنا فيها (واللي يمكن أنت فيها الآن). غياب النظام كان يسبب لنا مشاكل يومية:

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

رحلة الإنقاذ: بناء أول نظام تصميم لنا خطوة بخطوة

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

المرحلة الأولى: جرد الأصول (The UI Audit)

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

النتيجة؟ كانت صادمة! وجدنا 12 نوعًا مختلفًا من الأزرار التي من المفترض أن تكون “زرًا أساسيًا” واحدًا. كانت هذه اللحظة التي قلنا فيها بصوت واحد: “لازم نصلح هاي الفوضى”.

المرحلة الثانية: وضع القواعد الأساسية (The Foundation)

هنا بدأنا بوضع حجر الأساس. بدل ما نصمم مكونات، صممنا “الذرات” التي تتكون منها هذه المكونات. هذا المفهوم يُعرف بـ رموز التصميم (Design Tokens).

الفكرة بسيطة: بدل ما نكتب الألوان والمسافات بشكل مباشر في الكود (Hardcoding)، نخزنها في متغيرات مركزية.

مثال عملي برموز التصميم (CSS Variables)

الطريقة القديمة (السيئة):

.card {
  background-color: #FFFFFF;
  border: 1px solid #E1E4E8;
  padding: 16px;
  border-radius: 6px;
}

.button-primary {
  background-color: #007AFF;
  font-size: 14px;
  padding: 8px 16px;
}

الطريقة الجديدة باستخدام رموز التصميم:

/* tokens.css - المصدر الوحيد للحقيقة */
:root {
  /* Colors */
  --color-primary-500: #007AFF;
  --color-neutral-0: #FFFFFF;
  --color-neutral-200: #E1E4E8;

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

  /* Fonts */
  --font-size-sm: 14px;
  --font-size-md: 16px;

  /* Borders */
  --border-radius-md: 6px;
}

/* استخدام الرموز في المكونات */
.card {
  background-color: var(--color-neutral-0);
  border: 1px solid var(--color-neutral-200);
  padding: var(--space-md);
  border-radius: var(--border-radius-md);
}

.button-primary {
  background-color: var(--color-primary-500);
  font-size: var(--font-size-sm);
  padding: var(--space-sm) var(--space-md);
}

بهذه الطريقة، لو قررنا في المستقبل تغيير اللون الأساسي، نغيره في مكان واحد فقط (`–color-primary-500`)، وسيتغير في كل التطبيق بشكل سحري!

المرحلة الثالثة: بناء مكتبة المكونات

بعد وضع الأساس، بدأنا في بناء “المكعبات”. بدأنا من الأصغر إلى الأكبر (مفهوم يسمى Atomic Design):

1. الذرات (Atoms): أصغر الوحدات مثل: الألوان، الخطوط، الأيقونات، وحقول الإدخال، والأزرار. قمنا ببناء مكون <Button /> واحد يمكن تخصيصه ليصبح أساسيًا، ثانويًا، صغيرًا، أو كبيرًا.
2. الجزيئات (Molecules): مجموعات من الذرات تعمل معًا، مثل حقل إدخال مع عنوانه ورسالة خطأ.
3. الكائنات (Organisms): مكونات أكثر تعقيدًا تتكون من جزيئات وذرات، مثل شريط التنقل العلوي (Navbar) أو نموذج تسجيل الدخول الكامل.

كل مكون جديد كنا نبنيه، نضعه في مكتبة مشتركة ونكتب له توثيقًا واضحًا.

المرحلة الرابعة: التوثيق والنشر

نظام تصميم بدون توثيق جيد هو مجرد مجلد مليء بالكود لن يستخدمه أحد. هذه نقطة جوهرية.

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

• ما هو: شرح بسيط لوظيفة المكون.
• متى تستخدمه: سياق الاستخدام الصحيح.
• كيف تستخدمه: مثال على الكود وخيارات التخصيص المتاحة (Props).
• افعل ولا تفعل (Do’s and Don’ts): أمثلة بصرية على الاستخدام الصحيح والخاطئ للمكون.

أصبح هذا الموقع هو المرجع الأول لأي مصمم أو مطور في الفريق.

نصائح من قلب الميدان (من خبرة أبو عمر)

بناء نظام تصميم رحلة طويلة، وهذه بعض النصائح اللي تعلمتها بالطريقة الصعبة:

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

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

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

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

فكّر فيها… استثمار للمستقبل، مش مجرد شغل زيادة. والله ولي التوفيق.