الخلفية

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

ومن خلال ورشة عمل مكثفة مع العميل، تمكنّا من جمع المتطلبات وتحديد مفهوم المشروع بشكل أدق:

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

موجز التصميم

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

وبفضل نمو فريق التصميم لدينا، تمكنّا من قبول مشروع يتطلب إنجاز عدد كبير من الشاشات في وقت قصير.

التحديات

• عملنا عن بُعد مع عدد كبير من أصحاب المصلحة، منهم مالكو المنتج (Product Owners) وفريق التسويق خارج الموقع وفريق التطوير بـ React Native.
• كان يجب تسليم تصميم التطبيق خلال 40 يوم عمل.
• سيتولى فريق تطوير العميل كل أعمال التطوير. لذلك كان على OOZOU تسليم جميع الأصول وإرشادات تصميم كاملة لتنفيذها لاحقًا من قبل الأطراف الأخرى.
• وكما هو معتاد وفق مبدأ أساسي في OOZOU، اتفقنا مع العميل منذ البداية على أننا لن نعمل أي ساعات إضافية على الإطلاق. فكل شيء يجب أن يُنجز ضمن ساعات عملنا المعتادة البالغة 7 ساعات.

النماذج الأولية وتصميم الواجهات بالتوازي

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

احصلوا على اعتماد العميل وموافقته قبل الالتزام بأي عمل على الواجهة

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

وسار السبرينت (Sprint) لدينا على هذا النحو:

يمنحنا العمل بهذه الطريقة نافذة زمنية لإعادة صياغة مسار الاستخدام، ويبقي العميل منخرطًا في عملية التصميم.

ملف واحد و3 مصممين

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

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

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

وباتباع سير العمل هذا، تمكنّا من الحفاظ على عبء عمل معقول لكل عضو في الفريق مع هامش كافٍ من المرونة.

ما تعلّمناه

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