تحسين تطبيق الموبايل: رتّبه قبل أن تعيد بناءه

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

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

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

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

موقف يتكرر: الشكاوى تتزايد والقرار يأتي متسرعا

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

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

ثمن القرار المتسرع

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

السؤال الصحيح

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

من يجب أن يشارك في القرار

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

لماذا لا تعني الشكاوى أن التطبيق فاشل

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

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

العميل يصف الأعراض لا الأسباب

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

التطبيق الذي يعمل له قيمة

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

التطبيقات الكبيرة تتحسن باستمرار

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

كيف تقرأ الشكاوى وتحولها إلى مشكلات محددة

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

المصدر الأول: تقييمات المتاجر

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

المصدر الثاني: رسائل خدمة العملاء

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

المصدر الثالث: بيانات الاستخدام

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

المصدر الرابع: الملاحظة المباشرة

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

المصدر الخامس: فريقك الداخلي

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

أكثر مشكلات الترتيب شيوعا في التطبيقات

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

خطوات أكثر من اللازم

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

الزر المهم غير ظاهر

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

التسجيل الإجباري المبكر

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

نماذج طويلة

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

رسائل خطأ غامضة

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

بطء ظاهري يمكن تخفيفه

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

إشعارات مزعجة أو في غير وقتها

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

بحث لا يجد ما يبحث عنه المستخدم

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

تنقل مربك

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

مراجعة التطبيق خطوة بخطوة: كيف تتم عملية التدقيق

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

تحديد المهام الأساسية

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

تتبع كل مهمة وعد الخطوات

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

مقارنة ما نراه بالشكاوى

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

فحص الأساس التقني

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

مراجعة لوحة التحكم أيضا

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

تقرير واضح بالأولويات

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

مقارنة: إعادة الترتيب مقابل إعادة البناء

لتوضيح الفرق بين الطريقين، إليك مقارنة مباشرة:

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

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

متى يستحق التطبيق إعادة البناء فعلا

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

حين تكون التقنية قديمة وغير مدعومة

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

حين يكون كل تعديل صغير مكلفا جدا

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

حين يتغير نموذج العمل نفسه

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

حين لا يتحمل التطبيق عدد المستخدمين

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

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

وهذا النوع من القرارات يحتاج خبرة في الأنظمة والبرمجيات الخاصة لتقييمه بشكل صحيح.

كيف تنفذ التحسينات دون إرباك المستخدمين الحاليين

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

التنفيذ على دفعات

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

أخبر المستخدمين بما تغير

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

احتفظ بما يحبه المستخدمون

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

اختبر قبل النشر الواسع

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

استمع بعد كل تحديث

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

قائمة مراجعة قبل اتخاذ قرار إعادة البناء

• [ ] جمعت الشكاوى من تقييمات المتاجر ورسائل العملاء في ملف واحد.
• [ ] صنفت الشكاوى حسب نوع المشكلة وعرفت الأكثر تكرارا.
• [ ] راجعت بيانات الاستخدام وحددت أين يتوقف أغلب المستخدمين.
• [ ] جربت المهام الأساسية بنفسك وعددت خطوات كل مهمة.
• [ ] راقبت شخصا جديدا يستخدم التطبيق دون مساعدة.
• [ ] تأكدت هل التقنية المستخدمة ما زالت مدعومة.
• [ ] عرفت هل التعديلات الصغيرة سهلة أم مكلفة جدا في الكود الحالي.
• [ ] تأكدت أن الخادم وقاعدة البيانات يتحملان عدد المستخدمين.
• [ ] رتبت المشكلات حسب الأولوية وقررت أيها يصلح أولا.
• [ ] وضعت طريقة لقياس النتيجة بعد كل تحديث.

مؤشرات تخبرك أن التحسين نجح فعلا

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

معدل إتمام المهمة الأساسية

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

عدد رسائل الدعم عن نفس المشكلة

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

التقييمات الجديدة في المتاجر

راقب التقييمات التي تكتب بعد التحديث تحديدا. هل اختفت الكلمات التي كانت تتكرر مثل معقد ومربك؟ هل ظهرت كلمات جديدة إيجابية؟ التقييمات الجديدة تعكس تجربة المستخدمين مع النسخة المحسنة.

عودة المستخدمين

هل يعود المستخدم إلى التطبيق بعد أول طلب؟ هل يطلب مرة ثانية وثالثة؟ التطبيق السهل يشجع على العودة، والتطبيق المربك يستخدم مرة ثم ينسى. متابعة هذا المؤشر على مدى أسابيع تعطيك صورة عن الأثر الحقيقي للتحسين.

الوقت اللازم لإتمام المهمة

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

الخلاصة: افهم أولا، ثم قرر

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

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

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