بررسی موردی طراحی Splash Screen پف‌فیلم

قبلا در مقاله‌ی چک لیست طراحی Splash Screen در مورد اصول طراحی صفحه‌ی شروع یا Launch screen زیاد صحبت کرده بودم و هر چند به نظریات مخالف در رد استفاده ازش هم پرداخته بودم اما الان اگر برگردم و اون مقاله رو بخوام اصلاح کنم وزن بیشتری به ارائه‌ی دلایل عدم استفاده از اسپلیش اسکرین می‌دم.

این مقاله رو که بخونین دلایل بسیاری برای عدم استفاده از اسپلش اسکرین توضیح داده. اما در نهایت این ما هستیم که باید ما بر اساس ملاحظات و شرایط خومون تصمیم بگیریم.

در ابتدای اپلیکیشن کاملا دوبه‌شک بودم که بزاریمش یا نه و برای همین فرض رو گذاشتم رو نداشتن و صفحه‌ی اول رو با skeleton screen طراحی کردیم که تا زمانی که محتوایی برای نمایش از اینترنت دریافت نشده یه چیزی برای نمایش وجود داشته باشه.

اما در ادامه به سه دلیل تصمیم گرفتم از اسپلیش اسکرین استفاده کنیم.

شکستن زمان انتظار

زمانی که سرعت بارگزاری به هر دلیلی خیلی کند می‌شه بهتره ۲ مرحله المان بصری برای ارائه به کاربر داشته باشیم. یعنی یکبار در اسپلیش اسکرین کمی سرگرم می‌شه و سری دوم با Skeleton Screen سرگرم بشه. شکستن این بازه انتظار به دو زمان انتظار باعث می‌شه درک کاربر از مجموع زمان انتظار کمتر بشه و احساس کنه که اپلیکیشن سریعتر کار می‌کنه.

قبلا در مقاله‌ی اصول روانشناسی حاکم بر فرآیندهای زمانبر در مورد نحوه‌ی ادراک ما از زمان زیاد حرف زدم.

وزن بصری بیشتر برای Error

موضوع دومی که برامون مهم بود اینه که زمانی که اینترنت کاربر به طور کامل قطعه و نیازه که خطای مربوطه رو بهش نشون بدیم، هیچ المان جاذبِ توجه دیگه‌ای تو صفحه نباشه که توجه کاربر رو از خطا پرت کنه. صفحه‌ی اصلی با انیمیشن Skeleton Screen برای نمایش این موضوع به نظرم زیادی شلوغ بود در نتیجه ترجیه دادیم که نمایش خطا‌ی دسترسی به اینترنت رو در صفحه‌ی Splash Screen قرار بدیم که تمام توجه کاربر رو به خودش جلب کنه.

همینطور که در مقاله‌ی چک لیست طراحی Splash Screen گفتم در زمان بروز خطا بهتره که راه حل هم به کاربر بدیم. برای این منظور در زمان نمایش خطا بررسی مجدد رو هم قرار دادیم که عملا هیچکاری نمی‌کنه چون اپلیکیشن به صورت پیشفرض داره مدام اتصال رو بررسی می‌کنه و نیازی به اقدامی از جانب کاربر نیست. اما این دکمه یه جور دِلخوشکُنَک و حس کنترل به کاربر می‌ده که باعث می‌شه تجربه‌ی بهتری داشته باشه. برای مطالعه‌ی این موضوع به مقاله‌ی Placebo Effect مراجعه کنید.

یه چیزی دیگه‌ای هم که اصلا دنبالش نبودم و یه دفعه به ذهنم رسید این بود که زمانی که اینترنت قطعه با افکت گلیچ یه انیمیشنی به لوگو بدیم که جذاب باشه. البته نگرانم این جذابیت به حدی باشه که مانع کارکرد بشه و کاربر برای اینکه این انیمیشن رو ببینه عامدانه اینترنتشو قطع کنه که بیاد و این رو ببینه. همین مشکل رو هم در بازطرحی یکی از مودال‌ها داریم که در مقاله‌ی بعدی بهش اشاره می‌کنم. اما چون این انیمیشن رو دوست دارم اینجوری توجیه می‌کنم که چون این افکت افکتیه که آدما در تلویزیون‌هایی که مشکل آنتن‌دهی دارن بارها دیدن متوجه اینکه یه خطایی رخ داده می‌شن و هنوز هم صفحه به اندازه‌ای خلوت هست که خطای دسترسی به اینترنت سریع دیده بشه.

ما آدمها برای چیزهایی که خودمون ساختیم و کلی هزینه (زمانی یا مالی) براش کردیم ارزش بیشتری قائلیم و تمام قد ازش دفاع می‌کنیم. به این پدیده در اصطلاح Investment Bias گفته می‌شه که زیبا در مقاله‌ی ۶ اشتباه رایج در پروتوتایپ کردن در موردش توضیح می‌ده که چطور این خطا باعث می‌شه فقط اون نتایجی از تست کاربردپذیری رو که باب میل ماست ببینیم.

برندینگ

یکی از دلایلی که اکثر بیزینس‌ها برای اهمیت اسپلیش اسکرین ذکر می‌کنن همین برندینگه. ما هم در این مرحله‌ای که هستیم، فرضمون اینه که در یک صفحه‌ی خاص فقط لوگو و لوگوتایپ رو نشون بدیم که چشم کاربر عادت کنه به دیدن لوگو و اسم پف‌فیلم.

البته در این مورد کاملا بازیم و ممکنه یه زمانی تصمیم بگیریم این دیگه یکی از دلایل نباشه.

فارغ از این مسائل چون اسپلش اسکرین رو کاربر مانعی برای رسیدن به هدفش می‌دونه سعی کردیم خیلی سریع کاربر رو به صفحه‌ی اصلی هدایت کنیم و کمترین زمان ممکن رو در این صفحه سپری کنه.

یکی دیگه از موارد مهمی که باید به کاربر گوشزد کنیم اما انقدر مهم نیست که در Flow کاربر سدی ایجاد کنیم نمایش Toast استفاده از VPN که در اسپلش اسکرین میاد و تا صفحه‌ی اصلی ادامه پیدا می‌کنه و بعد محو می‌شه.

همچنین در بروزرسانی بعدی قراره (مشابه لوگوی نتفیلیکیس در Concept بالا) به کمک انیمیشن Shared Element لوگو رو از صفحه‌ی اسپلیش اسکرین به صفحه‌ی خانه ببریم که Consistency بهتری برقرار بشه و لوگو و لوگو تایپ توجه بیشتری به خودش بگیره. البته این موضوع ممکنه روی سرعت تاثیر منفی بزاره که لازمه تستش کنیم. ممکنه بعد از تست تصمیم بگیریم که برش داریم یا برای گوشی‌های ضعیف‌تر غیر فعالش کنیم.

در حال حاضر این قابلیت در React Native در نسخه‌ی آزمایشیه برای همین موکول کردیم به زمانی که این موضوع اضافه بشه به ورژن مورد استفاده‌ی ما.

همینطور که توی این توییت مشخص شد نوشتن ورژن برنامه در صفحه اپلیکیشن کمک می‌کنه که اگر اپلیکیشن در این صفحه باقی موند و نرفت جلوتر، کاربر بتونه با پشتیبانی تماس بگیره و با اعلام شماره نسخه برنامه کمک کنه مشکل پیش اومده رو راحت‌تر درک کنیم.

از این دست مقالات:

بررسی موردی طراحی Tab bar پف‌فیلم

بررسی موردی طراحی Login Page پف‌فیلم

بررسی موردی طراحی Splash Screen پف‌فیلم - در حال مطالعه

بررسی موردی طراحی Payment Result Page پف‌فیلم