فرض کنید کاربری یک اپلیکیشن مدیریت کار نصب کرده تا هیچ کار مهمی را فراموش نکند. اما حالا هر پیام، تغییر وضعیت، نظر جدید و یادآوری، بخشی از تمرکزش را می‌گیرد. کاربر از اعلان‌ها خسته شده و تصمیم دارد همه آن‌ها را خاموش کند.
خاموش‌کردن اعلان‌ها شاید مشکل مزاحمت را حل کند، اما اگر میان همان اعلان‌های آزاردهنده، خبری وجود داشته باشد که کاربر واقعا به آن نیاز دارد، چه اتفاقی می‌افتد؟
اینجا با یکی از چالش‌های طراحی محصول روبه‌رو هستیم: چطور تعداد مزاحمت‌ها را کم کنیم، بدون اینکه اطلاعات مهم را از دسترس کاربر خارج کنیم؟
این همان مسئله‌ای است که در سؤال هفتم از مجموعه هزار سؤال مصاحبه مدیر محصول بررسی می‌کنیم.
سؤال مصاحبه و هدف مصاحبه‌کننده
سؤال: برای کاربری که از دریافت اعلان‌های بیش از حد خسته شده، چگونه یک تجربه مناسب برای کنترل اعلان‌ها طراحی می‌کنید؟
این سؤال در دسته طراحی محصول و تجربه کاربری قرار می‌گیرد و سطح دشواری آن در منبع آموزشی، سخت ارزیابی شده است.
مصاحبه‌کننده صرفا نمی‌خواهد بداند چه تنظیماتی به صفحه اعلان‌ها اضافه می‌کنیم. او به دنبال این است که ببیند آیا می‌توانیم:
- مشکل واقعی کاربر را از درخواست ظاهری او تشخیص دهیم.
- گروه مشخصی از کاربران را انتخاب کنیم و نیازشان را درک کنیم.
- میان راحتی کاربر، ارزش اطلاع‌رسانی و نیازهای کسب‌وکار تعادل برقرار کنیم.
- راهکاری ارائه دهیم که بتوان آن را با هزینه و ریسک محدود آزمایش کرد.
- معیارهای مشخصی برای ارزیابی نتیجه و بازنگری تصمیم داشته باشیم.
تفاوت یک پاسخ معمولی با پاسخ حرفه‌ای، بیشتر از آنکه در تعداد قابلیت‌های پیشنهادی باشد، در منطق تصمیم‌گیری است.
ابتدا باید بفهمیم کاربر از چه چیزی خسته شده است
وقتی کاربری می‌گوید «اعلان‌های این برنامه خیلی زیاد است»، لزوما منظورش تعداد اعلان‌ها نیست.
ممکن است مشکل اصلی یکی از این موارد باشد:
تعداد زیاد: برنامه برای هر اتفاق کوچکی یک اعلان جداگانه می‌فرستد.
بی‌ارتباط بودن: کاربر پیام‌هایی دریافت می‌کند که ارتباط چندانی با کارها یا علایقش ندارند.
زمان نامناسب: اعلان مرتبط است، اما هنگام استراحت، تمرکز یا جلسه کاری دریافت می‌شود.
اولویت‌بندی ضعیف: یک پیام تبلیغاتی و یک هشدار مهم، با شدت و شیوه یکسان نمایش داده می‌شوند.
نبود کنترل: کاربر نمی‌تواند بدون خاموش‌کردن همه اعلان‌ها، فقط موارد مزاحم را متوقف کند.
این مشکلات به راهکارهای متفاوتی نیاز دارند.
مثلا اگر مشکل بی‌ارتباط بودن پیام‌هاست، اضافه‌کردن گزینه «مزاحم نشوید» شاید فقط نشانه‌های مشکل را پنهان کند. اگر مسئله زمان ارسال است، کاهش تعداد اعلان‌ها به‌تنهایی کافی نیست.
پس پیش از طراحی باید بدانیم کاربر واقعا چه چیزی را می‌خواهد تغییر دهد.
کدام کاربران را در اولویت قرار می‌دهیم؟
یکی از اشتباه‌های رایج در مصاحبه‌های طراحی محصول، تلاش برای حل هم‌زمان مشکل همه کاربران است.
برای شروع، بهتر است گروهی را انتخاب کنیم که مشکل در آن شدیدتر و قابل مشاهده‌تر است.
در مثال فرضی اپلیکیشن مدیریت کار، می‌توانیم روی کاربران فعالی تمرکز کنیم که روزانه با چند پروژه همکاری دارند و هم‌زمان اعلان‌های مربوط به پیام‌ها، تغییر وظایف و یادآوری‌ها را دریافت می‌کنند.
این انتخاب به معنای بی‌اهمیت بودن سایر کاربران نیست. فقط کمک می‌کند مسئله را در یک موقعیت مشخص بررسی کنیم.
برای شناخت این گروه، چند سؤال مهم داریم:
شدت مشکل چقدر است؟ آیا کاربران صرفا از اعلان‌ها شکایت می‌کنند یا به دلیل مزاحمت، اعلان‌ها را کاملا غیرفعال کرده‌اند؟
مشکل چند وقت یک‌بار اتفاق می‌افتد؟ آیا در تمام روز وجود دارد یا بیشتر هنگام فعالیت گروهی و ساعات کاری رخ می‌دهد؟
کاربران اکنون چه می‌کنند؟ آیا اعلان‌ها را بی‌صدا می‌کنند، از تنظیمات سیستم‌عامل استفاده می‌کنند یا پیام‌ها را نادیده می‌گیرند؟
کدام اعلان‌ها واقعا ارزشمند هستند؟ آیا کاربر برای تمام پیام‌ها واکنش نشان می‌دهد یا فقط تعداد محدودی از آن‌ها به اقدام معنادار منجر می‌شوند؟
برای پاسخ‌دادن، به ترکیبی از مصاحبه با کاربران، مشاهده نحوه استفاده و داده‌های محصول نیاز داریم.
داده‌های رفتاری می‌توانند مشخص کنند چه نوع اعلان‌هایی ارسال می‌شوند، چند بار تکرار می‌شوند و چه اقداماتی پس از دریافتشان اتفاق می‌افتد. با این حال، این داده‌ها به‌تنهایی علت نارضایتی را توضیح نمی‌دهند.
ممکن است کاربر اعلانی را باز نکند، چون اطلاعات مورد نیازش را همان‌جا دیده است؛ نه اینکه اعلان بی‌ارزش بوده باشد.
اینجاست که گفت‌وگو با کاربر اهمیت پیدا می‌کند.
چه راهکارهایی داریم و کدام را انتخاب می‌کنیم؟
سه مسیر اصلی را می‌توان بررسی کرد.
مسیر اول: خاموش‌کردن کامل اعلان‌ها
ساده‌ترین راه، قراردادن یک کلید برای فعال یا غیرفعال کردن تمام اعلان‌هاست.
مزیت این روش، سادگی و کنترل فوری است. اما مشکلش این است که میان پیام مهم و غیرضروری تفاوتی نمی‌گذارد.
این گزینه باید در دسترس کاربر باشد، ولی به‌تنهایی راهکار مناسبی برای مدیریت خستگی ناشی از اعلان‌ها نیست.
مسیر دوم: تنظیمات بسیار جزئی برای همه اعلان‌ها
می‌توانیم برای هر رویداد، نوع پیام، پروژه یا فعالیت، یک گزینه مستقل طراحی کنیم.
این روش انعطاف زیادی دارد، اما هزینه آن افزایش پیچیدگی است.
کاربری که از اعلان‌های زیاد خسته شده، احتمالا علاقه‌ای ندارد برای حل مشکل خود، ده‌ها گزینه مختلف را بررسی کند.
تنظیمات پیشرفته می‌توانند برای کاربران حرفه‌ای مفید باشند، اما نباید تجربه اولیه همه کاربران را پیچیده کنند.
مسیر سوم: اولویت‌بندی هوشمند همراه با کنترل ساده
برای شروع، این مسیر را ترجیح می‌دهم.
در این طراحی، اعلان‌ها بر اساس ارزش، فوریت و نوع اقدام مورد انتظار دسته‌بندی می‌شوند. کاربر هم می‌تواند با چند انتخاب روشن، شیوه دریافتشان را تغییر دهد.
مثلا سه گروه داشته باشیم:
اعلان‌های نیازمند اقدام: مانند واگذاری یک کار فوری یا تغییری که به تصمیم مستقیم کاربر نیاز دارد.
اطلاع‌رسانی‌های معمولی: مانند نظرات جدید، تغییر وضعیت کارها و به‌روزرسانی‌هایی که لزوما نیازمند واکنش فوری نیستند.
پیشنهادها و پیام‌های تبلیغاتی: مانند معرفی قابلیت‌های جدید یا پیشنهادهای تجاری که دریافتشان باید بر اساس رضایت و انتخاب کاربر باشد.
این دسته‌بندی قطعی و یکسان برای همه محصولات نیست. باید با تحقیق کاربری مشخص شود چه رویدادی در هر محصول واقعا فوری است.
مزیت مسیر سوم این است که بدون حذف کامل اطلاع‌رسانی، تعداد وقفه‌های غیرضروری را کاهش می‌دهد.
البته پیچیدگی دسته‌بندی رویدادها و احتمال تشخیص اشتباه فوریت، از هزینه‌ها و ریسک‌های آن هستند.
تجربه پیشنهادی چه ویژگی‌هایی دارد؟
به‌جای طراحی یک صفحه پیچیده، تجربه کنترل اعلان‌ها را حول چند رفتار ساده می‌سازیم.
۱. تنظیمات پیش‌فرض معقول
کاربر نباید برای داشتن تجربه‌ای آرام، مجبور باشد از ابتدا تعداد زیادی گزینه را تغییر دهد.
می‌توانیم رویدادهای کم‌اهمیت را به‌صورت پیش‌فرض بدون صدای مزاحم نمایش دهیم و پیام‌های تکراری مرتبط را تجمیع کنیم.
اعلان‌های تبلیغاتی هم نباید بدون رضایت مشخص کاربر فعال شوند.
۲. کنترل مستقیم از داخل اعلان
کاربر بهتر است بتواند همان لحظه که یک اعلان مزاحم دریافت می‌کند، رفتار آینده آن را تغییر دهد.
برای مثال:
- بی‌صدا کردن اعلان‌های مشابه
- توقف موقت اعلان‌های یک پروژه
- دریافت خلاصه به‌جای اعلان جداگانه
- دسترسی سریع به تنظیمات همان دسته
تغییرات باید روشن، قابل بازگشت و تا حد امکان بدون مراحل اضافی باشند.
۳. خلاصه‌سازی اعلان‌های غیرضروری
به‌جای ارسال چندین پیام جداگانه درباره تغییرات یک پروژه، می‌توانیم آن‌ها را در یک خلاصه جمع کنیم.
زمان دریافت خلاصه بهتر است قابل انتخاب باشد.
با این حال، نباید صرفا برای کاهش تعداد اعلان‌ها، اطلاعاتی را که به اقدام فوری نیاز دارند به تأخیر بیندازیم.
۴. احترام به زمان و تمرکز کاربر
کاربر باید بتواند ساعت‌های آرامش یا تمرکز خود را مشخص کند.
اگر سیستم‌عامل قابلیت‌هایی مانند Focus یا تنظیمات زمان‌بندی اعلان‌ها دارد، محصول باید با آن‌ها سازگار باشد، نه اینکه تلاش کند محدودیت‌های انتخاب‌شده کاربر را دور بزند.
راهنمای رسمی اپل نیز بر ارسال اطلاعات ارزشمند و به‌موقع، پرهیز از اعلان‌های تکراری و استفاده درست از سطح فوریت تأکید می‌کند.
۵. شفافیت درباره علت دریافت اعلان
کاربر باید بداند چرا یک پیام را دریافت کرده است.
مثلا «چون مسئول این وظیفه هستید» اطلاعات مفیدتری از یک اعلان مبهم ارائه می‌دهد.
همچنین محتوای حساس نباید بدون توجه به تنظیمات حریم خصوصی روی صفحه قفل نمایش داده شود.
نکته فنی مهم این است که کنترل‌های داخل برنامه جایگزین تنظیمات سیستم‌عامل نیستند.
در اندروید، کانال‌های اعلان امکان کنترل دسته‌های مختلف را در تنظیمات سیستم فراهم می‌کنند و از اندروید ۱۳ به بعد، ارسال بسیاری از اعلان‌ها نیازمند مجوز کاربر است. در محصولات اپل نیز مجوز اعلان و تنظیمات Focus و زمان‌بندی سیستم باید رعایت شوند.
مثال فرضی: بازطراحی اعلان‌های یک نرم‌افزار مدیریت پروژه
فرض کنیم یک شرکت نرم‌افزاری، محصولی برای مدیریت وظایف تیمی دارد.
تیم پشتیبانی گزارش می‌دهد که تعدادی از کاربران فعال، از حجم اعلان‌ها ناراضی هستند. داده‌های محصول نیز نشان می‌دهند برخی کاربران دریافت اعلان‌ها را غیرفعال کرده‌اند.
این‌ها نشانه وجود مشکل هستند، نه اثبات علت آن.
مدیر محصول همراه طراح تجربه کاربری، با کاربران ناراضی مصاحبه می‌کند و چند الگوی تکرارشونده را بررسی می‌کند.
فرض کنیم مشخص شود کاربران معمولا نمی‌خواهند اعلان مربوط به واگذاری وظیفه مهم یا تغییر موعد نزدیک را از دست بدهند، اما لازم نیست برای هر نظر عادی یا تغییر جزئی وضعیت، یک وقفه جدید ایجاد شود.
تیم سه گزینه را مقایسه می‌کند: کاهش عمومی تعداد اعلان‌ها، ساخت صفحه تنظیمات گسترده یا ایجاد دسته‌بندی محدود با تنظیمات پیش‌فرض بهتر.
برای آزمایش اولیه، گزینه سوم انتخاب می‌شود.
نسخه آزمایشی شامل این تغییرات است:
- تجمیع نظرات متوالی مربوط به یک وظیفه
- ارسال خلاصه تغییرات غیرضروری در زمان انتخابی کاربر
- حفظ اعلان‌های نیازمند اقدام در زمان مناسب
- امکان بی‌صدا کردن سریع یک دسته یا پروژه
- نمایش تنظیمات ساده با امکان دسترسی به گزینه‌های پیشرفته
توسعه‌دهندگان مسئول سازگاری با مجوزها و کانال‌های اعلان سیستم‌عامل هستند. طراح محصول مفهوم دسته‌ها و رفتار کنترل‌ها را با کاربران آزمایش می‌کند. تیم پشتیبانی گزارش‌های سردرگمی یا از دست رفتن اعلان‌های مهم را پیگیری می‌کند.
مدیر محصول درباره ارزش این تغییرات، اولویت اجرای آن‌ها و معیار موفقیت تصمیم می‌گیرد. اگر تیم از Scrum استفاده کند، Product Owner طبق Scrum Guide مسئول بیشینه‌سازی ارزش محصول و مدیریت مؤثر Product Backlog است؛ مدیر پروژه نیز در صورت وجود این نقش، هماهنگی اجرای کار در محدوده زمان و منابع توافق‌شده را دنبال می‌کند. این مسئولیت‌ها لزوما در همه سازمان‌ها میان افراد متفاوت تقسیم نشده‌اند.
برای شروع، تغییرات روی گروه محدودی از کاربران واجد شرایط آزمایش می‌شوند. گروه مقایسه نیز تجربه قبلی را حفظ می‌کند تا بتوانیم اثر تغییر را بهتر بررسی کنیم.
این آزمایش، سناریویی فرضی است و هیچ نتیجه عددی واقعی برای آن ادعا نمی‌کنیم.
موفقیت را چطور اندازه می‌گیریم؟
کاهش تعداد اعلان‌ها به‌خودی‌خود موفقیت نیست.
ممکن است تعداد پیام‌ها نصف شود، اما کاربران خبرهای مهم را از دست بدهند. در این حالت، ظاهر مسئله بهتر شده اما ارزش محصول کاهش پیدا کرده است.
برای ارزیابی، به سه نوع معیار نیاز داریم.
معیار نتیجه: سهم رویدادهای مهمی که کاربر در بازه زمانی متناسب با فوریت آن‌ها به‌درستی پیگیری می‌کند. مخرج این معیار، تمام رویدادهای مهم واجد شرایط است؛ نه فقط اعلان‌هایی که باز شده‌اند.
معیار تشخیصی: تعداد وقفه‌های قابل پیشگیری به‌ازای هر کاربر فعال در هفته، همراه با نرخ استفاده از گزینه‌های بی‌صدا کردن، خلاصه‌سازی و تغییر تنظیمات.
معیار محافظتی: نرخ از دست رفتن یا تأخیر در رسیدگی به رویدادهای مهم، غیرفعال‌سازی کامل اعلان‌ها، شکایت کاربران و مشکلات مرتبط با حریم خصوصی یا مجوزها.
بازه مشاهده باید از قبل تعیین شود و متناسب با دفعات وقوع رویدادهای مهم باشد. اگر این رویدادها کم‌تکرار باشند، یک آزمایش کوتاه ممکن است برای نتیجه‌گیری کافی نباشد.
همچنین بهتر است نتایج را برای گروه‌های مختلف کاربران و سیستم‌عامل‌ها جداگانه بررسی کنیم.
نرخ باز شدن اعلان‌ها معیار اصلی مناسبی نیست. ممکن است کاهش این نرخ اتفاق مثبتی باشد، چون کاربر اطلاعات مورد نیازش را بدون بازکردن برنامه دریافت کرده است.
در مقابل، اگر اعلان‌های مهم دیگر به اقدام مناسب منجر نشوند، باید تصمیم را بازنگری کنیم.
اگر این سؤال را در مصاحبه از من بپرسند، چه جوابی بدهم؟
نمونه پاسخ شفاهی:
«من اول مشخص می‌کنم کاربر دقیقا از چه چیزی ناراضی است؛ تعداد اعلان‌ها، بی‌ربط بودنشان، زمان دریافت یا نداشتن کنترل روی آن‌ها.
بعد یک گروه مشخص از کاربران را انتخاب می‌کنم. مثلا کسانی که در یک نرم‌افزار مدیریت کار، روزانه اعلان‌های زیادی از چند پروژه دریافت می‌کنند.
با بررسی داده‌ها و مصاحبه، مشخص می‌کنم کدام اعلان‌ها واقعا به تصمیم یا اقدام کاربر کمک می‌کنند و کدام‌ها فقط مزاحمت ایجاد می‌کنند.
برای راهکار اولیه، به‌جای ساختن یک صفحه شلوغ با ده‌ها تنظیم، اعلان‌ها را در چند دسته قابل فهم قرار می‌دهم. اعلان‌های مهم را به‌موقع نگه می‌دارم، موارد کم‌اهمیت را خلاصه می‌کنم و امکان بی‌صدا کردن سریع یا تغییر تنظیمات را در اختیار کاربر می‌گذارم.
بعد این تجربه را روی گروه محدودی آزمایش می‌کنم. موفقیت برای من فقط کمتر شدن تعداد اعلان‌ها نیست؛ می‌خواهم ببینم وقفه‌های غیرضروری کم شده‌اند، بدون اینکه رسیدگی به کارهای مهم افت کند.
اگر کاربران همچنان ناراضی باشند یا هشدارهای مهم را از دست بدهند، دسته‌بندی و تنظیمات پیش‌فرض را بازنگری می‌کنم.»
این پاسخ، هم انتخاب مشخصی دارد، هم منطق آن را توضیح می‌دهد و هم شرایط تغییر تصمیم را روشن می‌کند.
دو سؤال پیگیری مهم مصاحبه
۱. اگر فقط دو هفته برای بررسی این مسئله فرصت داشته باشید، چه می‌کنید؟
در این شرایط، تلاش نمی‌کنم یک سیستم کامل مدیریت اعلان طراحی کنم.
ابتدا داده‌های موجود را بر اساس نوع اعلان، دفعات ارسال، وضعیت مجوز و گروه کاربران بررسی می‌کنم. هم‌زمان با تعداد محدودی از کاربران پرمصرف یا ناراضی مصاحبه می‌کنم تا علت اصلی مشخص شود.
سپس یک تغییر کوچک و قابل بازگشت انتخاب می‌کنم؛ مثلا تجمیع اعلان‌های تکراری در یک دسته مشخص یا اضافه‌کردن گزینه بی‌صدا کردن همان دسته.
قبل از اجرا، معیار موفقیت و حد قابل قبول ریسک را تعیین می‌کنم.
دو هفته ممکن است برای تشخیص اولیه و آزمایش کاربردپذیری کافی باشد، اما لزوما برای اثبات تأثیر بلندمدت کافی نیست. این محدودیت را صریح اعلام می‌کنم.
۲. چه شواهدی باعث می‌شود راهکار پیشنهادی خود را رد کنید؟
اگر مشاهده کنیم کاربران پس از دریافت خلاصه‌ها، رویدادهای مهم را دیرتر پیگیری می‌کنند، باید در شیوه دسته‌بندی یا زمان ارسال تجدیدنظر کنیم.
همچنین اگر کاربران تنظیمات ساده را درک نکنند، مرتب آن‌ها را تغییر دهند یا برای رسیدن به نتیجه مطلوب همچنان همه اعلان‌ها را خاموش کنند، فرض ما درباره سادگی راهکار زیر سؤال می‌رود.
حتی ممکن است تحقیق نشان دهد مشکل اصلی تعداد اعلان‌ها نیست، بلکه ارسال پیام‌های بی‌ربط است. در این صورت، بهتر است پیش از توسعه کنترل‌های بیشتر، منطق تولید و هدف‌گیری اعلان‌ها را اصلاح کنیم.
پاسخ حرفه‌ای یعنی بتوانیم از یک تصمیم دفاع کنیم، بدون اینکه به آن وابسته شویم.
چه پاسخ‌هایی در مصاحبه ضعیف محسوب می‌شوند؟
«یک دکمه خاموش‌کردن اعلان‌ها اضافه می‌کنم.»
این قابلیت مفید است، اما تفاوت میان اطلاعات ضروری و مزاحمت را حل نمی‌کند.
«همه نوع اعلان را قابل تنظیم می‌کنم.»
این پاسخ بدون شناخت کاربر، پیچیدگی تصمیم‌گیری را به او منتقل می‌کند.
«با هوش مصنوعی تشخیص می‌دهیم چه چیزی مهم است.»
تا زمانی که داده معتبر، روش تشخیص، خطای قابل قبول و امکان اصلاح تصمیم مشخص نباشد، این پیشنهاد بیشتر یک وعده فنی است تا راهکار محصولی.
«نرخ کلیک روی اعلان‌ها را افزایش می‌دهم.»
افزایش تعامل با اعلان‌ها لزوما به معنای بهبود تجربه کاربر نیست. حتی ممکن است هدف کاهش مزاحمت را تضعیف کند.
«این قابلیت برای همه کاربران خوب است.»
کاربری که منتظر هشدار فوری عملیاتی است، نیاز متفاوتی با کاربری دارد که فقط می‌خواهد خلاصه فعالیت‌های روزانه را ببیند.
در همه این پاسخ‌ها یک ضعف مشترک وجود دارد: راهکار پیش از شناخت دقیق مسئله انتخاب شده است.
جمع‌بندی
برای کاربری که از اعلان‌های زیاد خسته شده، بهترین نقطه شروع، اضافه‌کردن تنظیمات بیشتر یا خاموش‌کردن همه اعلان‌ها نیست. ابتدا باید مشخص کنیم کدام اعلان‌ها ارزش ایجاد می‌کنند، کدام‌ها مزاحم هستند و کاربر در چه موقعیتی به چه نوع اطلاع‌رسانی نیاز دارد.
پیشنهاد من، ترکیبی از اولویت‌بندی بر اساس نیاز واقعی، تنظیمات پیش‌فرض مناسب، خلاصه‌سازی پیام‌های کم‌اهمیت و کنترل ساده و قابل بازگشت توسط کاربر است. این انتخاب باید با داده و تحقیق آزمایش شود و اگر باعث تأخیر در رسیدگی به موارد مهم یا افزایش سردرگمی شود، تغییر کند.
در مدیریت محصول، طراحی تجربه بهتر همیشه به معنای اضافه‌کردن قابلیت‌های جدید نیست. گاهی ارزشمندترین تصمیم این است که مشخص کنیم محصول چه زمانی نباید مزاحم کاربر شود.
منابع
۱. Apple Human Interface Guidelines — Notifications
۲. Apple Human Interface Guidelines — Managing Notifications
۳. Android Developers — Create and Manage Notification Channels
۴. Android Developers — Notification Runtime Permission
۵. Reforge — Product Manager Interview Questions
منبع پنجم برای شناخت ساختار و ارزیابی مصاحبه‌های مدیریت محصول است.
سؤال روز هفتم در فایل مرجع این مجموعه به‌عنوان تمرین طراحی محصول ارائه شده و نباید آن را سؤال رسمی تأییدشده یک شرکت خاص دانست.
