يا جماعة الخير، السلام عليكم ورحمة الله. اسمي أبو عمر، وأنا اليوم جاي أحكي لكم قصة صارت معي ومع فريقي قبل فترة، قصة “أزمة الزر الأزرق” زي ما بحب أسميها.
كانت الساعة تقارب الحادية عشرة ليلاً، وأنا وفريقي في اجتماع طارئ عبر الإنترنت. لا، لم يكن هناك عطل في الخوادم أو ثغرة أمنية خطيرة. المشكلة كانت أبسط وأكثر إحباطاً بكثير. العميل، وهو شخص دقيق جداً، أرسل بريداً إلكترونياً بعنوان “عاجل: عدم تناسق الألوان”، ومرفق به لقطتا شاشة من تطبيقنا.
الأولى لزر “تأكيد” في صفحة الدفع، والثانية لزر “حفظ” في صفحة الإعدادات. كلاهما كان من المفترض أن يكونا باللون الأزرق الرئيسي لعلامتنا التجارية. لكن، وتحت ضوء شاشة العميل الساطع، كانا درجتين مختلفتين من اللون الأزرق! واحدة كانت أفتح قليلاً، والثانية كانت تميل إلى البنفسجي. صرخة العميل كانت مدوية في بريده الإلكتروني: “لماذا يبدو تطبيقي وكأنه مرقع؟!”.
في ذلك الاجتماع الليلي، اكتشفنا الكارثة. لم يكن لدينا درجتان فقط من اللون الأزرق، بل سبع درجات مختلفة منتشرة في ملفات الـ CSS! كل مطور جديد ينضم للفريق، أو كل مطور يعمل على ميزة جديدة تحت الضغط، كان ببساطة يفتح منتقي الألوان (Color Picker) ويختار درجة “تبدو” صحيحة. كانت واجهاتنا، يا جماعة، “صايرة سلطة”. كل زر قصة، وكل حقل إدخال حكاية.
تلك الليلة، أدركنا أننا لا نعاني من مشكلة في الألوان، بل من مشكلة في “النظام”. كنا في جحيم الفوضى البصرية، وكان لا بد من إيجاد مخرج. هذا المخرج كان “نظام التصميم” (Design System).
ما هو جحيم الفوضى البصرية الذي أتحدث عنه؟
قبل أن أغوص في الحل، دعوني أصف لكم أعراض هذا الجحيم الذي كنا نعيشه، ولربما تعيشونه أنتم أيضاً دون أن تدركوا حجم المشكلة:
- مكونات غير متناسقة: أزرار بأحجام وزوايا دائرية مختلفة، حقول إدخال بارتفاعات متفاوتة، ظلال متنافرة، وأيقونات من عوالم مختلفة.
- هدر وقت المطورين: بدلاً من التركيز على منطق العمل المعقد، كان المطورون يقضون وقتاً ثميناً في أسئلة مثل: “ما هو رمز اللون الأزرق؟” أو “كم يجب أن يكون الهامش بين هذه العناصر؟”.
- إحباط المصممين: كان فريق التصميم يبدع في تصميمات متناسقة وجميلة على برامج مثل Figma أو Sketch، ليروا في النهاية تطبيقاً مشوهاً لا يمت لتصاميمهم بصلة.
- تجربة مستخدم مربكة: عندما لا يكون هناك تناسق بصري، يشعر المستخدم أن التطبيق غير احترافي، ويفقد الثقة به. التناسق يولد الألفة والراحة.
- صعوبة في التوسع: إضافة ميزة جديدة كانت تعني إعادة اختراع العجلة في كل مرة، مما يبطئ من سرعة التطوير بشكل كبير.
المنقذ: نظام التصميم (Design System) – مش مجرد مكتبة واجهات!
الكثير يخلط بين نظام التصميم ومكتبة المكونات أو دليل الأسلوب. لكن الأمر أعمق من ذلك. دعونا نفصلها حبة حبة.
ما هو نظام التصميم؟
ببساطة، نظام التصميم هو “المصدر الوحيد للحقيقة” (Single Source of Truth) لكل ما يتعلق بواجهة وتجربة المستخدم في منتجك. إنه دستوركم الرقمي الذي يجمع كل شيء في مكان واحد منظم.
نظام التصميم ليس مشروعاً له بداية ونهاية، بل هو منتج بحد ذاته، يعيش ويتطور مع تطور منتجك الرئيسي.
الفرق بين نظام التصميم، مكتبة المكونات، ودليل الأسلوب
- دليل الأسلوب (Style Guide): يركز على المظهر والهوية البصرية. يحدد الألوان الأساسية، الخطوط المستخدمة، أسلوب كتابة المحتوى، وكيفية استخدام الشعار. إنه “الروح”.
- مكتبة المكونات (Component Library): هي مجموعة المكونات البرمجية القابلة لإعادة الاستخدام (مثل الأزرار، حقول الإدخال، البطاقات) التي يستخدمها المطورون لبناء الواجهات. إنها “الجسد”.
- نظام التصميم (Design System): هو المظلة التي تجمع كل ما سبق وأكثر. يجمع دليل الأسلوب، ومكتبة المكونات، بالإضافة إلى المبادئ التوجيهية، أنماط الاستخدام، وقواعد “افعل ولا تفعل”. إنه “العقل والروح والجسد” معاً.
رحلتنا في بناء نظام التصميم: من الصفر إلى “إشي مرتب”
بعد “أزمة الزر الأزرق”، قررنا أن نبدأ هذه الرحلة. لم تكن سهلة، ولكنها كانت تستحق كل دقيقة. إليكم خطواتنا العملية:
المرحلة الأولى: جرد الفوضى (The UI Audit)
أول خطوة كانت مواجهة الواقع. قمنا بتشكيل فريق صغير من مطور ومصمم، ومهمته كانت أخذ لقطات شاشة لكل مكون فريد في تطبيقنا. كل الأزرار، كل النماذج، كل البطاقات، كل التنبيهات. ثم وضعناها جميعاً على لوحة رقمية (استخدمنا Miro) وبدأنا في تجميع المتشابهات.
كانت النتيجة صادمة ومضحكة في نفس الوقت. وجدنا 12 نوعاً مختلفاً من الأزرار، 7 أنواع من حقول الإدخال، و5 أساليب مختلفة لعرض رسائل الخطأ. عرض هذه اللوحة على الإدارة كان كافياً للحصول على موافقتهم ودعمهم الكامل للمشروع. لا شيء يقنع الإدارة مثل الأدلة الملموسة على الهدر وعدم الكفاءة.
المرحلة الثانية: وضع الأسس (Design Tokens)
هذه هي الخطوة التي تمنع تكرار “أزمة الزر الأزرق”. الـ Design Tokens (أو “رموز التصميم”) هي متغيرات تحمل القيم الأساسية لهويتك البصرية. بدلاً من كتابة الكود اللوني #3498db في كل مكان، نقوم بتعريفه كمتغير مركزي.
نصيحة أبو عمر: لا تسمّي المتغيرات بألوانها (مثل --blue-500) بل بوظيفتها (مثل --color-primary). لماذا؟ لأنه إذا قررت الشركة في المستقبل تغيير لونها الأساسي من الأزرق إلى الأخضر، كل ما عليك فعله هو تغيير قيمة متغير واحد فقط، وسيتغير اللون في كل مكان في التطبيق بطريقة سحرية!
مثال بسيط باستخدام متغيرات CSS:
/* tokens.css */
:root {
/* Colors */
--color-primary: #007bff; /* هذا هو الأزرق المعتمد والوحيد! */
--color-secondary: #6c757d;
--color-danger: #dc3545;
--color-text-primary: #212529;
/* Spacing */
--spacing-xs: 4px;
--spacing-sm: 8px;
--spacing-md: 16px;
--spacing-lg: 24px;
/* Font Sizes */
--font-size-base: 16px;
--font-size-lg: 1.25rem;
/* Border Radius */
--border-radius-sm: 4px;
--border-radius-md: 8px;
}
المرحلة الثالثة: بناء المكونات الأساسية (The Core Components)
بعد تحديد الرموز، بدأنا في بناء المكونات الأساسية باستخدام هذه الرموز. بدأنا بالأهم والأكثر استخداماً: الزر (Button).
بدلاً من السماح للمطورين بكتابة <button class="btn btn-primary">، قمنا بإنشاء مكون برمجي (في حالتنا كان React Component) يقوم بكل هذا العمل.
مثال مبسط لمكون زر في React:
// Button.jsx
import React from 'react';
import './Button.css'; // ملف يحتوي على الأنماط التي تستخدم الـ Design Tokens
// يقبل المكون "خصائص" (props) لتحديد شكله وسلوكه
const Button = ({ children, variant = 'primary', size = 'md', ...props }) => {
const className = `btn btn--${variant} btn--${size}`;
return (
<button className={className} {...props}>
{children}
</button>
);
};
export default Button;
الآن، عندما يريد مطور إضافة زر، لا يكتب HTML و CSS من الصفر، بل يكتب ببساطة:
import Button from './components/Button';
// ...
<Button variant="primary">تأكيد الطلب</Button>
<Button variant="secondary">إلغاء</Button>
هذا يضمن أن كل الأزرار في التطبيق متناسقة 100%، لأنها تأتي من نفس المصدر الموثوق.
المرحلة الرابعة: التوثيق ثم التوثيق ثم التوثيق!
مقولتي المفضلة: “مكون بدون توثيق هو مجرد كود غامض”. إذا لم يعرف فريقك بوجود هذه المكونات وكيفية استخدامها، فكل عملك سيذهب سدى.
استخدمنا أداة اسمها Storybook، وهي أداة رائعة لعرض المكونات وتوثيقها بشكل تفاعلي. لكل مكون، قمنا بتوثيق:
- عرض حي (Live Preview): لرؤية المكون بكل حالاته.
- الخصائص (Props): كل الخيارات المتاحة للمطور (مثل
variant,size,disabled). - قواعد الاستخدام (Do’s and Don’ts): الأهم! مثلاً: “افعل: استخدم الزر الأساسي (Primary) مرة واحدة فقط في الصفحة للإجراء الرئيسي. لا تفعل: تضع زرين أساسيين بجانب بعضهما البعض”.
- أكواد جاهزة للنسخ: لتسهيل حياة المطورين.
النتائج على أرض الواقع: من الفوضى إلى الإبداع
بعد عدة أشهر من العمل، أصبح لدينا نظام تصميم ناضج. والنتائج كانت مذهلة:
- سرعة التطوير: بناء صفحة جديدة أصبح مثل تجميع قطع الليغو. بدلاً من أسابيع، أصبحت تستغرق أياماً.
- جودة أعلى: قلت الأخطاء البصرية بشكل شبه كامل. أصبح التطبيق يبدو “إشي مرتب” واحترافي.
- تعاون أفضل: أصبح المصممون والمطورون يتحدثون نفس اللغة. مصطلحات مثل “Card with shadow level 2” أو “Primary button” أصبح لها معنى واحد ومحدد للجميع.
- تركيز على الإبداع: تحرر المصممون من دور “شرطة الواجهات” وأصبح لديهم الوقت لحل مشاكل تجربة المستخدم المعقدة. وتحرر المطورون من تعديلات الـ CSS الصغيرة وركزوا على كتابة كود أفضل وأكثر كفاءة.
نصائح من القلب: خلاصة خبرتي في أنظمة التصميم
إذا كنتم تفكرون في هذه الرحلة، اسمحوا لي أن أقدم لكم بعض النصائح العملية من تجربتي:
- ابدأ صغيراً: لا تحاول بناء كل شيء دفعة واحدة. ابدأ بجرد الفوضى، ثم حدد الألوان والخطوط، ثم ابنِ مكوناً واحداً (الزر مثلاً) بشكل ممتاز. النجاحات الصغيرة تبني الزخم.
- احصل على الدعم: نظام التصميم ليس مشروعاً تقنياً فقط، بل هو تغيير في ثقافة الشركة. اعرض “لوحة الفوضى” على الجميع واشرح الفوائد لكل فريق (المطورين، المصممين، مدراء المنتجات، وحتى التسويق).
- عيّن حارساً: يجب أن يكون هناك فريق أو شخص مسؤول عن نظام التصميم. مهمته هي الحفاظ عليه، تطويره، والإجابة على أسئلة الفريق.
- الأتمتة هي صديقك: استخدم أدوات لفحص الكود (Linting) للتأكد من أن المطورين يستخدمون الـ Design Tokens بدلاً من القيم الثابتة.
- التواصل هو المفتاح: أنشئ قناة تواصل (على Slack مثلاً) خاصة بنظام التصميم. شجع الأسئلة والاقتراحات. اجعله مشروعاً يخص الجميع.
الخلاصة: نظام التصميم ليس ترفاً، بل ضرورة 🚀
في عالم تطوير البرمجيات السريع، قد يبدو بناء نظام تصميم وكأنه عمل إضافي يمكن تأجيله. لكن من تجربتي، أقول لكم “من الآخر”: هو استثمار. استثمار في الوقت، الجودة، وسعادة فريقك. إنه الأساس الذي يسمح لك بالبناء بسرعة وثقة وجودة.
لا تدعوا كل زر في تطبيقكم يروي قصة فوضوية مختلفة. وحدوا قصصكم في ملحمة بصرية متناغمة وجميلة. ابدأوا اليوم، ولو بخطوة صغيرة، ولن تندموا أبداً.
والله ولي التوفيق.
