لماذا لا تغير المواقع المشهورة تصاميم واجهاتها القديمة ؟ وُجه لي هذا السؤال قبل مدة طويلة، سُئلت بحكم تخصصي في تصميم واجهة وتجربة المستخدم لعلي أعرف الجواب.

لم أكن أعرف حينها لماذا لا تخطوا تلك المواقع هذه الخطوة، لماذا يستمرون في استخدام واجهات عتيقة منذ فترة طويلة جدًا دون تغيير أو تحسين يذكر.

مؤخرًا عرفت السبب، ولعل صاحب السؤال قد عرف الإجابة قبلي 🙂 بما أنني تأخرت لهذه الدرجة. دعونا نبدأ الآن الحديث المهم بعد هذه التقدمة.

لماذا لا تغير المواقع المشهورة تصاميم واجهاتها القديمة :

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

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

المفترض أن يكون التغيير على 6 خطوات إذا سار الأمر كما خططنا، وفي حال حدثت مشكلة علينا العمل على تحسينها فورًا.

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

نكرر هذه العملية مع كل صفحة مهمة تحمل تغيير جذري، مثل الصفحة الرئيسية للمتاجر، وصفحة المنتج، السلة، وغيرها… هناك الكثير حول هذه النقطة، لعلي أخصص له مقال منفصل في المستقل إن شاء الله.

حسنًا، لماذا كل هذا التعقيد؟ لماذا لا نطلق التصميم الجديد دفعة واحدة؟

إطلاق تحديث كبير على خدمة لديها عدد قليل من المستخدمين لن يشكل فارق يذكر، عدد المستخدمين قليل من الأساس وخُسران 10% مثلًا ليس بالأمر الجلل، ويمكن تعويضه بسهولة.

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

لهذا تعديل بسيط في الواجهة بدون دراسة معمقة وتأني قد يكلفها الشركة خسائر مهولة.

أين المشكلة؟

تكمن المشكلة في أن المستخدمين قد اعتادوا على تجربة استخدام واحدة، والتي بالمناسبة قد تكون غير سليمة لكنهم مع ذلك قد ألفوها، والمستخدم البسيط بطبعة لا يحب التغيير، فبالنسبة له خدمة قديمة تحتاج لـ 5 خطوات مثلًا للقيام بإجراء معين أفضل من أخرى جديدة يمكنه إتمام نفس الأمر عبر خطوتين أو 3 فقط.

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

هل يجب على كل المنصات عمل هذه الخطوات أم لكل قاعدة شواذها؟

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

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

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

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

ما هي الأساليب المتاحة لتغيير واجهات المنصات:

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

التحسين المتتابع:

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

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

الحُزم المحدودة:

في هذا النوع يطلق التحديث الجديد على فئة قليلة فقط من المستخدمين، وبعد أخذ ملاحظاتهم وإضافة تحسينات من ردود أفعالهم تطلق النسخة المنقحة لمستخدمين أكثر، وهكذا حتى يعمم على كل المستخدمين.

ميزة هذا النوع أنه أسهل في البناء والمخاطر خلفة أقل بحكم أنه يطلق لفئة قليلة من المستخدمين. هذه الطريقة تستخدم أيضًا في الأسلوب الأول “التحسين المتتابع”.

النسخ المستقلة:

يعمد هذا النوع إلى إطلاق نسخة جديدة من المنصة، نسخة مستقلة تمامًا، مع المحافظة بالطبع على النسخة الأساسية (القديمة)، يروج للنسخة الجديدة لجذب الفئة المحبة للتغيير والتجربة، أو حتى لجذب فئات جديدة من المستخدمين.

ميزة هذا النوع أنه يعطي المصمم حرية كاملة في العمل، فهو ليس مقيد بهيكل أكل عليه الدهر وشرب، كما أنه أقل جهدًا للمصممين والمبرمجين على حد سواء.

لماذا تترك النسخة القديمة تعمل في ظل وجودة نسخة أفضل؟

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

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

التغيير المفاجئ:

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

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

لكن في الواقع التصميم الجديد مر بمراحل عميقة من الاختبار الفعلي من قبل خبراء ومختصين وتجربتها على مستخدمين حقيقيين، وبعد نجاح التصميم الجديد على الفئات المختبرة يُنشر للعامة.

أين تكمن صعوبة تغيير واجهات المواقع المشهورة :

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

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

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

نقطة مهمة:

الحديث في هذا المقال خاص بالمشاريع العملاقة، مثل تطبيقات البنوك، المتاجر الإلكترونية الضخمة، تطبيقات التوصيل والمطاعم، الشبكات الاجتماعية، التطبيقات العقارية والخدمية وغيرها… وليس المشاريع البسيطة مثل المدونات والمواقع الإخبارية…

لذلك إذا كان لديك مشروع ذو تجربة مستخدم سيئة لا تعذب مستخدميك بها أكثر مما فعلت بهم 🙂 حدثها بسرعة أرجوك حتى يستطيعوا النوم مرتاحي البال 🙂

تنبيه مهم:

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

أرجو من الله أن تكون كتابتي للمقال موفقة في توضيح لماذا لا تغير المواقع المشهورة تصاميم واجهاتها القديمة ، وأتمنى أن تكون مفيدة لكم.

كل التقدير والاحترام.

حقوق صورة المقال محفوظة للمبدع Vishnu Prasad