يا جماعة الخير، السلام عليكم ورحمة الله وبركاته…
قبل كم سنة، كنت شغال على مشروع ضخم، مشروع الكل متوقع منه الكثير. فريق الواجهات الأمامية (Frontend) في واد، وفريق تطبيقات الموبايل (iOS و Android) في واد ثاني، وحتى فريق التسويق اللي بيصمم الصفحات المقصودة (Landing Pages) كان في عالم لحاله. كانت الأجواء مثل ما بنحكي عنا في فلسطين “كل مين إيدو إلو”.
أذكر تمامًا ذلك الاجتماع المصيري. كنا نستعرض النسخة التجريبية من التطبيق أمام أصحاب المصلحة. واحد منهم سأل سؤال بسيط جدًا، لكنه كان مثل الصاعقة: “ليش شكل زر ‘التالي’ في شاشة التسجيل بيختلف عن زر ‘إضافة للسلة’ في صفحة المنتج، وبيختلف عن زر ‘إرسال’ في صفحة التواصل؟ أي واحد فيهم هو الصح؟”
ساد الصمت في الغرفة. نظر المبرمجون إلى المصممين، والمصممون نظروا إلى مدراء المنتج، والكل كان يبحث عن إجابة. الحقيقة المرة كانت: ما في إجابة. كل فريق كان يصمم وينفذ “على هواه”، معتمدًا على اجتهادات شخصية. النتيجة؟ تجربة مستخدم مشتتة، مظهر غير احترافي، وكابوس صيانة للمطورين اللي كانوا يضطروا يكتبوا كود نفس المكون (الزر) عشر مرات بعشر أشكال مختلفة.
في تلك اللحظة، أدركت أننا لا نعاني من مشكلة تقنية بحتة، بل من مشكلة منهجية وتنظيم. كان الحل يكمن في كلمة واحدة ستغير كل شيء: نظام التصميم (Design System).
ما هو “نظام التصميم” وليش هو المنقذ؟
خليني أبسطلك الموضوع. تخيل أنك تبني مدينة باستخدام مكعبات الليغو (LEGO). لو كل عامل بناء جاب مكعباته الخاصة بأحجام وألوان وأشكال مختلفة، راح تطلع المدينة بالنهاية عبارة عن فوضى عارمة، صح؟
نظام التصميم هو ببساطة “علبة الليغو الموحدة” لمشروعك. هو ليس مجرد دليل ألوان (Style Guide) أو مكتبة مكونات (UI Kit)، بل هو أعمق من ذلك بكثير. إنه المصدر الوحيد للحقيقة (Single Source of Truth) الذي يجمع كل شيء تحتاجه لبناء واجهة مستخدم متماسكة وفعالة. يحتوي على:
- المبادئ الأساسية: فلسفة التصميم التي توجه قراراتنا (مثلاً: البساطة، الوضوح، سهولة الوصول).
- الأساسات: الألوان، الخطوط، المسافات، الأيقونات، الظلال… كل شيء يتم تعريفه بشكل دقيق.
- مكتبة المكونات: “مكعبات الليغو” البرمجية القابلة لإعادة الاستخدام (أزرار، حقول إدخال، بطاقات، قوائم…).
- التوثيق والإرشادات: شرح لكيفية ومتى ولماذا نستخدم كل عنصر من هذه العناصر.
من الآخر، نظام التصميم هو اللغة المشتركة اللي بيتكلم فيها المصممون والمطورون ومدراء المنتج، لضمان أن الجميع يبني بنفس الأدوات وبنفس القواعد.
رحلتنا في بناء نظام التصميم: خطوة بخطوة
بعد ذلك الاجتماع، قررنا أن “نوقف المهزلة” ونبدأ ببناء نظام التصميم الخاص بنا. لم تكن رحلة سهلة، لكنها كانت مجدية. إليكم الخطوات العملية التي اتبعناها.
الخطوة الأولى: جرد الفوضى (UI Audit)
أول خطوة كانت مواجهة الواقع. قمنا بعملية “جرد” لكل الواجهات في جميع تطبيقاتنا. أخذنا لقطات شاشة لكل زر، كل حقل إدخال، كل نافذة منبثقة، كل بطاقة… كل شيء حرفيًا. جمعناهم في ملف واحد على أداة مثل Figma.
النتيجة كانت صادمة ومضحكة في نفس الوقت. وجدنا ما يلي:
- 17 شكلًا مختلفًا للزر الأساسي (Primary Button).
- أكثر من 25 درجة مختلفة من اللون الرمادي للنصوص.
- 8 أنواع من حقول إدخال النص، كل منها له حالة خطأ (Error State) مختلفة.
نصيحة من أبو عمر: هذه الخطوة ضرورية جدًا. لا يمكنك حل مشكلة لا تعرف حجمها. عملية الجرد البصري هي التي ستمنحك الدعم من الإدارة والفرق الأخرى، لأنها تجعل المشكلة ملموسة وواضحة للجميع.
الخطوة الثانية: وضع الأساسات (Design Tokens)
بدلاً من البدء مباشرة بتصميم المكونات، بدأنا من الأساس. قمنا بتعريف ما يسمى بـ “رموز التصميم” (Design Tokens). هذه هي القيم الأولية التي ستبنى عليها كل المكونات لاحقًا. إنها متغيرات تحمل قيمًا مرئية.
على سبيل المثال، بدلاً من استخدام كود اللون #007bff في كل مكان، قمنا بتعريفه كرمز:
/* في ملف CSS للأساسات */
:root {
/* Colors */
--color-primary-500: #007bff;
--color-neutral-900: #212529;
--color-neutral-100: #f8f9fa;
--color-success-500: #28a745;
/* 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-md: 16px;
--line-height-md: 1.5;
}
هذه الطريقة عبقرية، لماذا؟ لأنه لو قررنا في المستقبل تغيير اللون الأزرق الأساسي، كل ما علينا فعله هو تغيير قيمة المتغير --color-primary-500 في مكان واحد فقط، وسيتغير اللون في كل مكان بالمشروع! هذا هو معنى “المصدر الوحيد للحقيقة”.
الخطوة الثالثة: بناء مكتبة المكونات (Component Library)
الآن جاء وقت بناء “مكعبات الليغو”. بدأنا بأصغر المكونات وأكثرها استخدامًا، والتي تسمى في منهجية “التصميم الذري” (Atomic Design) بالذرات (Atoms).
- الذرات (Atoms): مثل الأزرار (Buttons)، حقول الإدخال (Inputs)، العناوين (Headings)، الأيقونات (Icons).
- الجزيئات (Molecules): مكونات مركبة من الذرات، مثل حقل بحث (حقل إدخال + أيقونة بحث + زر).
- الكائنات (Organisms): أجزاء أكبر من الواجهة، مثل شريط التنقل العلوي (شعار + قائمة روابط + حقل بحث).
لكل مكون، قمنا بتعريف كل حالاته الممكنة: الحالة الافتراضية (Default)، عند مرور الفأرة (Hover)، عند الضغط (Active)، معطل (Disabled)، وحالة التحميل (Loading).
كمثال، مكون الزر في إطار عمل مثل React قد يبدو هكذا من حيث المبدأ:
// Button.jsx - مثال توضيحي مبسط
function Button({ children, variant = 'primary', size = 'md', isDisabled = false }) {
const baseClasses = 'btn';
const variantClasses = `btn-${variant}`; // .btn-primary, .btn-secondary
const sizeClasses = `btn-${size}`; // .btn-md, .btn-lg
return (
<button
className={`${baseClasses} ${variantClasses} ${sizeClasses}`}
disabled={isDisabled}
>
{children}
</button>
);
}
// الاستخدام
<Button variant="primary" size="lg">اضغط هنا</Button>
<Button variant="secondary" isDisabled={true}>زر معطل</Button>
بهذه الطريقة، يضمن المطورون أنهم يستخدمون دائمًا نفس الزر المعتمد، مع خيارات تخصيص محددة ومدروسة.
الخطوة الرابعة: التوثيق.. ثم التوثيق.. ثم التوثيق!
وهنا يقع الكثيرون في الفخ. بناء المكونات الرائعة لا يكفي. إذا لم يكن نظامك موثقًا بشكل جيد، فلن يستخدمه أحد. مقولتي الدائمة في الفريق كانت: “الكود الذي لا يملك توثيقًا، هو كود غير موجود”.
استخدمنا أداة مثل Storybook التي تسمح لك بعرض مكوناتك بشكل تفاعلي ومعزول، وتوثيقها في نفس المكان. لكل مكون، قمنا بتضمين:
- شرح وظيفي: ماذا يفعل هذا المكون؟
- أمثلة استخدام (Code Snippets): كيف يستخدمه المطور في الكود.
- إرشادات “افعل ولا تفعل” (Do’s and Don’ts): متى تستخدم هذا الزر الأخضر؟ ومتى لا تستخدمه؟ مع أمثلة بصرية.
- خيارات التخصيص (Props): شرح لكل الخيارات المتاحة للمكون.
التوثيق الجيد هو الجسر الذي يربط بين عالم التصميم وعالم البرمجة.
كيف أقنعنا الجميع بالالتزام؟ (Adoption & Governance)
بناء النظام كان الجزء السهل نسبيًا. الجزء الأصعب كان إقناع الفرق بتبنيه والتخلي عن طرقهم القديمة. هذا ما فعلناه:
- المشاركة من اليوم الأول: لم نبنِ النظام في غرفة مغلقة. أشركنا ممثلين من كل فريق (مصممين ومطورين) في عملية اتخاذ القرار. أصبح النظام “نظامنا” كلنا، وليس “نظام أبو عمر وفريقه”.
- إظهار القيمة بسرعة: اخترنا مشروعًا تجريبيًا صغيرًا وبنيناه بالكامل باستخدام نظام التصميم الجديد. عندما رأى الجميع كيف تمكنا من بناء واجهات متكاملة في نصف الوقت المعتاد، بدأوا بالاقتناع.
- الدعم المستمر: أنشأنا قناة خاصة على Slack لطرح الأسئلة حول نظام التصميم، وقمنا بعقد ورش عمل دورية لتدريب الأعضاء الجدد.
- حوكمة واضحة: وضعنا عملية واضحة لطلب مكون جديد أو تعديل مكون حالي. هناك نقاش، ثم تصميم، ثم موافقة، ثم تنفيذ. هذا يضمن أن النظام ينمو بشكل منظم وليس عشوائيًا.
الخلاصة: من الفوضى إلى الإبداع المنظم 💡
نظام التصميم ليس مجرد ترف أو موضة عابرة. إنه استثمار استراتيجي في منتجك الرقمي. هو ما ينقلك من حالة “كل مين يغني على ليلاه” إلى أوركسترا متناغمة تعزف نفس اللحن الجميل.
الفوائد التي جنيناها كانت هائلة: تسريع عملية التطوير، تقليل الأخطاء البصرية، تحسين تجربة المستخدم بشكل جذري، تسهيل عملية انضمام المطورين والمصممين الجدد، والأهم من كل ذلك، توفير وقتنا وجهدنا للتركيز على حل المشاكل الحقيقية للمستخدم بدلاً من النقاش حول درجة اللون الأزرق في زر ما.
نصيحتي الأخيرة لك: لا تخف من البداية. ليس عليك بناء نظام تصميم كامل من الصفر. ابدأ صغيرًا. اتفق مع فريقك على لون أساسي واحد وخط واحد وزر واحد. قم بتوثيقهم واستخدامهم في كل مكان. ثم انتقل للمكون التالي. المهم أن تبدأ، وأن تجعل من “التناسق” و”إعادة الاستخدام” ثقافة في فريقك. رويدًا رويدًا، ستجد أنك بنيت أساسًا متينًا لمشاريع عظيمة قادمة. 🌱
والله ولي التوفيق.
