لنلقِ نظرة أقرب على الطريقة التي يمكننا (وينبغي لنا) أن نطبق بها أنظمة التصميم، لنخفف عبء الحفاظ على تنظيم جميع العناصر، ولنسهّل انضمام المصممين الآخرين إلى العمل.

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

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

أنشئوا هيكل ملفات معقولًا لمشاريعكم

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

نواجه في OOZOU بين حين وآخر معضلة "هل نفصل المكتبة أم لا". وهذا هو نهج فريقنا في التعامل معها:

أ. إن كان مشروعكم قصير الأمد، فاكتفوا بملف واحد.

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

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

ب. إن شعرتم بإمكانات نمو كبيرة، فابنوا ملف مكتبة أو اثنين.

يُنصح بفصل الملفات منذ الآن وربطها ببعضها، لأن المتغيرات ستزداد، مثل نسخ سطح المكتب المتجاوبة، والجوال، وPWA، والنسخة الأصلية (Native) من التطبيق نفسه.

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

ج. إن حان وقت التوسع، فحوّلوه إلى نظام تصميم متكامل!

هل لديكم تطبيقات ويب لسطح المكتب والجوال، وتطبيقات iOS وAndroid أصلية، مع نظام CMS؟ هنا يبدأ العمل الحقيقي! نتبع عادة هذه الممارسات في مشاريعنا الأكبر، مقسمة إما حسب المنصة المطلوبة (الجوال، CMS، تطبيقات الويب، وغيرها) أو حسب الميزات التي نسلمها لأصحاب المصلحة (الإعدادات، التهيئة والانضمام):

• الهوية (تضم العناصر المشتركة مثل الهوية البصرية والألوان وأنماط الخطوط)
• الأصول والرسوم التوضيحية (بمجموعتها الخاصة من الألوان والتأثيرات التي توسّع إرشادات الهوية الرئيسية)
• عناصر واجهة المستخدم والقوالب
• ملفات التصميم (مقسمة حسب الميزة مثل Home_Web وMobile وApps وPWA وCMS وغيرها، أو حسب المنصة مع ميزات متعددة، أو حسب اللغة عند تصميم تطبيق لعدة مناطق)

مكتبة التصميم

ستضم مكتبة واجهة المستخدم الرئيسية (أو المكتبات) بعض الفئات التالية أو أكثر:

1. الأساس: عناصر "لبنات البناء" الكلاسيكية التي تحدد البنية العامة لعناصر واجهة المستخدم، وتشمل:

   1. أصول الهوية: الشعار وعبارته التعريفية
   2. لوحة الألوان: مجموعة الألوان الأساسية والموسعة المبنية على إرشادات الهوية المؤسسية (CI)
   3. عائلة الخطوط: تضم أنواع الخطوط وعائلاتها المستخدمة في المنتج كله.
   • بسبب طريقة تعامل Figma مع أنماط ألوان الخطوط، نعرّف هنا أيضًا مجموعة محددة من ألوان الخطوط (باستخدام Text/ كمجموعة أم)

2. خيارات المسافات: عدد خيارات المسافات المسموح بها في النظام كله (على سبيل المثال، قد يبدأ نظام المسافات في مشروع ما بـ 4px، ويزداد بمقدار 4px، حتى حد أقصى 80px)

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

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

5. مكتبة المكونات: العناصر المشتركة المستخدمة في التصميم كله. هنا نحتفظ بالمكونات الأساسية ونسخها (instances)

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

ومع ذلك، ظلت هذه الأساليب تُنتج بعض المشكلات التي تحتاج إلى معالجة

المكونات (أو الرموز Symbols)

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

الخطوة 1: حددوا نظام التسلسل الهرمي لمكوناتكم

يتناول عدد كبير من مقالات Medium منهجية Atomic design لبراد فروست. وجدت المنهجية سهلة الفهم لكنها أصعب في التطبيق، لأن فريقنا يجد صعوبة كبيرة عمليًا في الفصل بين الذرات (Atoms) والجزيئات (Molecules) والكائنات (Organisms).

لحل ذلك، أنشئوا نظام "مكونات" موحدًا تتذكرون فيه كل عنصر باسمه الخاص. تخلّوا عن التجميع تمامًا، وأبقوا في أذهانكم حدًا معينًا لـ "دمج المكونات معًا". على سبيل المثال، مجموعة من زرين متجاورين أفقيًا ستكون أكثر من مجرد مكون، وستُسمّى ببادئة مثل 'Template/' أو ما شابه.

يساعد ذلك الآخرين أثناء بحثهم عن أي قواعد سبق وضعها، ويجنبهم دمج الشيء نفسه مرة أخرى. تذكروا أن تناقشوا الأمر مع أعضاء فريقكم وأن تضعوا مجموعة قواعد عامة تساعدهم على تحديد ما إذا كان العنصر قالبًا أم لا. وكل ما عدا ذلك يمكن أن يبقى مكونًا "عاديًا". الخطوة 2: حددوا مستويات تجاوز (override) المكونات في النظام عاجلًا أم آجلًا ستبنون مكونات أو قوالب متداخلة يمكن تجاوزها بعناصر شقيقة أخرى لتناسب سياق الشاشة (أو الحالة) الحالية.

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

• الإفراط في سهولة الوصول (مثل 4 مكونات رئيسية لأزرار بأربع حالات مختلفة) سيجعل صيانة النظام وبناءه بشكل متين أصعب فأصعب. إذا اضطررتم إلى تعديل الهوامش الداخلية للزر الأساسي 12 مرة، فنحن عمليًا نهدم الغرض من وجود النظام أصلًا.
• في المقابل، إذا كانت الطريقة مفرطة في المرونة (مثل 12 حالة نموذج في مكون رئيسي واحد) فسيصعب جدًا على المصممين الآخرين فهم ما تقصدونه وكيف تعمل العناصر معًا (أو كلٌّ منها بمفرده). وهذا يؤدي إلى عدم اتساق ويضطركم إلى المراجعة أكثر مما تودون

الفكرة الأساسية هي إيجاد نقطة التوازن في التطبيق، بحيث يسهل على الآخرين تعلّمها واتباعها، مع الحفاظ على المرونة بأقل جهد صيانة. وعادة يكون ذلك نحو 2-3 مكونات متداخلة لكل مكون رئيسي.

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

إدارة الإصدارات والتوثيق

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

لإعداد المكتبة وصيانتها بفعالية، أنصحكم بشدة بالامتناع عن حذف أي مكونات موجودة في النظام أو إجراء تغييرات جذرية غير ضرورية عليها، ما لم تكونوا متأكدين 100% من أنها لن تُفسد أي جزء من ملف العمل النشط. وإن لم يكن أمامكم خيار آخر، فأقترح بقوة أن تعتمدوا التحكم في الإصدارات (version control) لملف المكتبة.

ضعوا قاعدة لملاحظات الـ commit

يمكنكم فعل ذلك بسهولة عبر Abstract إن كنتم تعملون على Sketch. فقط تأكدوا من أن الجميع يكتبون ملاحظات commit ذات معنى

أما في Figma، فالتحكم في الإصدارات موضوع فيه شيء من التحدي، لأن مساهمة كل شخص في الملف تُعدّ المرجع المعتمد (source of truth). وقد تتحول الأمور إلى فوضى من الحفظ التلقائي إذا قررتم التراجع عن بعض التغييرات التي أُجريت على ملف مكتبة مرتبط في نظامكم.

أنصح باستخدام أمر 'Save to Version History' لتحديد نقاط في السجل. أنشئوا قاعدة Commit واطلبوا من الجميع الالتزام بها. ومن الأمثلة البسيطة أن تنشئوا نقطة بداية تكون نقطة عودة خاصة بكم عند بدء العمل، ثم نقطة نهاية أخرى حين تنتهون من عمل اليوم. وأقترح أن تكتبوا اسم المهمة لتعرفوا ما الذي تعملون عليه.

وإن صادف أن ابتعدتم عن هدف المهمة الأصلي، فضعوا نقطة بداية أخرى قبل ذلك وبعده، حتى تتمكنوا من تتبع الأمر والعودة إذا اكتشفتم أن خطأً ما قد وقع. احتفظوا بكتابة التعليمات للأمور الأصعب عند العمل ضمن فريق، فكروا في أي جزء من النظام تريدونه أن يكون "يُشرح مرة واحدة"، وأي جزء يحتاج إلى "تذكير" لكم وللآخرين.

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

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

تهانينا، أصبح لديكم نظام تصميم!

استرخوا واستمتعوا بكوب دافئ من الشاي. يُفترض أنكم الآن جاهزون لإعداد نظام التصميم لاستخدامه في مشروعكم القادم! وهذا على الأرجح أكثر من كافٍ لمساعدتكم على إعداد مكتبة قابلة للاستخدام بهيكل ملفات جيد جاهز للتوسع في المستقبل القريب.