يا جماعة الخير، السلام عليكم ورحمة الله وبركاته. معكم أخوكم أبو عمر.
خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة بتجسّد معنى الفوضى البرمجية والبصرية بحذافيرها. كنا شغالين على مشروع كبير، تطبيق ويب ضخم لشركة محترمة، ومعنا فريق من المطورين والمصممين اللي كل واحد فيهم “راسه براس”. في البداية، كان الحماس يطغى على كل شيء، والكل شغال زي النحل.
بعد حوالي ثلاثة أشهر، بدأنا نلاحظ شغلات غريبة. أنا كمطور خلفي (Backend) ما كنت أركز كثير على الواجهات، لكن لما احتجت أعمل تعديل بسيط على واجهة أمامية، انصدمت. فتحت صفحة “إضافة منتج جديد”، لقيت زر “حفظ” لونه أزرق سماوي مع حواف دائرية. بعدها فتحت صفحة “تعديل ملف المستخدم”، لقيت زر “تحديث” لونه أزرق غامق وشكله مربع. وفي صفحة “الدفع”، كان زر “إتمام العملية” أخضر وبظل خفيف تحته!
المصيبة الكبرى كانت في اجتماع مراجعة مع مدير المشروع الجديد. الشب فتح التطبيق على شاشة كبيرة قدام الكل، وصار يتنقل بين الصفحات وهو ساكت. بعدين عرض شريحة عليها 5 لقطات شاشة لـ 5 أزرار مختلفة، كلها بتأدي وظيفة “التأكيد” أو “الإرسال”. وسأل سؤال واحد بصوت هادي: “يا جماعة، أي واحد من هدول هو الزر الرسمي تبعنا؟”.
في هذيك اللحظة، حسيت الأرض بتبلعنا. إحراج ما بعده إحراج. كل مطور كان يطبّق اللي بشوفه مناسب، وكل مصمم كان يبدع على مزاجه في جزئيته. ما كان في مرجعية، ما كان في “مصدر للحقيقة” (Single Source of Truth). كان كل زر، وكل حقل إدخال، وكل بطاقة عرض… قصة مختلفة تماماً. وقتها أدركنا إننا غرقانين في جحيم الفوضى البصرية، وأنقذنا منه شيء واحد فقط: بناء “نظام تصميم” حقيقي من الصفر. وهذه هي القصة اللي راح أشارككم تفاصيلها اليوم.
ما هو “نظام التصميم” (Design System)؟ مش مجرد ألوان وأيقونات!
قبل ما نخوض في التفاصيل التقنية، خلونا نكون صريحين. كثير من الناس لما يسمعوا “نظام تصميم”، بفكروا إنه مجرد ملف Figma أو Sketch فيه شوية ألوان وخطوط وأيقونات (Style Guide). هذا جزء من الحقيقة، لكنه جزء صغير جداً.
نظام التصميم، يا جماعة، هو أكثر من هيك بكثير. هو المصدر الوحيد للحقيقة لكل ما يتعلق بواجهة المستخدم وتجربة المستخدم في منتجاتكم. فكر فيه كأنه “دستور” المشروع البصري والوظيفي. يتكون من:
- المبادئ والقيم: ليش إحنا بنصمم بهالطريقة؟ هل نركز على السرعة؟ على البساطة؟ على الوصولية (Accessibility)؟
- الأصول البصرية (Visual Assets): الألوان، الخطوط، الأيقونات، المسافات، الظلال… كل شيء له علاقة بالشكل.
- مكتبة المكونات (Component Library): هاي هي قلب النظام. مجموعة من المكونات البرمجية الجاهزة للاستخدام (أزرار، حقول إدخال، قوائم منسدلة، إلخ) واللي تم بناؤها وتجربتها مسبقاً.
- التوثيق (Documentation): شرح واضح لكيفية استخدام كل مكون، متى تستخدمه، ومتى لا تستخدمه (Do’s and Don’ts).
ببساطة، نظام التصميم هو مجموعة من المكونات القابلة لإعادة الاستخدام، واللي بتسترشد بمبادئ واضحة، عشان تقدر تبني عدد كبير من التطبيقات والصفحات بشكل متناسق وسريع. زي مكعبات الليجو LEGO بالضبط، عندك قطع أساسية بقواعد واضحة، بتقدر تبني فيها أي شيء يخطر على بالك.
رحلتنا من الفوضى إلى النظام: خطوات عملية
طيب يا أبو عمر، حكيت كتير عن أهميته، كيف نبدأ؟ بناء على تجربتنا المؤلمة والناجحة في نفس الوقت، هاي هي الخطوات العملية اللي مشينا عليها وأنصحكم فيها بشدة.
الخطوة الأولى: الجرد والتدقيق (The UI Audit)
هذه الخطوة مؤلمة لكنها ضرورية جداً. اللي عملناه هو إننا خصصنا يومين كاملين، وقام فريق المصممين والمطورين بأخذ لقطات شاشة لكل مكون في التطبيق. نعم، كل زر، كل تنبيه، كل نافذة منبثقة، كل نموذج إدخال… كل شيء.
جمعنا كل هاي الصور على لوحة بيضاء رقمية (استخدمنا أداة Miro وقتها). المنظر كان صادم! شفنا أكثر من 10 درجات مختلفة من اللون الأزرق، و7 أنواع من أزرار الحفظ، وعدد لا يحصى من أحجام الخطوط. هذه اللوحة كانت بمثابة “صفعة” صحّتنا كلنا وخلّت الكل يقتنع بضرورة التغيير.
نصيحة أبو عمر: لا تتخطى هذه المرحلة. عرض الفوضى بشكل مرئي هو أقوى حافز للفريق بأكمله، من المدراء للمطورين، للموافقة على تخصيص الموارد والوقت لبناء نظام التصميم.
الخطوة الثانية: وضع الأساسيات والرموز (Design Tokens)
بعد ما عرفنا حجم المشكلة، كان لازم نوحّد الأساس. ما بدأنا بتصميم المكونات مباشرة، بل بدأنا بتعريف ما يسمى بـ “رموز التصميم” (Design Tokens). فكر فيها كمتغيرات (Variables) لتصميمك.
بدل ما نحكي “استخدم اللون الأزرق السماوي #87CEEB”، صرنا نحكي “استخدم لوننا الأساسي `color-primary`”. هذا الرمز (`color-primary`) هو اللي بيحمل القيمة الحقيقية للون. لو قررنا بعد سنة نغير هويتنا البصرية ونخلي اللون الأساسي أخضر، كل اللي علينا نعمله هو تغيير قيمة هذا الرمز في مكان واحد فقط، وكل التطبيق بيتغير بشكل سحري!
هذه الرموز تشمل:
- الألوان: `color-primary`, `color-secondary`, `color-text`, `color-error`…
- المسافات: `spacing-sm`, `spacing-md`, `spacing-lg`… (مثلاً 8px, 16px, 24px)
- أحجام الخطوط: `font-size-h1`, `font-size-body`, `font-size-caption`…
- أوزان الخطوط: `font-weight-regular`, `font-weight-bold`…
- نصف قطر الحواف: `border-radius-sm`, `border-radius-full`…
كمثال عملي في CSS، هيك بكون شكلها:
/* tokens.css */
:root {
/* Colors */
--color-primary: #0052cc;
--color-success: #00875a;
--color-danger: #de350b;
--color-text-primary: #172b4d;
/* Spacing */
--space-4: 4px;
--space-8: 8px;
--space-16: 16px;
/* Fonts */
--font-size-md: 16px;
--font-family-body: 'Tajawal', sans-serif;
}
بعدها، أي CSS جديد بنكتبه، بنستخدم هاي المتغيرات بدل القيم الثابتة. هذا هو حجر الأساس للنظام كله.
الخطوة الثالثة: بناء مكتبة المكونات (من الذرة إلى الكائن الحي)
هنا يبدأ الشغل الممتع. اعتمدنا منهجية اسمها “التصميم الذري” (Atomic Design) لصاحبها براد فروست. الفكرة بسيطة ورائعة:
- الذرات (Atoms): هي أصغر وحدات بناء لا يمكن تجزئتها، مثل الألوان، الخطوط، الأيقونات، وحتى حقول الإدخال والأزرار في أبسط صورها. هي عبارة عن تطبيق مباشر للـ Design Tokens.
- الجزيئات (Molecules): هي مجموعة من الذرات اللي بتشتغل مع بعضها. مثلاً: حقل إدخال (ذرة) + عنوان الحقل (ذرة) + زر بحث (ذرة) = جزيء “شريط البحث”.
- الكائنات الحية (Organisms): هي مجموعة من الجزيئات والذرات اللي بتشكل قسم كامل من الواجهة. مثلاً: شعار (ذرة) + شريط البحث (جزيء) + قائمة التنقل (جزيء) = كائن “الهيدر” أو رأس الصفحة.
بدأنا بأهم مكون وأكثر مكون كان فيه فوضى: الزر (Button). بدل ما يكون عنا 10 أنواع من الأزرار، صممنا وبرمجنا مكون زر واحد فقط، لكنه ذكي وقابل للتخصيص عبر ما يسمى بالـ “Props”.
كمثال بسيط في React، صار مكون الزر عنا هيك:
// Button.jsx
// نستورد الستايل اللي بيستخدم الـ Design Tokens
import './Button.css';
function Button({ children, variant = 'primary', size = 'medium', disabled = false, onClick }) {
// بنبني اسم الكلاس بشكل ديناميكي
const className = `btn btn--${variant} btn--${size}`;
return (
<button className={className} disabled={disabled} onClick={onClick}>
{children}
</button>
);
}
// مثال للاستخدام
<Button variant="primary" size="large">إرسال</Button>
<Button variant="secondary">إلغاء</Button>
<Button variant="danger" size="small">حذف</Button>
بهذه الطريقة، صار عنا مكون واحد فقط مسؤول عن كل الأزرار في التطبيق. أي تعديل مستقبلي على شكل الأزرار بيتم في هذا الملف الواحد. لا مزيد من الأزرار اليتيمة والمنسية في زوايا التطبيق!
الخطوة الرابعة: التوثيق والنشر (إذا لم يكن موثقاً، فهو غير موجود)
هاي الشغلة اللي كثير فرق بتتجاهلها وبتدفع الثمن غالي. “الحكي بيناتنا”، المطور بطبعه كسول شوي، إذا ما لقى طريقة سهلة وسريعة عشان يستخدم المكون الجديد، رح يرجع لطبعه القديم ويبني المكون من الصفر. عشان هيك، التوثيق أهم من المكون نفسه أحياناً.
استخدمنا أداة اسمها Storybook، وهي أداة رائعة بتسمحلك تعرض كل مكوناتك بشكل معزول، وتوثق كل الـ Props اللي بياخدها، وتسمح للمطورين والمصممين يجربوها مباشرة في المتصفح.
لكل مكون، وثّقنا الآتي:
- شرح بسيط: ما هو هذا المكون وماذا يفعل.
- أمثلة للاستخدام (Props): كيف أجعله أساسياً؟ ثانوياً؟ كبيراً؟ صغيراً؟ معطلاً؟
- أفضل الممارسات (Do’s and Don’ts): متى تستخدم الزر الأساسي ومتى تستخدم الثانوي؟ لا تستخدم زر الحذف الأحمر إلا في عمليات الحذف النهائية، وهكذا.
نصائح من قلب الميدان (شغلات بتجلط تعلمناها بالطريقة الصعبة)
خلال رحلتنا، تعلمنا دروس قاسية لكنها مفيدة. اسمحولي أشارككم خلاصة خبرتي:
- ابدأ صغيراً: لا تحاول تبني كل شيء مرة واحدة. ابدأ بأهم 3-5 مكونات (زر، حقل إدخال، ألوان، خطوط). أثبت نجاحها وأهميتها، ثم توسع.
- احصل على دعم الإدارة: نظام التصميم هو “منتج” داخلي، ويحتاج وقت وموارد. اشرح للإدارة الفوائد طويلة الأمد (سرعة التطوير، تقليل الأخطاء، تجربة مستخدم متناسقة) عشان يقتنعوا ويخصصوا له فريق عمل.
- التعاون هو المفتاح: نظام التصميم ليس مشروع مصممين فقط أو مطورين فقط. يجب أن يكون هناك ممثل عن كل فريق (تصميم، تطوير أمامي، تطوير خلفي، ضمان جودة، منتج) ليشارك في صناعة القرار.
- اجعل استخدامه أسهل من عدم استخدامه: إذا كان تثبيت مكتبة المكونات واستخدامها معقداً، سيهرب منه المطورون. استثمر في جعل عملية الدمج (Integration) سلسة وبسيطة قدر الإمكان.
الخلاصة: استثمار في سلامك النفسي ومستقبل مشروعك ✨
بناء نظام تصميم كان من أفضل القرارات اللي اتخذناها في تاريخ المشروع. صحيح أنه أخذ منا وقت وجهد في البداية، لكن العائد كان أضعافاً مضاعفة. سرعة التطوير زادت بشكل ملحوظ، النقاشات العقيمة بين المصممين والمطورين حول “درجة اللون الأزرق” اختفت تماماً، وتجربة المستخدم النهائية أصبحت احترافية ومتناسقة.
نظام التصميم ليس رفاهية، بل هو استثمار ضروري لأي منتج رقمي يطمح للنمو والاستمرارية. هو ينقذك من الفوضى، ويسرّع وتيرة عملك، والأهم من كل هذا، يمنح فريقك “لغة مشتركة” يتحدث بها الجميع، من المصمم في زاويته إلى المطور في عالمه.
فيا صديقي المطور والمصمم، إذا كنت لا تزال تعيش في عالم “كل زر قصة مختلفة”، فربما حان الوقت لتبدأ بكتابة قصة جديدة: قصة النظام والاتساق والاحترافية. والبداية تكون بنظام تصميم قوي. بالتوفيق في رحلتكم! 🚀
