يا مية أهلاً وسهلاً فيكم! اسمحولي أحكيلكم قصة صارت معي قبل كم سنة، قصة بتورّجي كيف ممكن أبسط الأمور تفرط وتعمل مشاكل كبيرة لو ما انتبهنا الها من البداية.
كنّا شغالين على مشروع كبير، تطبيق ويب ضخم، وفريقنا ما شاء الله عليه، شعلة نشاط. مصممين شاطرين ومبرمجين وحوش. في البداية، الأمور كانت ماشية زي الحلاوة. بس بعد كم شهر، بلشت أحس في إشي غلط. كل ما أفتح جزء جديد من التطبيق، أحس حالي فتت على تطبيق تاني! الزر اللي لونه أزرق سماوي في صفحة البروفايل، بصير أزرق نيلي في صفحة الإعدادات. والخط حجمه 16 بكسل في مكان، و 15 بكسل في مكان تاني… يا لطيف!
وصلت المرحلة اللي صار فيها اجتماع بين فريق التطوير وفريق التصميم، والجو كان مشحون. المبرمج بحكي: “يا جماعة، المصمم أعطاني لون أزرق جديد، بس أنا عندي بالكود 10 درجات أزرق، أي واحد أستخدم؟!”. والمصمم برد: “يا زلمة، أنا صممت الزر مرة وحدة، ليش كل واحد فيكم عامله بشكل مختلف؟”. دخلت على الاجتماع وفتحت شاشة العرض وحطيت صورتين جنب بعض لنفس التطبيق، وحكيتلهم جملة وحدة: “يا جماعة، واجهاتنا صارت زي اللي عنده 50 ظل للون الأزرق، وإحنا مش عارفين أي واحد هو اللون الصح. إحنا في جحيم الفوضى البصرية”.
هون كانت نقطة التحول. قررنا إنه “لهون وبس”. كان لازم نلاقي حل جذري، مش مجرد “ترقيع”. وكان الحل اسمه: نظام التصميم (Design System).
ما هو نظام التصميم؟ وليش هو أهم من مجرد “دليل ألوان”؟
كتير ناس بتفكر إنه نظام التصميم هو مجرد ملف PDF حلو فيه كم لون وكم خط، وهاد أكبر غلط. نظام التصميم يا جماعة هو “المصدر الوحيد للحقيقة” (Single Source of Truth) لكل ما يتعلق بواجهة المستخدم وتجربة المستخدم في منتجك. هو مش مجرد وثيقة، هو نظام حي، متكامل، وقابل للتطور.
فكّر فيه كأنه “دستور” المشروع. بدل ما كل مطور أو مصمم “يجتهد” من عنده، الكل برجع لنفس الدستور. هاد الدستور مكون من عدة أجزاء رئيسية:
h3: المبادئ والغايات (Guiding Principles)
قبل ما تبني أي إشي، لازم تسأل حالك “ليش؟”. شو هي فلسفة التصميم تبعتنا؟ هل إحنا بنركز على البساطة؟ السرعة؟ الوضوح؟ هاي المبادئ بتكون زي البوصلة اللي بتوجه كل قرار تصميمي أو برمجي لاحقاً. مثلاً، من مبادئنا كانت: “الوضوح قبل الإبداع”. يعني ما بدنا نخترع العجلة ونعمل أشكال غريبة على حساب فهم المستخدم.
h3: مكتبة المكونات (Component Library)
هذا هو قلب نظام التصميم النابض. هون بنبني كل “قطع الليغو” اللي بنستخدمها لتركيب واجهاتنا. من أصغر قطعة (زي الأزرار، حقول الإدخال) لأكبر قطعة (زي الهيدر، الفوتر، الكروت). الأهم من هيك، هاي المكونات بتكون عبارة عن كود حقيقي، قابل لإعادة الاستخدام.
فائدة عملية: لما تعدّل على مكون الزر الأساسي في مكتبة المكونات (مثلاً تغير لونه)، التغيير هاد بسمّع وبظهر في كل مكان بستخدم هاد الزر في التطبيق كله! تخيل كمية الوقت والجهد اللي بتوفرها.
h3: الأنماط والرموز (Styles & Tokens)
هون منحل مشكلة الـ “50 ظل للأزرق”. بنعرّف مجموعة محددة وثابتة من الأنماط اللي رح نستخدمها في كل مكان:
- الألوان (Colors): لون أساسي واحد، لون ثانوي واحد، ألوان للتنبيهات (نجاح، خطأ، تحذير)، ودرجات محددة من اللون الرمادي. مش أكثر.
- الخطوط (Typography): بنعرّف سلم هرمي واضح لأحجام الخطوط (h1, h2, p, small text…).
- المسافات (Spacing): بنعتمد نظام مسافات موحد (مثلاً، مضاعفات الـ 8 بكسل) عشان كل العناصر تكون متناسقة مع بعضها.
- الأيقونات (Icons): مكتبة أيقونات موحدة بأسلوب واحد.
هاي الأنماط ما بتكون مجرد أرقام وقيم مكتوبة في ملف، بل بتكون “Tokens” أو متغيرات في الكود. مثال بسيط باستخدام CSS Custom Properties:
:root {
/* Color Tokens */
--color-primary-500: #0A74F0; /* هاد هو الأزرق المعتمد تبعنا! */
--color-neutral-900: #1A1A1A;
--color-neutral-100: #F5F5F5;
/* Font Size Tokens */
--font-size-lg: 1.25rem; /* 20px */
--font-size-md: 1rem; /* 16px */
/* Spacing Tokens */
--spacing-4: 1rem; /* 16px */
--spacing-2: 0.5rem; /* 8px */
}
.button-primary {
background-color: var(--color-primary-500);
padding: var(--spacing-2) var(--spacing-4);
font-size: var(--font-size-md);
border: none;
border-radius: 4px;
color: white;
}
شايفين كيف؟ كل إشي برجع للمتغيرات الأساسية. لو قررنا نغير اللون الأزرق، منغيره في مكان واحد بس!
رحلتنا من الفوضى إلى النظام: كيف بنينا نظام تصميم خاص فينا؟
الحكي سهل، بس الفعل هو اللي بجيب نتيجة. بناء نظام تصميم مش بكبسة زر، هو رحلة. وهاي هي مراحل رحلتنا باختصار:
h3: المرحلة الأولى: التدقيق البصري (The Audit) – يا لطيف، شو هاد!
أول خطوة كانت مؤلمة لكن ضرورية. عملنا فريق صغير من مصمم ومطور، ومهمتهم كانت بسيطة: خذوا لقطات شاشة (screenshots) لكل زر، كل حقل إدخال، كل قائمة منسدلة، كل لون، وكل حجم خط في التطبيق كله. النتيجة كانت صادمة! لقينا عنا 12 نوع مختلف من الأزرار، 8 أنواع من حقول الإدخال، وعدد لا يحصى من درجات الألوان والمسافات العشوائية. عرضنا هاي “لوحة العار” على كل الفريق، والكل اقتنع بحجم المشكلة.
h3: المرحلة الثانية: وضع الأساس (Laying the Foundation)
اجتمعنا (مصممين ومطورين) وقررنا الأساسيات. اخترنا لون أزرق واحد ليكون اللون الأساسي، وكم لون مساعد. اعتمدنا عائلة خطوط وحدة، وحددنا 5 أحجام أساسية فقط. والأهم، اعتمدنا نظام المسافات الموحد (8px grid). هاي القرارات البسيطة كانت حجر الأساس لكل إشي رح يجي بعدها.
h3: المرحلة الثالثة: بناء المكونات (Building the Components)
بلشنا نبني مكتبة المكونات البرمجية. اتبعنا منهجية اسمها “التصميم الذري” (Atomic Design). يعني بلشنا بأصغر إشي:
- الذرات (Atoms): المكونات اللي ما بتتجزأ، زي الزر، الأيقونة، حقل الإدخال.
- الجزيئات (Molecules): مجموعة من الذرات بتشتغل مع بعض، زي حقل البحث (حقل إدخال + أيقونة بحث + زر).
- الكائنات الحية (Organisms): مكونات أكبر وأكثر تعقيداً، زي الهيدر (شعار + قائمة تصفح + حقل بحث).
كل مكون بنيناه كان موثق بشكل ممتاز، مع أمثلة على كل حالاته (مثلاً، الزر في حالته العادية، عند تمرير الماوس فوقه، عند الضغط عليه، والحالة المعطلة).
h3: المرحلة الرابعة: التوثيق والنشر (Documentation and Adoption)
الكود بدون توثيق زي السيارة بدون مفتاح، ما إله قيمة. استخدمنا أداة زي Storybook عشان نعمل موقع داخلي خاص بنظام التصميم. هاد الموقع صار هو المرجع لكل حدا في الشركة. المصمم بشوف كيف شكل المكونات، والمطور بنسخ الكود الجاهز مباشرة. عملنا ورشات عمل لتدريب كل الفرق على كيفية استخدام النظام الجديد، وليش هو مهم إلهم.
نصائح من قلب الميدان (من أبو عمر شخصياً)
- ابدأ صغيرًا: مش ضروري تبني نظام تصميم كامل من أول يوم. ابدأ بالأشياء اللي بتسبب أكبر ألم، زي الأزرار والألوان.
- الكل لازم يشارك: نظام التصميم مش مسؤولية المصممين بس. لازم المطورين ومدراء المنتجات يكونوا جزء من العملية من اليوم الأول عشان ينجح.
- نظام التصميم هو مُنتَج، وليس مشروع: المشروع إله بداية ونهاية. أما نظام التصميم فهو مُنتَج حي، بحاجة لصيانة وتطوير مستمر، ولازم يكون إله فريق أو شخص مسؤول عنه.
- التوثيق، ثم التوثيق، ثم التوثيق: إذا المكون مش موثق وسهل الوصول إله، كأنه مش موجود. استثمروا في أدوات توثيق جيدة.
- لا تخف من قول “لا”: لما حدا يطلب منك تعمل مكون “على السريع” خارج نظام التصميم، لازم يكون عندك الشجاعة والثقة لتقله “لا، خلينا نعمله صح ضمن النظام عشان الكل يستفيد”.
الخلاصة: من جحيم الفوضى إلى جنة الاتساق ✨
الرحلة كانت طويلة ومتعبة، ما بكذب عليكم. بس النتيجة كانت تستاهل كل دقيقة تعب. اليوم، لما يجي مطور جديد على الفريق، خلال ساعات بكون قادر ينتج واجهات متناسقة وجميلة، لأنه ما عليه إلا يركّب قطع الليغو الجاهزة. المصمم صار يركز على حل مشاكل المستخدم الحقيقية بدل ما يضيع وقته في رسم نفس الزر للمرة المليون. وسرعة التطوير زادت بشكل ملحوظ، والفوضى البصرية صارت مجرد ذكرى سيئة بنضحك عليها.
بناء نظام التصميم هو استثمار في مستقبل منتجك وفريقك. هو اللي بحول الشغل من ردات فعل عشوائية إلى عمل منظم ومدروس. هو الجسر اللي بوحد لغة المصممين والمطورين. فلا تستهينوا بقوته.
يلا، شدوا حيلكم وابدؤوا بترتيب بيتكم الداخلي. صدقوني، مستقبلكم رح يشكركم. 💪
