لاختبار الاستخدام سمعة غير مستحقة بأنه مكلف وبطيء. عندما يسمع الناس "بحث المستخدم" يتخيلون مرآة أحادية الاتجاه ومشرف بحافظة ملفات وجدول زمني لمدة أسبوعين. هذا الإصدار من الاختبار موجود وله استخدامات — لكنه ليس الإصدار الذي تحتاجه معظم فريق المنتج في معظم الأوقات.
الإصدار الذي تحتاجه معظم الفريق هو أبسط: خمسة مستخدمين ومجموعة Figma الأولية أو بيئة التجميع واستدعاء فيديو و45 دقيقة لكل جلسة. عند التنفيذ بشكل جيد يكشف هذا عن معظم مشاكل الاستخدام الخطيرة قبل شحنها. عند التنفيذ بشكل متسق — حتى مرة واحدة لكل sprint — فإنه ينتج عن تحسن مركب في جودة المنتج لا يمكن لأي مقدار من تحليلات ما بعد الإطلاق أن ينسخه.
إليك كيفية تشغيله من الصفر.
خمسة مشاركين هو الرقم الصحيح لمعظم اختبارات الاستخدام. كشف بحث Jakob Nielsen أن خمسة مستخدمين يكتشفون حوالي 85٪ من مشاكل الاستخدام مع تناقص العائدات بعد ذلك. تشغيل ثلاث جلسات من خمسة مستخدمين في نقاط مختلفة في عملية التصميم أكثر قيمة من جلسة واحدة بخمسة عشر.
معايير التجنيد أكثر أهمية من العدد. اختبار استخدام مع خمسة أشخاص يطابقون بشكل وثيق شخصيتك المستهدفة سيكشف عن مشاكل حقيقية. اختبار مع خمسة عشر شخصاً لا يطابقون سينتج عنه ضوضاء. حدد معيارين أو ثلاثة معايير فحص — الدور والسياق والراحة التقنية — والتزم بها.
أسرع طريق تجنيد لمعظم الفريق هو إرسال بريد إلكتروني للمستخدمين الحاليين الذين أعطوا إذن الاتصال. عرض حافز متواضع — بطاقة هدية بقيمة 20 جنيهاً كافية لجلسة 45 دقيقة. استهدف جدول الجلسات في نفس الأسبوع؛ كلما طالت الفجوة بين التجنيد والاختبار زادت نسبة عدم الظهور.
الخطأ الأكثر شيوعاً في كتابة البرنامج النصي هو كتابة المهام كتعليمات: "انقر على الإعدادات ثم انتقل إلى الإخطارات وقم بتغيير التفضيل الخاص بك إلى ..." يخبر المستخدم بما يفعله مما يعني أنك تختبر ما إذا كانوا يستطيعون اتباع الاتجاهات وليس ما إذا كانت الواجهة حدسية.
اكتب المهام كسيناريوهات بدلاً من ذلك: "تخيل أنك تتلقى إخطارات كثيرة جداً وتريد فقط استقبال تنبيهات عندما يذكرك أحد مباشرة. أرني ما ستفعله." هذا يعطي المستخدم هدف واقعي ويسمح لك بملاحظة كيفية تنقلهم فعلياً — بما في ذلك حيث يشعرون بالارتباك.
الجزء الأصعب من إدارة اختبار الاستخدام هو مقاومة الرغبة في المساعدة. عندما يشعر المستخدم بالارتباك تقول كل غريزة للقفز و عرض له أين ينقر. لكن الارتباك هو البيانات. المستخدم الذي يكافح يخبرك أن هناك خطأ ما في الواجهة — واللحظة التي تتدخل فيها تفقد الإشارة.
اطلب من المستخدمين التفكير بصوت مرتفع طوال الجلسة: "بينما تذهب فقط أخبرني ما تنظر إليه وما تفكر فيه." هذا ينتج عنه تدفق مستمر من البيانات حول نموذجهم العقلي. لاحظ ليس فقط الأخطاء بل التردد — المستخدم الذي يتوقف لمدة ثلاث ثوان قبل النقر على الزر الصحيح كشف عن مشكلة تصميم حتى لو نجحوا في النهاية.
خطوة الاصطناعية هي حيث يتم إنشاء معظم القيمة — وحيث تقطع معظم الفريق الزوايا. الملاحظات الخام من خمس جلسات ليست نتائج. تصبح نتائج عندما تشرح كفريق وتجميع الملاحظات حسب الموضوع وتعين تصنيفات الخطورة.
قم بـ debrief في نفس اليوم من الجلسات أثناء كون الملاحظات طازجة. تجميع المشاكل إلى ثلاثة دلاء: حرج (لم يستطع المستخدمون إكمال المهمة)، معتدل (أكمل المستخدمون المهمة لكن بصعوبة كبيرة أو خطأ)، وطفيف (احتكاك لم يمنع الإكمال). المشاكل الحرجة تحتاج إلى إصلاح قبل الإطلاق. يجب إعطاء الأولوية للمشاكل المعتدلة في الـ sprint التالي. تذهب المشاكل الطفيفة إلى نماذج التصميم.
اكتب النتائج في صفحة واحدة: أكثر ثلاث مشاكل حرجة مع أدلة من مشاركين اثنين على الأقل وكل ذلك ولكل مشكلة تغيير تصميم مقترح. أي شيء يحتاج إلى مزيد من المساحة من هذا ينتمي إلى وثيقة منفصلة.