يا جماعة الخير، بتذكر مرة كنا شغالين على مشروع ضخم، نظام متكامل لشركة كبيرة فيه واجهات كثيرة: لوحة تحكم للمدير، تطبيق للموظفين، وبوابة للعملاء. فريق كبير، مبرمجين ومصممين، وكل واحد فينا “فنان”، كل واحد بحط لمسته الخاصة. أنا كنت ماسك جزء من لوحة التحكم، وزميلي أحمد ماسك تطبيق الموبايل، وسارة كانت مسؤولة عن بوابة العملاء.
بعد شهور من الشغل والتعب، اجتمعنا عشان ندمج الشغل كله ونعرضه للإدارة. فتحنا الشاشات جنب بعض… يا زلمة، كانت صدمة! كأنك فاتح ثلاث تطبيقات من ثلاث شركات مختلفة. الزر الأخضر عندي لونه “فسفوري”، عند أحمد “زيتي”، وعند سارة “نعناعي”. حجم الخط في كل شاشة شكل، أيقونة الحفظ مرة شكلها ديسك قديم ومرة شكلها سحابة ومرة إشارة صح. حسيت حالي واقف في سوق كل واحد بغني على ليله. المدير التنفيذي نظر إلينا وقال جملة ما بنساها: “شغلكم تقنياً ممتاز، بس ليش حاسس إني بستخدم ثلاث منتجات مش منتج واحد؟”.
في هذيك اللحظة بالزبط، عرفنا إنه المشكلة مش في الكود، المشكلة في “اللغة” اللي بنحكي فيها. كان لازم نوحد لغتنا البصرية، وهون بدأت رحلتنا مع “نظام التصميم”.
ما هو نظام التصميم (Design System)؟ وليش هو مش مجرد “مكتبة مكونات”؟
كتير ناس بتخلط بين نظام التصميم ومكتبة المكونات (UI Kit). خليني أبسطها:
- مكتبة المكونات (UI Kit/Component Library): هي مجموعة من المكونات الجاهزة للاستخدام زي الأزرار، حقول الإدخال، القوائم المنسدلة، إلخ. بتقدر تعتبرها “صندوق مكعبات الليجو”.
- نظام التصميم (Design System): هو الصورة الكاملة. هو مش بس صندوق الليجو، هو كمان الكتالوج اللي بشرحلك كيف تبني القلعة والسيارة والسفينة بنفس المكعبات. هو “اللغة” المشتركة اللي بتجمع المصممين والمطورين ومدراء المنتج.
نظام التصميم يحتوي على:
- المبادئ والقيم: ليش إحنا بنصمم هيك؟ هل هدفنا البساطة؟ السرعة؟ الجمالية؟
- إرشادات التصميم: كيف نستخدم الألوان، الخطوط، المسافات، الأيقونات، وحتى “نبرة الصوت” في النصوص.
- رموز التصميم (Design Tokens): متغيرات مركزية لكل قيم التصميم (زي لون أساسي، حجم خط، مسافة). رح نحكي عنها بالتفصيل.
- مكتبة المكونات: المكونات البرمجية الفعلية اللي بيستخدمها المطورين.
- التوثيق: أهم جزء! دليل الاستخدام اللي بشرح كل شي وكيف نستخدمه صح.
باختصار، نظام التصميم هو “المصدر الوحيد للحقيقة” (Single Source of Truth) لكل ما يتعلق بواجهة وتجربة المستخدم في منتجاتك.
رحلة بناء نظام التصميم الخاص بنا: من الفكرة للتنفيذ
بعد “الصدمة الحضارية” اللي حكيتلكم عنها، قررنا نبني نظام تصميم خاص فينا. الطريق ما كان سهل، بس كان يستاهل كل لحظة تعب. هاي هي المراحل اللي مرينا فيها:
المرحلة الأولى: الإقناع وجمع الحبايب (Getting Buy-in)
أول تحدي ما كان تقني، كان إنساني. كان لازم نقنع الإدارة العليا بأهمية المشروع. نظام التصميم مش مشروع جانبي، هو استثمار بيحتاج وقت وموارد. جهزنا عرض بسيط وضحنا فيه المشكلة (عرضنا صور الشاشات المختلفة جنب بعض) والحل المقترح والفوائد المتوقعة (سرعة في التطوير، تجربة مستخدم موحدة، تقليل الأخطاء).
نصيحة أبو عمر: لا تبدأ بكتابة سطر كود واحد قبل ما تاخد موافقة ودعم من كل الأطراف المعنية (الإدارة، المصممين، المطورين). نظام التصميم هو تغيير ثقافي قبل ما يكون تغيير تقني.
المرحلة الثانية: جرد الفوضى (The UI Audit)
هون بلش الشغل الممتع. عملنا فريق صغير من مصمم ومطور، وفتحنا كل شاشات تطبيقاتنا وأخذنا لقطات شاشة لكل “مكون” بنشوفه: كل الأزرار، كل حقول الإدخال، كل الألوان، كل الخطوط. جمعناهم في ملف واحد على أداة زي Figma. النتيجة كانت “جدار العار” اللي بيورجينا كمية التكرار وعدم الاتساق. كان عنا 15 درجة مختلفة من اللون الأزرق و 7 أشكال مختلفة لزر “التالي”!
هذا الجرد كان مؤلم لكنه ضروري، لأنه أعطانا صورة واضحة عن حجم المشكلة وساعدنا نحدد الأولويات.
المرحلة الثالثة: وضع الأساسات – رموز التصميم (Design Tokens)
هاي من أهم المراحل تقنياً. بدل ما نكتب الألوان والمسافات بشكل مباشر في الكود (hard-coding)، قررنا نعرّفها كـ “رموز” أو متغيرات في مكان مركزي واحد. هاي الرموز هي اللي بتربط بين لغة المصمم ولغة المبرمج.
تخيلها كملف JSON بسيط بيحتوي على كل قرارات التصميم الأساسية:
{
"color": {
"brand": {
"primary": { "value": "#0052CC" },
"secondary": { "value": "#FFC400" }
},
"text": {
"default": { "value": "#172B4D" },
"subtle": { "value": "#5E6C84" }
}
},
"space": {
"s": { "value": "4px" },
"m": { "value": "8px" },
"l": { "value": "16px" }
},
"font": {
"size": {
"body": { "value": "14px" },
"heading": { "value": "24px" }
}
}
}
الجميل في هاي الرموز إنه بنقدر نحولها تلقائياً لأي صيغة بيحتاجها المطور: متغيرات CSS, Sass, أو حتى متغيرات خاصة بـ iOS و Android. هيك، لو قررنا نغير اللون الأساسي للعلامة التجارية، بنغيره في مكان واحد فقط، وبيتحدث في كل التطبيقات تلقائياً. شغل نظيف!
المرحلة الرابعة: بناء المكعبات – مكتبة المكونات (Component Library)
بعد ما حطينا الأساسات (الرموز)، بلشنا نبني المكونات فوقها. بدأنا بأبسط الأشياء وأكثرها تكراراً (Atoms)، زي الزر (Button). بدل ما يكون عنا 10 أنواع أزرار، صار عنا مكون “Button” واحد فقط، بيقبل خصائص (props) عشان نغير شكله (مثلاً `variant=”primary”` أو `size=”large”`).
مثال بسيط جداً لمكون زر في React بيستخدم الرموز اللي عرفناها:
// في عالم مثالي، هذه الرموز ستأتي من حزمة npm
const tokens = {
color: { primary: '#0052CC', textOnPrimary: '#FFFFFF' },
space: { m: '8px', l: '16px' }
};
function Button({ children, variant = 'primary' }) {
const style = {
backgroundColor: tokens.color[variant],
color: tokens.color.textOnPrimary,
padding: `${tokens.space.m} ${tokens.space.l}`,
border: 'none',
borderRadius: '4px',
cursor: 'pointer'
};
return <button style={style}>{children}</button>;
}
بعدها، انتقلنا للمكونات الأعقد (Molecules & Organisms) اللي بتتكون من تجميع المكونات البسيطة، زي بطاقة المنتج (Product Card) اللي بتحتوي على صورة، عنوان، نص، وزر.
المرحلة الخامسة: التوثيق هو الملك (Documentation is King)
نظام تصميم بدون توثيق جيد هو مجرد مشروع جانبي لمجموعة من المطورين. التوثيق هو اللي بيخلي النظام حي وقابل للاستخدام من قبل أي شخص جديد بينضم للفريق.
استخدمنا أداة مثل Storybook اللي بتسمح لنا نعرض كل مكون في مكتبتنا بشكل تفاعلي، مع توثيق لكيفية استخدامه، والخصائص اللي بيقبلها، وأمثلة عملية مع الكود. كمان كتبنا إرشادات واضحة: متى تستخدم الزر الأساسي ومتى تستخدم الثانوي؟ ما هي أفضل الممارسات عند تصميم النماذج (Forms)؟ كل هذه الأسئلة لازم يكون جوابها موثق وواضح.
النتائج والثمار: كيف تغيرت حياتنا بعد نظام التصميم؟
بعد حوالي 6 أشهر من العمل، بدأنا نشوف الثمار الحقيقية:
- سرعة خيالية: بناء صفحة جديدة صار عبارة عن تجميع مكعبات ليجو جاهزة. المطور صار يركز على منطق العمل (Business Logic) بدل ما يضيع وقته في تنسيق CSS.
- تناسق بصري تام: كل منتجاتنا صارت تتكلم نفس اللغة البصرية. تجربة المستخدم صارت سلسة وموحدة.
- تعاون أفضل: صار في لغة مشتركة بين المصمم والمطور. المصمم بصمم باستخدام نفس المكونات والرموز اللي بيستخدمها المطور. النقاش صار عن “تجربة المستخدم” بدل ما يكون عن “درجة اللون الأزرق”.
- صيانة أسهل: لما قررنا نعمل rebranding ونغير الألوان الأساسية، الموضوع أخذ منا أيام بدل شهور. غيرنا الـ Design Tokens، عملنا build جديد، وخلص!
- إعداد أسرع للموظفين الجدد: المطور أو المصمم الجديد بيقدر يفتح توثيق نظام التصميم ويفهم كيف يبني واجهات متناسقة من أول يوم.
الخلاصة: من الفوضى إلى التناغم ✨
يا جماعة، بناء نظام تصميم هو رحلة طويلة ومتعبة، لكنها من أكثر الاستثمارات اللي ممكن تعملها وتعود عليك بالفائدة على المدى الطويل. هو مش مجرد أداة تقنية، هو عقلية وفلسفة عمل بتنقل فريقك من مجموعة أفراد بيشتغلوا جنب بعض، لفريق متناغم بيعزف نفس اللحن.
نصيحتي الأخيرة: لا تخاف تبدأ صغير. مش لازم تبني كل شي من أول يوم. ابدأ بجرد الفوضى، وحد الألوان والخطوط، وابني مكون أو اثنين. لما فريقك يشوف الفائدة بعينه، راح يصيروا كلهم من أكبر الداعمين للمشروع. تذكروا دايماً، الهدف هو بناء منتجات أفضل بشكل أسرع وأكثر كفاءة. يلا، شدوا حيلكم!
