مكوناتنا كانت جزرًا معزولة: كيف أنقذنا ‘نظام التصميم’ (Design System) من جحيم الفوضى

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

قبل كم سنة، كنا شغالين على مشروع كبير، تطبيق ضخم فيه واجهات كثيرة ومتعددة. كنت مسؤول عن فريق الواجهات الأمامية (Frontend)، وكان معنا فريق ثاني للتصميم وفريق للواجهات الخلفية. في يوم من الأيام، طلب منا مدير المنتج تعديل بسيط: تغيير درجة اللون الأزرق الأساسي في العلامة التجارية للشركة، وتكبير حجم الخط في الأزرار الرئيسية بمقدار 2 بكسل.

قلت في نفسي: “بسيطة، شغلة نص ساعة بالكثير”. يا ريت! اللي صار كان كابوس حقيقي. بعد ما بدأنا الشغل، اكتشفنا إنه اللون الأزرق هذا موجود بـ 17 درجة مختلفة في 80 ملف CSS مختلف! وكل زر له استايل خاص فيه. زر في صفحة تسجيل الدخول يختلف عن زر في صفحة الإعدادات، واللي يختلف عن زر في صفحة التقارير. قضينا ثلاثة أيام، نعم ثلاثة أيام كاملة، نلاحق الألوان والأزرار في كل زاوية من زوايا المشروع. وقتها وقفت مع الشباب وقلتلهم: “يا جماعة، شو هالفوضى؟ شغلنا صار زي اللي برقع ثوب مهلهل، كل ما تسكر فتحة بتطلعلك عشرة غيرها. لازم نلاقي حل جذري”.

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

ما هو الجحيم الذي كنا نعيش فيه؟ (مشكلة الجزر المعزولة)

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

• انعدام الاتساق (Inconsistency): كما ذكرت في القصة، كل جزء من التطبيق كان له شكل وملمس مختلف. هذا يؤذي تجربة المستخدم ويجعل المنتج يبدو غير احترافي.
• إعادة اختراع العجلة (Reinventing the Wheel): كل مطور جديد ينضم للمشروع، أو كل مهمة جديدة، كانت تعني بناء مكونات من الصفر. لدينا 5 أنواع مختلفة من الـ “Date Picker” لأن كل مطور بناه بطريقته. هذا هدر فظيع للوقت والجهد.
• صعوبة الصيانة والتطوير: التعديل البسيط اللي حكيت عنه أثبت لنا أن أي تغيير مستقبلي سيكون كارثة. الكود كان متشابكًا وهشًا، وتغيير شيء في مكان قد يكسر عشرة أشياء في أماكن أخرى.
• فجوة بين التصميم والتنفيذ: المصممون يسلموننا تصميم جميل ومتناسق في برنامج Figma، ولكن ما يتم تنفيذه على أرض الواقع شيء مختلف تمامًا. لا توجد لغة مشتركة بين المصمم والمطور.

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

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

لما بدأنا نبحث عن حل، تعرفنا على مصطلح “نظام التصميم”. في البداية، اعتقدنا أنه مجرد “Style Guide” أو مكتبة مكونات (Component Library). لكنه أعمق من ذلك بكثير.

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

مكونات نظام التصميم الأساسية

نظامنا، مثل معظم الأنظمة، قمنا ببنائه على عدة أعمدة رئيسية:

1. المبادئ التوجيهية (Design Principles): هذه هي الروح والفلسفة. أسئلة مثل: ما هي قيمنا؟ هل نفضل البساطة أم الوفرة؟ الوضوح أم الجمالية؟ هذه المبادئ توجه قراراتنا. مثلاً، من مبادئنا كان: “الوضوح قبل الإبداع”.
2. اللغة البصرية (Visual Language): هذه هي الذرات الأساسية.
   • الألوان (Colors): لوحة ألوان محددة وواضحة (لون أساسي، ثانوي، لون للنجاح، للخطر، إلخ) مع أسماء واضحة (مثلاً: `primary.500`, `red.400`).
   • الطباعة (Typography): مجموعة محددة من أحجام الخطوط وأوزانها (H1, H2, Body, Caption).
   • المسافات (Spacing): نظام للمسافات والهوامش (e.g., 4px, 8px, 16px, 32px) لتصبح المسافات بين العناصر متوقعة ومتناسقة.
   • الأيقونات (Iconography): مكتبة أيقونات موحدة بأسلوب واحد.
3. مكتبة المكونات (Component Library): هذا هو الجزء العملي والملموس. هي مجموعة من المكونات البرمجية القابلة لإعادة الاستخدام (مثل الأزرار، حقول الإدخال، البطاقات، القوائم). كل مكون يتم بناؤه مرة واحدة بشكل متقن، ثم يعاد استخدامه في كل مكان.
4. الأنماط والإرشادات (Patterns & Guidelines): هنا نجيب على سؤال “كيف؟”. كيف نستخدم هذه المكونات معًا لحل مشكلة معينة؟ مثلاً، “نمط تسجيل الدخول” يوضح كيفية استخدام مكونات حقل الإدخال والزر ورسائل الخطأ معًا لتكوين نموذج تسجيل دخول فعال.

رحلتنا العملية في بناء نظام التصميم

الكلام النظري جميل، لكن “الحكي ما بطعمي خبز”. خلونا ندخل في التفاصيل العملية وكيف بنينا هذا النظام خطوة بخطوة.

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

أول خطوة كانت مواجهة الواقع المؤلم. قمنا بعملية جرد لكل المكونات الموجودة في تطبيقاتنا. فتحنا كل الصفحات وأخذنا لقطات شاشة لكل زر، كل حقل إدخال، كل قائمة منسدلة، كل لون… وجمعناها كلها في ملف Figma واحد.

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

المرحلة الثانية: وضع الأساسات (Defining Foundations)

بعد مرحلة الصدمة، جلسنا معًا – مطورون ومصممون – لوضع حجر الأساس. بدأنا بالأشياء البسيطة:

• الألوان: اتفقنا على لوحة ألوان نهائية. لكل لون درجاته (من 50 إلى 900) وأعطيناها أسماء رمزية (Tokens) مثل --color-primary-500.
• الخطوط: اخترنا عائلة خطوط واحدة، وحددنا مقياسًا هرميًا واضحًا لأحجام الخطوط (e.g., `12px`, `14px`, `16px`, `20px`, `24px`).
• المسافات: اعتمدنا مقياسًا يعتمد على مضاعفات الرقم 4 (4px, 8px, 12px, 16px…).

نصيحة من أبو عمر: لا تبدأ من الصفر تمامًا. استلهم من أنظمة تصميم ناضجة مثل Material Design من جوجل، أو Ant Design، أو Carbon من IBM. انظر كيف حلوا المشاكل الشائعة وتعلم منهم، ثم قم بتخصيص الحلول لتناسب احتياجاتك وهويتك البصرية.

المرحلة الثالثة: بناء مكتبة المكونات (The Heart of the System)

هنا بدأ العمل البرمجي الجاد. قررنا بناء مكتبة المكونات باستخدام React، ولكن المبدأ ينطبق على أي إطار عمل آخر (Vue, Angular, Svelte).

بدأنا بأبسط وأكثر المكونات استخدامًا: الزر (Button). بدلًا من وجود 22 كودًا مختلفًا للزر، أصبح لدينا مكون واحد فقط، ذكي وقابل للتخصيص.

هذا مثال مبسط جدًا لمكون الزر الذي بنيناه:

// Button.jsx (React Component)

// نستورد الـ CSS الخاص بالمكونات
import './Button.css';

// variant: primary | secondary | danger
// size: sm | md | lg
// ...other props like onClick, disabled
const Button = ({ children, variant = 'primary', size = 'md', ...props }) => {
  
  // نحدد الكلاسات بناءً على الخصائص (props)
  const classNames = `btn btn--${variant} btn--${size}`;

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

export default Button;

الجمال في هذا النهج هو أننا نتحكم في شكل الزر من مكان واحد. إذا أردنا تغيير لون الأزرار الرئيسية (primary)، نعدل فقط كلاس .btn--primary في ملف CSS واحد، والتغيير سينعكس في كل مكان يستخدم هذا المكون في كل المشاريع.

أصبح المطور يستخدمه هكذا ببساطة:

import Button from './components/Button';

function MyPage() {
  return (
    <div>
      <h1>أهلاً بك</h1>
      <Button variant="primary" onClick={() => alert('تم الحفظ!')}>
        حفظ التغييرات
      </Button>
      <Button variant="secondary">
        إلغاء
      </Button>
    </div>
  );
}

لاحظ كيف أصبح الكود أسهل للقراءة وأكثر تعبيرًا عن القصد. لا يوجد أي كود تنسيق (CSS) في صفحة `MyPage`، فقط استدعاء لمكونات جاهزة.

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

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

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

• وصف للمكون ومتى يجب استخدامه.
• أمثلة تفاعلية تظهر كل الحالات (primary, secondary, disabled, with icon, etc.).
• جدول يوضح كل الخصائص (Props) التي يقبلها المكون.
• قسم “Do’s and Don’ts” (افعل ولا تفعل) مع أمثلة بصرية.

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

ثمار التعب والجهد: كيف تغير كل شيء؟

بعد حوالي 6 أشهر من العمل المتقطع على النظام، بدأنا نرى النتائج الحقيقية:

• سرعة تطوير خيالية: بناء صفحة جديدة أصبح يشبه بناء مجسم بالليغو. مجرد سحب وتركيب للمكونات الجاهزة. المهام التي كانت تأخذ أيامًا أصبحت تأخذ ساعات.
• اتساق كامل: كل زاوية في منتجاتنا أصبحت تتحدث نفس اللغة البصرية. هذا رفع من جودة المنتج وثقة المستخدم.
• تعاون أفضل: المصممون والمطورون أصبحوا يتحدثون لغة مشتركة. المصمم يقول “استخدم مكون Card مع variant من نوع elevated”، والمطور يفهم بالضبط ما يعنيه.
• صيانة أسهل: هل تذكرون قصة تغيير اللون الأزرق التي أخذت 3 أيام؟ الآن تأخذ 3 دقائق. نعدل متغير اللون في ملف واحد، ونعيد نشر المكتبة، وكل شيء يتم تحديثه تلقائيًا.

الخلاصة ونصيحة أخيرة من أبو عمر 🚀

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

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

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

والله ولي التوفيق.