فرض کنید پیام مهمی برای یکی از اعضای خانواده می‌فرستید، اما اینترنت درست در لحظه ارسال قطع می‌شود. برنامه پیام‌رسان شما پیام را ظاهرا ارسال کرده، ولی معلوم نیست به مقصد رسیده یا نه. حالا اگر این وضعیت هر روز تکرار شود، آیا اضافه کردن چند قابلیت جدید مشکل شما را حل می‌کند؟
این سناریو ما را به یکی از چالش‌های جدی طراحی محصول می‌رساند: چطور محصولی طراحی کنیم که فقط برای کاربران ایده‌آل کار نکند؟
سوال مصاحبه چیست و چه چیزی را ارزیابی می‌کند؟
سوال اول از مجموعه هزار سوال مصاحبه مدیر محصول این است:
«محصولی را که هر روز استفاده می‌کنید، برای فردی با دسترسی محدود طراحی کنید.»
در نگاه اول، سوال بسیار باز است. نه محصول مشخص شده، نه گروه کاربری و نه نوع محدودیت.
همین ابهام، بخش مهمی از آزمون است.
مصاحبه‌کننده می‌خواهد ببیند آیا می‌توانید قبل از پیشنهاد قابلیت، مسئله را تعریف کنید، گروهی مشخص از کاربران را انتخاب کنید و تصمیمی بگیرید که بتوان نتیجه آن را اندازه گرفت.
پاسخ قوی قرار نیست فهرستی از امکانات جذاب باشد. باید نشان دهد چرا یک مشکل را انتخاب کرده‌اید، چه گزینه‌هایی را کنار گذاشته‌اید و تحت چه شرایطی حاضر می‌شوید تصمیم خود را تغییر دهید.
قدم اول: دسترسی محدود یعنی چه؟
یکی از اشتباهات رایج این است که «دسترسی محدود» را بلافاصله معادل معلولیت یا اینترنت ضعیف بدانیم.
در حالی که این محدودیت می‌تواند شکل‌های متفاوتی داشته باشد:
- محدودیت فنی: اینترنت ناپایدار، گوشی قدیمی، حافظه کم یا باتری ضعیف.
- محدودیت جسمی یا حسی: مشکلات بینایی، شنوایی، حرکت یا کنترل دقیق دست.
- محدودیت اقتصادی: هزینه بالای اینترنت، دستگاه یا اشتراک.
- محدودیت مهارتی: آشنایی کم با فناوری یا دشواری در فهم زبان رابط کاربری.
- محدودیت موقعیتی: استفاده از محصول در محیط شلوغ، هنگام حرکت یا زمانی که دسترسی کاربر به دستگاه محدود است.
این گروه‌ها لزوما راه‌حل یکسانی نمی‌خواهند.
مثلا بزرگ‌تر کردن دکمه‌ها می‌تواند به فردی با محدودیت حرکتی کمک کند، اما مشکل کاربری را که هنگام ارسال پیام اینترنتش قطع می‌شود حل نمی‌کند.
پس اولین تصمیم مدیر محصول، انتخاب قابلیت نیست؛ انتخاب مسئله‌ای است که می‌خواهد حل کند.
در مصاحبه می‌توانیم ابتدا بپرسیم منظور از دسترسی محدود چیست. اگر مصاحبه‌کننده تعریف مشخصی نداشت، بهتر است فرض خودمان را شفاف بیان کنیم و ادامه دهیم.
قدم دوم: یک محصول روزمره و یک گروه کاربری مشخص انتخاب کنیم
برای این تمرین، یک پیام‌رسان موبایلی را انتخاب می‌کنیم.
فرض می‌کنیم گروه هدف، افرادی هستند که از گوشی‌های اقتصادی استفاده می‌کنند و در طول روز با قطعی یا ناپایداری اینترنت روبه‌رو می‌شوند.
این انتخاب به معنای مهم‌تر بودن این کاربران نسبت به گروه‌های دیگر نیست. فقط می‌خواهیم دامنه مسئله آن‌قدر مشخص باشد که بتوانیم درباره آن تصمیم بگیریم.
حالا باید بفهمیم کاربر واقعا چه کاری می‌خواهد انجام دهد.
آیا هدفش استفاده از تماس تصویری است؟ ارسال فایل؟ حضور در گروه‌های بزرگ؟
برای شروع، یکی از ابتدایی‌ترین کارهای یک پیام‌رسان را انتخاب می‌کنیم:
ارسال یک پیام متنی کوتاه و اطمینان از وضعیت واقعی آن.
در این مرحله، مسئله را می‌توان این‌طور تعریف کرد:
«کاربرانی که اتصال اینترنت پایداری ندارند، هنگام ارسال پیام نمی‌توانند همیشه تشخیص دهند پیامشان ذخیره شده، در انتظار ارسال است یا واقعا به مقصد رسیده است.»
اما این هنوز یک فرض است، نه یک یافته تحقیقاتی.
برای اعتبارسنجی آن باید با کاربران گفت‌وگو کنیم، رفتار واقعی آن‌ها را ببینیم و بررسی کنیم آیا همین مشکل از نظر شدت و تکرار، ارزش حل کردن دارد یا نه.
قدم سوم: نیاز واقعی را از درخواست قابلیت جدا کنیم
فرض کنید کاربران بگویند: «می‌خواهیم پیام‌رسان بدون اینترنت کار کند.»
این جمله می‌تواند ما را به سمت ساخت یک پیام‌رسان کاملا آفلاین ببرد، اما شاید چنین راه‌حلی اصلا لازم نباشد.
باید چند سوال دقیق‌تر مطرح کنیم:
- کاربر معمولا در چه مرحله‌ای ارتباطش را از دست می‌دهد؟
- مشکل اصلی، ناتوانی در نوشتن پیام است یا نامشخص بودن وضعیت ارسال؟
- آیا کاربر پیام را چند بار می‌فرستد چون مطمئن نیست دفعه اول ارسال شده است؟
- امروز برای حل مشکل چه کاری انجام می‌دهد؟
- در چه موقعیت‌هایی تاخیر قابل قبول است و در چه موقعیت‌هایی نیست؟
اینجا مشاهده رفتار اهمیت زیادی دارد.
اگر کاربران پس از قطع اینترنت چند بار دکمه ارسال را بزنند، مشکل ممکن است بیشتر از اینکه به سرعت اینترنت مربوط باشد، به ابهام در بازخورد محصول مربوط باشد.
از طرف دیگر، اگر پیام‌ها به دلیل اشکال فنی پس از اتصال مجدد از بین بروند، صرفا تغییر متن یا رنگ وضعیت ارسال کافی نیست.
یک مسئله ظاهرا مشابه می‌تواند به دو تصمیم محصولی کاملا متفاوت منجر شود.
قدم چهارم: راه‌حل‌ها را مقایسه کنیم
برای این گروه کاربری، دست‌کم سه مسیر قابل بررسی داریم.
گزینه اول: ساخت نسخه جداگانه و سبک پیام‌رسان
می‌توانیم برنامه‌ای با مصرف کمتر اینترنت، امکانات محدودتر و رابط کاربری ساده‌تر ارائه کنیم.
مزیت آن، امکان بهینه‌سازی گسترده برای دستگاه‌های ضعیف و ارتباط محدود است.
اما نگهداری دو نسخه می‌تواند هزینه توسعه و آزمایش را افزایش دهد و تجربه کاربران را بین دو محصول متفاوت تقسیم کند.
اگر هنوز مطمئن نیستیم نیاز کاربران چقدر گسترده است، چنین سرمایه‌گذاری‌ای زودهنگام خواهد بود.
گزینه دوم: اصلاح مسیر اصلی ارسال پیام
در این راهکار، به جای طراحی یک محصول تازه، همان تجربه اصلی پیام‌رسان را قابل‌اعتمادتر می‌کنیم.
برای مثال:
- پیام نوشته‌شده ابتدا به شکل امن روی دستگاه ذخیره شود.
- اگر ارتباط قطع بود، وضعیت «در انتظار ارسال» به‌وضوح نمایش داده شود.
- با بازگشت اتصال، برنامه برای ارسال دوباره تلاش کند.
- وضعیت‌های «در انتظار ارسال»، «ارسال‌شده به سرور»، «تحویل‌شده» و «ناموفق» با یکدیگر اشتباه گرفته نشوند.
- مصرف داده با اولویت دادن به پیام متنی و محدود کردن دریافت خودکار فایل‌های حجیم کاهش پیدا کند.
این تصمیم با اصول طراحی Offline-first هم سازگار است؛ رویکردی که در مستندات رسمی Android توضیح داده شده و در آن بخشی از عملکرد ضروری محصول بدون اتصال دائمی به اینترنت در دسترس می‌ماند.
البته نگهداری محلی پیام و ارسال مجدد باید از نظر امنیت، محرمانگی، جلوگیری از ارسال تکراری و مدیریت خطا هم طراحی شود.
گزینه سوم: ارسال پیام از مسیر جایگزین مانند SMS
ممکن است پیشنهاد کنیم وقتی اینترنت قطع شد، پیام از طریق پیامک ارسال شود.
این راهکار در بعضی شرایط ارزش بررسی دارد، اما بدون رضایت کاربر و بررسی هزینه، امنیت و محدودیت‌های اجرایی انتخاب مناسبی نیست.
به‌خصوص نباید چنین تصور شود که یک پیام‌رسان عادی می‌تواند ارتباط ضروری یا اضطراری را در هر شرایطی تضمین کند.
کدام را انتخاب کنیم؟
با فرض اینکه مشکل اصلی کاربران، قطع ارتباط و نامشخص بودن وضعیت پیام است، گزینه دوم انتخاب منطقی‌تری برای شروع محسوب می‌شود.
چون مسئله محدودتری را هدف می‌گیرد، در محصول فعلی قابل آزمایش است و پیش از سرمایه‌گذاری روی نسخه‌ای جداگانه، اطلاعات بیشتری به ما می‌دهد.
با این حال، اگر تحقیق نشان دهد مشکل اصلی به توان پردازشی دستگاه و هزینه مصرف اینترنت مربوط است، اولویت می‌تواند به سمت نسخه سبک‌تر تغییر کند.
یک سناریوی فرضی در محصول نرم‌افزاری
فرض کنید تیم محصول یک پیام‌رسان، به‌صورت فرضی، متوجه شده بخشی از کاربران در مناطق دارای اینترنت ناپایدار چند بار برای ارسال یک پیام تلاش می‌کنند.
هنوز نمی‌دانیم علت اصلی چیست.
ممکن است پیام به مقصد نرسد. ممکن است پیام رسیده باشد، اما وضعیت آن به‌موقع تغییر نکند. حتی ممکن است کاربر معنای علامت‌های وضعیت را متوجه نشود.
تیم محصول با همکاری طراح تجربه کاربری، توسعه‌دهندگان موبایل و بک‌اند و تیم پشتیبانی، سه منبع اطلاعاتی را بررسی می‌کند: گزارش‌های خطا، مشاهده انجام وظیفه توسط کاربران و گفت‌وگو درباره تجربه واقعی آن‌ها.
سپس یک نسخه آزمایشی محدود طراحی می‌شود که پیام را هنگام قطع اینترنت حفظ می‌کند و وضعیت آن را واضح‌تر نمایش می‌دهد.
در آزمایش، اتصال اینترنت به‌صورت کنترل‌شده قطع و دوباره برقرار می‌شود.
کاربر باید بتواند یک پیام کوتاه بنویسد، وضعیت آن را بفهمد و پس از بازگشت اینترنت، نتیجه ارسال را بررسی کند.
اینجا صرفا ارسال خودکار پیام کافی نیست. اگر کاربر همچنان نداند چه اتفاقی افتاده، بخشی از مسئله حل‌نشده باقی مانده است.
نکته دیگر این است که بازخورد محصول نباید فقط به رنگ یا یک علامت مبهم وابسته باشد. برای کاربرانی که از فناوری‌های کمکی استفاده می‌کنند، وضعیت‌های مهم باید قابل تشخیص باشند. دستورالعمل WCAG 2.2 نیز برای پیام‌های وضعیت در محتوای وب، پشتیبانی از اعلام آن‌ها به فناوری‌های کمکی را توضیح می‌دهد.
این مثال یک سناریوی آموزشی فرضی است، نه گزارشی از یک شرکت واقعی.
قدم پنجم: موفقیت را چطور اندازه بگیریم؟
یکی از خطاهای رایج این است که موفقیت را فقط با تعداد کاربران فعال یا تعداد پیام‌های ارسال‌شده بسنجیم.
این معیارها می‌توانند مفید باشند، اما به‌تنهایی نمی‌گویند تجربه کاربرانی که اینترنت ناپایدار دارند بهتر شده یا نه.
در این مسئله باید سه سطح اندازه‌گیری داشته باشیم.
معیار نتیجه (Outcome Metric)
درصد تلاش‌های ارسال پیام در گروه هدف که پس از بازگشت اتصال، در بازه زمانی تعیین‌شده با موفقیت به سرور ارسال می‌شوند و وضعیت درست و قابل‌فهمی به کاربر نشان می‌دهند.
مخرج این معیار باید همه تلاش‌های واجد شرایط ارسال در گروه آزمایش باشد، نه فقط پیام‌هایی که از ابتدا موفق بوده‌اند.
زمان سنجش را پیش از آزمایش تعیین می‌کنیم. مثلا می‌توان یک پنجره آزمایشی ۲۴ساعته پس از بازگشت اتصال در نظر گرفت؛ این عدد یک فرض طراحی آزمایش است، نه استاندارد عمومی.
معیارهای تشخیصی (Diagnostic Metrics)
نرخ تلاش مجدد دستی، مدت ماندن پیام در صف ارسال، تعداد خطاهای همگام‌سازی و میزان درک صحیح وضعیت پیام در آزمون کاربردپذیری.
این معیارها کمک می‌کنند بفهمیم بهبود یا افت نتیجه از کجا آمده است.
معیارهای محافظ (Guardrail Metrics)
نرخ ارسال تکراری، مصرف اینترنت و باتری، از دست رفتن پیام، خطاهای امنیتی و افت کیفیت تجربه کاربران دارای اینترنت پایدار.
برای مثال، افزایش تعداد پیام‌های ثبت‌شده لزوما موفقیت نیست؛ ممکن است بخشی از آن ناشی از ارسال تکراری باشد.
نکته مهم‌تر اینکه «ارسال به سرور» با «تحویل به گیرنده» یکی نیست. محصول نباید وضعیت موفقیت را زودتر از تایید واقعی اعلام کند.
اگر فقط دو هفته فرصت داشته باشیم چه کنیم؟
این یکی از سوالات تکمیلی همان مصاحبه است.
در چنین شرایطی، هدف ساخت محصول کامل نیست؛ هدف کاهش عدم‌قطعیت درباره مسئله و راه‌حل است.
هفته اول: گروه کاربری را مشخص می‌کنیم، چند گفت‌وگوی هدفمند و آزمون مشاهده‌ای انجام می‌دهیم، گزارش‌های فنی مرتبط را بررسی می‌کنیم و یک نمونه اولیه از وضعیت‌های جدید پیام می‌سازیم.
هفته دوم: نمونه را با کاربران گروه هدف، در شرایط اتصال ناپایدار آزمایش می‌کنیم. هم درک وضعیت پیام را می‌سنجیم و هم امکان فنی ذخیره و ارسال مجدد را بررسی می‌کنیم.
در پایان این دو هفته باید بتوانیم تصمیم بگیریم آیا مسئله به‌اندازه کافی واقعی و مهم است که توسعه ادامه پیدا کند، یا به تحقیق و تغییر مسیر نیاز داریم.
چه شواهدی باعث می‌شود راه‌حل خود را رد کنیم؟
این دومین سوال تکمیلی منبع است و اهمیت زیادی دارد.
یک مدیر محصول خوب نباید صرفا بتواند تصمیمش را توجیه کند؛ باید بداند چه شواهدی آن را بی‌اعتبار می‌کند.
مثلا اگر مشاهده کنیم کاربران وضعیت پیام را به‌خوبی متوجه می‌شوند، اما مشکل اصلی آن‌ها محدودیت حافظه و بسته شدن مداوم برنامه است، راهکار فعلی کافی نیست.
اگر ارسال خودکار باعث پیام‌های تکراری یا از دست رفتن داده شود، نمی‌توانیم بهبود ظاهری تجربه را موفقیت بدانیم.
یا اگر تحقیق نشان دهد بخش عمده کاربران به دلیل هزینه داده اصلا نمی‌توانند وارد برنامه شوند، اصلاح وضعیت ارسال پیام اولویت نخست نخواهد بود.
در هر سه حالت، باید فرض اولیه را بازبینی کنیم.
پاسخ پیشنهادی در مصاحبه
اگر بخواهیم تحلیل را به یک پاسخ طبیعی و قابل ارائه در جلسه مصاحبه تبدیل کنیم، می‌توانیم این‌طور بگوییم:
«اول مشخص می‌کنم منظور از دسترسی محدود چیه؛ چون ممکنه درباره اینترنت ضعیف، محدودیت جسمی یا دستگاه قدیمی صحبت کنیم و هرکدوم مسئله متفاوتی داشته باشن.
برای ادامه فرض می‌کنم می‌خوایم یک پیام‌رسان روزمره رو برای کاربرانی بهتر کنیم که اینترنت ناپایداری دارن.
به جای اینکه از اول دنبال ساخت یک نسخه جداگانه برم، بررسی می‌کنم کدوم کار اصلی کاربر مختل می‌شه. فرض اولیه من اینه که ارسال پیام کوتاه و اطمینان از وضعیت واقعی اون مشکل مهمیه.
با مشاهده رفتار کاربران و بررسی خطاهای محصول، این فرض رو می‌سنجم. اگر تایید شد، اول تجربه ذخیره امن پیام، ارسال مجدد پس از اتصال و نمایش واضح وضعیت رو آزمایش می‌کنم.
موفقیت رو با میزان انجام موفق این کار و درک درست وضعیت پیام می‌سنجم؛ در عین حال مراقب ارسال تکراری، مصرف داده و مشکلات امنیتی هستم.
اگر شواهد نشون بدن مسئله اصلی چیز دیگه‌ایه، مثلا هزینه اینترنت یا محدودیت سخت‌افزاری، اولویت راه‌حل رو تغییر می‌دم. هدفم ساختن امکانات بیشتر نیست؛ می‌خوام یک نیاز واقعی رو با کمترین هزینه یادگیری و ریسک ممکن حل کنم.»
این پاسخ نشان می‌دهد داوطلب فقط ایده‌پردازی نمی‌کند؛ از تعریف مسئله تا انتخاب راه‌حل، آزمایش و بازنگری را به هم متصل می‌کند.
پاسخ‌های ضعیف چه ویژگی‌هایی دارند؟
«یک نسخه ساده‌تر برای همه می‌سازم.»
مشکل این پاسخ آن است که گروه هدف و نوع محدودیت را مشخص نمی‌کند. ساده‌تر شدن رابط کاربری لزوما پاسخ مناسبی به ناپایداری اینترنت نیست.
«تمام قابلیت‌ها را آفلاین می‌کنم.»
این پاسخ بدون توجه به امکان فنی، هزینه و محدودیت‌های عملکرد آفلاین ارائه شده است. بعضی اقدامات ذاتا به تایید سرور یا ارتباط با طرف مقابل نیاز دارند.
«با افزایش تعداد کاربران فعال می‌فهمیم موفق بوده‌ایم.»
این معیار به‌تنهایی ارتباط مستقیمی با مسئله انتخاب‌شده ندارد. ممکن است استفاده از محصول بیشتر شود، اما کاربران هدف همچنان نتوانند پیامشان را با اطمینان ارسال کنند.
«این بهترین راه‌حل است.»
وقتی هنوز تحقیق و آزمایش انجام نشده، قطعیت بیش از حد نشانه ضعف استدلال است. پاسخ حرفه‌ای باید فرض‌ها، محدودیت‌ها و شواهد لازم برای تغییر تصمیم را روشن کند.
جمع‌بندی
طراحی محصول برای کاربران با دسترسی محدود، قبل از هر چیز تمرینی برای شناخت مسئله و اولویت‌بندی است. نمی‌توانیم همه محدودیت‌ها را با یک راه‌حل برطرف کنیم. باید گروه کاربری و وظیفه اصلی او را مشخص کنیم، نیاز واقعی را بشناسیم و چند مسیر را با توجه به ارزش، هزینه و ریسک مقایسه کنیم.
در مثال پیام‌رسان، با فرض اینکه مشکل اصلی اتصال ناپایدار و نامشخص بودن وضعیت ارسال است، بهبود مسیر ارسال پیام انتخاب مناسبی برای شروع خواهد بود؛ نه لزوما ساخت یک پیام‌رسان جدید. اگر شواهد نشان دهند مشکل اصلی در جای دیگری است، تصمیم هم باید تغییر کند.
مدیر محصول خوب کسی نیست که برای همه کاربران یک پاسخ آماده داشته باشد؛ کسی است که بداند برای کدام کاربر، کدام مسئله را و با چه شواهدی باید حل کند.
منابع
- Reforge — 7 Product Manager Interview Questions From Top Product Leaders — منبعی برای شناخت منطق ارزیابی و فرض‌سازی در پرسش‌های سناریومحور؛ نه تایید اینکه متن دقیق این سوال از مصاحبه رسمی خاصی آمده است.
- Android Developers — Build an Offline-first App — راهنمای رسمی معماری داده، ذخیره محلی، صف عملیات و همگام‌سازی در محصولات آفلاین‌محور.
- W3C — WCAG 2.2: Understanding Status Messages — توضیح الزامات دسترس‌پذیری پیام‌های وضعیت در محتوای وب.
