← المدونة

لماذا يرفض المستخدم طلب الصلاحية؟

لماذا يرفض المستخدمون نوافذ الصلاحيات؟ دليل عملي لتصميم طلبات الموقع والإشعارات بتوقيت صحيح، مع قائمة تحقق للمصممين.

10 / 2026 · 6 دقائق · تجربة وواجهة

يد تمسك هاتفاً تظهر على شاشته المقفلة إشعارات تطبيقات، فوق مكتب عمل.

نافذة تُرفض قبل أن تُفهم

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

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

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

درس من Hopper: طلبان، نتيجتان

في تجربة الإعداد داخل تطبيق Hopper لحجز الطيران يظهر طلبان للصلاحية يوضحان الفرق بين التوقيت الخاطئ والصحيح.

طلب الموقعطلب الإشعارات
متى ظهرعند الضغط على حقل «من أين» في أول جلسةبعد أن نصح التطبيق المستخدم بالانتظار لأن السعر قد ينخفض
السياقمرتبط بالحقل، لكن قبل بناء أي ثقةالمستخدم نفسه يريد أن يُنبَّه عند انخفاض السعر
من بدأ الطلبالتطبيقالمستخدم، بضغطه على «راقب السعر»
النتيجةرفض فوريقبول دون تردد

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

والبديل الأفضل لطلب الموقع بسيط: زر داخل الحقل مثل «استخدم موقعي الحالي» يوضّح الفائدة، فلا تظهر نافذة النظام إلا إذا اختاره المستخدم بنفسه.

شاشة في تطبيق Hopper تعرض توقّعات السعر، وزرّ «Be the first to know» مع «Not now» تحته.
Hopper: الطلب جاء بعد أن نصح التطبيق بالانتظار لأن السعر قد ينخفض، فصار زرّ «Be the first to know» جواباً عن حاجة شعر بها المستخدم.

خمسة مبادئ لطلب صلاحية يُقبل

  1. اطلب عند لحظة الحاجة، لا عند الفتح.اربط كل صلاحية بالميزة التي تحتاجها: الكاميرا عند أول مسح، الإشعارات عند أول متابعة، الموقع عند أول بحث قريب.
  2. دع المستخدم يبدأ الطلب.زر واضح مثل «استخدم موقعي» أو «نبّهني عند انخفاض السعر» يجعل نافذة النظام نتيجةً لاختياره، لا مفاجأةً له.
  3. استخدم شاشة تمهيد قبل نافذة النظام.اشرح الفائدة بجملة واحدة وصورة بسيطة، مع خيارين: «تفعيل» و«ليس الآن». الرفض في شاشتك قابل للتكرار لاحقاً، أما الرفض في نافذة النظام فشبه نهائي.
  4. اعرض الفائدة لا الصلاحية.«نُعلمك فور انخفاض سعر رحلتك» أقوى من «اسمح للتطبيق بإرسال الإشعارات».
  5. صمّم مساراً بديلاً.إن رفض المستخدم، يجب أن يكمل مهمته: إدخال المدينة يدوياً، أو تذكير داخل التطبيق بدل الإشعار. ولا تعاقبه بشاشة مغلقة.
افعل
شاشة تمهيد في تطبيق Meetup: جرس، وجملة تشرح الفائدة، وزرّان «Get reminder» و«No, thanks».
الفائدة بجملة واحدة، وخيار الرفض ظاهر بالقوّة نفسها. من يرفض هنا يمكن سؤاله لاحقاً.
لا تفعل
شاشة تمهيد في تطبيق N26 تشرح سبب طلب الموقع، وفيها زرّ «Enable location» وحده بلا خيار رفض ظاهر.
الفائدة مشروحة، لكن لا مخرج ظاهراً. الطريق الوحيد إلى الأمام هو القبول.

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

قائمة تحقق قبل التسليم

  • لا توجد أي نافذة صلاحية في أول شاشة يراها المستخدم
  • كل صلاحية مربوطة بفعل محدد يقوم به المستخدم
  • لكل صلاحية شاشة تمهيد تشرح الفائدة بجملة واحدة
  • شاشة التمهيد فيها «ليس الآن» واضحة وغير مخفية
  • النص يصف ما يكسبه المستخدم، لا ما يأخذه التطبيق
  • يوجد مسار بديل يكمل به المستخدم مهمته عند الرفض
  • يوجد مكان لاحق لإعادة عرض الطلب بلطف (مثلاً في الإعدادات أو عند تكرار الحاجة)

الخلاصة

طلب الصلاحية جزء من التجربة، لا عائق تقني قبلها. السؤال ليس «هل نحتاج هذه الصلاحية؟» بل «متى يريد المستخدم أن يعطيها لنا؟».

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

شارك المقال