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

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

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

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

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

“لم تكن المشكلة في الكود، بل في غياب اللغة المشتركة بين التصميم والبرمجة. كنا نتحدث لغات مختلفة ونحاول بناء نفس البيت.”

ما هو “جحيم الفوضى البصرية” الذي كنّا نعيشه؟

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

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

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

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

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

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

نظام التصميم ليس شيئًا واحدًا، بل هو منظومة متكاملة تتكون من عدة أجزاء رئيسية:

1. المبادئ والأهداف (Design Principles)

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

2. أساسيات التصميم أو “Design Tokens”

هذه هي الذرات التي تتكون منها واجهتنا. هي قيم مجردة تمثل الخصائص البصرية الأساسية، ويتم تخزينها كمتغيرات.

• الألوان: color-primary-500, color-text-default, color-background-page
• الخطوط: font-size-lg, font-weight-bold, line-height-heading
• المسافات: spacing-4 (يعادل 16px مثلاً), spacing-2 (يعادل 8px)
• الظلال، زوايا الحواف، إلخ.

الجميل في الـ Tokens أنها تفصل القرارات التصميمية عن التنفيذ. يمكن للمصمم أن يقرر تغيير color-primary-500 من الأزرق إلى الأخضر، وبمجرد تحديث هذا الـ Token، يتغير اللون في كل مكان في التطبيق تلقائيًا.

3. مكتبة المكونات (Component Library)

هنا يكمن قلب النظام. هذه هي مكعبات الليغو التي تحدثنا عنها. هي مجموعة من المكونات البرمجية الجاهزة للاستخدام، المعزولة، والموثقة جيدًا. مثل:

• الأزرار (Buttons)
• حقول الإدخال (Input Fields)
• البطاقات (Cards)
• القوائم المنسدلة (Dropdowns)
• النوافذ المنبثقة (Modals)

كل مكون يتم بناؤه باستخدام الـ “Design Tokens” ويأتي مع خيارات مختلفة (props). لنأخذ مثال الزر الشهير. بدلًا من 10 أنواع أزرار متناثرة في الكود، أصبح لدينا مكون واحد اسمه <Button>.

نصيحة من أبو عمر: عند بناء المكونات، فكر دائمًا في حالات الاستخدام المختلفة. الزر ليس مجرد نص وشكل. ماذا عن حالة التحميل (loading)؟ الحالة المعطلة (disabled)؟ هل يدعم أيقونات؟

إليك مثال مبسط جدًا لمكون زر باستخدام React و Styled-components، فقط لتتضح الفكرة:

// Button.jsx - هذا هو المكون البرمجي
import React from 'react';
import styled, { css } from 'styled-components';

// هذه هي الـ "Design Tokens" الخاصة بنا
const tokens = {
  colors: {
    primary: '#007bff',
    secondary: '#6c757d',
    danger: '#dc3545',
    textLight: '#fff',
  },
  spacing: {
    small: '8px 16px',
    medium: '12px 24px',
  },
  // ... والمزيد من الـ tokens
};

const StyledButton = styled.button`
  cursor: pointer;
  border: none;
  border-radius: 4px;
  font-weight: bold;
  
  // تطبيق الـ tokens
  color: ${tokens.colors.textLight};
  
  // استخدام الـ props لتغيير المظهر
  ${({ variant }) => variant === 'primary' && css`
    background-color: ${tokens.colors.primary};
  `}
  
  ${({ variant }) => variant === 'secondary' && css`
    background-color: ${tokens.colors.secondary};
  `}

  ${({ size }) => size === 'small' && css`
    padding: ${tokens.spacing.small};
    font-size: 14px;
  `}

  ${({ size }) => size === 'medium' && css`
    padding: ${tokens.spacing.medium};
    font-size: 16px;
  `}
`;

const Button = ({ children, variant = 'primary', size = 'medium', ...props }) => {
  return (
    <StyledButton variant={variant} size={size} {...props}>
      {children}
    </StyledButton>
  );
};

export default Button;

// --- في أي مكان آخر في التطبيق ---
// <Button variant="primary" size="medium">تأكيد</Button>
// <Button variant="secondary" size="small">إلغاء</Button>

4. التوثيق والإرشادات (Documentation & Guidelines)

المكونات بدون توثيق هي مجرد كود غامض. التوثيق هو الذي يحول مجموعة من المكونات إلى نظام حقيقي. يجب أن يجيب التوثيق على أسئلة مثل:

• ما هذا المكون؟ (وصف موجز)
• متى يجب استخدامه؟ (Use cases)
• متى لا يجب استخدامه؟ (Misuse cases)
• ما هي الخيارات المتاحة؟ (Props and variants)
• إرشادات الوصولية (Accessibility): كيف نضمن أن المكفوفين أو ذوي الإعاقة يمكنهم استخدامه؟

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

رحلتنا من الفوضى إلى النظام: كيف بنينا نظامنا خطوة بخطوة؟

بناء نظام تصميم ليس مشروعًا ينتهي في عطلة نهاية الأسبوع. إنه استثمار طويل الأمد. وهذه هي المراحل التي مررنا بها:

1. الإقرار بالمشكلة وتشكيل الفريق: أول خطوة كانت الاعتراف بوجود فوضى. جمعت المبرمجين والمصممين ومديري المنتجات في اجتماع، وعرضت عليهم “الجزر المعزولة” التي نعيش فيها. اتفق الجميع على الحاجة للتغيير وشكلنا فريقًا صغيرًا لقيادة المبادرة.
2. الجرد البصري (UI Audit): قمنا بعملية مملة ولكنها ضرورية: أخذنا لقطات شاشة لكل الأزرار، وحقول الإدخال، والبطاقات، وكل شيء في تطبيقنا. وضعناها كلها بجانب بعضها البعض. كانت الصورة صادمة وأفضل دليل لإقناع الإدارة بضرورة الاستثمار في هذا المشروع.
3. وضع القواعد الأساسية: بدأنا بالأساسيات. اتفقنا على لوحة ألوان محدودة، ومجموعة خطوط، ونظام مسافات رياضي (يعتمد على مضاعفات الرقم 8). هذه كانت أول “Design Tokens” لنا.
4. بناء المكونات الأولى: لم نحاول بناء كل شيء دفعة واحدة. بدأنا بالمكون الأكثر استخدامًا وتكرارًا: الزر. ثم حقل الإدخال. مع كل مكون جديد نبنيه، كنا نستبدله في التطبيق تدريجيًا.
5. التوثيق ثم التوثيق ثم التوثيق: من اليوم الأول، التزمنا بتوثيق كل قرار وكل مكون. هذا جعل عملية التبني أسهل بكثير.
6. التبني والنشر: لم نفرض النظام على الجميع بالقوة. بل جعلناه الخيار الأسهل والأسرع والأفضل. عندما يرى المبرمج أنه يمكنه بناء صفحة كاملة في ساعات بدلاً من أيام باستخدام المكونات الجاهزة، سيتبنى النظام بحب.

نصائح من “أبو عمر” لتبدأ رحلتك الخاصة

إذا كنت تشعر أنك تعيش في نفس الفوضى التي كنا فيها، فإليك بعض النصائح العملية من القلب:

• ابدأ صغيرًا: لا تحاول بناء نظام تصميم كامل من الصفر. ابدأ بمكون واحد أو اثنين (الزر واللون هما أفضل بداية). أثبت قيمته ثم توسع.
• نظام التصميم هو مُنتَج، وليس مشروعًا: المشروع له بداية ونهاية. أما نظام التصميم فهو منتج حي يحتاج إلى رعاية وصيانة وتطوير مستمر، تمامًا مثل منتجك الأساسي.
• التعاون هو المفتاح: نظام التصميم الذي يبنيه المبرمجون وحدهم سيفشل. والذي يبنيه المصممون وحدهم سيفشل. يجب أن يكون جهدًا مشتركًا منذ اليوم الأول.
• اجعل التوثيق ممتعًا وسهل الوصول: استخدم أدوات تفاعلية مثل Storybook أو Zeroheight. لا أحد يحب قراءة ملفات PDF مملة.
• قِس النجاح: حاول قياس تأثير النظام. هل قلّ وقت تطوير الميزات الجديدة؟ هل انخفض عدد الـ “Bugs” المتعلقة بالواجهة؟ هذه الأرقام ستساعدك في الحصول على دعم مستمر من الإدارة.

الخلاصة: من جزر معزولة إلى قارة متصلة 🏝️➡️🌍

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

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