اختبار قابلية الاستخدام بميزانية صفر تقريباً: خمسة أشخاص وجوال وساعة

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

كم شخص تحتاج؟

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

من تختار؟

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

اكتب مهاماً لا تعليمات

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

إدارة الجلسة: أصعب شيء إنك تسكت

• اشرح في البداية: «نحن نختبر التطبيق، مو نختبرك. ما فيه إجابة غلط».
• اطلب منه يفكر بصوت عالٍ: وش يدور عليه، ووش يتوقع يصير.
• لا تساعده لما يعلق. عد لعشرة في بالك. لحظة التعثر هي المعلومة.
• لو سأل «وش أسوي؟»، رد بسؤال: «وش تتوقع؟»
• سجّل الشاشة والصوت بإذنه، أو خلّ شخصاً ثانياً يكتب الملاحظات.

وش تسجّل بالضبط؟

• هل أكمل المهمة؟ وبدون مساعدة أو بمساعدة؟
• وين تردد أو رجع للخلف أو ضغط شيئاً غلط؟
• الكلمات اللي استخدمها لوصف الأشياء — غالباً أفضل من كلماتك.
• التعليقات العفوية مثل «ليش هذا هنا؟» أو «كنت أحسبه…».

وبعد ما تخلص الجلسات يجي الجزء اللي يحدد هل الاختبار كان مفيداً فعلاً أو مجرد تجربة لطيفة، لأن الملاحظات اللي ما تتحول لتعديلات تُنسى خلال أسبوع.

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

اختبر قبل البرمجة أيضاً

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

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

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

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

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

اجعله عادة، مو حدثاً

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

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