يا جماعة الخير، خلوني أحكيلكم قصة صارت معي قبل كم سنة. كنا شغالين على مشروع كبير، تطبيق تجارة إلكترونية ضخم، وكنا فريق متحمس ومليان طاقة. في البداية، كل شي كان ماشي “زي الحلاوة”. كل مطور ماسك جزئية، وكل واحد بيبدع وبيطلع شغل. بس بعد كم شهر، لما كبر المشروع، بلشت المصايب تبيّن.
بتذكر منيح هذاك اليوم، مدير المنتج دخل علينا المكتب ومعالم وجهه ما بتبشر بالخير. فتح التطبيق على شاشتين جنب بعض: صفحة المنتجات وصفحة العروض الخاصة. وقال جملة واحدة: “يا جماعة، ليش الزر هان لونه أزرق سماوي، وهان أزرق نيلي؟ وليش هاد حوافه دائرية وهاد مربعة؟ هو كل واحد فينا عنده براند لحاله؟”.
وقتها كلنا طلعنا في بعض. الحقيقة المرة كانت إنه ما في “براند” واحد. كان عنا “براندات” بعدد المطورين في الفريق. كل واحد فينا كان عنده نسخته الخاصة من المكونات. كان عندي مجلد اسمه omar_components وزميلي عنده saleh_components. كنا بننسخ ونلصق الكود، وكل واحد بيعدّل على مزاجه. النتيجة؟ تطبيق مشوه، صيانته كابوس، وتجربة المستخدم، الله يستر عليها. كنا عايشين في جحيم من عدم الاتساق، وما كنا عارفين إنه الحل موجود واسمه “نظام التصميم”.
الجحيم اللي كنا عايشين فيه: فوضى ما إلها آخر
قبل ما نحكي عن الحل، لازم أوصفلكم حجم المشكلة اللي كنا فيها. الفوضى ما كانت بس في الألوان، كانت متغلغلة في كل زاوية من زوايا الكود والتصميم.
أزرار بألف لون وشكل
الزر، أبسط مكون في أي واجهة مستخدم، كان عنا متحف فنون حديثة. كل مطور كان يصنع زره الخاص. شوفوا مثلاً هالكودين اللي بيعملوا (نظرياً) نفس الأشي: زر أساسي.
الزر الأول (من كود المطور “أ”):
<button style="background-color: #007bff; color: white; padding: 10px 20px; border-radius: 5px; border: none;">
إضافة للسلة
</button>
الزر الثاني (من كود المطور “ب”):
.primary-button {
background: #007acc;
color: #FFF;
padding: 12px 18px;
border-radius: 8px;
border: 1px solid #005c99;
font-weight: bold;
}
النتيجة؟ زرين مختلفين في الحجم، اللون، الحواف، وحتى في طريقة الكتابة (inline style vs class). ولما كان يجي تعديل على تصميم الأزرار، كنا نحتاج نلف على المشروع كله ونعدّل في عشرات الأماكن، وغالباً كنا ننسى كم واحد منهم.
رحلة البحث عن اللون “الأزرق الصح”
مشكلة الألوان كانت قصة لحالها. في ملفات الـ CSS تبعتنا، كنت تلاقي مهرجان ألوان:
color: #337ab7;background-color: blue;border-color: rgb(51, 122, 183);$primary-color: #337ab7;(في ملف Sass)--main-blue: #337AB7;(في ملف CSS آخر)
ما كان في مصدر واحد للحقيقة. كل واحد بيختار “الأزرق” اللي بيعجبه. هذا الأشي مش بس بيعمل تباين بصري، بل بيصعّب جداً عملية تغيير الهوية البصرية للمشروع في المستقبل.
“وين الكود تبع البطاقة؟” – التكرار القاتل
المكونات المعقدة شوي، زي بطاقة عرض المنتج (Product Card)، كانت الكارثة الأكبر. كل صفحة فيها منتجات، كان المطور ينسخ كود البطاقة من صفحة ثانية ويلصقه، وبعدين يعدّل عليه حسب الحاجة. صار عنا 5 أو 6 نسخ مختلفة من نفس البطاقة. لما قررنا نضيف “شارة خصم” على البطاقة، اضطر فريق كامل يقضي يومين بس عشان يضيف هاي الشارة على كل النسخ المكررة. شغل ميت وضياع وقت ومجهود.
بناء سفينة النجاة: خطواتنا لإنشاء نظام التصميم
بعد “المحاضرة” اللي أخذناها من مدير المنتج، قعدنا كلنا، مطورين ومصممين، وقررنا إنه “لهون وبس”. لازم نلاقي حل جذري. وبعد بحث وقراءة، وصلنا للحل السحري: نظام التصميم (Design System).
نظام التصميم ليس مجرد مكتبة مكونات أو دليل ألوان. إنه “المصدر الوحيد للحقيقة” (Single Source of Truth) الذي يجمع كل شيء: مبادئ التصميم، الإرشادات، والأصول التقنية (الكود)، لتمكين الفرق من بناء منتجات رقمية متسقة وعالية الجودة وبسرعة.
وقررنا نبني سفينة النجاة الخاصة فينا. هاي هي الخطوات اللي اتبعناها:
المرحلة الأولى: الجرد والتوثيق (The UI Audit)
أول خطوة كانت أشبه بعملية “تنقيب أثري”. قمنا بجرد كل المكونات الموجودة في التطبيق. فتحنا كل الشاشات وأخذنا لقطات شاشة لكل الأزرار، حقول الإدخال، البطاقات، القوائم، وكل شي. جمعناهم في مكان واحد (استخدمنا أداة زي Figma) وبلشنا نشوف حجم الكارثة. كان عنا 15 نوع زر مختلف، و8 أنواع بطاقات، وعدد لا نهائي من درجات اللون الرمادي.
المرحلة الثانية: وضع المبادئ والأساسات (The Foundations)
بعد ما عرفنا شو عنا، كان لازم نقرر شو بدنا. قعد المصممون مع المطورين لوضع الأساسات. هاي الأساسات هي الـ DNA تبع نظامنا الجديد:
- الرموز التصميمية (Design Tokens): هاي كانت أهم خطوة تقنية. بدل ما نستخدم قيم ثابتة (hard-coded) زي
#007bffأو16px، قمنا بتعريف “رموز” أو متغيرات لكل شي. هاي الرموز هي قيم مجردة بتمثل خيارات التصميم.
مثال على ملف رموز للألوان باستخدام متغيرات CSS:
:root {
/* Colors */
--color-primary-500: #007bff;
--color-primary-600: #0069d9;
--color-neutral-100: #f8f9fa;
--color-neutral-900: #212529;
/* Spacing */
--space-xs: 4px;
--space-sm: 8px;
--space-md: 16px;
--space-lg: 32px;
/* Fonts */
--font-size-body: 16px;
--font-size-h1: 32px;
}
هيك، بدل ما أكتب color: #007bff، صرت أكتب color: var(--color-primary-500). لو حبينا نغير اللون الأساسي في المستقبل، بنغيره في مكان واحد بس!
- سلم الخطوط (Typography Scale): حددنا أحجام وخطوط ثابتة لكل العناوين والنصوص (h1, h2, body, caption).
- لوحة الألوان (Color Palette): اعتمدنا لوحة ألوان واضحة ومحددة: لون أساسي، ثانوي، لون للنجاح، لون للخطأ، ودرجات من اللون الرمادي.
المرحلة الثالثة: بناء مكتبة المكونات (The Component Library)
هون بلش الشغل البرمجي الجد. بدأنا ببناء المكونات من الصفر، لكن هالمرة بطريقة صحيحة: قابلة لإعادة الاستخدام ومبنية على الرموز التصميمية اللي حددناها. اتبعنا منهجية اسمها “التصميم الذري” (Atomic Design):
- الذرات (Atoms): بنينا أصغر الوحدات زي الزر (Button)، حقل الإدخال (Input)، الأيقونة (Icon).
- الجزيئات (Molecules): ركبنا الذرات مع بعض لنعمل مكونات أعقد، زي حقل بحث (مكون من حقل إدخال وزر بحث).
- الكائنات (Organisms): جمعنا الجزيئات لنعمل أجزاء أكبر من الواجهة، زي الهيدر (Header) أو قائمة المنتجات.
شوفوا مثلاً كيف صار شكل مكون “الزر” الجديد (مثال باستخدام React):
// Button.jsx
// بنستخدم مكتبة زي classnames عشان ندمج الكلاسات بسهولة
import cx from 'classnames';
import './Button.css'; // ملف الـ CSS اللي بيستخدم الـ Design Tokens
const Button = ({ children, variant = 'primary', size = 'medium', disabled = false, ...props }) => {
const buttonClasses = cx(
'btn', // الكلاس الأساسي
`btn--${variant}`, // btn--primary, btn--secondary
`btn--${size}`, // btn--small, btn--medium
{ 'btn--disabled': disabled }
);
return (
<button className={buttonClasses} disabled={disabled} {...props}>
{children}
</button>
);
};
export default Button;
الآن، أي مطور بده زر، بيستخدم هذا المكون. ما في مجال للاجتهاد الشخصي. بده زر كبير أخضر؟ بسيطة: <Button variant="success" size="large">تأكيد</Button>. الكل بيستخدم نفس اللغة ونفس الكود.
المرحلة الرابعة: التوثيق والنشر (Documentation & Publishing)
نظام تصميم بدون توثيق واضح هو نظام ميت. لازم كل الفريق يعرف شو المكونات الموجودة وكيف يستخدمها. استخدمنا أداة اسمها Storybook، وهي أداة رائعة بتسمحلك تعرض كل مكوناتك بشكل تفاعلي، مع أمثلة كود وطرق استخدام مختلفة. صار التوثيق تبعنا موقع داخلي، أي مطور جديد بفوت عليه وبيتعلم كل شي بيحتاجه خلال ساعات.
أرض الميعاد: الفوائد اللي حصدناها
الرحلة كانت طويلة ومتعبة، لكن النتيجة كانت تستاهل كل دقيقة. الانتقال لنظام التصميم نقلنا من الجحيم لأرض الميعاد. وهاي بعض الفوائد اللي لمسناها بشكل مباشر:
سرعة خرافية في التطوير 🚀
بناء صفحة جديدة صار يشبه اللعب بالمكعبات (LEGO). بدل ما نبني كل مكون من الصفر، صرنا نسحب المكونات الجاهزة من المكتبة ونركبها. مهمة كانت تاخذ يومين، صارت تاخذ 3 ساعات.
اتساق يريح العين والقلب
التطبيق صار شكله متجانس ومحترف. تجربة المستخدم تحسنت بشكل ملحوظ لأنه تعلم سلوك التطبيق مرة واحدة. الزر الأساسي شكله وسلوكه واحد في كل مكان. ما في مفاجآت مزعجة.
صيانة أسهل، وصداع أقل 🤕
لما قررنا نعدّل على شكل الحواف في كل الأزرار ونخليها أكثر دائرية، التعديل أخذ 5 دقائق بالضبط. غيرنا قيمة متغير واحد في ملف الـ Design Tokens، وكل شي تحدث تلقائياً. لا بحث ولا تكرار ولا وجع راس.
لغة مشتركة بين المطورين والمصممين
صار في لغة موحدة. المصمم ما عاد يقول “بدي زر أزرق”، صار يقول “استخدم Button--primary“. المطور فاهم عليه بالضبط. النقاشات صارت أسرع وأكثر فعالية.
نصائح من خبرة أبو عمر الكم
إذا كنتم بتفكروا تبنوا نظام تصميم خاص فيكم، اسمحولي أقدملكم كم نصيحة من القلب، من خبرتي في الميدان:
- ابدأوا صغاراً: ما تحاولوا تبنوا كل شي مرة واحدة. ابدأوا بأهم 3-5 مكونات (الزر، حقل الإدخال، الألوان، الخطوط). بعدين توسعوا شوي شوي.
- الكل لازم يشارك: نظام التصميم مش مسؤولية المطورين لحالهم أو المصممين لحالهم. هو مسؤولية مشتركة. لازم الكل يقتنع بالفكرة ويشارك في بنائها.
- اعتبروه منتجاً، وليس مشروعاً جانبياً: نظام التصميم هو منتج داخلي له مستخدمين (المطورين والمصممين)، ولازم يكون له مسؤول، وخطة عمل، وتحديثات مستمرة.
- التوثيق ثم التوثيق ثم التوثيق: استثمروا في أدوات توثيق جيدة زي Storybook أو Zeroheight. التوثيق هو اللي بيخلي النظام حي وقابل للاستخدام.
الخلاصة ✨
يا جماعة، الاستثمار في نظام تصميم هو واحد من أفضل القرارات اللي ممكن ياخذها أي فريق تقني. هو مش رفاهية أو موضة، هو ضرورة أساسية لبناء منتجات قابلة للنمو والتطور بكفاءة وجودة. هو اللي بينقلكم من فوضى الاجتهادات الفردية إلى قوة العمل الجماعي المنظم.
صحيح إنه بده شغل وتعب في البداية، لكنه استثمار بيرجع عليكم أضعاف مضاعفة في المستقبل على شكل وقت، وجودة، وراحة بال. فلا تترددوا، ابدأوا اليوم، ولو بخطوة صغيرة.
ويلا، شدّوا حيلكم! 💪