اختبار نقاط الجودة الموضوعية مع خريطة رحلة العميل

مرحبا يا مواطني خابروفسك!

أنا محلل حسب المهنة ، لقد تم تصميم الأنظمة ومتطلبات الكتابة لمدة 10 سنوات. أقترح مناقشة نهج اختبار UX / UI.

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

لماذا لا تتذكر بياناتي واستبدلت بها؟ لماذا تفرض خيارات إضافية - يقلل الولاء؟

أعتقد أنني لست الوحيد الذي أزعج من UX / UI غير المريحة وغير المفهومة. السؤال: كيف يتم علاجها؟



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

عادةً ما يأتي اختبار الجودة على النحو التالي:

• يعمل الفريق بكل قوته لجعل الوظائف في الوقت المحدد ولا أحد يفكر في UX / UI
• يتم فحص UX / UI فقط للتوافق مع التخطيطات
• يتم إجراء اختبار UX / UI حسب الذوق والتقييم الشخصي للمختبر. نعم ، يمكن تبرير ذلك من خلال القواعد العامة (على سبيل المثال ، من كتب Cooper "On Interfaces") ، ولكن في الأنظمة المخصصة وأنظمة B2B ، غالبًا ما تكون هناك حلول غير تافهة. قد يختلف الفريق في الأذواق والأفكار حول الجميلة. ونتيجة لذلك ، يؤدي هذا إلى نزاعات غير بناءة بسبب الاختلافات في الرأي. الأقوى يفوز فيهم.

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

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

لماذا لا تحقق من هذا المبدأ و UX / UI؟

خوارزمية الاختبار:

1) تحديد سياسة الاختبار.

• مجموعة من البرامج النصية للمستخدم للاختبار
• مؤشرات الجودة المختبرة: الراحة ، بيئة العمل ، الفهم ، إلخ.

2) ابحث عن المستجيبين للاختبار

من 3 إلى 5 مستجيبين. يمكن أن يكون المستخدمون النهائيون أو أعضاء فريق آخر. الشيء الرئيسي هو الاستقلال عن فريق التطوير.

3) إجراء دراسة. كرر

الدورة مع كل مستجيب
> أخذ قالب بطاقة المستخدم.
> يتم إعطاء المستجيب مقدمة عن المهمة ونظام / نموذج أولي / تخطيط قيد التشغيل
> خطوات المستجيب وتعليقاته ووقت الخطوة - يتم تسجيل كل هذا في
نهاية النموذج



4) تجميع البيانات.

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

• أعمدة المصفوفة - خطوات البرنامج النصي.
• الخطوط هي مؤشر على عدم الرضا.
• عند التقاطع - نتائج خرائط المستجيبين.
• الخطوات التي استغرقت معظم الوقت أو المشاعر السلبية ، وسوء الفهم - هذه هي آلام جودة النظام.

5) ضع قائمة بالمشكلات الموجودة.

أسميته GrowthPointsList.



يتم تلخيص البيانات في قائمة المشاكل + توقعات المستجيبين لكيفية تصرف النظام. يمكنك تحديد مستوى التأثير على مرور البرنامج النصي:

1. غير قادر على استكمال البرنامج النصي
2. سلبية ولكن مرت النصي
3. كان لدى بعض المستجيبين سلبيات ، لكنهم تمكنوا من تجاوز النص.

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

أعتقد أن عالم التطبيقات يمكن أن يتغير نحو الراحة والبساطة للمستخدمين النهائيين.

قناة Telegram - tlgg.ru/@analyst_way (مسار المحللين)