لحظة الصمت التي تسبق الكلام
في الغرفة صمت. مستخدم جديد يبحث منذ دقيقة عن زر "احفظ وأكمل"، والشاشة نفسها اعتمدها الفريق قبل أسبوع كامل. لم يكن أحد في الاجتماع يشك في أنها جاهزة. الشاشة بدت منطقية في الملفات، ومتسقة مع النموذج الذي رسمناه، ولم تُثر اعتراضاً في المراجعات الداخلية. ثم أُعطيت لشخص لم يشارك في تصميمها، ولم يقرأ المواصفات، ولم يعرف ما الذي نقصده. في خمس دقائق عرف ما لم تكشفه أسابيع من النقاش.
هذه ليست قصة عن مستخدم مرتبك. هي قصة عن الفارق بين ما نعرفه نحن عن منتجنا وما يعرفه من يدخله لأول مرة.
لماذا تعمي المراجعة الداخلية أصحابها
من يبني الشاشة يعرف أين يقع الزر، لأنه هو من وضعه هناك. عقله يملأ الفراغ تلقائياً. حين ينظر إلى الشاشة يرى الترتيب الذي تخيله وليس الترتيب الذي تُظهره الصفحة فعلاً. هذا الانحياز لا يعيبه، إنه جزء من طريقة عمل الدماغ، لكنه يجعل المراجعة الذاتية أداة ضعيفة لاكتشاف مشاكل الواجهة.
المراجعة الداخلية تقيس شيئاً آخر: هل تبدو الشاشة متسقة مع القرار؟ هل تطابق المواصفة؟ هذه أسئلة مشروعة، لكنها لا تسأل: هل يستطيع شخص لا يعرف شيئاً أن يكمل المهمة دون أن يتوقف؟
الاختبار الذي يكشف في دقائق
الاختبار البسيط هو أن تطلب من شخص لم يعمل على المنتج أن يكمل مهمة محددة، ثم تصمت. لا تشرح، لا تشير، لا تساعد. تراقب فقط. عندما يتوقف لأكثر من بضع ثوانٍ، فهذه هي المعلومة التي تحتاجها. التوقف نفسه هو التشخيص.
الخطوات عملية:
- اختر مهمة واحدة واضحة، مثل حفظ تعديل على سجل موجود.
- اختر شخصاً من خارج الفريق، ويفضل أن يكون ممن يستخدمون أدوات مشابهة يومياً.
- اطلب منه أن يتكلم بصوت عالٍ أثناء التنفيذ، وأن يقول ما يظنه قبل أن يضغط.
- سجّل النقاط التي يتردد فيها، لا النقاط التي ينجح فيها.
الجملة التي يقولها المختبَر في لحظة التردد غالباً ما تكون أدق من أي تقرير. "أظن أن هذا يحفظ؟" تعني أن التسمية لم تكن واضحة. "أين ذهب الزر؟" تعني أن الزر في مكان لا يتوقع المستخدم أن يجده فيه.
ما الذي يحدث بعد الكشف
الخطأ الشائع بعد اكتشاف مشكلة من هذا النوع هو الإسراع في إصلاحها بتغيير الزر إلى مكان آخر أو تغيير لونه. هذا غالباً يعالج العرض ولا يعالج السبب. السؤال الأصح هو: لماذا تبدو الخطوة التالية غير واضحة؟ هل لأن الشاشة تحمل معلومات كثيرة؟ هل لأن الأفعال متشابهة في الصياغة؟ هل لأن المستخدم لا يعرف ما الذي تغيّر منذ خطوته الأخيرة؟
الإجابة عن هذه الأسئلة تقود إلى تعديل أعمق في البنية، وليس مجرد تجميل سطحي.
الاختبار قبل التوسع
الميزة التي تُختبر مع خمسة أشخاص قبل إطلاقها توفر على الفريق أسابيع من الإصلاح بعد الإطلاق. التكلفة الحقيقية لأي خطأ في الواجهة ليست لحظة الإصلاح، بل المستخدمون الذين غادروا دون أن يقولوا شيئاً. أغلب المشاكل في الواجهات لا تصل إلى مراجعة المنتج لأن المستخدم الذي واجهها لم يشتكِ، ببساطة ترك التطبيق.
لهذا يصبح الاختبار المبكر ضرورة وليس رفاهية. كلما كانت الشاشة أقرب إلى الاستخدام الحقيقي، كانت التعديلات أرخص وأسرع.
في النهاية
الصمت في الغرفة لم يكن فشلاً، بل كان معلومة. كان الفريق قد وصل إلى نقطة يصعب فيها أن يرى ما بناه بعيون غريبة. الحل ليس أن نصبح أقل ثقة بعملنا، بل أن نضع عملنا أمام من لا يعرفه قبل أن نعتبره منتهياً. الشاشة التي تحتاج إلى شرح لتُستخدم لم تنتهِ بعد، مهما بدت مكتملة في الملفات.
