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

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

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

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

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

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

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

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

المنقذ: ما هو نظام التصميم (Design System) ببساطة؟

لما طرحنا المشكلة، كان الحل واضحًا: نحن بحاجة إلى “مصدر حقيقة واحد” (Single Source of Truth). هذا المصدر هو ما يُعرف بـ نظام التصميم (Design System).

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

1. قطع الليغو (المكونات): وهي الأجزاء البرمجية والتصميمية الجاهزة للاستخدام (أزرار، حقول إدخال، بطاقات، قوائم…).
2. دليل التركيب (الإرشادات): وهو اللي بيشرح كيف ومتى تستخدم كل قطعة، وشو القواعد اللي لازم تتبعها عشان تبني شيء متناسق وجميل.
3. لغة مشتركة: المصممون والمطورون ومديرو المنتجات صاروا كلهم يحكوا نفس اللغة. لما نقول “Primary Button”، الكل عارف بالضبط عن شو بنحكي.

نظام التصميم يتكون من عدة أعمدة أساسية، وكلها بتشتغل مع بعضها.

أساسيات التصميم (Design Tokens)

هذه هي “ذرات” النظام. هي قيم مجردة تمثل الخصائص البصرية الأساسية. بدل ما نكتب في الكود color: #0A74E8;، بنكتب color: var(--color-primary-500);. هذه “التوكنز” بتكون معرفة في مكان واحد.

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

مثال على ملف توكنز بسيط بصيغة JSON:

{
  "color": {
    "brand": {
      "primary": { "value": "#0A74E8" },
      "secondary": { "value": "#5E6C7F" }
    },
    "text": {
      "default": { "value": "#172B4D" },
      "subtle": { "value": "#5E6C7F" }
    }
  },
  "spacing": {
    "base": { "value": "4px" },
    "small": { "value": "{spacing.base.value} * 2" }, // 8px
    "medium": { "value": "{spacing.base.value} * 4" } // 16px
  },
  "typography": {
    "font": {
      "main": { "value": "'Tajawal', sans-serif" }
    }
  }
}

هذه التوكنز يمكن تحويلها تلقائيًا إلى متغيرات CSS, SASS, أو حتى متغيرات في كود Swift و Kotlin.

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

هنا يكمن السحر العملي. هذه هي مجموعة المكونات البرمجية الجاهزة اللي بيستخدمها المطورين. كل مكون (مثل الزر) يتم بناؤه مرة واحدة بشكل مثالي، مع مراعاة كل الحالات (default, hover, disabled, active)، ومع مراعاة معايير الوصولية (Accessibility).

مثال بسيط لمكون “زر” باستخدام React و TailwindCSS، يستهلك التوكنز بشكل غير مباشر عبر إعدادات Tailwind:

// Button.jsx
// نفترض أن ألوان 'primary' و 'secondary' معرفة في إعدادات Tailwind
// بناءً على ملف التوكنز الخاص بنا.

export function Button({ children, variant = 'primary', onClick }) {
  const styles = {
    primary: 'bg-primary text-white hover:bg-primary-dark',
    secondary: 'bg-gray-200 text-gray-800 hover:bg-gray-300',
  };

  return (
    <button 
      className={`px-4 py-2 rounded-md font-bold transition-colors ${styles[variant]}`}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

الآن، بدل ما كل مطور يبني زر من الصفر، صار ببساطة يستخدم هذا المكون الموحّد.

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

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

• متى أستخدم الزر الأساسي (Primary) ومتى أستخدم الثانوي (Secondary)؟
• كيف أكتب النصوص داخل الرسائل التحذيرية؟ (Tone of Voice)
• ما هي أفضل الممارسات لاستخدام الأيقونات؟ (Do’s and Don’ts)
• كيف نضمن أن تصميمنا متاح للجميع (Accessibility)؟

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

رحلتنا في بناء نظام التصميم: من وين بلّشنا؟

الكلام النظري حلو، بس التطبيق هو المحك. رحلتنا ما كانت سهلة، وهاي هي الخطوات اللي مشينا فيها:

1. جرد الفوضى (UI Audit): أول خطوة كانت مؤلمة لكن ضرورية. عملنا فريق صغير من مصمم ومطور، ومهمتهم كانت أخذ لقطات شاشة لكل المكونات في كل تطبيقاتنا. جمعنا كل الأزرار مع بعض، كل حقول الإدخال مع بعض، وهكذا. النتيجة كانت صادمة، يا ساتر! لقينا أكثر من 20 درجة مختلفة من اللون الأزرق و15 تصميمًا مختلفًا للزر الرئيسي. هذه الصور كانت الدليل القاطع اللي احتجناه عشان نقنع الإدارة بأهمية المشروع.
2. وضع المبادئ والأساسيات: اجتمع المصممون مع كبار المطورين وقرروا الأساسيات: لوحة الألوان النهائية، سلم الخطوط والأحجام (Typography Scale)، ونظام المسافات (Spacing System). كان نقاشًا طويلًا لكنه كان استثمارًا ضروريًا للمستقبل.
3. البناء التدريجي: ما حاولنا نبني كل شيء مرة واحدة. “ابدأ بالأشياء اللي بتتكرر زي شرب المي”. بدأنا بأكثر المكونات استخدامًا: الزر، حقل الإدخال، والبطاقة (Card). بنيناها بشكل متقن، وثّقناها، وأطلقناها كإصدار أول.
4. التبني والنشر: هذه أصعب مرحلة. كيف تقنع فرقًا اعتادت على العمل بطريقتها الخاصة أن تتبنى النظام الجديد؟ قمنا بعمل ورشات عمل، جلسات برمجة ثنائية (Pair Programming)، ووفرنا دعمًا مستمرًا. احتفلنا بأول فريق يتبنى النظام بنجاح، وهذا شجع الباقين.

نصائح أبو عمر الذهبية لنجاح نظام التصميم الخاص بك

من خلال تجربتنا، تعلمت كم درس حابب أشارككم فيها:

• نظام التصميم هو منتج، وليس مشروعًا: المشروع له بداية ونهاية. أما نظام التصميم فهو منتج حي يتطور مع تطور منتجاتك. يجب أن يكون له فريق مسؤول، خارطة طريق، وإصدارات.
• ابدأ صغيرًا، لكن فكر كبيرًا: لا تحاول حل كل مشاكل العالم من اليوم الأول. ابدأ بمكونين أو ثلاثة، أثبت قيمتها، ثم توسّع.
• التعاون هو مفتاح النجاح: نظام التصميم ليس مسؤولية المصممين وحدهم أو المطورين وحدهم. هو مسؤولية مشتركة. يجب أن تكون هناك حلقة تواصل مستمرة بين كل الأطراف.
• اجعل التوثيق أولوية قصوى: نظام تصميم بدون توثيق جيد هو مجرد مجلد أكواد لن يستخدمه أحد. استثمر في كتابة توثيق واضح، عملي، ومزود بأمثلة.
• لا تنسَ إمكانية الوصول (Accessibility): ابنِ المكونات مع الأخذ في الاعتبار معايير الوصولية منذ البداية (مثل تباين الألوان، ودعم قارئات الشاشة، والتنقل عبر لوحة المفاتيح). هذا ليس رفاهية، بل هو أساس أي منتج محترم.

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

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

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

الله يوفقكم جميعًا في مشاريعكم.