كيف نراجع موقع عيادة قبل اقتراح إعادة البناء

العيادة كانت تشتغل منذ ٢٠١٩. الموقع بُني على WordPress بقالب عام، وأُضيفت فوقه إضافات على مرّ السنين: حجز مواعيد، نموذج تواصل، صفحات أطباء، مدوّنة طبية. الفريق الإداري كان يشعر أن الموقع 'قديم' و'بطيء' و'لا يحوّل'. السؤال الذي طُرح علينا: ابنوا واحداً جديداً.

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

ما فعلناه في الأسبوعين

قسّمنا الوقت إلى أربع طبقات من القراءة، كل طبقة تجيب على سؤال محدّد قبل الانتقال للتالية:

1. طبقة الأداء التقني — Lighthouse، WebPageTest، فحص الـTTFB من ثلاث مناطق سعودية، تحليل حجم الحزمة، عدد الطلبات.
2. طبقة المحتوى — قرأنا كل صفحة منشورة (٤٧ صفحة). كم منها يحصل على زيارات؟ كم منها يقود إلى حجز موعد؟ ما المسارات الفعلية للمستخدم وفق قوقل أناليتكس؟
3. طبقة الحجز — جرّبنا حجز موعد بأنفسنا، على الجوّال وسطح المكتب، بثلاث شخصيات مختلفة (مريض جديد، مريض راجع، مريض يحجز لأحد أفراد العائلة).
4. طبقة الفريق — جلسات منفردة مع المسؤول الإداري، طبيبتين، ومسؤول السنترال. ما الذي يخفّف عليهم؟ ما الذي يضيع وقتهم؟

النتائج التي لم نتوقّعها

كان الموقع بطيئاً، صحيح. LCP ٤.٢ ثانية على الجوّال، CLS ٠.٣١. هذه أرقام سيّئة بأي مقياس. لكن السبب لم يكن WordPress، ولم يكن القالب — كان شريط صور دوّار في الصفحة الرئيسية يحمّل ١٢ صورة كاملة الدقّة قبل أي محتوى آخر. حلّ ذلك يستغرق نصف يوم، لا إعادة بناء.

الأهم: نظام الحجز كان يعمل، لكن مسار الحجز على الجوّال كان يفقد ٣٨٪ من المستخدمين في خطوة اختيار الطبيب. السبب؟ القائمة المنسدلة تعرض ٢٣ اسماً بترتيب أبجدي. على شاشة ٣٧٥px، المستخدم يحتاج تمريراً عبر ٢٣ خياراً بدون أي تصفية أو تخصص. الحلّ ليس إعادة البناء — الحلّ تحسين خطوة واحدة.

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

ما اقترحنا في النهاية

إعادة بناء كاملة، نعم — لكن بشكل مختلف عمّا توقّعناه في اليوم الأول. القرار جاء من البيانات، لا من الإغراء التقني:

• المرحلة ٠ (أسبوع): إصلاحات سريعة على الموقع الحالي. حذف الشريط الدوّار، تحميل مؤجّل للصور، تحسين مسار الحجز. مكاسب فورية في الأداء والتحويل دون انتظار إعادة البناء.
• المرحلة ١ (٨ أسابيع): إعادة بناء على Next.js مع طبقة محتوى مخصّصة. ليس لأن WordPress سيّء — بل لأن الفريق الإداري يحتاج تحكّماً أعمق في صفحات الأطباء وفي محتوى التعليم الصحي، وتجربة التحرير في WordPress كانت تُربكهم.
• المرحلة ٢ (مستمر): شراكة شهرية لإعادة كتابة صفحات الأطباء والمحتوى التعليمي. لا إعادة بناء تحلّ مشكلة محتوى — يحتاج كاتباً يفهم اللغة الطبية ونفسية المريض.

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

الدرس

إعادة البناء هي أغلى توصية يمكن لاستوديو أن يقدّمها. ولأنها الأغلى، يجب أن تكون مبنية على البيانات لا على الانطباع. العميل يثق بك أكثر حين تقول 'ما تحتاج إعادة بناء كاملة، تحتاج إصلاح هاتين الخطوتين' — حتى لو كان ذلك أقل ربحاً لك في المدى القريب.

والمدى البعيد؟ هذه العيادة وقّعت معنا المرحلة ١ والمرحلة ٢ لأنّنا قلنا لها لا لإعادة البناء الفورية. لأن الثقة بُنيت من القرار الصحيح، لا من البيع السريع. هذه هي الشراكة طويلة المدى بالنسبة لنا — وهذه هي الطريقة الوحيدة التي نعرف نشتغل بها.