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

يا أهلاً وسهلاً فيكم، معكم أخوكم أبو عمر.

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

الزبون قلب في التطبيق شوي، سكت، وبعدين حكى جملة صارت كابوسنا لأسابيع: “شغلكم حلو… بس ليش كبسة ‘أضف للسلة’ هون لونها أزرق سماوي، وفي صفحة المنتج لونها أزرق نيلي؟ وليش هاي حوافها دائرية وهذيك حادة؟”.

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

هذيك الليلة كانت نقطة التحول. قررنا إنه “خلص، بكفي فوضى!”. ومن رحم هذه المعاناة، ولد قرارنا بتبني ما يسمى بـ “نظام التصميم” أو الـ Design System. وهذه هي حكايتنا معه.

ما هو “نظام التصميم” (Design System)؟ وليش هو المنقذ؟

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

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

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

  • المبادئ التوجيهية (Guiding Principles): فلسفة التصميم الخاصة بمنتجك. هل هو مرح أم جاد؟ بسيط أم غني بالمعلومات؟
  • أدوات التصميم (Design Tokens): الوحدات الأساسية زي الألوان، الخطوط، المسافات، الظلال، إلخ.
  • مكتبة المكونات (Component Library): القطع البرمجية الجاهزة والقابلة لإعادة الاستخدام (الأزرار، حقول الإدخال، القوائم، الكروت).
  • التوثيق (Documentation): الدليل الشامل اللي بيشرح كيف ومتى تستخدم كل عنصر من العناصر السابقة.

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

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

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

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

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

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

الخطوة الثانية: وضع الأساسات وتوحيد اللغة (Defining Design Tokens)

قبل ما نبني أي مكون، لازم نتفق على “الأبجدية” اللي رح نستخدمها. هاي الأبجدية هي ما يسمى بالـ Design Tokens. هي متغيرات بتحمل قيم أولية للتصميم.

بدل ما نكتب في الكود color: #3498db;، صرنا نكتب color: var(--color-primary-500);.

هذا التغيير البسيط كان ثوري! ليش؟ لأنه لو قررنا بعد سنة نغير درجة اللون الأزرق الأساسية في التطبيق، ما بنحتاج نمر على مئات الملفات ونعمل find & replace. كل اللي بنعمله هو تغيير القيمة في مكان واحد فقط!

قسمنا الـ Tokens لعدة فئات:

  • الألوان: (Primary, Secondary, Success, Error, Warning, Neutral) ولكل لون درجاته.
  • الطباعة (Typography): عائلات الخطوط، الأحجام (sm, md, lg, xl)، الأوزان (regular, medium, bold).
  • المسافات (Spacing): مقاييس موحدة للمارجن والبادينج (space-4, space-8, space-12, space-16).
/* مثال بسيط على ملف tokens.css */
:root {
  /* Colors */
  --color-primary-500: #3498db;
  --color-primary-600: #2980b9;
  --color-success-500: #2ecc71;
  --color-error-500: #e74c3c;
  --color-neutral-900: #2c3e50; /* For text */
  --color-neutral-100: #ecf0f1; /* For backgrounds */

  /* Spacing (based on a 4px grid) */
  --space-4: 0.25rem;  /* 4px */
  --space-8: 0.5rem;   /* 8px */
  --space-16: 1rem;    /* 16px */
  --space-24: 1.5rem;  /* 24px */

  /* Fonts */
  --font-family-base: 'Tajawal', sans-serif;
  --font-size-md: 1rem; /* 16px */
  --font-size-lg: 1.25rem; /* 20px */

  /* Borders */
  --border-radius-sm: 4px;
  --border-radius-md: 8px;
}

الخطوة الثالثة: بناء مكتبة المكونات (The Component Library)

هون ببلش الشغل الممتع. بعد ما صار عنا الأساسات (Tokens)، بدأنا نبني “قطع الليغو” البرمجية. اتبعنا منهجية اسمها “التصميم الذري” (Atomic Design) بشكل مبسط:

  • الذرات (Atoms): أصغر مكونات لا يمكن تجزئتها، مثل الزر (Button)، حقل الإدخال (Input)، الأيقونة (Icon).
  • الجزيئات (Molecules): مجموعة من الذرات تعمل معًا، مثل حقل البحث (حقل إدخال + زر بحث).
  • الكائنات (Organisms): مكونات أكثر تعقيدًا تتكون من جزيئات وذرات، مثل الهيدر (شعار + قائمة تنقل + حقل بحث).

أخذنا أشهر مكون سبب لنا الألم، “الزر”، وقررنا نصنع منه نسخة مثالية. عملنا مكون React واحد اسمه <Button /> يقبل خصائص (props) تحدد شكله وسلوكه.

// مثال على مكون زر بسيط في React
// Button.jsx
import React from 'react';
import './Button.css'; // ملف الستايل اللي بيستخدم الـ Design Tokens

function Button({ children, variant = 'primary', size = 'md', onClick, disabled }) {
  // بنبني الكلاسات بناءً على الخصائص
  const classNames = `btn btn--${variant} btn--size-${size}`;

  return (
    <button className={classNames} onClick={onClick} disabled={disabled}>
      {children}
    </button>
  );
}

// وفي ملف Button.css
.btn {
  /* ستايلات مشتركة */
  font-family: var(--font-family-base);
  border-radius: var(--border-radius-md);
  padding: var(--space-8) var(--space-16);
  cursor: pointer;
  border: 1px solid transparent;
}

.btn--primary {
  background-color: var(--color-primary-500);
  color: white;
}
.btn--primary:hover {
  background-color: var(--color-primary-600);
}

.btn--secondary {
  background-color: var(--color-neutral-100);
  color: var(--color-primary-500);
  border-color: var(--color-primary-500);
}

.btn--size-md {
  font-size: var(--font-size-md);
}

صرنا بدل ما كل مبرمج يكتب كود CSS جديد لكل زر، صار كل اللي عليه يعمله هو استخدام المكون الجديد: <Button variant="primary">إضافة للسلة</Button> أو <Button variant="secondary">إلغاء</Button>. يا الله شو كان هالإشي مريح!

الخطوة الرابعة: التوثيق هو الملك (Documentation is King)

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

استخدمنا أداة اسمها Storybook، وهي أداة رائعة بتخليك تعرض كل مكوناتك بشكل تفاعلي ومعزول. لكل مكون، كتبنا شرح بسيط:

  • ما هو هذا المكون؟ (مثال: الزر الأساسي للتطبيق).
  • متى تستخدمه؟ (مثال: استخدم الـ primary للإجراء الرئيسي في الصفحة).
  • متى لا تستخدمه؟ (مثال: لا تضع زرين primary بجانب بعضهما البعض).
  • الخصائص (Props): قائمة بكل الخصائص اللي بقبلها المكون مع أمثلة.

صار الـ Storybook هو الملعب والموسوعة لكل الفريق. أي مبرمج جديد بنضم النا، أول إشي بنعمله بنبعثله رابط الـ Storybook. خلال ساعة بكون فاهم كل مكوناتنا وكيف يستخدمها.

النتائج المبهرة: كيف تغير كل شيء؟

الاستثمار في بناء نظام التصميم كان من أفضل القرارات اللي أخذناها. النتائج ما كانت بس بصرية، بل لمسناها في كل جوانب الشغل:

  1. سرعة خرافية في التطوير: بناء شاشة جديدة تحول من أيام إلى ساعات. صرنا “نركب تركيب” بدل ما “نبرمج من الصفر”.
  2. تناسق بصري تام: التطبيق صار شكله “مرتب” و احترافي. تجربة المستخدم صارت سلسة ومتوقعة.
  3. صيانة أسهل: هل هناك خطأ في تصميم الأزرار على أجهزة آيفون؟ نصلحه في ملف واحد (مكون الزر)، والتصليح يطبق على كل الأزرار في التطبيق فوراً. “صلح مرة، بترتاح العمر كله”.
  4. لغة مشتركة: المصمم والمبرمج ومدير المنتج صاروا يتكلموا نفس اللغة. المصمم بقول “استخدموا مكون Card مع زر Secondary”، والمبرمج بكون عارف بالضبط شو المقصود بدون الحاجة لشرح طويل.
  5. تسهيل دخول المبرمجين الجدد: أحمد، المبرمج الجونيور، صارت إنتاجيته أعلى بكثير لأنه بطل خايف “يخرب” التصميم. عنده كتالوج واضح للقطع اللي لازم يستخدمها.

خلاصة الحكاية ونصيحة من القلب ❤️

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

يمكن بتحكي لحالك: “يا أبو عمر، أنا بشتغل لحالي أو فريقي صغير، ما عنا وقت لكل هالحكي”. نصيحتي إلك: ابدأ صغيرًا جدًا. مش ضروري تبني نظام متكامل من أول يوم.

ابدأ بملف CSS واحد مشترك، سميه global.css أو theme.css. عرف فيه بس متغيرات الألوان الأساسية والخطوط والمسافات. بس هاي الخطوة البسيطة رح توفر عليك ساعات من العذاب في المستقبل.

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

يلا شدوا حيلكم، وخلينا نبني تطبيقات مرتبة بتفتح النفس! 💪

أبو عمر

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

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

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

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

آخر المدونات

خوارزميات

كانت مهامنا تتنفذ بعشوائية: كيف أنقذنا ‘الفرز الطوبولوجي’ من جحيم الاعتماديات المتشابكة؟

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

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

كانت تغييرات قاعدة بياناتنا فوضى عارمة: كيف أنقذتنا أدوات الترحيل (Database Migrations) من جحيم “التعديل اليدوي على الإنتاج”؟

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

27 مايو، 2026 قراءة المزيد
الحوسبة السحابية

كانت إعداداتنا السحابية كتاباً مفتوحاً: كيف أنقذتنا أدوات CSPM من جحيم الثغرات الصامتة؟

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

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

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

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

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

كانت قاعدة بياناتنا على وشك الانهيار: كيف أنقذنا التخزين المؤقت (Caching) من جحيم الاستعلامات المتكررة؟

أشارككم قصة حقيقية من قلب المعركة التقنية، عندما كادت قاعدة بياناتنا أن تنهار تحت ضغط الاستعلامات المتكررة. اكتشفوا كيف كان التخزين المؤقت (Caching) هو طوق...

27 مايو، 2026 قراءة المزيد
التكنلوجيا المالية Fintech

كانت بياناتنا البنكية سجينة: كيف أنقذتنا واجهات برمجة التطبيقات المفتوحة (Open Banking) من جحيم الأنظمة المغلقة؟

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

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

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

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

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