البحث في الموقع

حين تُستخدم كلمة مرن (Agile) في مجال الرياضة فإنها تشير إلى الحيوية، والطاقة والمرونة، ويوصف بها الرياضيون وأبطال الأولمبيات الذين تميزوا في ألعابهم، كما يمكن استخدامها لوصف العمليات العقلية التي تتسم بالسرعة والمرونة والحدّة. أما في عالم تصميم تجربة المستخدم فإنها تشير إلى عدد العمليات التي تبدأ بميزانية قليلة، وتجمع فرقًا من المساهمين من أجل إنهاء سلسلة مهام معينة. ويركّز المنظور المرن على التفاعلات والأفراد، ومساهمات المستخدمين، والاستجابة السريعة للتغيير. منهجية التدافع (Scrum Methodology) بدأ استخدام نمط العمل المرن المبني على نموذج التدافع (Scrum Model) لأول مرة في تصميم البرمجيات، ويبدأ عادة بفريق يخطط لاجتماع يقسّم الأعضاء فيه العمليات إلى أجزاء صغيرة ويقررون أي المهام ستوكل إلى كل عضو، ثم ينشئون قائمة بالمهام التي يمكن إنهاؤها في إطار زمني محدد، ويكون عادة بين الأسبوعين والشهر. ويقوم فريق التدافع (Scrum Team) بكتابة الشيفرة البرمجية واختبار أداء المزايا خلال المرحلة الأولى التي تُسمّى "First Agile Sprint”، وهي إطار زمني قصير من العمل المكثّف. ويحضر أعضاء هذا الفريق اجتماعات قصيرة يومية ينظمّها شخص تكون مهمته أشبه بالمدرّب، ويطلق عليه عادة "Scrum Master”، ويشارك الأعضاء في هذه الاجتماعات ما أنجزوه ويفكرون في حلول للمشاكل، وتحافظ هذه الاجتماعات اليومية على إبقاء جميع الأعضاء مدركين لما فعله كل واحد منهم خلال تلك المرحلة. الصورة عبر الموقع prosoftnearshore.com. ثم يعرضوا ما أنجزوه في نهاية المرحلة على المالكين (حملة الأسهم [stakeholders]) ليتلقّوا منهم النقد والملاحظات، فيخططوا للمرحلة التالية من التطوير وما سيتغير فيها أو يُراجَع على ضوء هذه المراجعات. ويساعد نمط العمل المرن الفرَق على إنهاء المشاريع أسرع، لهذا تبنّت مجالات مثل القانون والتسويق منهجيات مشابهة، ذلك أن نمط العمل المرن في تجربة المستخدم هو المسؤول عن رسم الخطوات من أول البحث وتجميع بيانات المستخدمين من خلال اختبار قابلية الاستخدام، وذلك قبل التطوير مباشرة. ويُقدّر من يستخدمون نمط العمل المرن لتجربة المستخدم بنحو 69% من العاملية في مجال تجربة الاستخدام، ولدى جوجل منهجية تيسّرالانتقال من التصميم إلى الاختبار في وقت لا يتجاوز أسبوعًا، لكن لا شك أن كل منظّمة تستطيع أن تعدّل مراحل تلك المنهجية لتناسب أفضل الإطارات الزمنية لمشاريعها. الانتقال إلى أنماط عمل تجربة المستخدم المرنة يسرّع العمل الجماعي من عملية التحول إلى مخططات العمل المرنة إذ ينشئ المصممون والمطورون والمدراء فرقًا مشتركة تتداخل وظائفها ليعمل الجميع على أوجه مختلفة من المشكلة في نفس الوقت. وتركز كل فئة -كمجموعة و كأفراد- على أنشطة المستخدم واحتياجاته وتفاعلاته، وتنظر إلى كل ناحية من خلال تلك العدسة. وتكون العملية بهذا الشكل سلسلة من المراحل أو الأجزاء، ويمكن أن يرجع التطوير من أجل تصحيح خطأ أو فكرة غير صحيحة، أو يتقدّم للأمام إلى المرحلة التالية. تصميم تجربة المستخدم القِطَعية للتخطيط المرن (Chunk UX Design) قد يكون من المغري أن ينقل الفريق تركيزه من تلبية احتياجات المستخدم إلى إنهاء المهام التي بين يديه حين يتحرك بسرعة ليرى المشروع من البداية إلى النهاية في فترة موجزة للغاية. وإن المنتج النهائي لن يكون له قيمة إن لم يحقق الأهداف التي صُمم من أجلها. ويأتي دور التصميم القِطَعي (Chunk design) هنا في أنه يقسّم العمل إلى مهام أصغر كي تعيد تركيزك إلى البحث المرتكز حول المستخدم، فتحدد أولًا هدفك ثم تخطط أنشطة تجربة الاستخدام التي تدعم هذا الهدف، ثم بعد ذلك تقسّم تلك الأنشطة إلى مهام أصغر، وتستخدم بعدها برنامج يعتمد النظام المرن-agile أو بطاقات لاصقة لإنشاء قصص المستخدم- user stories. ويجب أن تقرر الترتيب المناسب لإنجاز تلك المهام ومن سيكون مسؤولًا عن كل واحدة، ويجب أن يكون كل قرار مرتبطًا بإحدى قصص المستخدم- user story. العمل مثل جوجل تتبع عمليات التصميم القوية خطة نظامية، لكن تمهّل قليلًا إن خرجت فكرة عما هو مخطط لها إذ هناك دومًا مساحة للتنفيذ مرة أخرى، وأعد النظر فيها مرة أخرى قبل التقدّم لما بعدها. ويتضمن أسلوب العمل في جوجل خمس مراحل، يحق للمصممين أن يتنقلوا بينها ذهابًا وإيابًا في أي وقت. ودعنا نلق نظرة على كل واحدة من تلك الخطوات التي صممت لتستغرق كل منها يومًا واحدًا، وتستطيع الشركات التي لا تتبع الخط الزمني لجوجل أن تستخدم نفس التسلسل لكي تتحول إلى نمط عمل مرن هي الأخرى. تفصيل المشروع (Unpack the Project) تبدأ مرحلة التصميم في جوجل باجتماع يشمل كل الأفراد الذين لهم علاقة بالمشروع من مختلف أقسام المؤسسة، من المصممين إلى مسؤولي المبيعات إلى ممثلي خدمة العملاء وحتى المدراء، إذ يجب أن يدلي كل هؤلاء بآرائهم من البداية. وبسبب هذا الجمع من الأشخاص ومستويات المسؤولية، فمن من المفيد هنا دعوة شخص تكون مهمته إبقاء الحديث داخل نطاق المشروع. إليك بعض الأمور التي يجب أن تناقشها في خطوة تفصيل المشروع: قدّم تصورًا عامًا عن الكيفية التي ستنتفع بها الشركة من الحل الذي لديك. اعرض مقارنات لما لدى المنافسين لك. استعرض المشكلة والحلول الجزئية الحالية التي تحاول معالجتها. جهّز شخصيات المستخدمين التي تستهدفها، وكذلك نتائج التحليلات التي قمت بها. لخّص الحل الذي تقترحه. استعرض مقاييس تجارية تدعم نجاح الحل الذي تقدّمه. إن نمط العمل المرن يبدأ بتوضيح رؤيتك من البداية، حتى لو لم تتبع أو تستخدم تسلسل جوجل في مشاريعها، فيقدّم المصممون رؤيتهم المبدئية للفريق، سواء عبر رسومات سريعة "Sketches” أو عبر تخطيط لرحلة المستخدم "cutomer journey mapping” داخل الموقع أو المنتج بشكل عام. صياغة مسوّدات للحلول (Sketching Solutions) يتفرق كل من حضر اجتماع تفصيل المشروع لينشئ رسومات بسيطة باستخدام قلم وورقة للحلول المحتملة، وللمشاركين أن يقسّموا الحلول إلى أجزاء صغيرة، ويوضّحوا الترتيب الذي يرونه لتلك الأجزاء. وبشكل عام، ابدأ بإطار عمل بسيط، وستتضح التفاصيل مع الوقت في كل مرة تكرره فيها. اتخاذ القرارات (Making decisions) اسرد العوامل المهمة لك، مثل ميزانيتك، والعوائق التقنية، ومدخلات المستخدمين، ثم راجع الحلول المحتملة لتقلل هذه الحلول إلى عدد محدود وفقًا لما تقتضيه العوامل التي لديك. أيضًا، أنشئ لوحات قصصية "Storyboards” لأفضل الحلول التي جمعتها، واستخدم حائط تصميم "Design Wall” -حائط أو لوحة تعلق عليها الحلول- لتعرض الحلول التي لديك، ثم أعد تقييمها من حيث تركيز كل منها على المستخدم. إنشاء نماذج أولية (Creating Prototypes) تأخذ كل مجموعة أحد الحلول وتبدأ في العمل، تقترح جوجل هنا بناء نماذج أولية بسرعة باستخدام قوالب Keynote أو أي أداة أخرى تسمح بتطوير النماذج في فترة يوم. لا تنس أن تطور عملية اختبار لهذه النماذج لاستخدامها في اليوم التالي أو المرحلة التالية، ويحبّذ كذلك أن تدعو حمَلة الأسهم للمشاركة في كل خطوة. اختبار التصاميم (Testing Designs) اطلب من المستخدمين أن يتفاعلوا مع نموذجك الأولي، وسجّل أنت ملاحظاتك عن تفاعلهم بينما يستخدموه لترى ما الذي لم يحدث كما خططت له، فإن تجربة المستخدم هي التي ستقود المرحلة التالية. يمكن هنا أن يسجّل المصممون المشاكل في تجربة الاستخدام من أخطاء التصميم أو مشاكل الأداء الخلفي (Back End Performance). قد تحتاج المؤسسات في البداية إلى وقت أطول من المتوقع لإنهاء بعض المراحل، تمامًا مثلما يتطور الرياضيون مع التمرين المستمر، لذا فإن فرق التصميم ستنجز أسرع مع التدرب المستمر والمتكرر، وسواء كنت ستجعل نمط العمل المرن الخاص بك مثل نموذج جوجل أو ستطور واحدًا مختلفًا لمؤسستك، فإن إدارة الوقت ستكون جزءًا مما يجعل العملية المرنة ذات كفاءة إنتاج عالية. تعقّب الوقت وضبطه (Time Tracking and Time Boxing) يتوقع أسلوب العمل المرن تقدّم العمل ويتابعه على مدار الوقت تمامًا كما يتوقّع العدّاء الوقت اللازم لإنهاء مسافة ما ويستخدم نقاطًا على طول تلك المسافة ليتابع إنجازه. وتساعد هذه التوقعات الفِرَق على توقع الوقت اللازم لتسليم منتج ما، وقد يكون حساب وقت كل مرحلة صعبًا في البداية، لكن ستجد أن العمل يسير على نمط يمكن توقعه مع الوقت، فيمكنك معه توقع الوقت اللازم لإنهاء مهام فردية خلال المرحلة. أما ضبط الوقت فيتضمن وضع وقت محدد يمكن لنشاط أن ينتهي فيه، فضع إطارًا زمنيًا لبحث تجربة المستخدم وراجع الاجتماعات والمراحل كي تقف على أسباب زيادة الكفاءة، هذا الأسلوب سيدفع كل عضو أن يرفض الأفكار التي لا تصلح مباشرة، ويركز على تلك التي تبدو واعدة. العمل الجماعي هو الذي يوجه مخطط العمل كما أن مرحلة التصميم لها أجزاء واضحة تتجانس معًا، فإن كل عضو في الفريق له دور داخل حلقة تتكرر، فالمصممون يتصورون الصفحات بشكل عام، ويناقشون مهام التصميم على أنها ضرورة لإنشاء الصورة الكاملة، لكن ذلك قد يعني أنهم يعملون بشكل مستقل عن بقية الفريق. ولتلافي ذلك، اكتب مهامًا -مثل قصة المستخدم user story- ، وأشرك الفريق في إنشاء محتوى موجه لأهداف منفردة صغيرة، واسمح للصورة الكاملة أن تتطور من مدخلات الفريق. وإن للمصممين أغلب المدخلات في المزايا التقنية الضرورية للمشروع "Backlog#Product_backlog)"، وكذلك التحليل والتطوير والاختبار، ويكون الوقت مناسبًا لمساهمة المصممين حين يبدأ مطوِّر في العمل على التفاصيل، ويمكن استخدام أدوات إدارة مشاريع مثل basecamp ومنصات التصميم مثل UXPin وتطبيق invision لتسهيل عملية التواصل بين المصممين والمطورين. إن دورة التصميم التكراري هذه تشمل التصميم من أجل القصص الفردية، وتخوض كل منظمة عملية فريدة حين تنتقل إلى مخطط عمل مرن لتجربة المستخدم، فكن مستعدًا للتغيير إلى أن يتطور فريقك ومنتجك إلى شيء أكبر مما كنت تتصور في البداية. ترجمة -بتصرف- لمقال How to Create an Agile UX Workflow لصاحبه Stephen Moyers