Reframing the Problem في البرمجة والـ Product

لما المشكلة مش في السرعة… المشكلة في الإحساس

Reframing the Problem في البرمجة والـ Product

في عالم البرمجة والـ Product، فيه مهارة ذكية جدًا بتفرق التيم الشاطر عن التيم اللي دايمًا بيطفي حرائق، اسمها
إعادة تعريف المشكلة – Reframing the Problem.

الفكرة ببساطة:
ما تاخدش الشكوى زي ما هي وتبني عليها حلول تقيلة على طول، لكن توقف وتسأل نفسك:

هو المستخدم متضايق من إيه بجد؟
من الزمن؟
ولا من الإحساس بالزمن؟
ولا من إنه مش فاهم إيه اللي بيحصل؟
ولا من إنه حاسس إن السيستم “سايبُه واقف”؟

فرق بسيط في السؤال، بس بيغيّر شكل الحل بالكامل.

---

المشكلة مش دايمًا تقنية… غالبًا نفسية (وده المجال اللي بعشق القراءة فيه)

أكتر رد فعل شائع في التيمات التقنية:

• “السيستم بطيء”

• “نزوّد سيرفرات”

• “نحسّن الكاش”

• “نغيّر الـ Architecture”

وكل ده ممكن يكون صح تقنيًا…
بس أحيانًا مالوش أي تأثير حقيقي على إحساس المستخدم.

المستخدم في الآخر مش بيقيس:

• Response Time

• Throughput

• CPU Usage

المستخدم بيقيس:

• “أنا حاسس إن اللي عملته اشتغل؟”

• “فيه فايدة حصلت؟”

• “أنا فاهم اللي بيحصل ولا لأ؟”

وده اللي بيسموه:
Perceived Performance
الأداء المُدرَك، وده ساعات بيبقى أهم من الأداء الحقيقي.

---

السؤال الصح

بدل ما تسأل:

“إزاي نقلل زمن التنفيذ؟”

جرّب تسأل:

“إزاي نقلل الزمن اللي المستخدم يحس فيه إن مفيش حاجة بتحصل؟”

هنا بقى بتفتح باب حلول UX، Product، وDesign ما كانتش باينة وانت مركز بس في الكود.

---

أمثلة من السوفت وير والـ UX

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

1. Progress Bar

   • بدل ما تسيب المستخدم قدام شاشة فاضية، بتحطله شريط بيزيد مع الوقت.

   • هو فعليًا لسه مستني نفس المدة، بس الإحساس مختلف؛ فيه حركة، فيه توقع، فيه وضوح.

2. Skeleton Screens

   • زي اللي بنشوفه في فيسبوك وLinkedIn وInstagram.

   • بيظهر شكل رمادي مكان الصور أو البوستات، وبعدين البيانات الحقيقية تملأ المكان.

   • النتيجة؟ المستخدم يحس إن الصفحة فتحت فورًا، والباقي مجرد تفاصيل بتكمل.

3. تشغيل الفيديو بجودة منخفضة أولًا

   • على منصات زي YouTube وNetflix، الفيديو بيبدأ بجودة منخفضة وبعدين تتحسن تدريجيًا.

   • المستخدم يحس إن الفيديو بدأ بسرعة، رغم إن التحميل نفسه موزع جوه التجربة.

4. خرائط السواق في تطبيقات الركوب

   • Uber وCareem بيعرضوالك الخريطة والسواق بيتحرك فيها.

   • نفس الوقت اللي بيستغرقه وصول العربية، بس الإحساس بالتحكم والمتابعة بيقلل التوتر.

5. Tips ورسائل أثناء الانتظار

   • تطبيقات زي Dropbox أو Google Drive لما ترفع ملفات كبيرة:

     • بتعرض نصايح استخدام

     • Features بسيطة ماكنتش واخد بالك منها

     • أو جملة لطيفة تحسسك إن اللي بيحصل مقصود مش عطل

   • ده يشغل دماغك بدل ما تركز في الانتظار.

6. لغة ألطف بدل رسائل جافة

   • بدل “جاري التحميل” أو “انتظر…”

   • تلاقي “بنجهز تجربتك” أو “ثانية وإحنا بنضبط الأمور لك”.

   • نفس الفعل، بس الإحساس ألطف وأهدى.

7. برامج تقيلة زي Microsoft Office أو أدوات التحليل

   • لما تفتح ملف ضخم، بدل شاشة مجمدة، تظهر رسالة:
     “جاري استرجاع بياناتك، قد يستغرق هذا بعض الوقت”

   • محدش قلل الوقت فعليًا، لكن وضوح اللي بيحصل بيقلل التوتر.

8. الألعاب في وقت التحميل (Loading)

   • ألعاب كتير زي Assassin’s Creed أو FIFA بتعرض قصة قصيرة أو نصائح لعب أو مشهد صغير.

   • بدل ما تحس إنك برا اللعبة، بتحس إنك جوه التجربة.

9. Background / Async Processing

   • تطبيقات البريد زي Gmail وOutlook: وإنت بتقرأ الرسائل القديمة، هو بيجيب الجديدة في الخلفية.

   • عمرك ما حسيت إنك قاعد مستني الإيميلات تتحدث، رغم إن العمليات بتحصل.

10. أنيميشن عند إضافة منتج للسلة

    • مواقع زي Amazon أو Souq.com: المنتج يطير للعربة والعداد يزيد.

    • الإبهار البسيط ده يغطي على أي تأخير بسيط في حساب الإجمالي أو تحديث البيانات.

11. رحلة البحث عن الرحلات في مواقع الطيران

    • Expedia وSkyscanner: بدل رسالة “جارٍ البحث عن الرحلات”، تلاقي أيقونات تتحرك أو طيارة بتمشي بين المدن.

    • نفس الزمن، بس الإحساس أهدى وأوضح.

12. رسائل خفيفة في تطبيقات الموسيقى

    • Spotify وApple Music: “بنختار أنسب الأغاني لمودك” بدل “جارٍ تحميل الـPlaylist”.

    • إعادة تعريف اللي بيحصل من “تحميل” لـ“اختيار ذكي”.

13. لعبة الديناصور في Google Chrome

    • النت فصل؟ بدل رسالة خطأ بس، اللعبة الصغيرة بتخليك تتسلى.

    • المشكلة الأساسية ما اتحلتش، بس إحساس العجز اتحوّل لتجربة لطيفة.

14. سحب لتحديث المحتوى مع أنيميشن

    • في Twitter وInstagram، لما تسحب لتحديث، تلاقي حركة للوجو أو شكل بيتغير.

    • حركة بسيطة، لكنها تخلي الانتظار مش ملل.

15. تطبيقات المواعدة (عياذا بالله)

    • زي Tinder وBumble: لما تنتظر Profiles جديدة، الواجهة بتدي إحساس إن في حد “بيتجهز” يتعرضلك، مش مجرد تحميل.

    • الانتظار بقى جزء من لعبة الاستكشاف.

---

مثال شهير من شركة عملاقة: Google Search

Google بتخدم مليارات عمليات البحث يوميًا.
وأي إحساس بالبطء حتى لو وهمي بيفرق.

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

“السيرفرات بطيئة”

لكن:

“المستخدم حاسس إن الصفحة تقيلة”

رغم إن زمن الاستجابة الحقيقي كان ممتاز.

الحل كان مبني على 3 عناصر أساسية:

1. تبسيط الواجهة بصريًا (Cognitive Load)

   • صفحة شبه فاضية، عناصر قليلة، مفيش ضوضاء.

2. إظهار القيمة الأساسية فورًا (Progressive Disclosure)

   • العناوين والنصوص تظهر أول، والباقي (صور، فيديو، توصيات، Knowledge Panels) تتحمّل بعدين.

3. مؤشرات حركة خفيفة (Feedback Loops)

   • Spinners بسيطة، Transitions سلسة، تحميل تدريجي مفهوم.

الرسالة:

“النتيجة وصلت… إحنا بس بنكمّل”

---

إعادة تعريف المشكلة جوه التيم

❌ قبل:

“إزاي نقلل زمن تحميل كل حاجة؟”

✅ بعد:

“إزاي المستخدم يحس إن نتيجة بحثه ظهرت فورًا، حتى لو باقي العناصر لسه بتتحمّل في الخلفية؟”

---

إزاي تستخدم التفكير ده كـ Team Leader أو Product Designer؟

1. غيّر صياغة المشكلة

   • ما تكتبش Ticket: “Improve performance”

   • اسأل: إمتى بالظبط بيحس المستخدم بالبطء؟ شايف إيه؟ فاهم إيه اللي بيحصل؟

2. صمّم لحظة الانتظار

   • أي لحظة سكون = توتر.

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

3. اشتغل Async والـ Background

   • تقارير، Imports، Jobs تقيلة… خليه يشتغل في الخلفية.

   • المستخدم يشوف Notification لما يخلص، بدل ما يحس إنه واقف مستني.

4. علّم التيم يسأل عن الإحساس

   • ٤ ثواني: شاشة بيضا = تجربة سيئة

   • Skeleton + Progress = تجربة مقبولة

5. التجربة نفسها Value

   • المنتج مش بس Features + Speed

   • المنتج كمان إحساس، وضوح، احترام لوقت المستخدم

---

الخلاصة

لما تعرف تعيد تعريف المشكلة صح، ساعات بتحقق فرق أكبر من أي Refactoring أو تحسين Backend،
لأنك بتوصل لدماغ المستخدم قبل السيرفر.