7 أخطاء شائعة في اختبار تجربة المستخدم ، وكيفية تجنبها

مرجع مفيد للمزالق الشائعة للمبتدئين ومختبري تجربة المستخدم ذوي الخبرة

لا ينبغي أن يبدو اختبار تجربة المستخدم بمثابة اختبار. تصوير بروك كاغل على Unsplash
ليس ما تنظر إليه هو ما يهم. هذا ما تراه - ثورو

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

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

الخطأ الأول: جعل المهمة معقدة جدًا أو غامضة

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

توصي NNg بالتفكير في إنشاء سيناريوهات المهام بدلاً من "الاختبارات". تتكون سيناريوهات المهام من ثلاثة أجزاء رئيسية:

  1. جملة تحدد سياق المهمة.
  2. جملة تصف النشاط الذي يجب على المشارك القيام به.
  3. زوجان من أسئلة المتابعة المستهدفة ، يتم طرحهما بعد الانتهاء من النشاط الأساسي. (اختياري)

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

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

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

الخطأ الثاني: طرح الأسئلة الرائدة

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

  1. اطرح أسئلة لا تزرع إجابة في ذهن المشارك.
  2. اطرح أسئلة تُظهر اهتمامك: لا تحكم أو تصحح أو تنتقد.
  3. دع المشارك يقود اتجاه أسئلتك.

لكن هذه الأسئلة نظرية للغاية. ولهذا السبب قمت بتطوير مجموعة من الأسئلة المباشرة نسبيًا والتي أصبحت الآن جزءًا من مجموعة أدوات المقابلة. الجزء الصعب هو ترجمة هذه إلى عادة (التي لا يوجد اختصار لها لـ 10000 ساعة لـ Gladwell). أسئلتي الثلاثة الأولى هي:

  • "صحيح ، نعم ... ما الذي يجعلك تقول ذلك؟"
  • "نعم ، نعم ... لماذا تعتقد ...؟"
  • "أرى ، هذا منطقي ... ثم ماذا ...؟"

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

الخطأ الثالث: التحدث

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

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

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

الخطأ الرابع: جعل اختبار تجربة المستخدم اختبارًا

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

أسهل طريقة وجدت للتغلب على ذلك هي معالجتها علانية في بداية الجلسة. في كل مقابلة أو جلسة مراقبة أو اختبار عبر الإنترنت ، أبدأ العملية بالقول:

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

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

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

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

الخطأ الخامس: الدفاع عن اختيارات التصميم الخاصة بك

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

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

أفضل طريقة اكتشفتها لتجنب الوقوع في هذا الفخ هي التنفس وتكرار هذا الشعار قبل كل جلسة:

نحن نختبر مسودة أولية تقريبية ، ونتطلع إلى إيجاد طرق لتحسين منتجنا

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

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

قام فريق التصميم بتجميع هذا التصميم معًا [مزيفًا إذا كان عليك ذلك] ، وهم مهتمون بإيجاد مكان النقاط اللاصقة

الخطأ السادس: التطلع إلى التأكيد على أن تصميمك جيد

أي قراء يحبون قصائدك يشكون في حكمهم - وينديل بيري

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

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

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

الخطأ السابع: نسيان إغلاق الحلقة

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

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

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

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

تم نشر هذا المنشور في الأصل على LinkedIn في 2018. مقطع فيديو لهذه المشاركة على WordPress TV