Privacy UX: أفضل الإخطارات وطلبات الأذونات

• الجزء 1: مخاوف الخصوصية والخصوصية في نماذج الويب
• الجزء 2: تجارب أفضل بشأن الموافقة على ملفات تعريف الارتباط
• الجزء 3: تجربة أفضل للإشعارات وطلبات الأذونات
• الجزء 4: إطار تصميم الخصوصية المدرك للخصوصية

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

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

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

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

"غالبًا ما تظهر في الأوقات التي تكون فيها أقل صلة بالموضوع ، وتخلق إحساسًا زائفًا بالإلحاح ، وتضعف التركيز وتسبب الإحباط".

- أليكس بوتريفايف ، اتصال داخلي

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

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

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

الوجوه المتعددة للإخطارات

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

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

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

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

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

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

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

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

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

لذلك يمكن أن تكون الإشعارات مختلفة ، ويُنظر إلى الإشعارات المختلفة بشكل مختلف ؛ ومع ذلك ، فكلما كانت الإشعارات شخصية وذات صلة وفي الوقت المناسب ، زادت المشاركة التي يجب أن نتوقعها. ولكن ماذا يعني كل هذا لتصميم الإشعارات ، وكيف يمكننا جعلها أقل تدخلاً وأكثر كفاءة؟

لا تعتمد على الافتراضات العامة: قم بإعداد أوضاع الإعلام

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

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

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

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

يمكن أن نكون أكثر دقة حتى من هذا ، على الرغم من ذلك. قدم Basecamp ، على سبيل المثال ، خياري "Always On" و "Work Can Wait" كجزء من تجربتهم على متن الطائرة ، بحيث يمكن للعملاء الجدد تحديد ما إذا كانوا يرغبون في تلقي الإشعارات فور حدوثها (في أي وقت) ، أو اختيار وقت محدد النطاقات والأيام التي يمكن فيها إرسال الإشعارات. أو بالعكس ، يمكننا أن نسأل المستخدمين متى لا يريدون إزعاجهم ، ونعلق الإشعارات في ذلك الوقت. لا يرغب كل عميل في تلقي إشعارات متعلقة بالعمل خارج ساعات العمل أو في عطلة نهاية الأسبوع ، حتى لو كان زملاؤهم يعملون لساعات إضافية ليلة السبت على الجانب الآخر من الكوكب.

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

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

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

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

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

اختر التوقيت بعناية

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

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

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

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

تجنب المواقف العصيبة حسب التصميم

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

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

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

تقليل التكرار عن طريق تجميع الإخطارات

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

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

بمجرد زيادة حجم الإشعارات ، يمكننا البدء في تجميعها وتقديم ملخصات مضغوطة في الوقت المناسب. على سبيل المثال ، يلخص Facebook الإشعارات في كتل غير تدخلية ، حيث يبرز كل سطر نوعًا واحدًا بالضبط من الأحداث ، مثل ردود الفعل على رسالة معينة ("رد ستويان ستيفانوف و 48 شخصًا آخر على مشاركتك ...") . من ناحية أخرى ، يبدو أن LinkedIn يطلق كل حدث واحد تقريبًا واحدًا تلو الآخر ("Stoyan Stefanov علق على منشورك") ، وبالتالي يلوث تدفق الإشعارات ويجعل من الصعب مسحها واستخدامها.

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

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

هذا ، بالطبع ، يتطلب أيضًا حلقات تغذية راجعة مستمرة.

السماح للمستخدمين بتأجيل الإشعارات أو إيقافها مؤقتًا

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

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

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

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

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

عيّن الحدود وأنشئ شجرة قرارات للإشعارات

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

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

اجعل الاشتراك والانسحاب واضحين

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

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

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

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

طلب الإذن ، الطريق المتواضع

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

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

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

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

بشكل أساسي ، نقوم بتقسيم موجه الإذن إلى طلبين:

1. طلب مضمن في واجهة المستخدم ،
2. طلب أصلي على مستوى المتصفح.

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

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

مقاييس المسار للإشعارات

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

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

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

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

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

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

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

Admittedly, these issues will not be raised immediately, but as customers keep using an interface and contribute more and more personal data, doubts and concerns start appearing more frequently, especially if more people from their social circles are involved. Some of these issues are easy refinements, but others are substantial and often underestimated blockers.

In the final article of the series, we'll be looking into notifications UX and permission requests, and how we can design the experience around them better, with the user's privacy in mind.

• Part 1: Privacy Concerns And Privacy In Web Forms
• الجزء 2: تجارب أفضل بشأن الموافقة على ملفات تعريف الارتباط
• Part 3: Better Notifications UX And Permission Requests
• الجزء 4: إطار تصميم الخصوصية المدرك للخصوصية

Useful Resources And References

• “Designing Notifications For Apps,” Shashank Sahay
• “Different Types Of Notifications: Websites, Apps And Beyond,” Joanna Martin
• “It's Time For Notifications To Get Smart,” Alex Potrivaev
• “Improving User Experience With Real-Time Features,” Lauren Plews