أهم جزء في عملية تصميم المنتج بأكملها هو تسليم التصاميم لجمع ملاحظات أصحاب المصلحة.

قبل Figma، كان فريق التصميم في OOZOU يستخدم كومة من الأدوات لإنجاز العمل. وكان لكثير منها نظامه الخاص للتحكم في "الإصدارات" بشكل أو بآخر، سواء برفع رابط للمشاركة أو باستيراد artboard من Sketch. وكانت كل أداة تحتاج إلى إدارة دقيقة على حدة وانتباه دائم من فريق التصميم.

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

1. نقلّل تدفّق الملاحظات (حتمًا)
2. نسلّم ملف تصميم بنظام "متقلّب"

وهذا ما سنتناوله في هذا المقال.

1. تقليل تدفّق الملاحظات

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

الخيار A: قسّموا الملفات بحسب مراحل التسليم

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

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

الخيار B: استخدموا Overflow لعرض الـ Wireframes والواجهات

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

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

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

وبعد الحصول على الموافقة على الـ wireframes ومسار المستخدم (user flow)، نستبدل عادةً الـ wireframes بشاشات واجهة فعلية، حتى يرى العميل بسهولة كيف تتحول الـ wireframes إلى واجهات حقيقية.

2. تسليم ملف تصميم متقلّب

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

الخيار A: أنشئوا ملف تسليم منفصلًا

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

ولتخفيف فروق الإصدارات بين الملفين، تعاملوا مع ملف العمل بوصفه "النسخة النهائية" كما تفعلون في أي بنية أخرى للتحكم في الإصدارات، ثم احفظوها في سجل الإصدارات باسم ‘[Handoff] XXXX’ أو ما يشبهه، ليعرف فريقكم نقطة التسليم الحالية. واحرصوا على تغطية كل تغيير عند تحديث ملفات التسليم. والطريقة الموصى بها هي حذف الصفحة بالكامل واستبدالها بالصفحة التي تعملون عليها حاليًا.

الخيار B: ارتجلوا!

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

شيء أخير...

رغم كل المعاناة التي مررتم بها لجعل كل شيء يعمل بسلاسة، علينا أن نعترف بأنكم لن تهربوا من واقع إصلاح العيوب، ومراجعة ملفات التصميم، والتجريب بين طرق التسليم المفضّلة لعملائكم بين حين وآخر. لذلك لا توجد طريقة فعّالة بنسبة 100% تنجح في كل الأوقات.

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

شكرًا لمتابعتكم حتى النهاية!

لا تترددوا في مناقشة أي شيء تجدونه صعب التطبيق، وسأكون سعيدًا بمساعدتكم في حل مشكلتكم!