Agile UX: كيفية دمج UX وتصميم المنتج في Agile

غالبًا ما يتم تعريف DevOps على أنه العمليات والعمليات والمنهجيات والأدوات والثقافة المحيطة بتطوير برامج وأنظمة الشركة.

لكن الهندسة لا تعمل في فراغ. تأتي المخططات والأفكار والتصميمات والمفاهيم من متخصصي تصميم المنتجات الذين يقررون التخطيطات والتدفقات والتفاعل. هؤلاء هم أفراد وفرق من غير المهندسين يشاركون أهداف DevOps والنتائج المرجوة.

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

يرغب المطورون والمهندسون المعماريون في المشاركة عندما يقوم المنتج والفرق الإبداعية بتصميم البرنامج أو النظام. ولكن أين هذا في التعريف الحالي لـ DevOps؟ تريد فرق المنتج وتجربة المستخدم والفرق الإبداعية الاستمرار في المشاركة أثناء العمليات الهندسية ، ومع ذلك فإن العديد من المنهجيات تستبعدهم. هذه صوامع قديمة نحتاج إلى تفكيكها.

يرى عملاؤك فقط تجربة المستخدم الخاصة بك (UX). إنهم لا يعرفون عدد المطورين لديك أو ما إذا كنت من النوع Agile أو Lean. ليس لديهم أي فكرة عن أدوات DevOps التي يتم استخدامها. تجربة المستخدم الخاصة بشركتك هي المنتج ، ويمكنها أن تصنعك أو تحطمك. يتساءلون من بنى قطعة الخردة هذه. مع وجود الكثير من المنافسة وسعادة الأشخاص لإلغاء تثبيت تطبيق أو مغادرة موقع ويب ، هل ستحصل على فرصة ثانية مع العميل الذي تخلى عنك؟

يتدرب Agile نادرًا على UX أو العمل مع متخصصي UX

غالبًا ما تجد العديد من الفرق الهندسية تجربة مستخدم منعزلة ويصعب التعاون معها. لا يبدو أن تجربة المستخدم (UX) لا تتسم باللين والعديد من نكهات Agile تستبعد تفاصيل حول كيفية العمل مع UX. تشير بعض مناهج Agile تحديدًا إلى أن وصف مالك المنتج لميزة ما هو "جيد بما فيه الكفاية".

يقع SAFe Agile في خطأ تقرير أن أفضل طريقة لحل صوامع UX هي استبعادها تمامًا. "تمكّن SAFe فرق Agile" من القيام بـ "Lean UX" الخاصة بهم. نظرًا لأن المزيد من الشركات تدرك قيمة دمج متخصصي تجربة المستخدم وعملية تجربة المستخدم الكاملة ، فإن SAFe تسير في الاتجاه الخاطئ.

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

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

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

أهمية دمج خبراء UX المتخصصين في Agile

في أواخر عام 2018 ، نشرت شركة الاستشارات الإدارية McKinsey & Company تقريرًا بعنوان "القيمة التجارية للتصميم" عن بحث أجروه مع أكثر من 300 شركة.

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

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

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

جمعت McKinsey البيانات الكمية ووجدت أن الشركات التي تبنت تصميم UX حققت إيرادات أكثر بنسبة 32٪ وعائدات أكبر بنسبة 56٪ للمساهمين في فترة 5 سنوات. لا يكفي إعلان شركتك على أنها "تركز على المستخدم". يجب أن تسير في الطريق من خلال دمج ممارسي تجربة المستخدم والعمليات من التخطيط والمحفظة وصولاً إلى التطوير وضمان الجودة.

عمليات تطوير البرمجيات مع تجربة المستخدم وبدونها

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

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

يتعين على الهندسة بعد ذلك العودة إلى البداية ، ومعرفة ما يريده هذا الشخص الآن ، وبناء ، واختبار ، وتخطي أصابعه في أن هذا هو السحر.

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

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

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

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

UX لديها عملية رسمية

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

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

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

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

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

سيكون أفضل استخدام للشخصيات هو تضمينهم في كل مكان. يتخيل المنتج الميزات بناءً على الشخصيات (والبيانات الجيدة). تصميمات UX على أساس الشخصيات. اختبارات ضمان الجودة مع تخيل أنهم هؤلاء الأشخاص. يمكن أن يضيف التسويق تفاصيلهم الديموغرافية وتفاصيل أخرى ، لكن يجب عليهم أيضًا التفكير في كيفية تعامل صوت العلامة التجارية ووسائل التواصل الاجتماعي والإعلان مع الشخصيات.

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

هندسة المعلومات لها علاقة بالتسلسلات الهرمية والهيكل والتصنيفات. قد يكون هذا هو التنقل في الموقع ، أو قد يكون كيفية تصنيف المنتجات في قاعدة بيانات التجارة الإلكترونية. نريد التأكد من أن العملاء سيجدون بسهولة المنتجات حسب الفئات والبيانات الوصفية والفلاتر.

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

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

تم إجراء النماذج الأولية لتجربة المستخدم من أجل:

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

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

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

هناك 5 أسباب رئيسية لإجراء UX للاختبارات قبل تسليمها إلى الهندسة:

1. أفضل استخدام لوقت وموارد الهندسة. إذا كنت تريد أن يرى المشاركون في الاختبار منتجًا نهائيًا تم إنشاؤه بواسطة المهندسين ، فيجب عليك إنشاءه واختباره بحثًا عن الأخطاء. إذا أدى اختبار UX إلى إحداث التغييرات اللازمة في الضوء ، فسيتعين على المطورين إعادة البناء وسيتعين على QA إعادة الاختبار. إذا أظهر اختبار UX فشلًا أكبر للمفهوم ، فقد يعني ذلك أن وقت الهندسة قد ضاع تمامًا لأن هذا ليس رمزًا سينتهي به الأمر في أي مكان. سيتعين إعادة التفكير في المفهوم وإعادة تصميمه واختباره حديثًا.
2. كرر وراء الكواليس. عندما تقوم الشركات ببنائها ، فقط قم بشحنها ، وكررها ، وقم بالبناء والشحن مرة أخرى ، فهذا يعني أن العملاء يشاهدون مجموعة متنوعة من الإصدارات. إنهم يرون العمل قيد التقدم ويشاهدون صنع النقانق. غالبًا ما تكون هذه تجربة محبطة ومربكة تتطلب من العملاء الاستمرار في إعادة تعلم نظام يتطور. من الأفضل التكرار وراء الكواليس في عملية UX وأن تكون واضحًا مع المختبرين أنه نموذج أولي أو نسخة توضيحية.
3. المراقبة والقياس. إذا تم إصدار مفهوم جديد بشكل مباشر ، فلن يكون لدى باحثو تجربة المستخدم طريقة جيدة لمشاهدة الأشخاص يستخدمونه ، وطرح الأسئلة عليهم ، والحصول على نوع التعليقات التي تحتاجها تجربة المستخدم لتحديد ما إذا كان هناك شيء جاهز أو يحتاج إلى تكرار آخر. تريد تجربة المستخدم دائمًا معرفة السبب والنوعية وليس فقط ماذا أو كم. كيف ينفق المستخدمون ، ويحولون ، ويتفاعلون ، وما إلى ذلك؟ يؤدي تجنب اختبار UX المناسب إلى صعوبة تشخيص المشكلات أو نقاط ألم العميل وحلها.
4. اختبار UX يؤتي ثماره. اختبار UX ليس تكلفة ضخمة. تريد بعض أدوات الاختبار التابعة لجهات خارجية أقل من 100 دولار لكل مشارك في الاختبار ، وبعضها يتطلب التزامًا سنويًا بحد أدنى لآلاف الدولارات. هذه ليست نفقات ضخمة بالنظر إلى الميزانية الإجمالية للشركة لعملية تطوير البرمجيات وأهمية الاختبار المبكر لملاحظات. تكلف جولات اختبار المستخدم دائمًا أقل وتتحرك بشكل أسرع من جعل المبرمجين يبنون شيئًا قد نضطر إلى التراجع عنه أو بنائه مرة أخرى.
5. اختبار المستخدم يحل الحجج. إذا كانت شركتك لا تسمح لمتخصصي تجربة المستخدم باتخاذ القرار النهائي بشأن كيفية تصميم المنتج ، فقد تجد أن تجربة المستخدم تتعارض مع المنتج أو الهندسة أو أحد أصحاب المصلحة عندما تكون هناك أفكار مختلفة لما يجب بناؤه وإصداره إلى عميل. أو ماذا لو كان لدى UX فكرتان قويتان ويتساءلون أيهما يتصل بشكل أفضل بالعملاء؟ الحل هنا هو اختبار المستخدم.

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

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

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

ماذا يحدث عندما يتم التحايل على تجربة المستخدم أو الحد منها؟

أعلن Skype مؤخرًا أن إعادة تصميمه لعام 2017 ، والتي تهدف إلى جعله أكثر شبهاً بـ Snapchat ، كانت فاشلة. لا يريد المستخدمون الميزات الجديدة أو يحتاجونها أو يحبونها. كانت ردة الفعل كبيرة بما يكفي لدرجة أن سكايب أصدرت إعلانًا في 2018 بأنهم سيعيدون تصميم سكايب مرة أخرى. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

كان خبراء UX يعرفون في العديد من خطوات عمليتهم أن هذه الميزات من المحتمل أن تكون غير مرغوب فيها أو تفشل. كان من الممكن أن تكشف الأبحاث التي أجريت مع المستخدمين المستهدفين بسرعة أنهم لا يريدون أن يصبح سكايب Snapchat. كان من الممكن أن يؤدي قتل المشروع أو التمحور في هذه المرحلة المبكرة إلى توفير ملايين الدولارات على Skype بالإضافة إلى الصحافة السيئة وعزل العملاء.

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

عملية Agile UX

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

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

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

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

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

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

ممارس UX جزء من فريق Agile

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

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

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

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

قياس النتائج

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

• شكاوى أقل
• تقييمات أفضل للتطبيق
• أعلى تقييمات التطبيق
• تذاكر دعم أقل
• مكالمات مركز اتصال أقل
• دلالات أكثر إيجابية من المشاركات الاجتماعية
• المزيد من عمليات تثبيت التطبيق ، عدد أقل من عمليات إلغاء التثبيت
• AOV (متوسط ​​قيمة الأمر) زيادة
• ارتفاع معدل التحويل

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

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

Agile UX هو استثمار يدفع أكثر من نفسه

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

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

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