واجهاتنا كانت فوضى بصرية: كيف أنقذنا ‘نظام التصميم’ (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”.

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

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

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

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

أبو عمر

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

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

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

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

آخر المدونات

​معمارية البرمجيات

كانت خدماتنا ككرة صوف: كيف حررتنا ‘المعمارية الموجهة بالأحداث’ (EDA) من جحيم التبعيات؟

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

26 أبريل، 2026 قراءة المزيد
ذكاء اصطناعي

كان أداء نماذجنا يتدهور بصمت: كيف أنقذنا رصد انحراف البيانات (Data Drift) من جحيم التنبؤات الفاسدة؟

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

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

كنا نسأل قاعدة البيانات عن كل شاردة وواردة: كيف أنقذتنا ‘مرشحات بلوم’ (Bloom Filters) من جحيم استعلامات التحقق؟

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

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

ميزانيتنا التسويقية كانت ثقباً أسود: كيف أنقذنا ‘نموذج الإحالة المبني على البيانات’ من جحيم تخمين العائد على الاستثمار؟

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

26 أبريل، 2026 قراءة المزيد
برمجة وقواعد بيانات

كان بحثنا بطيئاً وغير دقيق: كيف أنقذنا البحث كامل النص (Full-Text Search) من جحيم استعلامات LIKE؟

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

26 أبريل، 2026 قراءة المزيد
التوظيف وبناء الهوية التقنية

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

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

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