تصور کنید کاربری بعد از یک ماه وارد اپلیکیشن بانک می‌شود تا موجودی حسابش را بررسی کند و یک قبض را بپردازد. اما به‌جای اینکه سریع به کارش برسد، با صفحه‌ای پر از تبلیغات، نمودارهای مالی، پیشنهادهای تسهیلات و قابلیت‌هایی روبه‌رو می‌شود که شاید هیچ‌وقت از آن‌ها استفاده نکند.
حالا یک سوال مهم پیش می‌آید: آیا باید صفحه اصلی را برای این کاربر ساده‌تر کنیم یا ممکن است با حذف اطلاعات و امکانات، تجربه او را بدتر کنیم؟
این همان تصمیمی است که یک مدیر محصول باید بتواند با شناخت رفتار کاربران، تحلیل داده‌ها و درک محدودیت‌های کسب‌وکار بگیرد.
سوال مصاحبه چیست و چه چیزی را می‌سنجد؟
چگونه صفحه اصلی یک اپلیکیشن بانکی را برای کاربری طراحی می‌کنید که فقط ماهی یک‌بار وارد آن می‌شود؟
این سوال در دسته طراحی محصول و تجربه کاربری (Product Design & UX) قرار می‌گیرد.
مصاحبه‌کننده صرفا به‌دنبال یک طرح زیبا یا فهرستی از قابلیت‌های پیشنهادی نیست. او می‌خواهد ببیند آیا می‌توانیم:
- مسئله واقعی کاربر را از ظاهر سوال تشخیص دهیم.
- بدون پیش‌داوری درباره کاربران کم‌فعالیت، نیاز آن‌ها را بررسی کنیم.
- بین سادگی، دسترسی سریع، امنیت و اهداف تجاری بانک تعادل برقرار کنیم.
- چند راهکار قابل اجرا را مقایسه و یکی را با دلیل انتخاب کنیم.
- موفقیت تصمیم را با رفتار واقعی کاربران بسنجیم.
- مشخص کنیم چه شواهدی می‌تواند تصمیم اولیه ما را تغییر دهد.
در واقع، این سوال بیشتر از آنکه مهارت طراحی رابط کاربری را بسنجد، قدرت تصمیم‌گیری محصولی را ارزیابی می‌کند.
قدم اول: چرا کاربر فقط ماهی یک‌بار وارد می‌شود؟
یکی از اشتباهات رایج این است که تعداد ورود به اپلیکیشن را مستقیما معادل رضایت یا نارضایتی کاربر بدانیم.
اما ورود ماهانه لزوما نشانه مشکل نیست.
ممکن است کاربری فقط زمان دریافت حقوق، پرداخت اقساط یا بررسی گردش حساب به اپلیکیشن نیاز داشته باشد. برای چنین فردی، استفاده ماهانه می‌تواند دقیقا همان رفتاری باشد که انتظار داریم.
در مقابل، ممکن است کاربر دیگری به‌دلیل پیچیدگی اپلیکیشن، فراموش‌کردن مسیر خدمات یا تجربه ناموفق قبلی کمتر وارد آن شود.
این دو کاربر رفتار ظاهرا مشابهی دارند، اما به راهکارهای متفاوتی نیاز دارند.
بنابراین، پیش از طراحی باید چند سوال را روشن کنیم:
- کاربران ماهانه معمولا برای انجام چه کاری وارد اپلیکیشن می‌شوند؟
- آیا کار موردنظرشان را با موفقیت انجام می‌دهند؟
- آیا فاصله میان ورودها انتخاب خودشان است یا نتیجه اصطکاک در تجربه کاربری؟
- کدام قابلیت‌ها برایشان ضروری است و کدام بخش‌ها فقط صفحه را شلوغ می‌کند؟
- آیا مسئله اصلی پیدا کردن خدمات است، فهمیدن وضعیت حساب یا نگرانی درباره امنیت؟
برای پاسخ، می‌توانیم داده‌های رفتاری، مسیرهای پیمایش، خطاهای کاربران، تماس‌های پشتیبانی و مصاحبه‌های کوتاه را کنار هم بررسی کنیم.
اصل مهم این است که کم‌استفاده‌بودن را پیش از شناخت علت، مسئله فرض نکنیم.
قدم دوم: یک گروه مشخص را انتخاب کنیم
طراحی یک صفحه اصلی برای تمام کسانی که ماهی یک‌بار وارد اپلیکیشن می‌شوند، انتخاب دقیقی نیست.
مثلا می‌توانیم سه گروه را در نظر بگیریم:
- افرادی که برای بررسی موجودی و تراکنش‌ها وارد می‌شوند.
- افرادی که پرداخت‌های دوره‌ای مانند قبض، قسط یا انتقال وجه دارند.
- افرادی که به‌دلیل پیچیدگی یا نگرانی از اشتباه، کمتر از خدمات دیجیتال استفاده می‌کنند.
برای هر گروه باید شدت نیاز، تکرار وظیفه، مشکلات فعلی و راه‌حل جایگزین را بررسی کنیم.
فرض کنیم بررسی اولیه نشان دهد گروه دوم، یعنی کاربران دارای پرداخت‌های ماهانه، مسئله مشخص‌تر و قابل‌آزمایش‌تری دارند.
در این صورت، مسئله طراحی را می‌توان این‌طور تعریف کرد:
چطور کمک کنیم کاربران دارای پرداخت‌های ماهانه، پس از ورود به اپلیکیشن، بدون جست‌وجوی طولانی و بدون افزایش احتمال خطا، کار اصلی خود را انجام دهند؟
این تعریف از «طراحی صفحه‌ای ساده‌تر» مفیدتر است، چون مشخص می‌کند برای چه کسی، چه رفتاری و با چه محدودیتی می‌خواهیم تجربه را بهتر کنیم.
قدم سوم: صفحه اصلی باید به چه سوال‌هایی پاسخ دهد؟
برای کاربری که مدت زیادی از آخرین ورودش گذشته، صفحه اصلی بهتر است سه نیاز را پوشش دهد:
۱. وضعیت حساب من الان چگونه است؟
کاربر ممکن است بخواهد بدون باز کردن چند صفحه، بداند چه اتفاقی در حسابش افتاده است.
در نتیجه، نمایش اطلاعاتی مانند موجودی حساب، تراکنش‌های اخیر و تغییرات مهم از آخرین مراجعه می‌تواند مفید باشد.
اما این بخش باید چند ویژگی داشته باشد:
- آخرین زمان به‌روزرسانی اطلاعات روشن باشد.
- اطلاعات قدیمی به‌عنوان وضعیت فعلی نمایش داده نشود.
- امکان پنهان‌کردن موجودی و اطلاعات حساس وجود داشته باشد.
- پیام‌های ضروری از پیشنهادهای تبلیغاتی قابل‌تشخیص باشند.
نمایش خلاصه تغییرات از آخرین مراجعه می‌تواند به کاربر کمک کند، اما فقط زمانی که داده‌ها کامل و قابل‌اعتماد باشند.
۲. چطور کار اصلی خودم را انجام دهم؟
کاربری که هر روز از اپلیکیشن استفاده می‌کند، احتمالا مسیر انجام کارهایش را بهتر به خاطر می‌سپارد.
اما کاربر ماهانه ممکن است هر بار مجبور شود همان مسیر را دوباره پیدا کند.
در طراحی تجربه کاربری، اصل «تشخیص به‌جای یادآوری» (Recognition Rather Than Recall) به همین مسئله اشاره دارد. طبق توضیح Nielsen Norman Group، مشاهده گزینه‌های قابل‌شناسایی معمولا نسبت به به‌یادآوردن آن‌ها بدون راهنما، بار ذهنی کمتری ایجاد می‌کند.
بنابراین بهتر است اقدامات اصلی با عنوان‌های روشن و قابل‌فهم در دسترس باشند؛ مانند:
- انتقال وجه
- پرداخت قبض
- مشاهده گردش حساب
- پرداخت اقساط
البته این فهرست نباید صرفا بر اساس حدس ما انتخاب شود. ترتیب و اهمیت گزینه‌ها باید از پژوهش کاربران و داده‌های واقعی به دست بیاید.
نکته دیگر این است که دسترسی سریع به یک عملیات، نباید به معنی حذف مراحل ضروری تایید آن باشد.
۳. آیا موضوع مهمی هست که باید به آن توجه کنم؟
کاربری که ماهی یک‌بار وارد می‌شود، ممکن است از یک تغییر مهم در حساب یا خدمات بانک مطلع نباشد.
برای چنین فردی، اطلاع‌رسانی درباره یک اقدام ضروری می‌تواند ارزشمندتر از نمایش چند پیشنهاد تجاری باشد.
مثلا اگر قسطی نزدیک به سررسید باشد یا وضعیت یک درخواست بانکی تغییر کرده باشد، نمایش آن در جای مناسب می‌تواند مفید باشد.
البته این اطلاعات باید دقیق، مرتبط و قابل اقدام باشند. یک پیام قدیمی یا هشدار مبهم ممکن است به‌جای کمک، باعث نگرانی یا تصمیم اشتباه شود.
قدم چهارم: کدام رویکرد طراحی مناسب‌تر است؟
در این مرحله سه گزینه اصلی داریم.
رویکرد اول: یک صفحه ثابت برای همه کاربران
تمام کاربران صفحه‌ای یکسان با مجموعه مشخصی از خدمات می‌بینند.
مزیت این روش، سادگی توسعه، قابلیت پیش‌بینی و کاهش پیچیدگی نگهداری است.
اما ممکن است کاربران ماهانه همچنان برای رسیدن به کار اصلی خود مجبور باشند گزینه‌های نامرتبط زیادی را بررسی کنند.
رویکرد دوم: شخصی‌سازی کامل صفحه اصلی
در این روش، صفحه بر اساس تاریخچه استفاده، رفتار و احتمالا نیازهای پیش‌بینی‌شده هر کاربر تغییر می‌کند.
این رویکرد در صورت وجود داده و زیرساخت مناسب می‌تواند مفید باشد، اما هزینه و ریسک بیشتری دارد.
برای کاربری که ماهی یک‌بار وارد می‌شود، داده رفتاری ممکن است آن‌قدر محدود باشد که سیستم نتواند نیاز بعدی او را با اطمینان پیش‌بینی کند.
از طرفی، اگر جای گزینه‌ها مدام تغییر کند، کاربری که به‌ندرت وارد اپلیکیشن می‌شود ممکن است هر بار با محیطی ناآشنا روبه‌رو شود.
رویکرد سوم: ساختار ثابت با راهنمایی متناسب با نیاز
برای شروع، این رویکرد را انتخاب می‌کنم.
صفحه اصلی یک ساختار پایدار و قابل‌پیش‌بینی دارد؛ موجودی و وضعیت حساب، اقدامات اصلی و مسیر دسترسی به سایر خدمات همیشه در جای مشخصی قرار می‌گیرند.
در کنار آن، می‌توان یک بخش کوچک و کنترل‌شده برای اطلاعات مرتبط با مراجعه ماهانه در نظر گرفت.
مثلا خلاصه تغییرات حساب از آخرین مراجعه یا دسترسی به یک پرداخت دوره‌ای که کاربر قبلا انجام داده است.
تفاوت این روش با شخصی‌سازی کامل این است که اطلاعات مرتبط تغییر می‌کنند، نه اینکه ساختار صفحه هر بار از نو چیده شود.
این انتخاب هم ریسک یادگیری مجدد رابط کاربری را کاهش می‌دهد و هم اجازه می‌دهد ارزش قابلیت‌های تکمیلی را جداگانه آزمایش کنیم.
یک محدودیت مهم: سادگی نباید امنیت را قربانی کند
در یک اپلیکیشن بانکی، کاهش تعداد کلیک‌ها همیشه به معنی بهترشدن تجربه کاربری نیست.
فرض کنیم کاربری بتواند با یک لمس وارد صفحه انتقال وجه شود. این تغییر احتمالا مفید است، اما نباید کنترل هویت، تایید مقصد یا سایر مراحل ضروری امنیتی را حذف کند.
به همین ترتیب، نمایش اطلاعات مالی حساس در صفحه اصلی باید با ملاحظات حریم خصوصی هماهنگ باشد.
دسترس‌پذیری نیز اهمیت دارد. خوانایی متن، عنوان‌های قابل‌فهم، اندازه مناسب ناحیه لمس و قابل‌استفاده‌بودن رابط برای افراد دارای محدودیت‌های حرکتی یا بینایی باید بررسی شود. استاندارد WCAG 2.2 مرجع مفیدی برای ارزیابی جنبه‌هایی از دسترس‌پذیری است، هرچند کاربرد الزامات آن در محصولات بومی موبایل باید متناسب با فناوری و مقررات مربوط بررسی شود.
از نگاه کسب‌وکار هم نباید صفحه اصلی را صرفا با هدف افزایش فروش محصولات مالی طراحی کنیم.
به‌عنوان نمونه، راهنمای Consumer Duty نهاد ناظر مالی بریتانیا (FCA) بر ارائه اطلاعات قابل‌فهم، حمایت موثر از مشتری و جلوگیری از آسیب‌های قابل‌پیش‌بینی تاکید می‌کند. این یک چارچوب نظارتی بریتانیایی است، نه قانونی که خودکار برای تمام بانک‌های دنیا اعمال شود؛ بااین‌حال، معیار مناسبی برای فکرکردن به تعادل میان منفعت کاربر و کسب‌وکار فراهم می‌کند.
مثال عملی: بازطراحی صفحه اصلی یک بانک دیجیتال
سناریوی فرضی
فرض کنیم تیم محصول یک بانک دیجیتال متوجه شده بخشی از کاربران با فاصله تقریبا ماهانه وارد اپلیکیشن می‌شوند.
داده‌های اولیه نشان می‌دهد بعضی از این کاربران پس از ورود، میان چند بخش جابه‌جا می‌شوند تا به خدمات پرداخت یا گردش حساب برسند.
این رفتار به‌تنهایی ثابت نمی‌کند طراحی نامناسب است؛ شاید کاربران صرفا در حال بررسی بخش‌های مختلف باشند.
مدیر محصول با کمک تحلیلگر داده، پژوهشگر تجربه کاربری و تیم پشتیبانی بررسی می‌کند که این جابه‌جایی‌ها در چه شرایطی رخ می‌دهند و آیا به خطا، رهاکردن وظیفه یا تماس با پشتیبانی منتهی می‌شوند.
پس از بررسی، دو راهکار برای آزمایش انتخاب می‌شوند:
گزینه اول: افزودن میان‌برهای مشخص برای خدمات پرکاربرد در صفحه اصلی.
گزینه دوم: حفظ میان‌برها و افزودن خلاصه‌ای از تغییرات مهم حساب از آخرین مراجعه.
برای کاهش هزینه و ریسک، ابتدا نمونه اولیه این دو گزینه در آزمون کاربردپذیری بررسی می‌شود.
اگر کاربران بتوانند با ساختار ثابت و میان‌برهای روشن وظایف خود را به‌خوبی انجام دهند، شاید اصلا نیازی به توسعه بخش خلاصه تغییرات نباشد.
اما اگر سردرگمی اصلی درباره اتفاقات مالی بین دو مراجعه باشد، نمایش خلاصه تغییرات می‌تواند ارزش بیشتری ایجاد کند.
تیم طراحی مسئول وضوح رابط است، مهندسی امکان اجرای آن را بررسی می‌کند و تیم امنیت درباره حفظ کنترل‌های حساس نظر می‌دهد. مدیر محصول باید با کنار هم گذاشتن این شواهد، درباره اولویت سرمایه‌گذاری و نتیجه مورد انتظار تصمیم بگیرد.
در سازمان‌هایی که از Scrum استفاده می‌کنند، Product Owner مسئول بیشینه‌سازی ارزش محصول و مدیریت موثر Product Backlog است. این مسئولیت لزوما با عنوان شغلی Product Manager یکی نیست. مدیر پروژه نیز در صورت وجود چنین نقشی بیشتر بر هماهنگی تحویل و محدودیت‌های اجرایی تمرکز دارد.
موفقیت طراحی را چطور اندازه بگیریم؟
یکی از دام‌های این سوال، انتخاب تعداد ورود به اپلیکیشن به‌عنوان شاخص اصلی موفقیت است.
اگر کاربری فقط به یک مراجعه ماهانه نیاز داشته باشد، افزایش دفعات ورود او لزوما ارزش بیشتری ایجاد نمی‌کند.
معیار اصلی باید به موفقیت او در انجام کار موردنظر مربوط باشد.
برای این مسئله، می‌توانیم چند شاخص تعریف کنیم:
۱. نرخ تکمیل موفق وظیفه اصلی
درصد کاربرانی که در مراجعه ماهانه، وظیفه مشخص خود مانند پرداخت قبض یا دریافت صورت‌حساب را با موفقیت انجام می‌دهند.
مخرج این شاخص باید کاربران دارای همان قصد یا نیاز باشد، نه تمام کسانی که وارد اپلیکیشن شده‌اند. در پژوهش کاربردپذیری می‌توان قصد را از قبل مشخص کرد و در تحلیل محصول نیز وظایف قابل‌شناسایی را جداگانه سنجید.
۲. زمان رسیدن به نتیجه
مدت‌زمان لازم از شروع مسیر تا تکمیل وظیفه، مثلا پرداخت موفق قبض.
این شاخص به ما می‌گوید آیا دسترسی واقعا سریع‌تر شده است یا فقط دکمه‌ها را جابه‌جا کرده‌ایم.
۳. نرخ خطا و رهاکردن فرایند
میزان خطاهای قابل‌مشاهده، تلاش‌های ناموفق و خروج از فرایند پیش از تکمیل آن، به تفکیک نوع وظیفه.
۴. شاخص‌های محافظتی
نرخ تراکنش اشتباه یا ناموفق، مشکلات امنیتی و احراز هویت، تماس‌های پشتیبانی مرتبط و شکایت‌های کاربران نباید در نتیجه تغییر افزایش نامطلوبی داشته باشند.
بهتر است معیارها و حدود قابل‌قبول آن‌ها پیش از آزمایش مشخص شوند.
ازآنجاکه این کاربران تقریبا ماهانه مراجعه می‌کنند، ارزیابی اثر واقعی بهتر است حداقل چند چرخه مراجعه را پوشش دهد. نتیجه‌گیری از چند روز داده، بدون درنظرگرفتن الگوی استفاده این گروه، می‌تواند گمراه‌کننده باشد.
همچنین داده‌های حساس مالی نباید صرفا برای اندازه‌گیری تجربه کاربری، بی‌دلیل در ابزارهای تحلیلی ثبت شوند.
نمونه پاسخ در جلسه مصاحبه
اگر قرار باشد این تحلیل را به شکل یک پاسخ طبیعی و مختصر در مصاحبه مطرح کنم، می‌توانم بگویم:
«من اول بررسی می‌کنم چرا این کاربر ماهی یک‌بار وارد اپلیکیشن می‌شود. چون ممکن است اصلا مشکلی وجود نداشته باشد و کاربر فقط برای پرداخت‌های ماهانه یا بررسی حسابش مراجعه کند.
بعد با داده‌های رفتاری و چند مصاحبه مشخص می‌کنم این کاربران معمولا چه کاری انجام می‌دهند و کجا به مشکل می‌خورند.
اگر فرض کنیم نیاز اصلی‌شان انجام سریع چند کار مشخص است، ترجیح می‌دهم صفحه اصلی ساختار ثابتی داشته باشد و خدمات مهم مثل موجودی، انتقال وجه، پرداخت قبض و گردش حساب به‌راحتی پیدا شوند.
اگر شواهد نشان دهند کاربران از اتفاقات بین دو مراجعه بی‌خبر می‌مانند، یک خلاصه ساده از تغییرات مهم حساب را هم آزمایش می‌کنم.
برای سنجش نتیجه، بیشتر از تعداد ورود، به نرخ تکمیل وظیفه، زمان انجام آن و خطاها توجه می‌کنم. البته امنیت و حریم خصوصی خط قرمز طراحی هستند.
اگر آزمون‌ها نشان دهند مشکل اصلی چیز دیگری است، مثلا فرایند ورود یا تایید تراکنش، اولویت را تغییر می‌دهم و سراغ همان مسئله می‌روم.»
این پاسخ نشان می‌دهد که به‌جای ارائه یک فهرست از قابلیت‌ها، برای تصمیم‌گیری مسیر مشخصی داریم.
سوالات تکمیلی احتمالی مصاحبه‌کننده
سوال اول: اگر فقط دو هفته برای بررسی مسئله وقت داشته باشید، چه می‌کنید؟
در دو هفته نمی‌توانیم اثر بلندمدت یک طراحی را بر رفتار کاربران ماهانه با اطمینان اندازه بگیریم. اما می‌توانیم درباره ارزش ادامه سرمایه‌گذاری تصمیم بهتری بگیریم.
در چنین شرایطی:
- چند مسیر مهم کاربران ماهانه را از داده‌های موجود استخراج می‌کنم.
- با نمونه‌ای از کاربران این گروه مصاحبه می‌کنم و وظایف اصلی آن‌ها را شناسایی می‌کنم.
- با کمک طراح، یک یا دو نمونه اولیه کم‌هزینه می‌سازم.
- آزمون کاربردپذیری انجام می‌دهم تا مشکلات قابل‌مشاهده در انجام وظایف مشخص شوند.
- براساس شواهد، درباره آزمایش محدود در محصول واقعی تصمیم می‌گیرم.
هدف دو هفته، اثبات افزایش وفاداری یا تغییر رفتار ماهانه نیست؛ هدف این است که ابهام اصلی را با هزینه کم کاهش دهیم.
سوال دوم: چه شواهدی باعث می‌شود راهکار پیشنهادی خود را کنار بگذارید؟
اگر مشخص شود کاربران بدون مشکل خاصی وظایف خود را انجام می‌دهند، بازطراحی صفحه اصلی اولویت کمتری پیدا می‌کند.
همچنین اگر آزمون‌ها نشان دهند میان‌برهای جدید باعث انتخاب اشتباه، سردرگمی یا کاهش دسترسی به خدمات ضروری شده‌اند، باید آن‌ها را اصلاح یا حذف کنیم.
ممکن است داده‌ها نشان دهند مشکل اصلی نه صفحه اصلی، بلکه بازیابی رمز عبور، ورود مجدد یا مراحل تایید تراکنش است.
در این صورت، اصرار بر بازطراحی صفحه اصلی تصمیم درستی نخواهد بود.
مدیر محصول باید بتواند از تصمیمش دفاع کند، اما نباید به آن وابسته شود.
پاسخ‌های ضعیف و اشتباهات رایج
«چون کاربر کم وارد می‌شود، همه قابلیت‌های اضافی را حذف می‌کنم.»
این پاسخ مسئله کاربر را مشخص نکرده و فرض می‌کند سادگی همیشه با حذف قابلیت‌ها به دست می‌آید. ممکن است یک خدمت کم‌استفاده برای همان کاربر حیاتی باشد.
«با هوش مصنوعی همه‌چیز را شخصی‌سازی می‌کنم.»
این پیشنهاد بدون بررسی کیفیت داده، امکان پیش‌بینی و هزینه توسعه مطرح شده است. شخصی‌سازی نامطمئن حتی ممکن است تجربه کاربر ماهانه را پیچیده‌تر کند.
«کاری می‌کنم هر روز وارد اپلیکیشن شود.»
اینجا هدف کسب‌وکار با نیاز کاربر اشتباه گرفته شده است. تعداد ورود بیشتر، بدون ارزش مشخص، معیار مناسبی برای موفقیت نیست.
«برای راحتی کاربر مراحل تایید تراکنش را کم می‌کنم.»
در محصول مالی، ساده‌سازی باید همراه با بررسی خطر تقلب، خطای پرداخت و الزامات امنیتی باشد. کاهش اصطکاک به‌تنهایی مجوز حذف کنترل‌های ضروری نیست.
جمع‌بندی
برای طراحی صفحه اصلی اپلیکیشن بانکی که کاربر آن ماهی یک‌بار وارد می‌شود، بهترین نقطه شروع اضافه‌کردن قابلیت‌های جدید یا حذف امکانات فعلی نیست. ابتدا باید بفهمیم کاربر در این مراجعه به‌دنبال چه چیزی است و آیا در رسیدن به آن با مشکل روبه‌رو می‌شود.
اگر شواهد نشان دهند مسئله اصلی پیدا کردن و انجام خدمات ماهانه است، یک ساختار ثابت، دسترسی روشن به وظایف پرکاربرد و نمایش کنترل‌شده اطلاعات مرتبط می‌تواند انتخاب مناسبی باشد. این راهکار در مقایسه با شخصی‌سازی کامل، ساده‌تر آزمایش می‌شود و احتمال سردرگمی ناشی از تغییر مداوم رابط را کاهش می‌دهد.
اما این فقط یک فرضیه طراحی است، نه نسخه‌ای قطعی برای همه بانک‌ها. اگر پژوهش و داده‌ها نشان دهند مشکل واقعی در ورود، امنیت، فهم اطلاعات مالی یا بخش دیگری از تجربه قرار دارد، باید راهکار و اولویت‌ها را تغییر دهیم.
وظیفه مدیر محصول این نیست که کاربر را بیشتر در اپلیکیشن نگه دارد؛ وظیفه او این است که کمک کند کاربر با اطمینان، کمترین تلاش غیرضروری و بدون آسیب به امنیت، به نتیجه‌ای که می‌خواهد برسد.
منابع
۱. Reforge — Product Manager Interview Questions — مرجع الگوهای ارزیابی تفکر و تصمیم‌گیری محصول در مصاحبه؛ نه تاییدیه رسمی برای طرح دقیق این سناریو.
۲. Nielsen Norman Group — Memory Recognition and Recall in User Interfaces — اصول شناخت و یادآوری در طراحی رابط کاربری.
۳. W3C — Web Content Accessibility Guidelines (WCAG) 2.2 — معیارهای دسترس‌پذیری رابط‌های دیجیتال.
۴. Financial Conduct Authority — About the Consumer Duty — اصول حمایت از مصرف‌کننده و ارائه اطلاعات قابل‌فهم در خدمات مالی بریتانیا.
