كل شاشة كانت جزيرة معزولة: كيف أنقذني “نظام التصميم” (Design System) من فوضى الواجهات؟

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

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

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

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

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

كثير ناس بتخلط بين نظام التصميم ودليل الأنماط (Style Guide). الحقيقة إنه دليل الأنماط هو جزء صغير من نظام التصميم. خليني أبسطها:

• دليل الأنماط (Style Guide): هو وثيقة ثابتة بتحدد الألوان الأساسية، الخطوط، شكل الشعار، وكيفية استخدامه. زي كتالوج الألوان اللي بتختاره لدهان بيتك.
• نظام التصميم (Design System): هو أعمق وأشمل. هو “الدستور” الكامل لبناء واجهاتك. هو ليس مجرد “ماذا” (الألوان والخطوط)، بل أيضاً “كيف” و “لماذا”. إنه مجموعة من المبادئ، والمكونات القابلة لإعادة الاستخدام (كود حي)، والإرشادات، والأدوات التي تساعد الفرق على بناء منتجات رقمية متماسكة وبسرعة.

ببساطة، نظام التصميم هو صندوق العِدّة المتكامل، أما دليل الأنماط فهو مجرد قائمة بالموجودات داخل الصندوق.

الفرق الجوهري: المبادئ والمكونات الحية

اللي بيميز نظام التصميم هو إنه “حي”. المكونات اللي فيه مش مجرد صور وأمثلة، بل هي مكونات برمجية حقيقية (Code Components) بيستخدمها المطورين مباشرة في مشاريعهم. أي تحديث على مكون “الزر” في نظام التصميم، بينعكس تلقائياً في كل مكان يُستخدم فيه هذا الزر داخل التطبيق. هذه هي القوة الحقيقية: مصدر واحد للحقيقة (Single Source of Truth) للتصميم والبرمجة معاً.

أركان نظام التصميم: كيف نبني الأساس صح؟

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

1. المبادئ التوجيهية (Guiding Principles)

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

من هذه الإجابات، بنطلع بمبادئ أساسية. مثلاً:

• الوضوح أولاً: يجب أن تكون واجهاتنا سهلة الفهم والاستخدام فوق كل اعتبار.
• الكفاءة: تمكين المستخدم من إنجاز مهامه بأقل عدد من الخطوات.
• إمكانية الوصول (Accessibility): منتجنا يجب أن يكون قابلاً للاستخدام من قبل الجميع، بغض النظر عن قدراتهم.

هذه المبادئ بتصير هي المرجعية اللي بنحتكم إلها لما نختلف على قرار تصميمي.

2. رموز التصميم (Design Tokens)

هنا يبدأ السحر التقني. الـ “Tokens” هي المتغيرات الأساسية اللي بتحمل كل القيم الأولية لتصميمك. هي “ذرات” التصميم. فكر فيها كمتغيرات مركزية لكل شيء مرئي.

بدل ما تكتب في ملف الـ CSS الخاص بك color: #0A74DA; في 50 مكان مختلف، بتعرف “Token” واحد.

مثال على ملف Tokens بصيغة JSON:

{
  "color": {
    "brand": {
      "primary": { "value": "#0A74DA" },
      "secondary": { "value": "#F6F8FA" }
    },
    "text": {
      "default": { "value": "#24292E" },
      "subtle": { "value": "#586069" }
    }
  },
  "font": {
    "size": {
      "base": { "value": "16px" },
      "large": { "value": "20px" }
    }
  },
  "spacing": {
    "small": { "value": "8px" },
    "medium": { "value": "16px" },
    "large": { "value": "24px" }
  }
}

الجميل في الموضوع؟ لو قررت الشركة بعد سنة تغير لونها الأساسي من الأزرق إلى الأخضر، كل ما عليك فعله هو تغيير قيمة color.brand.primary في مكان واحد، وسيتغير اللون في كل التطبيق بطريقة سحرية. هذا يوفر أياماً، بل أسابيع من العمل اليدوي المكرر.

3. مكتبة المكونات (Component Library)

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

مثال لمكون “زر” بسيط باستخدام React و CSS-in-JS (معتمدة على Tokens افتراضية):

// Button.jsx
import React from 'react';
import styled from 'styled-components';
import { tokens } from './tokens'; // استيراد الـ Tokens

const StyledButton = styled.button`
  background-color: ${tokens.color.brand.primary};
  color: white;
  border: none;
  border-radius: 6px;
  padding: ${tokens.spacing.small} ${tokens.spacing.medium};
  font-size: ${tokens.font.size.base};
  cursor: pointer;

  &:hover {
    opacity: 0.9;
  }
`;

const Button = ({ children }) => {
  return <StyledButton>{children}</StyledButton>;
};

export default Button;

الآن، أي مطور في الفريق يريد إضافة زر، لن يكتب CSS من الصفر. سيقوم ببساطة باستيراد هذا المكون: <Button>حفظ التغييرات</Button>. النتيجة؟ كل الأزرار في التطبيق متطابقة 100% في الشكل والسلوك.

4. الأنماط والإرشادات (Patterns and Guidelines)

وجود المكونات لا يكفي. يجب أن نوفر دليلاً لكيفية استخدامها. هذا القسم يجيب على أسئلة مثل:

• متى نستخدم الزر الأساسي (Primary) ومتى نستخدم الزر الثانوي (Secondary)؟
• كيف يجب أن تظهر رسائل الخطأ في حقول الإدخال؟
• ما هو الترتيب المثالي للعناصر في صفحة الإعدادات؟
• إرشادات لكتابة النصوص داخل الواجهات (UX Writing).

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

تجربتي الشخصية: كيف طبقنا نظام التصميم خطوة بخطوة؟

الحكي النظري جميل، لكن التطبيق هو المحك. في مشروعنا، لم ننتقل من الفوضى إلى النظام بين يوم وليلة. اتبعنا نهجاً تدريجياً وواقعياً:

1. مرحلة الجرد والتدقيق (The Audit): أول خطوة كانت مؤلمة لكنها ضرورية. قمنا بعمل جرد بصري لكل مكونات التطبيق. أخذنا لقطات شاشة لكل الأزرار، حقول الإدخال، القوائم، الألوان المستخدمة. وضعناها كلها في ملف واحد. كانت النتيجة “صدمة حضارية” كما ذكرت، لكنها كشفت حجم المشكلة للجميع.
2. مرحلة التأسيس (Foundation): عقدنا ورشات عمل بين المصممين والمطورين. اتفقنا على المبادئ الأساسية، وحددنا لوحة الألوان والخطوط والمسافات النهائية. ثم قمنا بإنشاء ملف الـ “Tokens” المركزي.
3. بناء المكونات الأساسية (Build Core Components): لم نحاول بناء كل شيء دفعة واحدة. بدأنا بالأكثر استخداماً: Button, Input, Typography, Colors. بنيناها في مستودع (repository) منفصل واستخدمنا أداة مثل Storybook لعرضها وتوثيقها بشكل تفاعلي.
4. التبني التدريجي (Gradual Adoption): هذه أهم نصيحة عملية. لم نوقف كل شيء ونعيد كتابة التطبيق بأكمله. “شوي شوي”. كل ميزة جديدة كان لزاماً عليها استخدام نظام التصميم. أما الميزات القديمة، فكنا نقوم بتحديثها وتحويلها لاستخدام النظام الجديد كلما احتجنا للعمل عليها وإصلاح خطأ فيها. هذا النهج قلل المخاطر وجعل العملية سلسة.

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

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

• ابدأ صغيراً جداً: لا تحلم ببناء نظام تصميم بحجم “Material Design” من جوجل في أول يوم. ابدأ بالألوان والخطوط وزر واحد فقط. النجاحات الصغيرة تبني الزخم للمشاريع الكبيرة.
• التعاون هو المفتاح: نظام التصميم ليس مشروع قسم التصميم أو قسم البرمجة. هو منتج داخلي يخدم الفريق كله. يجب أن يشعر الجميع بالملكية. “إيد وحدة ما بتزقف”.
• التوثيق، ثم التوثيق، ثم التوثيق: إذا لم يكن المكون موثقاً وسهل الاكتشاف والاستخدام، فهو غير موجود. اجعل التوثيق واضحاً، عملياً، ومتاحاً للجميع.
• ضع آلية للحوكمة والتطوير: من المسؤول عن قبول المكونات الجديدة؟ كيف يمكن لمطور أن يقترح تحسيناً؟ وجود عملية واضحة يضمن أن النظام ينمو ويتطور ولا يموت.

الخلاصة: من جُزُر معزولة إلى قارة متصلة 🏝️ ➡️ 🌍

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

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