بتذكر أول يوم إلي في هذاك المشروع، فتحت التطبيق عشان آخذ فكرة عن الشغل. قلبت في الشاشات، وكل ما أفتح شاشة جديدة، كانت عيوني تتوسع من الصدمة أكثر. زر “تأكيد” هون لونه أزرق سماوي، وفي شاشة ثانية لونه أخضر فاقع، وفي مكان ثالث كان بنفسجي بحواف دائرية غريبة. كأنه كل مطور في الفريق قرر يورجينا إبداعه الشخصي في تصميم الأزرار!
وقتها، همست لحالي وأنا بهز براسي: “يابا، شو هالسلطة هاي؟”. الموضوع ما كان بس ألوان، كان كل شيء: أحجام الخطوط، المسافات بين العناصر، أشكال مربعات الإدخال… فوضى عارمة. في اجتماع الفريق الأول، طرحت الموضوع. قلتلهم يا جماعة الخير، الشغل هيك ما بمشي. المستخدم بفوت على التطبيق بحس حاله ضايع في سوق شعبي، كل محل إله شكل ولون. لازم نوحد جهودنا ونبني على أساس متين. من هنا، بدأت رحلتنا لإنقاذ المشروع من “جحيم الفوضى البصرية” عبر بناء ما يُعرف بـ “نظام التصميم”.
ما هو نظام التصميم (Design System)؟ وليش هو مش مجرد “دليل ألوان”؟
خليني أبسطها. كثير ناس بفكروا نظام التصميم هو مجرد ملف PDF فيه كم لون وشوية خطوط. لأ يا حبايب، الموضوع أعمق من هيك بكثير. نظام التص’ميم هو “مصدر الحقيقة الأوحد” (Single Source of Truth) لكل ما يتعلق بواجهة المستخدم في منتجك.
تخيله مثل قطع الليغو (LEGO). عندك مجموعة من القطع الأساسية (أزرار، حقول إدخال، بطاقات) مع كتالوج واضح بشرح كيف تركب هاي القطع مع بعضها عشان تبني أي شيء بدك ياه (سيارة، بيت، سفينة فضاء) بشكل متناسق وجميل. نظام التصميم هو مجموعة المكونات البرمجية القابلة لإعادة الاستخدام، مع المبادئ والإرشادات اللي بتحكم شكلها وطريقة تفاعلها.
الأعراض اللي كانت تصرخ: “أنقذونا، نحتاج نظام تصميم!”
قبل ما نبدأ، كان لازم نقنع الإدارة والทีม كله بضرورة هاي الخطوة. ما كان صعب، لأن الألم كان واضح للكل:
- الفوضى البصرية وعدم الاتساق: زي ما حكيت في البداية. هذا يضعف ثقة المستخدم بالمنتج ويجعله يبدو غير احترافي.
- بطء التطوير بشكل قاتل: كل مطور كان يعيد اختراع العجلة في كل مرة. بدل ما يستخدم زر جاهز، كان يبنيه من الصفر، وهذا هدر فظيع للوقت والجهد.
- جحيم الصيانة والتعديل: تخيل لو مدير المنتج طلب تغيير بسيط: “بدنا نغير درجة اللون الأزرق الأساسي في التطبيق”. طلب بسيط، صح؟ غلط! في حالتنا، كان هذا يعني إنه لازم نمر على عشرات الملفات في المشروع ونعدل اللون يدوياً في كل مكان، مع خطر نسيان بعض الأماكن.
- فجوة بين المصممين والمطورين: المصمم يسلمنا تصميم خرافي على Figma، بس اللي بيطلع مع المطورين في النهاية إشي “قريب منه”. ليش؟ لأنه ما في لغة مشتركة. نظام التصميم هو الجسر اللي بيخلي المصمم والمطور يتكلموا نفس اللغة.
رحلة البناء: من الفوضى إلى النظام خطوة بخطوة
ما بنينا كل إشي بيوم وليلة. الموضوع كان عملية تدريجية ومنظمة. هاي هي الخطوات اللي مشيناها، وأنصح أي فريق يمشي عليها.
الخطوة الأولى: الجرد البصري (The UI Audit)
هاي كانت الخطوة الصادمة والمهمة. عملنا “جردة” لكل شيء في التطبيق. أخذنا لقطات شاشة لكل الأزرار، كل حقول الإدخال، كل البطاقات، كل القوائم… وجمعناهم كلهم في ملف واحد. لما عرضنا الملف في الاجتماع، الكل انصدم. كان عنا 12 نوع مختلف من الأزرار الأساسية! هاي اللحظة كانت كفيلة بإقناع آخر متشكك في الفريق بضرورة التغيير.
الخطوة الثانية: وضع الأساسيات (Design Tokens)
قبل ما نبني أي مكون، لازم نتفق على الأساسيات. هاي الأساسيات بنسميها في عالم التصميم “Design Tokens”، وهي عبارة عن متغيرات بتحمل قيم التصميم الأساسية. هيك بنضمن إنه لو غيرناها في مكان واحد، التغيير يسمّع في كل التطبيق.
- الألوان (Colors): حددنا لوحة ألوان واضحة: لون أساسي (Primary)، ثانوي (Secondary)، لون للنجاح (Success)، للخطأ (Error)، للتنبيه (Warning)، ودرجات مختلفة من الرمادي.
- الخطوط (Typography): اخترنا عائلة خطوط واحدة، وحددنا مقياساً هرمياً واضحاً (H1, H2, H3, Body, Caption) بأحجام وأوزان محددة.
- المسافات (Spacing): وهاي نقطة كثير ناس بتهملها. عملنا مقياس للمسافات مبني على مضاعفات رقم معين (مثلاً 8px). فصارت المسافات عنا (8px, 16px, 24px, 32px…). بطل في إشي اسمه `margin-left: 13px;`!
كمثال بسيط في CSS، هيك ممكن تبدو هاي المتغيرات:
:root {
/* Colors */
--color-primary-500: #007bff;
--color-success-500: #28a745;
--color-danger-500: #dc3545;
--color-neutral-900: #212529;
--color-neutral-100: #f8f9fa;
/* Spacing */
--space-1: 4px;
--space-2: 8px;
--space-3: 12px;
--space-4: 16px;
/* Typography */
--font-family-base: 'Tajawal', sans-serif;
--font-size-lg: 1.25rem;
--font-size-md: 1rem;
--font-size-sm: 0.875rem;
}الخطوة الثالثة: بناء المكونات (Component Library)
هون ببدأ الشغل الجد. بدأنا ببناء المكونات من الأصغر للأكبر، حسب مبدأ “التصميم الذري” (Atomic Design).
مثال: مكون الزر (The Almighty Button)
بدل ما يكون عنا 12 نوع زر مبعثرين في الكود، صار عنا مكون واحد ذكي اسمه <Button>. هذا المكون بيقبل خصائص (props) بتتحكم في شكله وسلوكه.
مثلاً، في إطار عمل زي React، المكون ممكن يبدو هيك (بشكل مبسط):
import React from 'react';
import './Button.css'; // ملف الـ CSS اللي بيستخدم المتغيرات اللي فوق
const Button = ({ children, variant = 'primary', size = 'medium', disabled = false, onClick }) => {
// بناء اسم الكلاس ديناميكياً بناءً على الخصائص
const classNames = `btn btn--${variant} btn--${size}`;
return (
<button className={classNames} onClick={onClick} disabled={disabled}>
{children}
</button>
);
};
export default Button;
والآن، بدل ما كل مطور يكتب HTML و CSS لزر جديد، صار ببساطة يكتب:
<Button variant="primary" size="large">تأكيد الطلب</Button>
<Button variant="secondary" onClick={handleCancel}>إلغاء</Button>
<Button variant="danger" disabled>حذف الحساب</Button>
لاحظ الجمال؟ مكون واحد، قابل لإعادة الاستخدام، متسق 100%، وسهل الصيانة. لو قررنا نغير شكل الأزرار الثانوية (secondary)، بنعدل مكان واحد فقط!
الخطوة الرابعة: التوثيق والنشر
نظام تصميم بدون توثيق واضح هو مجرد مجلد ملفات في المشروع لا أحد يعرف عنه شيئاً. التوثيق هو روح النظام. استخدمنا أداة اسمها Storybook، وهي أداة رائعة بتسمحلك تعرض كل مكوناتك بشكل تفاعلي، مع أمثلة على كل حالاته المختلفة (primary, secondary, disabled, etc.) وتوثيق لخصائصه.
صار الـ Storybook هو الكتالوج الرسمي للفريق. المصمم بشوف المكونات المتاحة قبل ما يصمم شاشة جديدة، والمطور الجديد بفوت عليه عشان يتعلم كيف يبني الواجهات بسرعة.
النتائج: من الفوضى إلى جنة الاتساق البصري
بعد شهور من العمل، النتائج كانت مذهلة وتستحق كل دقيقة تعب:
- سرعة تطوير خرافية: بناء شاشة جديدة صار عبارة عن تجميع مكعبات ليغو جاهزة.
- اتساق يريح العين (والنفس): التطبيق صار له هوية بصرية واضحة وموحدة، وهذا زاد من ثقة المستخدمين.
- صيانة سهلة زي شرب المي: طلب تغيير لون أساسي؟ دقيقة واحدة وبتكون المهمة خلصت.
- تعاون أفضل بين الفرق: المصممون والمطورون ومديرو المنتجات صاروا يتكلمون لغة المكونات المشتركة.
نصائح من قلب أبو عمر
من خبرتي في هاي الرحلة وغيرها، بحب أشارككم كم نصيحة عملية:
- ابدأ صغيراً، لكن ابدأ الآن: لا تحاول تبني نظام تصميم ضخم من أول يوم. ابدأ بالأهم: الألوان، الخطوط، ومكون أو اثنين مثل الزر وحقل الإدخال. ثم قم بالتوسع تدريجياً.
- المشاركة للجميع: نظام التصميم ليس مسؤولية فريق الواجهات الأمامية وحده. يجب أن يكون جهداً مشتركاً بين المصممين والمطورين (frontend و backend) ومديري المنتجات.
- التوثيق، ثم التوثيق، ثم التوثيق: إذا لم يكن المكون موثقاً وسهل الاكتشاف، فلن يستخدمه أحد. استثمر في أدوات توثيق جيدة.
- لا تجعله سجناً، بل مرشداً: يجب أن يتطور نظام التصميم مع تطور المنتج. ضع آلية واضحة لإضافة مكونات جديدة أو اقتراح تعديلات. الهدف هو التوجيه وليس التقييد المطلق.
نظام التصميم ليس مشروعاً له بداية ونهاية، بل هو منتج بحد ذاته، يخدم منتجاتك الأخرى. يجب أن يعيش ويتنفس ويتطور معها.
الخلاصة النهائية 🏁
بناء نظام تصميم كان من أفضل القرارات الاستراتيجية اللي اتخذناها. هو مش مجرد ترف تقني أو موضة، بل هو استثمار حقيقي في جودة المنتج، كفاءة الفريق، وسعادة المستخدمين (وراحة بال المطورين!). هو الفرق بين بناء بيت على أساس متين من الخرسانة، وبنائه على رمل الشاطئ.
إذا كنت تعاني في مشروعك من “سلطة” المكونات والفوضى البصرية، فربما حان الوقت لتجمع فريقك وتقول لهم: “يا جماعة، خلينا نرتب شغلنا ونبني نظام تصميم”. صدقني، راح تدعيلي. يلا، شدّوا حيلكم! 😉
