_هذا هو الجزء الثاني من سلسلة "3 حلول عملية في التصميم"، ونعرض فيها المبادئ التي تقوم عليها طريقة اعتمدناها في جميع مشاريعنا المبنية على Figma. تنطبق معظم هذه النصائح على Sketch أيضًا (بل وعلى ملفات Sketch المستوردة إلى Figma). وإذا وجدتم صعوبة في تطبيق أيٍّ منها، فلا تترددوا في مراسلتي في قسم التعليقات لنناقشها معًا! _

التكرار ممل، بكل بساطة

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

1. حذف مكوّن رئيسي (Master component) بأمان من ملف المكتبة
2. تقليل الوقت الذي تستهلكه صيانة المكوّنات (باستخدام التجاوز على مستويين أو أكثر)
3. تسريع التعامل مع المكوّنات في ملفكم المحلي
4. إدارة حالات الشاشة المختلفة (مثل الخطأ والنجاح والحالة الفارغة والترجمة وغيرها)

1. ضعوا علامة "Deprecated" على المكوّن الرئيسي قبل حذفه

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

وفجأة تجدون أنفسكم تفتشون في كل ملف من ملفات التصميم السابقة واحدًا تلو الآخر لاستبدال المكوّن القديم.

لا داعي للبحث أكثر! بفضل هذا المقال المفيد من Steve Dennis أصبحنا نضع علامة على المكوّن الرئيسي في المكتبة قبل حذفه. نستخدم طبقة بنقش ذي لون صارخ فوق كل عنصر، وهذا يوفر علينا وقتًا كبيرًا عندما نحتاج إلى "تنظيف" فوضى المكوّنات أثناء العمل على عدة ميزات في وقت واحد. الفكرة مستوحاة من مفهوم العناصر المهملة (deprecated) في عالم البرمجة. وضع علامة "مهمل" على عنصر يشبه تعليق لافتة تقول: "إذا رأيت هذا في ملفات التصميم، فاستبدله فورًا"، ثم يُحذف المكوّن الرئيسي بعد أن يؤكد أعضاء الفريق أن كل شيء على ما يرام.

إليكم ملف SVG كمثال لتبدأوا فورًا. واحرصوا على تغيير لونه إلى لون أقبح ليترك انطباعًا لدى زملائكم! ويمكنكم أيضًا إعادة تسمية المكوّنات نفسها ليسهل العثور عليها في قائمة الطبقات، زيادةً في الحرص.

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

2. ورقة النسخ (لملف النظام)

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

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

تذكّروا ألا تكدّسوا جميع "طبقات الخيارات" معًا داخل مكوّن رئيسي واحد

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

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

ج. ضعوا مكوّن المكتبة داخل ملف العمل المحلي

استكمالًا لموضوع التجاوز في المكوّنات الرئيسية: إذا كان وقتكم ضيقًا، جرّبوا إنشاء إطار (frame) من مكوّن طُبّقت عليه التجاوزات مسبقًا، واستخدموه بدلًا من المكوّن الموجود في مكتبة المكوّنات الرئيسية.

مع المرونة الكبيرة تأتي مسؤولية كبيرة

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

د. قالب داخل الملف للتعامل السريع مع حالات الشاشة

قد تتطلب بعض الشاشات عرض عدة حالات لا تختلف عن الشاشة الأصلية إلا بفروق صغيرة. فتنسخونها وتلصقونها عدة مرات دون تفكير. ثم تصلكم ملاحظات العميل، فتجدون أنفسكم تصلحون الهوامش الداخلية (padding) للعنصر نفسه 4 مرات متتالية، لأنكم لم تُعدّوا شاشة قالب مناسبة لجميع الحالات التي صممتموها.

عندما تحوّلون صفحة كاملة إلى مكوّن لاستخدامه مع التجاوز، فكّروا في تغليف الصفحة بإطار آخر (أو artboard) لتحتفظوا باسمها وتربطوها بالصفحات الأخرى في مسار التنقل. ثم يمكنكم إعادة تسمية المكوّن الرئيسي بداخله بما يتوافق مع نظام تسمية المكوّنات لديكم، مثل "Page/xxx" أو "Template/xxx"

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

نأمل أن يساعدكم هذا في مهمتكم (للتخلص من الملل)

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