مكوناتنا كانت تتكاثر كالفطر: كيف أنقذنا ‘نظام التصميم’ من جحيم الفوضى البصرية؟

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

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

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

ما هو نظام التصميم… يا جماعة؟

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

تخيلوا إنه عندكم علبة مكعبات ليغو (LEGO) ضخمة. نظام التصميم هو هاي العلبة بكل ما فيها:

• المكعبات نفسها (Components): هي الأزرار، حقول الإدخال، القوائم، البطاقات… كل قطعة بصرية في نظامك.
• كتيّب التعليمات (Guidelines & Principles): هو اللي بشرح لك كيف تركب هاي المكعبات مع بعض. متى تستخدم المكعب الأحمر ومتى الأزرق؟ كيف تبني حائط متين؟ هاي هي قواعد تجربة المستخدم، سهولة الوصول (Accessibility)، ونبرة الصوت (Tone of Voice).
• المكونات الأساسية للمكعبات (Design Tokens): هي المادة الخام اللي انصنعت منها المكعبات. الألوان، أحجام الخطوط، المسافات، الظلال. هاي هي “الذرات” اللي بتشكل كل إشي في نظامك.

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

الفوضى قبل الهدوء: كيف تعرف إنك في ورطة؟

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

عدم الاتساق… كل زر بغني على ليلاه

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

بطء التطوير والمراجعات اللي ما بتخلص

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

تجربة مستخدم “مشرشحة”

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

بناء سفينتنا: خطواتنا العملية نحو نظام تصميم متكامل

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

الخطوة الأولى: الجردة (خلينا نشوف شو إلنا وشو علينا)

أول إشي عملناه كان عملية “جرد” مؤلمة لكن ضرورية. فتحنا كل شاشات التطبيق وبلشنا نجمع “سكرين شوتس” لكل المكونات الموجودة: كل الأزرار، كل حقول الإدخال، كل التنبيهات… كل إشي. جمعناهم في ملف واحد على Figma (أو أي أداة بتستخدموها) وبلشنا نصنفهم. النتيجة كانت صدمة! لقينا عنا حوالي 15 نوع مختلف من الأزرار فقط!

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

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

بعد ما عرفنا شو عنا، قررنا نوحّد المادة الخام. هون بيجي دور الـ “Design Tokens”. هي متغيرات بتحمل قيم التصميم الأساسية. بدلاً من كتابة اللون #007bff في كل مكان، بنعرف “token” اسمه color-primary وبنستخدمه.

هذا الأسلوب بخلي التعديلات المستقبلية سهلة جداً. لو قررنا نغير اللون الأساسي للعلامة التجارية، بنغيره في مكان واحد فقط، وكل المكونات بتتحدث تلقائياً. يا سلام!

مثال بسيط على ملف tokens بصيغة JSON:

{
  "color": {
    "brand": {
      "primary": { "value": "#0052CC" },
      "secondary": { "value": "#FFC400" }
    },
    "text": {
      "default": { "value": "#172B4D" },
      "subtle": { "value": "#5E6C84" }
    }
  },
  "spacing": {
    "scale": {
      "100": { "value": "8px" },
      "200": { "value": "16px" },
      "300": { "value": "24px" }
    }
  },
  "typography": {
    "font": {
      "family": { "value": "'Tajawal', sans-serif" }
    }
  }
}

الخطوة الثالثة: بناء المكونات (من الذرة إلى المجرة)

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

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

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

مثال على مكون “زر” بسيط في React يستخدم الـ Tokens:

// Button.jsx
// بنفترض إنه عنا طريقة لتحويل ملف الـ JSON إلى متغيرات CSS

import './Button.css';

// بنستخدم متغيرات CSS اللي تم إنشاؤها من الـ Tokens
// var(--color-brand-primary)
// var(--spacing-scale-100)

const Button = ({ children, variant = 'primary', onClick }) => {
  // `variant` يمكن يكون 'primary', 'secondary', 'danger'
  const className = `btn btn--${variant}`;

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

export default Button;

الخطوة الرابعة: التوثيق هو الملك… بلا منازع

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

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

• ما هو؟ شرح بسيط للمكون ووظيفته.
• متى نستخدمه؟ (Do’s) مع أمثلة.
• متى لا نستخدمه؟ (Don’ts) مع أمثلة.
• الخيارات المتاحة (Props): مثل الحجم (size)، النوع (variant)، الحالة (disabled).
• إرشادات سهولة الوصول (Accessibility): كيف نتأكد إنه المكون قابل للاستخدام من قبل الجميع.

دروس من الخنادق: نصائح أبو عمر الشخصية

هاي الرحلة علمتني كثير، وحاب أشارككم “الزبدة” من خبرتي:

1. ابدأ صغيراً وحقق فوزاً سريعاً: لا تحاول بناء كل النظام مرة واحدة. ابدأ بأكثر مكون مؤلم عندكم (غالباً بكون الزر Button). ابنيه صح، وثّقه، وخلّي الفريق يستخدمه. هذا الفوز السريع رح يعطيكم دفعة معنوية ويقنع المشككين.
2. التعاون هو أساس النجاح: نظام التصميم ليس مشروعاً للمصممين فقط أو للمطورين فقط. هو مسؤولية مشتركة. اعملوا ورشات عمل، جلسات برمجة ثنائية (pair programming) بين المصمم والمطور، وخلي الكل يشارك في القرارات.
3. عامل النظام كمنتج مستقل: نظام التصميم هو منتج، ومستخدموه هم فريقك (المطورين والمصممين). لازم يكون له مدير منتج (أو شخص مسؤول)، وخارطة طريق، وتحديثات دورية. لا تعامله كمشروع جانبي، وإلا سيموت.
4. التبني هو التحدي الأكبر: بناء النظام جزء من المعادلة، لكن إقناع الفرق الأخرى باستخدامه هو الجزء الأصعب. لازم “تسوق” للنظام داخلياً. أظهر لهم كيف بيوفر وقتهم، بيحسن جودة شغلهم، وبخليهم يركزوا على الإبداع بدلاً من إعادة اختراع العجلة.

الخلاصة… والزبدة

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

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