محصول: نمادنو
پلتفرم: موبایل (iOS / Android)
طراح: آرزو عربی
نقش: طراح محصول (مالکیت کامل)
نمادنو یک سوپر اپلیکیشن مالی است که با هدف تجمیع چند سرویس مالی و شبهمالی در یک تجربهی یکپارچه طراحی شده است. این محصول در حال حاضر بهصورت محدود و داخلی در سطح هلدینگ لانچ شده و شامل ماژولهای اصلی زیر است:
از همان ابتدای طراحی، یکی از چالشهای اصلی نمادنو این بود که سرویسهایی با ماهیت، ریسک و سطح تعهد کاملاً متفاوت باید در قالب یک اپلیکیشن واحد کنار هم قرار بگیرند.
من از ابتدای شکلگیری نمادنو، بهعنوان تنها Product Designer پروژه، مسئول طراحی محصول بهصورت end-to-end بودهام؛ از:
در کنار من:
در مراحل اولیه طراحی، تمرکز اصلی روی:
اما با رشد محصول و اضافهشدن فلوهای عمیقتر و حساستر مانند خرید بیمه، لیزینگ و پرداختهای چندمرحلهای بهتدریج مشخص شد که برخی تصمیمهای اولیهی نویگیشن، در مقیاس بزرگتر، چالشهای جدیدی ایجاد میکنند.
این چالشها نه در طراحی اولیه، بلکه:
خودشان را نشان دادند.
در نمادنو، همهی فلوها رفتار و نیاز یکسانی ندارند. برخی مسیرها کوتاه، کمریسک و قابل قطع هستند؛ اما برخی دیگر:
نمونههایی از این فلوها:
با افزایش تعداد این فلوها، مسئلهی اصلی بهتدریج مشخص شد:
چگونه میتوان جابهجایی کاربر را در فلوهای عمیق مدیریت کرد، بدون اینکه او را گم کنیم، از فرایند خارج کنیم یا تمرکزش را بشکنیم؟
این کیساستادی به بررسی پاسخ این سؤال میپردازد.
چالش ناوبری در نمادنو فقط به حرکت بین صفحات محدود نبود. بررسی سناریوها نشان داد این مسئله سه لایه اثر دارد:
در فلوهای مالی و تعهدآور، هر اصطکاک ناوبری میتواند باعث تردید، توقف یا خروج ناخواسته از مسیر شود. از طرف دیگر، برای تیم فنی نیز ساختار بازگشت و خروج نامشخص، پیچیدگی در پیادهسازی و تست سناریوها ایجاد میکرد.
به همین دلیل، این مسئله در سطح «اصلاح یک دکمه» قابل حل نبود و نیاز به بازتعریف الگوی ناوبری داشت.
با بازبینی فلوهای محصول، مشخص شد مسئله از یک ناهماهنگی ساختاری ناشی میشود:
تنوع فلوها بالا بود، اما رفتار ناوبری یکنواخت تعریف شده بود.
در عمل، سه نوع مسیر متفاوت در محصول وجود داشت:
اما سیستم ناوبری برای هر سه نوع مسیر، یک رفتار Back یکسان در نظر گرفته بود. همین موضوع باعث افزایش هزینه بازگشت در فلوهای عمیق شد.
در این مرحله یک تضاد طراحی شکل گرفت:
از یک طرف، کاربر باید بتواند سریع از فلو خارج شود یا مسیرش را تغییر دهد.
از طرف دیگر، در فلوهای حساس نباید خروج تصادفی یا پرت شدن توجه رخ دهد.
این تضاد بین سه هدف شکل گرفت:
بنابراین تصمیم ناوبری باید Context-Based میبود، نه ثابت.
مسئله طراحی به این شکل صورتبندی شد:
چگونه میتوان در یک سوپراپ مالی با فلوهای ناهمگن، مدلی از ناوبری طراحی کرد که هم خروج سریع و کمهزینه را ممکن کند،تمرکز و ایمنی فلوهای حساس حفظ کند و هم نرخ خروج رو در مراحل حساس پایین نگه داریم؟
این سؤال مبنای مرحله بعد طراحی و بررسی گزینههای مختلف ناوبری شد.
پس از صورتبندی مسئله ناوبری، تصمیم گرفتم به جای اصلاح موردی اجزای UI، گزینههای مختلف ناوبری را در سطح الگو (Navigation Pattern) بررسی و مقایسه کنم. هدف، رسیدن به یک مدل تصمیمگیری بود که بتواند برای انواع فلوها قابل اعمال باشد، نه فقط یک مسیر خاص.
در این مرحله، تمرکز من روی رفتار Back، Home و Exit در فلوهای مختلف قرار گرفت.
گزینه اول: ناوبری مبتنی بر Back خطی
در این مدل، دکمه بازگشت در هدر همیشه کاربر را یک مرحله به عقب در استک صفحات برمیگرداند. این الگو ساده، قابل پیشبینی و همسو با الگوی پیشفرض سیستمعامل است.
مزایا:
محدودیتها:
نتیجه: برای مسیرهای کوتاه مناسب است، اما برای فلوهای چندمرحلهای مالی ناکافی است.
گزینه دوم: افزودن Home در هدر داخلی
در این الگو، علاوه بر Back، یک آیکون Home در هدر صفحات داخلی قرار میگیرد تا کاربر بتواند با یک اقدام به داشبورد بازگردد.
مزایا:
ریسکها:
نتیجه: برای صفحات انتخابی و مرور مناسب است، اما برای فلوهای ورود اطلاعات حساس، پرریسک است.
گزینه سوم: Exit / انصراف متنی با تأیید
در این مدل، به جای آیکون Home، یک اکشن متنی مانند «انصراف» یا «خروج از فرایند» در هدر فلوهای چندمرحلهای قرار میگیرد و با تأیید دو مرحلهای همراه میشود.
مزایا:
محدودیت:
نتیجه: برای فلوهای طولانی و حساس، رفتار ایمنتری ایجاد میکند.
گزینه چهارم: نگهداشتن Bottom Navigation در عمق صفحات
یکی از گزینههای بررسیشده، حفظ Bottom Navigation در صفحات داخلی برای فراهم کردن پرش سریع بین ماژولها بود.
مزایا:
ریسکها:
نتیجه: فقط تا سطوح انتخابی قابل قبول است، نه در فلوهای مرحلهای.
بررسی گزینهها نشان داد هیچ الگوی واحدی برای همه فلوها مناسب نیست. تفاوت ماهیت مسیرها ایجاب میکند که ناوبری نیز رفتار تطبیقی داشته باشد.
به همین دلیل، تصمیم طراحی از یک مدل ثابت به یک مدل Context-Based Navigation تغییر جهت داد مدلی که رفتار هدر و اکشنهای خروج را بر اساس نوع فلو تعیین میکند.
تفاوت ماهیت فلوها از صفحات نمایشی تا فرایندهای چندمرحلهای مالی نیازمند رفتار ناوبری متفاوت است.
به همین دلیل، به جای انتخاب یک الگوی واحد، یک مدل ناوبری تطبیقی تعریف کردم که رفتار هدر و ابزارهای خروج و بازگشت را بر اساس نوع فلو تنظیم میکند.
در این مدل، نوع مسیر تعیین میکند کاربر چه ابزار ناوبری ببیند، نه صرفاً سطح عمق صفحه.
برای عملیاتی کردن مدل، ابتدا فلوهای محصول را به سه دسته رفتاری تقسیم کردم:
صفحات مرور و انتخاب
صفحات لیست، دستهبندی، انتخاب سرویس، مشاهده اطلاعات
Back خطی فعال
Bottom Navigation فقط تا عمق اول
آیکون Home در هدر
پرش بین ماژولها آزاد
هدف: سرعت جابهجایی بالا
مسیرهای انتخابی چندسطحی
انتخاب صندوق، انتخاب نوع خدمت، انتخاب محصول
Back خطی فعال
آیکون Home در هدر
امکان بازگشت سریع به داشبورد
هدف: کاهش هزینه بازگشت بدون ایجاد ریسک
فلوهای چندمرحلهای حساس
خرید بیمه، درخواست لیزینگ، پرداخت، OTP، تأیید نهایی
Back مرحله ای داخل فلو
آیکون Home حذف
بهجای آن اکشن «انصراف / خروج از فرایند» قرار میگیرد
خروج با دیالوگ تأیید همراه است
هدف: حفظ تمرکز + جلوگیری از خروج تصادفی
بر اساس این مدل، هدرها به دو الگوی اصلی محدود شدند:
هدر ناوبری عمومی
هدر فلو مرحلهای
کاهش تنوع هدرها به دو الگو، پیچیدگی پیادهسازی و یادگیری را کاهش داد.
برای جلوگیری از تداخل ناوبری، یک قانون عمق تعریف شد:
Bottom Navigation فقط تا لایههای انتخابی نمایش داده میشود و با شروع فلو مرحلهای حذف میشود.
این قانون باعث شد:
یکی از جنبههای مهم این فرآیند، تأیید مدل نهایی با مدیر محصول (PM) بود. چون مدل ناوبری تأثیر زیادی بر تعامل کاربر و هماهنگی تیمها داشت، لازم بود که با نیازهای محصول و اهداف استراتژیک همراستا باشد.
در این مرحله، با مدیر محصول جلساتی برای بررسی اثرات تغییرات برگزار کردیم و پس از تأیید نهایی، مدل ناوبری تطبیقی به تیم فنی معرفی شد.
پس از تعریف مدل ناوبری تطبیقی، گام بعدی تبدیل تصمیمهای UX به قواعد اجرایی قابل پیادهسازی برای تیم فرانت بود. بعد از یک جلسه برای ارائه مسئله و راه حل آن و شنیدن نظرات تیم فرانت و گرفتن موافقت از آنها، هدف این بود که رفتار ناوبری وابسته به تفسیر شخصی توسعهدهنده نباشد و بهصورت Rule-based اجرا شود.
برای این منظور، رفتار ناوبری بهصورت مجموعهای از قوانین مشخص برای نوع فلو، نوع هدر و وضعیت Bottom Navigation مستندسازی شد. این مستندسازی باعث شد تصمیم ناوبری از سطح کامپوننت به سطح سیستم ارتقا پیدا کند.
پس از تعریف قواعد ناوبری، سناریوهای تست نیز شفافتر شد. تیم فنی میتوانست بداند:
در هر نوع صفحه:
این شفافیت، هزینه تست سناریوهای عمیق را کاهش داد و بازتولید خطاهای ناوبری را سادهتر کرد.
در این مرحله، مدل ناوبری از سطح تصمیم طراحی به سطح قرارداد اجرایی بین طراحی و توسعه تبدیل شد. این تبدیل، ریسک تفسیر متفاوت و اجرای ناهماهنگ را کاهش داد و ناوبری را به بخشی از سیستم طراحی محصول تبدیل کرد، نه صرفاً یک تصمیم UI.
نتیجه طراحی و اثرات بر تجربه کاربر
تأثیر روی تیم فنی و عملکرد محصول
درسهای آموختهشده
نتیجه نهایی
مدل ناوبری تطبیقی باعث بهبود قابل توجه تجربه کاربر، افزایش تمرکز در فلوهای حساس و کاهش مشکلات در تیم فنی شد. این مدل بهعنوان یک راهحل جامع برای مسیرهای مختلف طراحی شد و تأثیر مثبت خود را در عملکرد کلی محصول گذاشت.
