واجهاتنا كانت فوضى بصرية: كيف أنقذنا ‘نظام التصميم’ (Design System) من جحيم عدم الاتساق؟

يا جماعة الخير، السلام عليكم ورحمة الله.

اسمحوا لي أبدأ معكم بقصة صارت معي قبل كم سنة، قصة بتلخص المعاناة اللي كتير من فرق التطوير بتعيشها. كنا في اجتماع كبير، بنعرض النسخة الجديدة من تطبيقنا اللي تعبنا عليه شهور طويلة. مدير المنتج، شب حرك وشاطر، قرر يعمل حركة ذكية (أو هيك كان مفكر وقتها). فتح شاشتين من التطبيق جنب بعض على البروجكتر الكبير: شاشة تسجيل الدخول، وشاشة الملف الشخصي.

ساد الصمت في القاعة لثواني، وبعدها سمعت واحد من الزملاء بهمس: “هذول تطبيقين مختلفين؟”. والله يا جماعة، كان معه حق. لون الزر الأزرق في الشاشة الأولى مختلف عن لونه في الشاشة الثانية بدرجة “يا دوب” العين تلقطها. حواف الحقول في الأولى دائرية بالكامل، وفي الثانية دائرية شوي. حتى الخط، مع إنه نفس النوع، بس حجمه مختلف بنقطة أو نقطتين. كانت فوضى بصرية مُقنّعة، شغل “كل واحد بغني على ليله”.

هذا الموقف كان زي الكف اللي صحانا. أدركنا إنه كل مبرمج جديد بيجي على الفريق، أو كل مصمم بيشتغل على جزئية جديدة، بيضيف “لمسته” الخاصة، والنتيجة كانت كوكتيل مشوّه بصرياً، وصداع لا ينتهي في الصيانة والتطوير. من يومها، بدأت رحلتنا مع ما يُعرف بـ “نظام التصميم” أو الـ Design System. وهذه هي حكايتنا…

ما هو “نظام التصميم” بالأصل؟ وليش هو مش مجرد “Style Guide”؟

كتير ناس بتخلط بين نظام التصميم ودليل الأنماط (Style Guide). خليني أبسطها: دليل الأنماط هو زي كتالوج الألوان وورق الحائط في محل الديكور، بيعطيك الخيارات المتاحة. أما نظام التصميم، فهو مصنع “ليغو” (LEGO) كامل ومتكامل.

نظام التصميم هو المصدر الوحيد للحقيقة (Single Source of Truth) لكل ما يتعلق بواجهة المستخدم وتجربته. هو مش بس مجموعة ألوان وخطوط، بل هو منظومة حية تتكون من ثلاث ركائز أساسية:

1. المبادئ والقيم (The “Why”)

قبل ما تبني أي زر أو تكتب أي سطر كود، لازم تسأل حالك: شو فلسفتنا في التصميم؟ هل هي البساطة؟ السرعة؟ الوضوح؟ الوصولية (Accessibility)؟ هذه المبادئ هي البوصلة اللي بتوجه كل قرار تصميمي وبرمجي. مثلاً، من مبادئنا كان: “الوضوح قبل الجمال”. يعني لو في تصميم “فخم” بس معقد، وتصميم أبسط بس واضح للمستخدم، بنختار الثاني بدون تردد.

2. المكونات القابلة لإعادة الاستخدام (The “What”)

هذه هي قطع الليغو اللي حكيت عنها. هي عبارة عن مكتبة من المكونات البرمجية والتصميمية الجاهزة للاستخدام. تبدأ من أصغر إشي (الذرات):

  • الألوان (Colors)
  • الخطوط (Typography)
  • المسافات (Spacing)
  • الأيقونات (Icons)

وبعدها بتبني مكونات أكبر (الجزيئات والكائنات):

  • الأزرار (Buttons)
  • حقول الإدخال (Input Fields)
  • البطاقات (Cards)
  • القوائم (Menus)
  • النوافذ المنبثقة (Modals)

الفكرة إنك بتصمم وتبرمج الزر مرة واحدة “على أصوله”، وبعدها كل الفريق بيستخدم نفس الزر بالضبط في كل مكان. ما في مجال للاجتهادات الشخصية.

3. الإرشادات والتوثيق (The “How”)

هذا هو كتيب التعليمات اللي بيجي مع قطع الليغو. كيف تستخدم هاي المكونات؟ متى تستخدم الزر الأساسي (Primary) ومتى تستخدم الثانوي (Secondary)؟ كيف لازم تكون المسافات بين العناصر؟ شو هو “صوت ونبرة” (Voice and Tone) النصوص اللي بنكتبها داخل التطبيق؟

التوثيق الجيد هو اللي بيحول نظام التصميم من مجرد مشروع تقني إلى ثقافة عمل داخل الفريق.

رحلتنا في بناء نظام التصميم: من الفوضى إلى النظام

الموضوع ما صار بيوم وليلة، كانت رحلة طويلة ومقسمة على مراحل واضحة.

المرحلة الأولى: جرد الفوضى (The UI Audit)

رجعنا لـ “جدار العار” تبعنا. عملنا جرد كامل لكل مكونات واجهاتنا. أخذنا سكرين شوت لكل الأزرار، كل حقول الإدخال، كل الألوان المستخدمة في التطبيق. النتيجة كانت صادمة ومضحكة بنفس الوقت: اكتشفنا إنه عنا 12 درجة مختلفة من اللون الأزرق، و7 أنماط مختلفة للأزرار! سميناها وقتها “مهرجان الأزرار”.

نصيحة من أبو عمر: لا تتجاهل هذه الخطوة. قد تكون مؤلمة، لكنها ضرورية عشان تورجي الإدارة وباقي الفريق حجم المشكلة بالأرقام والصور. لما يشوفوا الفوضى بعينهم، بصير أسهل تاخد موافقة ودعم لمشروع زي هيك.

المرحلة الثانية: وضع حجر الأساس (Design Tokens)

قررنا توحيد كل شي. اتفقنا على لوحة ألوان محددة، على درجات الخطوط، على نظام مسافات مبني على مضاعفات رقم معين (مثلاً 8px). هذه المتغيرات الأساسية بنسميها “Design Tokens”.

هاي الـ Tokens مش مجرد قيم مكتوبة في ملف تصميم، لأ، هي متغيرات حقيقية في الكود. كمبرمجين، عملناها كمتغيرات CSS Custom Properties عشان نستخدمها في كل المشروع.

/* design-tokens.css */
:root {
  /* Colors */
  --color-primary-500: #005A9C; /* The main blue */
  --color-secondary-500: #F78F1E; /* The main orange */
  --color-neutral-900: #1A1A1A; /* Dark text */
  --color-neutral-100: #FFFFFF; /* White */

  /* Fonts */
  --font-family-base: 'Tajawal', sans-serif;
  --font-size-base: 16px;
  --font-size-lg: 18px;
  --font-size-sm: 14px;

  /* Spacing */
  --space-1: 4px;
  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  
  /* Borders */
  --border-radius-sm: 4px;
  --border-radius-md: 8px;
}

هذا الملف الصغير كان بداية الثورة. بطل في مبرمج “يخترع” لون من عنده. الكل صار يستخدم هاي المتغيرات. لو حبينا نغير اللون الأساسي للتطبيق في المستقبل، بنغيره في مكان واحد بس!

المرحلة الثالثة: بناء المكونات “على أصولها”

بدأنا بأهم وأكثر مكون مستخدم: الزر (Button). صممنا كل حالاته (عادي، عند المرور عليه بالماوس، عند الضغط، معطل) وأشكاله (أساسي، ثانوي، نصي). وبعدها برمجناه كمكون مستقل (React/Vue/Angular component) بيستقبل خصائص بسيطة.

مثلاً، بدل ما المبرمج يكتب كل مرة كود HTML و CSS لزر، صار يكتب هيك بس:

<!-- Primary Button -->
<Button variant="primary">اضغط هنا</Button>

<!-- Secondary Button -->
<Button variant="secondary">إلغاء</Button>

<!-- Disabled Button -->
<Button variant="primary" disabled>معطل</Button>

وهكذا، شوي شوي، بنينا مكتبة كاملة من المكونات. كل مكون جديد بنبنيه، بنحذف كل التطبيقات القديمة له من الكود وبنستبدلها بالمكون الجديد الموحد. شغل تنظيف وترتيب أخذ وقت، بس النتيجة كانت تستاهل.

المرحلة الرابعة: التوثيق والنشر

نظام تصميم بدون توثيق، زي السيارة بدون كتالوج. ما حدا رح يعرف يستخدمه صح. استخدمنا أداة اسمها “Storybook” عشان نعمل موقع توثيق داخلي. هذا الموقع صار يعرض كل مكوناتنا بشكل تفاعلي.

أي مبرمج أو مصمم جديد بيفوت على الفريق، أول شي بنعطيه رابط هذا الموقع. بيقدر يشوف كل المكونات المتاحة، يجربها، ويشوف أمثلة كود جاهزة لكيفية استخدامها، ويقرأ الإرشادات (Do’s and Don’ts). هذا وفّر علينا ساعات وساعات من الشرح والتكرار.

النتائج التي حصدناها: جنة الاتساق

بعد تطبيق النظام، تغيرت حياتنا للأفضل بشكل جذري:

  • سرعة تطوير خرافية: بناء الصفحات الجديدة صار زي تركيب الليغو. بدل ما نبني كل شي من الصفر، صرنا نجمع مكونات جاهزة.
  • اتساق يريح العين (والأعصاب): كل شاشات التطبيق صارت تحكي نفس اللغة البصرية. تجربة المستخدم صارت سلسة ومتوقعة.
  • صيانة أسهل: لما نلاقي مشكلة في مكون، بنصلحها في مكان واحد (في نظام التصميم)، والتصليح بيظهر في كل مكان بيستخدم هذا المكون.
  • تعاون أفضل: صار في لغة مشتركة بين المصممين والمبرمجين. بطل في نقاشات طويلة عن “درجة اللون الأزرق”. صار الحكي “استخدم الـ Primary Button مع الـ Card component”.

الخلاصة: نصيحة من أخوكم أبو عمر

بناء نظام تصميم مش مشروع بتعمله وبتنساه، هو منتج داخلي لازم تهتم فيه وتطوره باستمرار. هو استثمار في البداية، لكن العائد تبعه على المدى الطويل ضخم جداً من ناحية الكفاءة والجودة وتجربة المستخدم.

إذا كنت بتعاني من الفوضى وعدم الاتساق في واجهاتك، فالحل مش في توظيف ناس أكثر أو عمل اجتماعات أطول. الحل في بناء “نظام”. ابدأوا صغار، اعملوا جرد للفوضى، وحدوا الأساسيات (الألوان والخطوط)، ابنوا أول مكون، ووثقوه. شوي شوي، رح تلاقوا حالكم بنيتوا أساس متين لشغل مرتب ونظيف، شغل على أصوله.

تذكروا دائماً، الاتساق هو علامة الاحترافية، ونظام التصميم هو طريقكم للوصول إليها. 👍

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التكنلوجيا المالية Fintech

كانت قراراتنا الائتمانية صندوقاً أسود: كيف أنقذنا ‘الذكاء الاصطناعي القابل للتفسير’ (XAI) من جحيم التحيز والشكاوى التنظيمية؟

في هذه المقالة، أشارككم قصة حقيقية من قلب الميدان عن كيفية تحولنا من نماذج ذكاء اصطناعي غامضة في التقييم الائتماني إلى أنظمة شفافة وقابلة للتفسير...

16 مايو، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

كانت أعطالنا تباغتنا في منتصف الليل: كيف أنقذنا Prometheus من جحيم المراقبة التفاعلية؟

أشارككم قصتي، يا جماعة، من ليالي السهر الطويلة أمام شاشات السيرفرات المحترقة، إلى راحة البال التي منحنا إياها نظام Prometheus. هذه ليست مجرد مقالة تقنية،...

16 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

طلبات الدمج تموت في الانتظار: كيف أنقذ “ميثاق مراجعة الكود” فريقنا من جحيم التأخير والجدل؟

أتذكر ذلك اليوم جيداً، طلب دمج (Pull Request) عالق لأسبوع، ونقاش حاد بين اثنين من أفضل المبرمجين حول تفصيل بسيط. كانت هذه هي القشة التي...

16 مايو، 2026 قراءة المزيد
اختبارات الاداء والجودة

كانت تحديثاتنا تكسر التصميم: كيف أنقذنا ‘اختبار التراجع البصري’ من جحيم الأخطاء المرئية؟

أشارككم قصة حقيقية من قلب المعركة البرمجية، وكيف تحولنا من فوضى الأخطاء المرئية بعد كل تحديث إلى ثقة وهدوء بفضل اختبارات التراجع البصري (Visual Regression...

16 مايو، 2026 قراءة المزيد
أتمتة العمليات

كان مطورنا الجديد ينتظر أياماً: كيف أنقذتنا ‘أتمتة إعداد البيئة’ من جحيم الأسبوع الأول الضائع؟

أتذكر جيداً كيف كان انضمام مطور جديد للفريق يعني بداية أسبوع من المعاناة والإحباط. في هذه المقالة، أسرد لكم قصة حقيقية حول كيف أنقذتنا أتمتة...

15 مايو، 2026 قراءة المزيد
نصائح برمجية

كانت إعادة المحاولة تدمر بياناتنا: كيف أنقذتنا ‘اللامتناهية’ (Idempotency) من جحيم العمليات المكررة؟

في ليلة لم أنم فيها، كانت أنظمتنا المالية تنهار بسبب عمليات دفع متكررة. أشارككم اليوم قصة كيف أنقذنا مفهوم "اللامتناهية" (Idempotency) من كارثة محققة، وكيف...

15 مايو، 2026 قراءة المزيد
​معمارية البرمجيات

كانت خدماتنا تتحدث في نفس الوقت: كيف أنقذتنا ‘المعمارية القائِمَة على الأحداث’ (EDA) من جحيم الاقتران المحكم؟

في ليلة إطلاق عصيبة، كادت خدماتنا المترابطة أن تُغرق المشروع بأكمله. أروي لكم كيف تحولنا من فوضى الاقتران المحكم إلى مرونة المعمارية القائمة على الأحداث...

15 مايو، 2026 قراءة المزيد
ذكاء اصطناعي

كانت نماذجنا تموت بصمت: كيف أنقذتنا ‘مراقبة تعلم الآلة’ (ML Monitoring) من كارثة التنبؤات الفاسدة؟

أشارككم قصة حقيقية من الميدان، حين كادت نماذج الذكاء الاصطناعي التي بنيناها بجهد أن تنهار بصمت. اكتشفوا معنا ما هي "مراقبة تعلم الآلة" (ML Monitoring)،...

15 مايو، 2026 قراءة المزيد
البودكاست