كيفية البحث عن رحلة المستخدم غير المخطط لها وتحقيق أقصى استفادة منها
نشرت: 2022-03-10يمكن تعريف الاحتياطيات على أنها خطة بديلة يمكن استخدامها ، وفي سياق رحلات المستخدم ، ستكون مسارًا بديلاً لسلوك المستخدم المتوقع أو المخطط له. لذلك ، عندما نفكر في مواقعنا وتطبيقاتنا ، فإننا نبنيها مع وضع خطة معينة في الاعتبار لتحقيق هدف معين من خلال اتخاذ طريق معين وتجربة تجربة معينة.
إذا كنت من ذوي الخبرة في بناء المنتجات ، فستعرف أن المستخدمين يميلون إلى القيام بأشياء لم تخطط لها ، ولا بأس بذلك لأننا لا نستطيع فهم جميع احتياجاتهم ونواياهم. هذا هو السبب في أن الاحتياطيات قيمة للغاية.
على مر السنين ، قمنا بتجربة واختبار العديد من الأدوات في Venture Harbour لمساعدتنا في الحصول على حلقات ملاحظات أفضل. منتجاتنا لها احتياجات تتطلب أنواعًا مختلفة من الأدوات للكشف عن جميع أنواع الرؤى. من الخرائط الحرارية وأدوات تسجيل الزائرين (مثل Hotjar و Fullstory) إلى منصات التحليلات مثل Google Analytics و Amplitude.
هذه الأدوات رائعة وتساعدنا على إنجاز الكثير ، لكنها لا تصل إلا إلى هذا الحد. نحتاج الآن إلى الحصول على رؤى أعمق لا يمكن تحقيقها إلا من خلال تطبيق احتياطيات على رحلات المستخدم الخاصة بك .
للبدء ، نحتاج إلى التفكير في السلوكيات أو المسارات البديلة التي قد يختبرها مستخدمونا والتي لم نكن نتوقعها. فيما يلي ثلاث عوائق شائعة:
- طريق مسدود
انتهت رحلة المستخدم ، ولا توجد خطوات واضحة أو إلى الأمام. سيكون الهدف هو تقديم الخطوات التالية للمستخدم وتتبع تلك الاختيارات. - المناطق الرمادية
يتفاعل المستخدم مع موقعك أو تطبيقك ، لكن لدينا القليل من الفهم أو لا نفهم على الإطلاق ما يجري ، أو لماذا يفعلون ما يفعلونه. الهدف هو إلقاء الضوء على تلك المناطق للتعرف على ما قد يحدث. - أخطاء
يتم تقديم رسالة خطأ للمستخدم لا تعطي سياقًا غير كافٍ. الهدف هنا هو تقديم سياق من خلال التفاعل مع المستخدم للحصول على تعليقات منه.
دعنا نتعمق في بعض الأمثلة من الحياة البرية حيث تكون حلقات التغذية الراجعة مفقودة من الإجراءات الاحتياطية الشائعة. بعد ذلك ، سأتابع بأفكار حول كيف يمكن أن تبدو حلقة الملاحظات وكيف تعمل في تلك الاحتياطيات.
ملاحظة : فقط لكي تعرف ، هذه نماذج بالأحجام الطبيعية تستند إلى سيناريوهات من العالم الحقيقي.
تحويل الطرق المسدودة إلى مناجم ذهب
تعتبر النهايات الميتة في تدفق المستخدم أمرًا شائعًا. تتمثل إحدى طرق اكتشافها في تحليل صفحات الخروج الخاصة بك في أداة تتبع التحليلات ، مثل Google Analytics. سيؤدي هذا إلى إبراز صفحات الخروج الشائعة على موقعك أو تطبيقك ويمنحك نقطة بداية لبدء التحقيق.
نحتاج الآن إلى طرح السؤال البسيط:
"لماذا يغادر المستخدمون عند هذه النقاط؟"
ألق نظرة على الصفحات الفعلية التي تحدث فيها هذه المخارج وابدأ في التفكير في أي نقطة في عملية استخدام التطبيق أو الموقع الذي يكون المستخدم عنده عندما وصل إلى هذا الطريق المسدود. هل بدأوا للتو ، أم أنهم في منتصف الطريق أم أنهم قريبون من تحقيق هدف معين في الرحلة؟ ستساعدك هذه الاعتبارات في رسم صورة أفضل لوضع المستخدم والأسباب المحتملة.
مثال: نهايات مسدودة في البحث
طريق مسدود شائع جدًا هو البحث عندما تبحث عن شيء ما وتظهر لك صفحة "لا توجد نتائج". بدأت الشركات في الاستثمار حقًا في هذه الصفحات ، وستجد أنه من الطبيعي أن تظهر لك نوعًا ما من النتائج - خاصة على مواقع التجارة الإلكترونية.
عند البحث عن أي شيء ، يجب أن نرجع نوعًا ما من النتائج على الأقل. عندما لا يكون لدينا نتيجة فعلية لعرضها ، فإننا بحاجة إلى التفكير بشكل خلاق في كيفية الاستفادة من هذه السيناريوهات. يمكن أن يتخذ هذا شكل سؤال أو إجراء شائع قد يكون نية بحث المستخدم في المقام الأول.
فيما يلي مثال على بحث مسدود:
في هذه الحالة ، ما الذي يمكننا اكتشافه من المستخدم ولا نعرفه بالفعل لمساعدتنا في تحسين تجربته ومساعدتنا على التعلم؟ ما هي الأسئلة التي يمكن أن نطرحها عليهم؟ ما الذي يمكن أن نقدمه للمستخدم في هذه المرحلة ، بعد أن لم يعثروا على ما يبحثون عنه؟
هذا السيناريو الخاص مثير للاهتمام ، وفكرت في بضع أفكار حول كيفية الحصول على معلومات من المستخدم لمساعدتنا في تحسين تطبيقنا وتزويدهم بالخطوة التالية.
كما هو موضح أدناه ، نبدأ بإخبار المستخدم أن ما يبحث عنه غير متوفر الآن ، ولكن يمكن أن يكون في المستقبل. في المقابل ، يمكننا الحصول على بعض التعليقات حول ما كانوا يأملون في فعله أو العثور عليه بدلاً من ذلك:
يمكننا بعد ذلك تزويد المستخدم بالخطوة التالية من خلال تزويدهم بفلتر يساعدهم في العثور على بديل وإبلاغنا لاحقًا بفئة الامتداد التي كانوا يبحثون عنها ، والتي يمكننا بعد ذلك مراجعة وتحديد الفئات التي يجب أن نستثمرها في الوقت الحالي. من خلال جمع هذه المعلومات من المستخدم ، يمكننا البدء في بناء قاعدة معرفية لما قد يتوقعه المستخدمون في هذه السيناريوهات والبدء في اقتراح فئات واقتراحات أكثر ذكاءً للمستخدم النهائي في المستقبل. بهذه الطريقة ، يمكننا تزويدهم بتجربة مستخدم أفضل بكثير.
مثال: نهايات طبيعية مسدودة
يمكن أن تحدث النهايات المسدودة أيضًا بترتيب طبيعي لموقعك أو تطبيقك. قد تكون هناك سيناريوهات يقابل فيها المستخدمون صفحة تفتقر إلى المحتوى ولا توجد خطوة إلى الأمام بسبب عدم توفر الوقت لدى النظام لمعالجة البيانات. أو ربما لم يتم إنشاء البيانات بعد ، كما هو موضح أدناه:
والآن ما نريد فعله هو التأكد من شيئين:
- يجب أن يفهم المستخدم لماذا وما الذي يحدث ؛
- قم بإشراك المستخدم أثناء انتظار البيانات.
يوجد أدناه معلومات ودية وقيمة ومفيدة لكل من المستخدم ولأنفسنا. يُعرض على المستخدم إخطارات ليتم إرسالها إلى عنوان بريده الإلكتروني - جنبًا إلى جنب مع اشتراك لمدة شهر مجانًا! في المقابل ، نحصل على إبلاغ المستخدمين بموعد العودة إلى التطبيق: مستخدمون سعداء بشهر مجاني ، وبيانات إضافية عن المستخدمين أنفسهم. من الأفضل دائمًا أن يفوز الجميع!
بمرور الوقت ، يمكننا البدء في فهم ما إذا كان غالبية المستخدمين يرغبون في الحصول على ميزات معينة أم لا ، وما إذا كانوا يفضلون بدء تشغيلها افتراضيًا أو إزالتها تمامًا. أيضًا ، يمكن أن تساعد المعلومات الواردة من الاستطلاعات في زيادة فهمنا لتوقعات المستخدمين للتطبيق ، ومساعدتنا في تشكيله ليلائم احتياجات المستخدمين.
يوصى بالقراءة : كيفية تحسين عملية التصميم الخاصة بك مع الشخصيات المستندة إلى البيانات
تحويل المناطق الرمادية إلى رؤى
ما أعنيه بـ "المناطق الرمادية" هي المناطق التي تفتقر إلى البصيرة والوضوح بشأن ما قد يفعله المستخدمون أو لماذا يتخذ المستخدمون قرارات معينة. عادةً ما تكون هذه المجالات ليست ذات أولوية عالية للموقع / التطبيق ولكنها جزء من رحلة المستخدم الرئيسية. كلما زادت البيانات التي نمتلكها خلال رحلة المستخدم ، كان بإمكاننا أن نفهم بشكل أفضل أسباب وأسباب وطرق تصرفات المستخدمين.
مثال: فهم "الآخر" الخاص بك
من الشائع جدًا تصنيف شيء ما على أنه "آخر" عندما لا يكون هناك توافق واضح. يوجد أدناه مثال على هذا النوع من واجهة المستخدم ، وبينما نقوم بتحليل هذا السيناريو ، من الواضح أن البصيرة الوحيدة التي لدينا هي أننا نعلم أن المستخدم يصنف هذا النوع على أنه نوع "آخر" ، وهذا يتركنا مع القليل من الفهم لما هو عليه أو ما ينوون أن يكون.
بالطبع ، يمكننا أن نتحرى أكثر قليلاً عما يسمى بـ "الآخر" ونجد بعض الأسطر المشتركة ، لكننا لا نعرف ما الذي قد يقصده المستخدم من خلال تسميته بذلك.
لذا ، كيف يمكننا تغيير هذا السيناريو من مجرد إجابة "أخرى" إلى شيء إعلامي ومفيد لكل من المستخدم ونحن؟ إن النهج الذي أقترحه أكثر تعقيدًا بعض الشيء ولكنه سيجعل التجربة أكثر جاذبية.
نريد أن نسمح للمستخدمين إما باختيار خيارهم من خلال النقر على الخيار الذي يعرفون أنهم يريدون أو من خلال البحث عما يعتقدون أنهم يبحثون عنه. لماذا هذا مفيد؟ حسنًا ، عندما يتعلق الأمر بخيارات التسمية ، قد نقوم بتسميتها بطريقة مختلفة تمامًا مقارنة بالطريقة التي قد يفكر بها المستخدم . ولكن إذا كنا لا نزال غير قادرين على تقديم إجابة للمستخدم الذي يبحثون عنه ، فيجب أن نبدأ محادثة معهم من خلال عرض سؤال ومربع نص عليه ، ونسألهم عما يبحثون عنه ولماذا. (ربما نضيف أيضًا سطرًا سنتابعه معهم ونجد حلاً لاحتياجاتهم.)
عندما نبدأ في العثور على سلاسل رسائل مشتركة في عمليات البحث والردود التي نحصل عليها ، يمكننا البدء في ضبط البحث لخدمة المستخدم الذي يحتاجه على الأرجح ، ويمكننا أيضًا إنشاء ميزات جديدة مع زيادة الطلب أيضًا.
مثال: افهمك البحث الفوري
هناك منطقة رمادية أخرى أدناه هي أحد الأمثلة على استخدامي للبحث الفوري أثناء البحث عن بعض الكلمات الرئيسية غير المرتبطة بأي شيء لدي في حسابي.
من هذه التجربة طرحت على نفسي الأسئلة التالية:
- ما النتيجة من هذا السيناريو؟
- هل يمكنني معرفة مدى شيوع هذا السيناريو؟
- ما الذي يحاول المستخدم تحقيقه؟
- كيف يمكننا مساعدتهم للوصول إلى حيث يريدون؟
يوجد أدناه نافذة نتائج "لا توجد نتائج" مع حلقة ملاحظات لمساعدتنا في التعرف على احتياجات المستخدمين. يتم تعبئة نتائج البحث بطريقة يمكن أن تجلب رؤى حول احتياجات المستخدمين ، وتزودنا ببعض الوضوح على الأقل حول ما يبحثون عنه بالضبط باستخدام خيار "البحث في".
بعض الطرق لإشراك المستخدمين لديك هي:
- تقديم إجراءات مشتركة على موقعك أو تطبيقك للمستخدم لإنشاء المحتوى الذي يبحثون عنه ؛
- قدم خيار تلقيهم إشعارًا بمجرد أن يصبح الشيء الذي كانوا يبحثون عنه متاحًا (هذه طريقة رائعة لإعادة المستخدم في مرحلة لاحقة) ؛
- اسمح لهم بتقديم ملاحظات مباشرة لأن التحدث إلى شخص ما في بعض الأحيان سيحل كل شيء (والمحادثة هي أفضل مصدر للتعليقات).
يمكننا التعلم والحصول على نتائج أكثر ذكاءً من خلال النتائج التي نحصل عليها من حلقة التعليقات هذه ، طالما أننا نبدأ في تقديم اقتراحات أكثر ذكاءً للفئة لمستخدمينا . بمرور الوقت ، يمكن تعلم العادات الشخصية للمستخدمين الفرديين ويمكننا البدء في اقتراح خيارات من المرجح أن يكون لها صدى لدى هذا المستخدم بسبب إجراءاتهم وعمليات البحث السابقة.
اجعل رسائل أخطاءك قوة
سواء اخترنا قبولها أم لا ، فإن الأخطاء تحدث. عندما تحدث ، يجب أن نعرف عنها ، لكن في بعض الأحيان يمكننا التعامل مع الأخطاء بطريقة عامة لا تساعدنا أو تساعد المستخدم.
مثال على ذلك هو عندما يتفاعل المستخدم مع موقعك أو تطبيقك حيث يقوم بحفظ نوع من البيانات على نظامك ، ولكن لسبب ما ، يتم فقد الاتصال وتفشل العملية. لا يوجد الكثير لتشخيص ما يجري أو ما حدث ولكننا نعلم أنه كان هناك خطأ. الإجراء القياسي هو إبلاغ المستخدم بحدوث خطأ وربما المحاولة مرة أخرى.
عندما نعرف القليل عن المشكلة من جانبنا ، أو ربما كانت ناجمة عن مجموعة من الأشياء ، فهذه فرصة رائعة لاستعادة بعض التعليقات من المستخدم حول ما يحدث. أعتقد أن هذا هو أبسط طريقة احتياطية للتنفيذ ، ولكن أقل ما أراه.
السيناريو المعتاد هو عندما يتم حفظ شيء ما تلقائيًا أثناء استخدامك للموقع أو التطبيق. هذا هو السيناريو المتزايد خاصة مع اتصالات المحمول ؛ يعد فهم أن موقعك يستخدمه المستخدمون أثناء التنقل أو عبر اتصال جوّال فكرة رائعة ، ويجب أن نحاول جمع هذه المعلومات قدر الإمكان.
أو يمكنك جعله أبسط للمستخدم. إذا كان لديك بالفعل فكرة عن ماهية المشكلة وترغب في الحصول على فكرة أفضل عن عدد المرات التي حدثت فيها للمستخدم ، فقدم لهم خيارات ولكن مع السماح لهم بإخبارك بما مروا به. بمجرد حصولك على هذه المعلومات ، يمكنك بعد ذلك البدء في استثمار وقتك في الميزات الجديدة الممكنة للمساعدة في حل تلك المشكلات المعطاة ، ونأمل أن تجد نفسك غير مضطر إلى إظهار رسالة خطأ على الإطلاق.
شيء مهم يجب تذكره هو أنه ليس من الضروري أن يكون الاحتياطي ميزة دائمة ، ولكن يمكن أن يكون مؤقتًا لمساعدتك في معرفة ما يجب طرحه أو ما يجب بناؤه بعد ذلك. يتطلب الأمر القليل من الاستثمار والوقت لجمع البيانات ، ولكن يمكن اعتبارها بمثابة اختبار قيد التشغيل في مناطق من رحلة المستخدم الخاصة بك لم تنظر إليها من قبل ، وستضيف فقط إلى فهم المستخدمين واحتياجاتهم.
مع كل هذا ، فإن التراجع في عالم مثالي لن يكون موجودًا أبدًا. إذا كنت تعمل في مشروع جديد تمامًا أو تعيد صياغة تدفق المستخدم ، فضع لنفسك التحدي المتمثل في إنشاء تدفق حيث لن يواجه المستخدم سيناريوهات مثل هذه أبدًا. ضع في اعتبارك كيفية منع المستخدم من البحث عن شيء غير موجود. تتبع وتحليل جميع مناطق رحلة المستخدم الخاصة بك لفهم كل خطوة من خطواتهم وصياغة الطرق التي لن تظهر فيها رسالة خطأ أبدًا.
يوصى بالقراءة : اختبار أ / ب لتجارب الجوال أولاً
أين تكلفك الإجراءات الاحتياطية؟
ستبدو الإجراءات الاحتياطية مختلفة اعتمادًا على منتجك ، حيث ستطرح أسئلة مختلفة وتقدم خيارات مختلفة ، لكنها ستلعب جميعًا دورًا مهمًا في تعريض نفسك والمستخدمين لخيارات وفهم أفضل.
ماذا بعد؟
لماذا لا تستغرق بضع ساعات للنظر في رحلات المستخدم الخاصة بك وتوثيق مكان المناطق الرمادية ، وكذلك البحث عن طريق مسدود ورسائل خطأ (لا تزال) موجودة في منتجك.
فيما يلي بعض الأدلة للبدء:
- طريق مسدود
ابدأ في استكشاف تحليلاتك - وإذا لم تكن كذلك بالفعل - فاستعن بالراحة هناك. عادةً ما يتم تتبع صفحات الخروج افتراضيًا وستزودك برؤى رائعة عن المرحلة التي يغادر فيها المستخدمون الموقع. فكر في المكان الذي سيكون فيه المستخدمون في رحلتهم وفكر في نوع الاحتياجات التي قد تكون لديهم في تلك النقاط. - المناطق الرمادية
إذا لم تكن قد قمت بذلك بالفعل ، فقم برسم رحلة المستخدم الخاصة بك وابدأ في تحديد المجالات التي قد تكون لديك أسئلة حولها. ضع في اعتبارك النقاط التي يتخذ فيها المستخدمون قرارات وفكر في الخيارات التي تقدمها لهم. تذكر خيار "الآخر" وفكر في أي مكان يمكن أن يكون عامًا تمامًا. ابدأ في تتبع هذه الخيارات لمعرفة عدد المرات التي يتم اختيارها ، ثم ابدأ في استكشاف طرق الحصول على تعليقات من المستخدمين حول ما يريدون. - أخطاء
يمكنك تحديد المكان الذي قد يظهر فيه خطأ في تطبيقك بسرعة. مع وجود موقع / تطبيق يقوم بالحفظ والتحديث والعمل في الوقت الفعلي ، من المحتمل أن تكون الأخطاء جزءًا أساسيًا من نظامك. ابدأ بتحديد المنطقة الأكثر استخدامًا ، مما قد يؤدي إلى الأماكن التي تظهر فيها الأخطاء بشكل متكرر. استثمر في رسائل الخطأ هناك وابدأ في جمع التعليقات حول سبب عرضها - سواء من نظامك أو من المستخدم أيضًا. أوصي أيضًا بإنشاء رسالة خطأ افتراضية مع حلقة ملاحظات يمكن استخدامها عبر الموقع لأي ميزة جديدة حتى تبدأ في التعلم من هذه الأخطاء من اليوم الأول.
بناء احتياطي سعيد!