لماذا يبدو تطبيقك المبني بالذكاء الاصطناعي بطيئًا (حتى لو لم يكن كذلك): وهم وقت الانتظار

تطبيقك يجلب البيانات في 1.2 ثانية. الإنسان يمكنه إدراك 100 مللي ثانية فقط. أنت أسرع بـ12 مرة من إدراك الإنسان، ومع ذلك لا يزال الأمر يبدو بطيئًا. لماذا؟

زمن الانتظار المُدرَك — أي مدى بطء التطبيق في نظر من يستخدمه — لا علاقة له تقريبًا بزمن التحميل الفعلي. ما يهم هو هل يفهم المستخدم ما يحدث أثناء انتظاره. البطء والسرعة أكاذيب؛ الاستجابة هي الحقيقة الوحيدة.

لماذا يبدو تطبيقي بطيئًا حتى عندما يكون سريعًا؟

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

1. غياب الاستجابة أثناء الانتظار.

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

هذا هو سبب شعوره بالبطء رغم أن 1.2 ثانية زمن معقول لعملية حسابية حقيقية. قلق المستخدم هو ما يملأ ذلك الصمت.

2. الشاشات الفارغة.

تُحمَّل صفحة. يظهر العنوان الرئيسي. ثم لا شيء لمدة 800 مللي ثانية بينما يجلب التطبيق القائمة الموجودة أسفله. تبدو الصفحة معطّلة — تخطيط ناقص، لا عنصر نائب، مجرد… تحميل. انتظار من 800 مللي ثانية يتحول إلى توقف مُدرَك مدته 5 ثوانٍ، لأن عين المستخدم ترى النقص وكأنه فشل.

3. غياب الإحساس بالتقدم.

تبدأ عملية طويلة. تظهر عبارة “جارٍ التحميل…”. ثم ماذا؟ هل هي عند 10% أم 90%؟ هل لدى المستخدم وقت لاحتساء قهوة، أم أنها ستنتهي خلال ثلاث ثوانٍ؟ غياب التقدم يولّد القلق. سريع + غامض = يبدو أبطأ من بطيء + شفّاف.

كيف تُصلح تطبيقًا يبدو بطيئًا؟

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

الحل الأول — أظهِر شيئًا فورًا

ضع حالة تحميل قبل أن تبدأ عملية الجلب. شاشة هيكلية، أو مؤشر دوّار، أو رسالة “جارٍ التفكير…”. أي شيء يقول “استلمت نقرتك، وأنا أعمل عليها”.

مثال: يُرسَل نموذج حجز. فورًا، يتغير نص الزر إلى “جارٍ التحقق من التوفر…” مع مؤشر دوّار صغير. عندها فقط يبدأ الجلب الفعلي. يرى المستخدم استجابة لفعله فورًا، رغم أن العمل الفعلي يستغرق 1.2 ثانية. هذه الاستجابة الفورية هي ما يجعل الانتظار يبدو قصيرًا.

اطلب من الأداة: بعد أن ينقر المستخدم على الزر الرئيسي، غيّر نص الزر وأضِف حالة تحميل قبل إرسال الطلب. إنها تعليمة واحدة فقط.

اختبار: على هاتفك، فعّل الإجراء. يجب أن تظهر الاستجابة في أقل من 100 مللي ثانية. إن رأيت 500 مللي ثانية من الصمت قبل ظهور حالة التحميل، فسيلوم المستخدم التطبيق.

الحل الثاني — اِملأ الفراغ

بدلًا من شاشة بيضاء مع عبارة “جارٍ التحميل…” في الزاوية، أظهِر شكل ما هو قادم.

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

اطلب من الأداة: أضِف نسخة نائبة (هيكلية) من القائمة أو الجدول قبل جلب البيانات الحقيقية. عند وصول البيانات، استبدل الهيكل النائب بالمحتوى الفعلي. نعم، هذا جزء إضافي يجب بناؤه. يستحق العناء لأنه يقلّص زمن الانتظار المُدرَك إلى النصف.

اختبار: حمّل الصفحة على اتصال بطيء (جوال، بمعدل مخفَّض إلى 4G). هل ترى صفحة فارغة أم شكلًا؟ الشكل هو الفائز دائمًا.

الحل الثالث — أظهِر التقدم

للعمليات التي تتجاوز ثلاث ثوانٍ، أظهِر مدى التقدم فيها.

قصة حقيقية: نموذج يُصدّر 500 صف من البيانات إلى جدول بيانات. يستغرق ذلك 4 ثوانٍ. بدون مؤشر تقدم: “جارٍ التصدير…” (يبدو وكأنه 15 ثانية، فيلغي المستخدم العملية). مع مؤشر تقدم: “جارٍ تصدير الصف 127 من 500” (يتحدّث كل 200 مللي ثانية، ويبدو وكأنه ثانيتان رغم أن العمل الفعلي لم يتغير).

التنبيه الصادق: إن كنت لا تعرف حقًا كم من الوقت ستستغرق العملية، فلا تُزيّف شريط التقدم. شريط مزيف يتوقف عند 67% يخون الثقة أكثر من رسالة صادقة تقول “جارٍ العمل”. التقدم الحقيقي (إن استطعت حسابه) يتفوّق دائمًا على التقدم المزيف.

اطلب من الأداة: لأي عملية تتجاوز ثانيتين، أرسِل تحديثات تقدم. لرفع ملف، اعرض كم ميغابايت تم إرساله. لجلب قائمة، اعرض “تم تحميل 50 عنصرًا، جارٍ جلب المزيد…”. حتى لو لم تعرف الإجمالي، معرفة أن شيئًا ما يحدث تغيّر الإدراك.

اختبار: أبطئ شبكتك إلى 3G وراقب العملية. هل تبدو متوقفة أم تبدو وكأنها تتقدم؟

---

كيف تختبر إن كان تطبيقك يبدو بطيئًا؟

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

إن قال إنه بطيء، تحقق من ثلاثة أمور:

1. هل رأى استجابة خلال 100 مللي ثانية؟ (تغيّر نص، مؤشر دوّار، تغيّر حالة)
2. هل رأى شكل الصفحة أثناء الانتظار؟ (هيكل نائب، عنصر مؤقت، أي شيء)
3. هل عرف مدى تقدم العملية؟ (للانتظارات التي تتجاوز 3 ثوانٍ)

إن كانت الإجابة “لا” على أي من هذه الأسئلة، أصلِح تلك النقطة أولًا.

---

السرعة ليست رقمًا. استدعاء API يستغرق 1.2 ثانية بلا أي استجابة يبدو أبطأ من عملية تستغرق 3 ثوانٍ لكنك ترى فيها تقدمًا كل نصف ثانية. الفرق ليس في التطبيق — بل في الحوار القائم بين التطبيق والشخص الذي يستخدمه.

أصلِح الاستجابة. الناس تتوقف عن لوم البطء عندما تفهم ما يحدث.