واحدة من أكبر المشاكل التي كنت أشاهدها سابقًا ضمن المشاريع هي عدم وجود نظام تصميم يضبط عملية التصميم والتطوير معًا، حيث تجد أن الألوان والمُكوِّنات تُبنى وتُستخدَم بطريقة عشوائية، مما يؤدي إلى مشاكل هائلة عندما يبدأ حجم المشروع بالازدياد.
وطبعًا الحل لكل المشاكل هو استخدام نظام تصميم يضبط مُكوِّنات المشروع بشكل واضح لكل الأشخاص والفرق التي تعمل عليه، في هذا المقال سوف نشرح ما هو نظام التصميم، ممَّ يتكوَّن، وأين نَتَبَنّاه؟
ما هو نظام التصميم؟
نظام التصميم (Design System) هو مجموعة من القواعد والمُكوِّنات القابلة لإعادة الاستخدام مثل الألوان والمسافات والتايبوغرافي، مع توثيق يشرح كيفية تطبيقها. يعتمد عليه المُصمِّمون والمُطوِّرون لبناء واجهات مُتَّسقة في شكلها وسلوكها، بدل البدء من الصفر في كل شاشة.
مثلًا، إذا كنت تعمل على تطبيق لحجز المواعيد، سيُحدِّد النظام شكل زر تأكيد الحجز، وحالته أثناء إرسال الطلب، وطريقة إظهار الخطأ إذا تعذّر الحجز. وعندما تُصمِّم صفحة لتعديل الموعد، تستطيع استخدام القواعد والمُكوِّنات نفسها بدون إعادة تصميمها مرة أخرى.
يُوضِّح دليل Nielsen Norman Group عن أنظمة التصميم أن النظام يشمل الموارد المشتركة والأشخاص الذين يُديرونها. فملف مُنظَّم لا يبقى مفيدًا طويلًا إذا لم يُحدِّثه أحد، أي يجب أن تدرك أن نظام التصميم ليس عبارة عن ملف أو قواعد تُبنى لمرة واحدة وإنما ملف يعيش معك طول فترة عمر المشروع.
هل مكتبة المُكوِّنات نظام تصميم؟
مكتبة المُكوِّنات جزء من نظام التصميم. فهي تُوفِّر الأزرار والحقول والقوائم وغيرها من العناصر الجاهزة للاستخدام. أما النظام فيشرح أيضًا متى تستخدمها، وكيف تتصرّف، ومن يُراجِع التغييرات عليها، أي أن نظام التصميم عبارة عن شيء أعمّ وأكبر من المكتبة فقط.
أما دليل الهوية البصرية فيُركِّز على طريقة ظهور العلامة، مثل الشعار والألوان والخطوط. ويستفيد نظام التصميم من هذه الهوية، ثم يُضيف تفاصيل تحتاجها الواجهات، مثل حالات التفاعل ورسائل الخطأ وإمكانية الوصول.
أما ملف الواجهات الجاهزة (UI Kit) والذي يتوفَّر بشكل كبير في الإنترنت، فقد يساعدك على بدء التصميم بسرعة، لكنه لا يُخبرك بالضرورة كيف يُنفَّذ ما فيه برمجيًا أو كيف تُحدَّث موارده قبل اعتماده.
ممَّ يتكوَّن نظام التصميم؟
الأسس البصرية
ابدأ بالقِيَم التي تتكرّر في الواجهات: الألوان والخطوط وأحجام النصوص والمسافات والأيقونات. إذا وُجد دليل للهوية البصرية، استخدمه كنقطة بداية، ثم اختبر ملاءمة خياراته للشاشات والمحتوى.
لا يكفي أن تختار لونًا أحمر؛ حدِّد استخدامه. هل يدلّ على خطأ؟ أم يُستخدَم لإجراء يحتاج إلى انتباه، مثل حذف الحساب؟ الفصل بين هذه الاستخدامات يساعد الفريق على اختيار اللون المناسب للاستخدام المناسب.
يمكن تمثيل هذه القرارات من خلال رموز التصميم (Design Tokens) والتي هي أسماء مرتبطة بقِيَم مُحدَّدة. مثلًا، يرتبط الاسم color.text.error بلون نص الخطأ، بدل كتابة قيمة اللون يدويًا في كل موضع. يشرح نظام التصميم الأمريكي USWDS كيف تُساعد مجموعة مُحدَّدة من القِيَم على توحيد التصميم وتسهيل التواصل مع التطوير.
المُكوِّنات وحالاتها
المُكوِّن عنصر يُعاد استخدامه مثل زر أو حقل إدخال، يُجهَّز لاستخدامه لاحقًا ضمن الشاشات والتصاميم، وطبعًا تحتاج إلى توضيح حالاته وسلوكه، وليس شكله العادي فقط.
لنأخذ حقل البريد الإلكتروني مثالًا. وثِّق اسم الحقل ونص المساعدة وما يظهر عند تركه فارغًا ورسالة الخطأ عند إدخال عنوان غير صحيح. وضِّح أيضًا كيف يتعامل مع النص الطويل، وكيف ينتقل إليه الشخص باستخدام لوحة المفاتيح.
عندما تتوفّر نسخة برمجية من المُكوِّن، اربطها بتوثيقه. يجب أن يعرف المُطوِّر أي مُكوِّن يقابل التصميم، وأن يستطيع المُصمِّم مراجعة السلوك الفعلي بعد التنفيذ، في هذه النقطة يمكنك استخدام ميزة Code Connect في Figma للقيام بذلك.
أنماط الاستخدام
النمط هو طريقة مُوثَّقة لإنجاز مهمة متكرّرة، وقد يجمع أكثر من مُكوِّن. مثلًا، يحتاج تعديل موعد إلى اختيار موعد جديد، ومراجعة التفاصيل، ثم تأكيد التغيير.
المطلوب هنا شرح ترتيب الخطوات والمعلومات، وما يحدث إذا تعذّر إكمال المهمة. لذلك لا تقتصر الأنماط على تجميع العناصر بصريًا. يعرض قسم الأنماط في GOV.UK أمثلة لمهام مثل إدخال العناوين ومراجعة الإجابات، مع إرشادات لاستخدام المُكوِّنات ضمن سياقها.
كيف يبدو التوثيق المفيد؟
بدل كتابة «هذا زر الحذف» اشرح القرار الذي يحتاجه من سيستخدمه. في مثال افتراضي لحذف عنوان محفوظ، يمكن أن يتضمّن التوثيق:
الاستخدام: استخدمه لإزالة عنوان محفوظ من الحساب، وليس لإلغاء تعديلات لم تُحفَظ بعد.
النص: اكتب «حذف العنوان» حتى يكون الإجراء واضحًا.
التأكيد: إذا كان الحذف نهائيًا، اشرح نتيجته ووفِّر زرًا لإلغاء العملية قبل تأكيد الحذف.
الحالات: وضِّح ما يظهر أثناء التنفيذ، وعند النجاح، وعند فشل الطلب.
إمكانية الوصول: لا تعتمد على اللون وحده لتوضيح خطورة الإجراء، وراجِع استخدام الزر بلوحة المفاتيح.
يمكنك الاطّلاع على توثيق الأزرار في GOV.UK لرؤية كيف يجمع النظام بين أمثلة الاستخدام، وإرشادات النص، والكود. استفد من طريقة الشرح، ثم اكتب القواعد المناسبة لمُنتَجك، أيضًا يمكنك تضمين هذا التوثيق كإرشادات داخل مكتبة التصميم في Figma من أجل مساعدة Figma Agent في فهم المُكوِّنات واستخدامها بطريقة صحيحة.
متى تحتاج إلى نظام تصميم؟
بشكل عام أي مشروع لا يُعتبَر عبارة عن صفحة واحدة أو عدة صفحات بسيطة سوف تحتاج إلى بناء نظام تصميم، أي عندما تتكرّر العناصر بين شاشات كثيرة، أو يعمل أكثر من فريق على المُنتَج، أو تتراكم نُسَخ مختلفة من المُكوِّن نفسه. عندها يساعدك المرجع المشترك على تقليل إعادة العمل وتسهيل مراجعة التغييرات.
لكن لا يلزم أن تبني نظامًا ضخمًا لكل مشروع. في نموذج أوّلي صغير، قد تكفي أسس بسيطة وعدد محدود من المُكوِّنات. ويمكنك تَبَنّي نظام قائم أو تكييفه بدل بناء كل شيء بنفسك، بعد مراجعة ملاءمته وحقوق استخدامه.
حتى طريقة البناء ليس من الضروري أن تكون فورية، أي ليس من الضروري بناء نظام تصميم كامل العناصر لكل مشروع، قم ببناء ما تحتاجه أثناء العمل فقط، فنظام التصميم كبير الحجم يحتاج إلى وقت وخبرة في إدارته، والتعامل معه وصرف كل هذا المجهود عليه إن لم يكن ضروريًا فهو مضيعة للوقت.
ولا يُغني النظام عن فهم احتياجات الجمهور أو اختبار الواجهة. وجود حقل جاهز لا يعني أن عليك طلب هذه المعلومة أصلًا. يُوضِّح مقال تصميم واجهات الاستخدام من الفكرة إلى التنفيذ كيف يرتبط بناء الواجهة بالقرارات التي تسبقه.
كيف تبدأ بناء النظام؟
راجع ما لديك أولًا
اجمع أمثلة من الشاشات الحالية، وقارِن الأزرار والحقول والمسافات والنصوص المتكرّرة. ابحث عن اختلافات لا تخدم حاجة واضحة، مثل وجود ثلاث طرق لعرض الخطأ نفسه.
بعدها اتّفق مع الفريق على ما يستحق التوحيد. ليس كل اختلاف خطأ؛ فقد يحتاج إجراء رئيسي إلى بروز أكبر من إجراء ثانوي.
ابنِ ما تحتاجه وجرّبه
اختر مهمة حقيقية، مثل حجز موعد، وابنِ المُكوِّنات اللازمة لها. جرِّبها داخل الشاشة قبل تعميمها. هل تستوعب النص العربي؟ هل تبقى واضحة مع تكبير النص؟ وهل تتكيّف مع المساحة المتاحة؟ راجِع أيضًا ظهور البريد الإلكتروني والأرقام داخل الواجهة العربية، ووضوح العنصر الذي يصل إليه الشخص أثناء التنقّل بلوحة المفاتيح.
هذه التجربة تُظهِر ما ينقص المُكوِّن أسرع من بناء حالات كثيرة لمجرد احتمال استخدامها. أضف الحالات الجديدة عندما تكون لها حاجة مفهومة.
اتّفق على التنفيذ والصيانة
حدِّد مع المُطوِّر الأسماء والحالات والسلوك، ثم راجعا النسخة المُنفَّذة. تغيير المُكوِّن في Figma وحده لا يُغيِّر المُنتَج تلقائيًا.
اتّفقا أيضًا على طريقة طلب التعديلات واعتمادها. عند استبدال مُكوِّن قديم، وضِّح البديل وكيفية الانتقال إليه قبل حذفه. يمكن أن يبدأ هذا التنظيم بمسؤول واضح وسِجِلّ تغييرات بسيط، ثم يتوسّع بحسب حجم الفريق.
كيف تُطبِّقه داخل Figma؟
استخدم المُتغيِّرات (Variables) للقِيَم التي تحتاج إلى مشاركتها وتغييرها، وأنماط النصوص (Text Styles) لتنسيقات الكتابة. ابنِ المُكوِّنات باستخدام Auto Layout، ونظِّم اختلافاتها عبر Variants وخصائص المُكوِّن بدل تكرار نُسَخ منفصلة يصعب تحديثها.
المُتغيِّر وسيلة لحفظ قيمة داخل Figma، أما رمز التصميم فيُعبِّر عن قرار تريد مشاركته بين التصميم والكود. مثلًا، يمكن تمثيل لون نص الخطأ بمُتغيِّر في الملف وقيمة مقابلة في الكود. اتّفق مع المُطوِّر على العلاقة بينهما وكيفية تحديثهما، بدل افتراض أنهما متزامنان تلقائيًا.
اختر أسماء تُوضِّح الاستخدام، وأضف وصفًا قصيرًا للمُكوِّن، ثم انشر المكتبة ليتمكّن الفريق من استخدامها. توصي إرشادات Figma لتنظيم المُكوِّنات والمُتغيِّرات بالتسمية الواضحة والبنية القابلة لإعادة الاستخدام؛ وهي مفيدة للفريق وللأدوات التي تتعامل مع ملفاته.
ولتعلُّم كل هذه الخطوات بطريقة عملية، يمكن متابعة دورة متقدمة في Figma حيث قمنا بشرح عملي لكل من بناء أنظمة التصميم، والمُتغيِّرات، وAuto Layout، وخصائص المُكوِّنات، وتنظيم المكتبات. والأفضل دائمًا أن تربط ما تتعلّمه بمشروع تعمل عليه، حتى تعرف لماذا تحتاج إلى كل خاصية وتتدرَّب عليها بشكل فعلي.
ومع استخدام أدوات الذكاء الاصطناعي، تزداد أهمية توثيق قواعد المكتبة. يمكنك قراءة مقال وكيل Figma وإرشادات أنظمة التصميم لمعرفة كيف تُرفِق هذه القواعد بالمكتبة. أما معلومات الجمهور واحتياجاته، فيشرح مقال ملف UX.md طريقة تنظيمها لتوجيه الأدوات؛ وهي تُكمِّل قواعد الواجهة ولا تحلّ محلّها.
كيف تعرف أنه يُفيد الفريق؟
راقِب استخدامه في العمل: هل يجد زملاؤك المُكوِّن المناسب؟ هل يحتاجون إلى نُسَخ منفصلة منه كل مرة؟ وهل يجيب التوثيق عن الأسئلة التي تتكرّر أثناء التنفيذ؟
إذا كان الفريق يتجاوز المكتبة باستمرار، افهم السبب قبل إضافة قواعد جديدة. ربما ينقصها مُكوِّن مهم، أو يصعب العثور على الموجود، أو تختلف نسختها عن الكود.
ابدأ بمُكوِّن يتكرّر في مشروعك، ووثِّق استخدامه وحالاته، ثم جرِّبه مع مُصمِّم ومُطوِّر. ما يتعذّر عليهما فهمه هو نقطة مناسبة لتحسين النظام.
المصادر
تاريخ النشر
14 أكتوبر 2026
آخر تعديل
14 أكتوبر 2026
