لماذا تتحدث Maison Code عن هذا

في Maison Code Paris، نعمل كضمير معمari لعملائنا. غالبًا ما نرث حزمًا “حديثة” تم بناؤها دون فهم أساسي للحجم.

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

هلوسة البناء ولعنة العلم

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

لماذا تناقش Maison Code اختبار المستخدم

في Maison Code، لا نقوم فقط بكتابة التعليمات البرمجية. نحن نبني المنتجات. لقد رأينا الشركات الناشئة تضيع 500 ألف دولار في بناء مجموعة ميزات معقدة لا يفهمها أحد. يطلقون. الصراصير. “لماذا لا يستخدمون عامل التصفية المتقدم؟” لأنهم لم يعلموا بوجودها قبل أن نكتب سطرًا واحدًا من التعليمات البرمجية، أو مباشرة بعد النموذج الأولي لـ MVP، فإننا نؤيد اختبار قابلية الاستخدام. نحن نسهل هذه الجلسات بشكل فعال. نحضر “صوت العميل” إلى غرفة الهندسة. من الصعب الجدال مع البيانات. “الرأي العام هو أن اللون الأزرق أفضل.” مقابل “فشل 5 من أصل 5 مستخدمين في العثور على زر الخروج.” البيان الثاني يدفع العمل. نتحدث عن هذا لأن ** ديون UX ** حقيقية مثل الديون التقنية.

النوعي مقابل الكمي: الصورة الكاملة

أنت بحاجة إلى كلا مصدري البيانات لاتخاذ القرارات.

** البيانات الكمية (“ماذا”)**:

الأدوات: Google Analytics، وMixpanel، وAmplitude.
الرؤى: “معدل الارتداد هو 60% على صفحة التسعير.” “انخفض معدل التحويل بنسبة 2% على الهاتف المحمول.”
النقطة العمياء: لا تخبرك بالسبب. هل ارتدوا لأن السعر مرتفع جدًا؟ أو لأن الصفحة لم يتم تحميلها؟ أم لأن الخط كان قبيحاً؟

** البيانات النوعية (“السبب”)**:

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

المنهجية: اختبار الأم

نحن نتبع مبادئ “اختبار الأم” لروب فيتزباتريك. إذا سألت والدتك: “هل أعجبك تطبيقي؟”، فسوف تقول: “نعم، عزيزتي، إنه جميل”. إنها تكذب لحماية مشاعرك. يريد معظم المستخدمين أن يكونوا لطيفين. القاعدة رقم 1: لا تسأل أبدًا عن الآراء (“هل يعجبك؟”). اسأل عن السلوكيات. القاعدة رقم 2: أعطهم مهمة محددة (السيناريو). “تخيل أنك تخطط لرحلة إلى باريس في عطلة نهاية الأسبوع القادمة. حاول حجز فندق بأقل من 200 دولار.” ** القاعدة رقم 3 **: اصمت. لا ترشدهم. “انقر هناك.” “لا، ليس هذا.” إذا تعثروا، دعهم يناضلون قليلاً. النضال هو البيانات. إذا سألوا “ماذا يفعل هذا الزر؟”، اعكسه مرة أخرى: “ماذا تعتقد أنه يفعل؟“

الاختبار الخاضع للإشراف مقابل الاختبار غير الخاضع للإشراف

هناك طريقتان رئيسيتان لتشغيل هذا.

1. الاختبار الخاضع للإشراف (التكبير/الحضور الشخصي)

أنت على اتصال مع المستخدم.

البروتوكول: “فكر بصوت عالٍ”. اطلب من المستخدم أن يروي أفكاره. “أنا أبحث عن السعر… لا أستطيع العثور عليه… أقوم بالنقر فوق هذه القائمة…”
الإيجابيات: رؤى عميقة. يمكنك أن تسأل “لماذا ترددت هناك؟”. يمكنك محور الاختبار إذا وجدوا خطأً جديدًا. بناء التعاطف.
السلبيات: باهظة الثمن. مضيعة للوقت (ساعة واحدة لكل مستخدم + جدولة). خطر تحيز المستخدم (“تأثير هوثورن” - يتصرفون بشكل أكثر ذكاءً لأنهم مراقبون).

2. الاختبار غير الخاضع للإشراف (UserTesting.com، Maze، Lookback)

تقوم بتحميل نموذج أولي (رابط Figma) أو عنوان URL مباشر. تكتب سيناريو المهام. يقوم المستخدمون بتسجيل شاشتهم وصوتهم أثناء القيام بذلك بمفردهم في غرفة نومهم.

الإيجابيات: سريع. يمكنك بدء الاختبار في الساعة 5 مساءً والحصول على 10 مقاطع فيديو بحلول الساعة 9 صباحًا. رخيصة (إيه).
السلبيات: لا يمكن المتابعة. يمكن للمستخدمين الاتصال به هاتفيًا (فقط انقر سريعًا للحصول على الأموال).
الاستراتيجية: استخدم الإشراف من أجل “الاكتشاف” (ما الذي يجب أن نبنيه؟). استخدم Unmoderated لـ “التحقق من الصحة” (هل قمنا ببنائه بشكل صحيح؟).

أدوات التجارة

نماذج فيجما: أرخص رمز هو الرمز الذي لا تكتبه. قم ببناء “دمية قابلة للنقر” في Figma. يبدو حقيقيا ولكن ليس له خلفية. اختبر هذا. إذا فشل المستخدمون، يمكنك تغيير الرسم. يستغرق 10 دقائق. إذا قمت باختبار إصدار الكود، فسيستغرق تغييره يومين. ** تفشل بسرعة. **
منصات التوظيف: UserTesting.com: معيار المؤسسة. الوصول باهظ الثمن ولكن فوري إلى خصائص سكانية محددة (“طبيب أسنان في أوهايو يربح 100 ألف دولار”). UsabilityHub / Ballpark: اختبارات أرخص وأقصر. استخدم قائمتك الخاصة: أرسل رسالتك الإخبارية بالبريد الإلكتروني. تقديم بطاقة هدايا أمازون بقيمة 50 دولارًا. هؤلاء هم المستخدمون الحقيقيون لديك.
الاختبار السلبي (Hotjar / Microsoft Clarity): قم بتثبيت البرنامج النصي على موقعك المباشر. يسجل جلسات فيديو للزوار الحقيقيين (مجهول الهوية). شاهد 10 جلسات أثناء تناول وجبة الغداء. خرائط التمثيل اللوني: تعرض المكان الذي ينقر فيه الأشخاص. نقرات الغضب: النقر السريع على أحد العناصر. تشير إلى “يبدو هذا الزر ولكنه ليس كذلك.” -> أصلح هذه المشكلة على الفور.

قاعدة المستخدمين الخمسة (مجموعة Nielsen Norman)

أثبت جاكوب نيلسن رياضيًا أن الاختبار مع 5 مستخدمين وجد 85% من مشاكل سهولة الاستخدام. لا تحتاج إلى 50 مستخدمًا.

يعثر المستخدم 1 على أدوات الحظر المهمة (تسجيل الدخول معطل).
يؤكدها المستخدم 2.
يؤكدها المستخدم 3.
يضيف المستخدم 6 القليل جدًا من المعلومات الجديدة (تناقص المرتجعات). الاستراتيجية: قم بإجراء اختبارات صغيرة بشكل متكرر. اختبار مع 5 مستخدمين. إصلاح الخلل. اختبار مع 5 مستخدمين مرة أخرى. حلقة تكرارية >> دراسة ضخمة.

وجهة نظر المتشككين

“ليس لدينا وقت. لدينا موعد نهائي.” نقطة مضادة: إذا أطلقت منتجًا محيرًا، فسوف تقضي شهورًا في إصلاحه والتعامل مع تذاكر الدعم. “كيف يمكنني إعادة تعيين كلمة المرور الخاصة بي؟” -> إذا طرح 100 شخص هذا السؤال، فهذا يعني أن لديك خطأ في تجربة المستخدم. اختبار المستخدم لمدة ساعة واحدة يمكن أن يوفر شهرًا واحدًا من إعادة العمل الهندسي. يعمل اختبار المستخدم على تسريع المنتج الصالح، حتى لو أدى إلى تأخير الإصدار الأول لمدة يوم واحد. إنها استراتيجية للحد من المخاطر.

الأسئلة الشائعة

س: من الذي يجب علينا توظيفه؟ ج: الأشخاص الذين يتناسبون مع شخصيتك. إذا كنت تبيع SaaS لأطباء الأسنان، فلا تختبره مع المراهقين. نموذجهم العقلي مختلف. إذا كنت تبيع معجون أسنان (مستهلك)، اختبر مع أي شخص.

س: ما هو اختبار A/B مقابل اختبار المستخدم؟ اختبار A/B (اختبار الانقسام) كمي. “أي لون زر يتم تحويله بشكل أفضل؟ أحمر أم أخضر؟” اختبار المستخدم ** نوعي **. “لماذا نقروا على اللون الأحمر؟” استخدم اختبار المستخدم لإنشاء الفرضيات. استخدم اختبار A/B للتحقق من صحتها على نطاق واسع.

الخلاصة

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

المستخدمين في حيرة؟

إذا كان صندوق بريد الدعم الخاص بك مليئًا بـ “كيف أفعل X؟”، أو كان معدل التغيير لديك مرتفعًا، فهذا يعني أن تجربة المستخدم الخاصة بك معطلة. Maison Code تجري أبحاثًا احترافية حول تجربة المستخدم واختبارات سهولة الاستخدام. نحن نوظف المستخدمين المناسبين، ونكتب النصوص، ونسهل الجلسات، ونقدم “مقاطع مميزة” قابلة للتنفيذ للحظات التي يتعثر فيها المستخدمون.

قم بتوظيف مهندسينا.