اختبار تطبيقك المبني بالذكاء الاصطناعي كما لو كنت غريبًا عنه (قبل أن يجد مستخدموك الأخطاء)

لماذا تظهر الأخطاء فقط عندما يستخدم شخص آخر تطبيقك؟

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

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

يجرّبه زميلك في العمل: يختار تاريخًا، فيلاحظ أن المنطقة الزمنية خاطئة. ارتباك. يغادر الصفحة.

تجرّبه والدتك: تختار تاريخًا في الماضي عن طريق الخطأ، فيتعطل التطبيق.

صديقك على الهاتف المحمول: أداة اختيار التاريخ لا تعمل (لا يستطيع النقر على الحقل).

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

كيف تختبر تطبيقًا كما يفعل الغريب؟

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

الطريقة الأولى: اسأل شخصًا حقيقيًا (تستغرق 15 دقيقة)

أرسل رسالة لصديق: “هل يمكنك تجربة هذا بسرعة وتخبرني برأيك؟” أعطه الرابط، ودعه يتجول فيه لمدة 5-10 دقائق، ثم اسأله:

• ماذا كنت تحاول أن تفعل؟
• هل عمل التطبيق كما توقعت؟
• ما الذي أربكك؟
• ما الذي كنت ستغيّره؟

ستحصل على مفاجآت. “لم أستطع إيجاد زر الإرسال” (لأنك أخفيته داخل نافذة منبثقة). “لم أكن أعرف أنه يجب عليّ ملء البريد الإلكتروني” (لأنك لم تضع علامة تشير إلى أنه إلزامي). “لماذا يقول حجزي يوم الثلاثاء بينما اخترت الأربعاء؟” (مشكلة منطقة زمنية لم تلاحظها).

لماذا تنجح هذه الطريقة: الشخص الحقيقي يختبر المسار المتوقّع والمسارات المعطوبة عن غير قصد التي لم تفكر فيها.

لكن انتبه: على الأرجح سيكون لطيفًا معك. قد لا يخبرك أن شيئًا ما سيئ فعلًا لأنه لا يريد جرح مشاعرك. راقب تعابير وجهه أكثر من كلماته.

الطريقة الثانية: اختبر على جهاز لا تستخدمه عادة (تستغرق 5 دقائق)

إذا بنيت التطبيق على سطح المكتب، اختبره على هاتفك. وإذا بنيته على هاتفك، اختبره على جهاز لوحي.

افتح تطبيقك. حاول أن:

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

معظم أدوات البناء بالذكاء الاصطناعي تنتج تخطيطات متجاوبة بشكل جيد، لكنك ستندهش مما يتعطل عند عرض 375 بكسل أو على اتصال بطيء.

لماذا تنجح هذه الطريقة: الهاتف المحمول يغيّر كل شيء في مدى سرعة شعور التطبيق وكيفية تفاعل الناس معه. استدعاء قاعدة بيانات يستغرق ثانيتين أمر مقبول على سطح المكتب. أما على الهاتف عبر شبكة 4G، فيبدو التطبيق معطوبًا.

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

الطريقة الثالثة: اختبار القائمة المرجعية (تستغرق 10 دقائق)

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

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

هذه ليست بديلاً عن المختبِرين الحقيقيين، لكنها أفضل من إطلاق شيء لم يُختبر إطلاقًا.

ما الذي يجب أن تنتبه له أثناء اختبار شخص ما لتطبيقك؟

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

التردد: إذا توقف الشخص قبل النقر على زر، فهذا يعني أن الزر غير واضح. وإذا سأل “هل يُفترض أن أملأ هذا؟”، فهذا يعني أن الحقل غير موسوم بوضوح كافٍ.

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

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

تجربة الهاتف المحمول: إذا استغرقت النقرة ثلاث ثوانٍ لتُسجَّل، سيظن المستخدم أن التطبيق معطوب (على الأرجح ليس معطوبًا — الشبكة بطيئة فقط — لكنه يبدو معطوبًا). وإذا لم يستطع رؤية النص بسبب ضعف التباين، فلن يشتكي؛ سيغادر ببساطة.

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

هل يمكن لأداة البناء بالذكاء الاصطناعي إصلاح الأخطاء التي يجدها الغرباء؟

نعم — بمجرد أن تصف ما رأيته، لا ما تعتقد أنه المشكلة، يمكن لأداة البناء إصلاحه مباشرة. لست مضطرًا لإصلاحه بنفسك:

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

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

اختبار الغريب، في كل مرة

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

ستجد:

• أخطاء لم تكن تعرف بوجودها
• مسارات عمل أصعب مما ظننت
• افتراضات وضعتها لا يشاركك فيها المستخدمون

الجميل في الأمر: هذا الاختبار مجاني، ويستغرق 10 دقائق، ويقلّل عدد رسائل “لماذا لا يعمل هذا؟” إلى النصف.

غيّر المنطقة الزمنية لهاتفك إلى مكان غريب، استخدم تطبيقك، وعُد إليّ إن وجدت شيئًا مثيرًا للاهتمام.