اپ ترنج (بیمه)
کاربر در این اپ طرح مناسب را انتخاب میکند، اطلاعات لازم برای صدور بیمهنامه را تکمیل میکند، هزینه را میپردازد و بعد از خرید سرمایهاش را مدیریت میکند.
بیمه و سرمایهگذاری در یک اپ
رز ترنج بیمه را با سرمایهگذاری مبتنی بر طلا ترکیب میکند. افران هم بیمه را در کنار سرمایهگذاری در صندوق درآمد ثابت ارائه میدهد.
اپ همه مراحل را پوشش میدهد: انتخاب طرح و مبلغ، تکمیل اطلاعات هویتی و پستی، پرداخت، دیدن بیمهنامه، افزایش سرمایه، برداشت و مدیریت حساب بانکی.
این محصول برای موبایل و به زبان فارسی طراحی شده است.
کوتاه نگه داشتن خرید، بدون پنهان کردن پیشنیازها
خرید هر طرح به اطلاعات بیمه، هویت، آدرس و پرداخت نیاز داشت. چالش این بود که این اطلاعات را بگیریم، بدون اینکه مسیر به یک فرم طولانی تبدیل شود.
اپ باید بعد از پرداخت هم مفید میماند؛ کاربر باید بیمهنامه و سرمایهاش را ببیند، مبلغ اضافه کند یا برداشت انجام دهد.
طراحی محصول از معماری تا تحویل
در این پروژه سهماهه بهعنوان طراح محصول با مدیر محصول، توسعهدهنده فرانتاند و توسعهدهنده بکاند همکاری کردم.
- معماری اطلاعات
- طراحی جریانهای کاربر
- طراحی تجربه کاربر
- طراحی رابط کاربری
- دیزاین سیستم
- پروتوتایپ
- UX Writing
- Design QA
- همکاری با توسعهدهندگان و تحویل طراحی
سه بخش: ورود، خرید و مدیریت
اپ را به سه بخش تقسیم کردم: ورود، انتخاب و خرید طرح، و مدیریت آن بعد از خرید.
اطلاعات هویتی و آدرس در همان مسیر خرید گرفته میشوند. واریز و برداشت به هر بیمهنامه متصلاند و اطلاعات پروفایل و حساب بانکی در همه بخشها در دسترس است.
- ورودشماره موبایلتأیید OTPورود یا ایجاد حساب
- آنبوردینگمشاهده داراییمعرفی طرحهاامنیت
- خانه و معرفی طرحها
- رز ترنجسرمایهگذاری مبتنی بر طلا
- افرانسرمایهگذاری درآمد ثابت
- مبلغ و شرایط
- کد ملی و تاریخ تولد
- اطلاعات پستی
- مرور پیشفاکتور و ویرایش مبلغ
- پرداخت
- داراییهاارزش کلبیمهنامهها
- جزئیات بیمهنامهارزش روزتعداد واحدمبلغ قابل برداشتواریزبرداشت
- تراکنشهای خرید، واریز و برداشت
- حسابهای بانکیافزودن حساباعتبارسنجی شباتأیید مالکیت
- پروفایلاطلاعات فردیآدرسحساب بانکیپشتیبانی
- بارگذاریحالت خالیاعتبارسنجیهشدارخطای شبکهانتظارموفقیت
از مشاهده طرح تا بیمهنامه فعال
مشاهده طرحها
بررسی رز ترنج و افران.
انتخاب رز یا افران
بارگذاری وضعیت خرید مرتبط با طرح.
ورود مبلغ سرمایهگذاری
قالببندی مبلغ و نمایش حداقل و واحد تقریبی.
تکمیل اطلاعات هویتی
اعتبارسنجی کد ملی، تاریخ تولد و مالکیت موبایل در صورت نیاز.
تکمیل اطلاعات پستی
اعتبارسنجی کد پستی دهرقمی و دریافت یا بهروزرسانی آدرس.
مرور پیشفاکتور
بررسی هزینهها و مبلغ با امکان ویرایش.
آمادهسازی پرداخت
بهروزرسانی جزئیات پرداخت و دریافت شناسه.
درگاه پرداخت
اتصال به درگاه پرداخت.
بیمهنامه فعال
پس از پردازش موفق، بیمهنامه در سبد نمایش داده میشود.
پیش از ایجاد پیشفاکتور، حداقل مبلغ، اطلاعات هویتی ضروری و کد پستی اعتبارسنجی میشوند. پیشفاکتور در انتظار پرداخت همچنان قابلویرایش است تا کاربر بتواند جزئیات مالی را مرور یا مبلغ را پیش از پرداخت اصلاح کند.
پس از فعالشدن، بیمهنامه وارد سبد کاربر میشود و دسترسی به ارزش روز، جزئیات قرارداد، واریز، برداشت و تراکنشها را فراهم میکند.
ساختار، پیش از پرداخت بصری
هفت صفحه کمجزئیات، ساختار محصول را نمایش میدهند. اینها مستندات بازنگرانه هستند و بهعنوان وایرفریمهای اولیه پروژه معرفی نمیشوند.
ورود و OTP
کشف طرح
مبلغ سرمایهگذاری
هویت و اطلاعات پستی
داشبورد دارایی
برداشت دومرحلهای
جزئیات بیمهنامه
چرا مسیر خرید اینطور طراحی شد
اطلاعات هویتی و پستی زمانی پرسیده میشوند که برای صدور بیمهنامه لازماند؛ نه در یک فرم طولانی ابتدای مسیر.
کاربر قبل از وارد کردن اطلاعات بیشتر، طرح و مبلغ را میبیند.ممکن است همه پیشنیازها از ابتدای مسیر برای او روشن نباشند.رز با رنگ زرشکی و سرمایهگذاری مبتنی بر طلا معرفی میشود. افران آبی و مبتنی بر درآمد ثابت است. خرید و مدیریت هر دو مسیر یکسانی دارد.
کاربر دو طرح را تشخیص میدهد، بدون اینکه دو رابط متفاوت یاد بگیرد.رنگ اقدامهای عمومی باید از رنگ هر طرح قابلتشخیص باشد.ارزش روز، مبلغ پرداخت، تعداد واحد و مبلغ قابل برداشت از اطلاعات فرعی برجستهترند.
کاربر عددهای مهم را سریعتر پیدا میکند.صفحه جزئیات همچنان ممکن است شلوغ شود.احراز هویت، انتخاب تاریخ، کد پستی، ویرایش مبلغ، واریز، برداشت و افزودن حساب در پنل پایین صفحه انجام میشوند.
کاربر هنوز طرح یا بیمهنامه فعلی را در پسزمینه میبیند.کارهای طولانی برای این فضای محدود مناسب نیستند.کاربر ابتدا تعداد واحد را مشخص میکند و بعد حساب مقصد را انتخاب میکند.
پیش از انتخاب حساب، مبلغ تقریبی برداشت دیده میشود.یک مرحله به عملیات اضافه میشود.مبلغ فقط به حساب بانکی ثبتشده و تأییدشده کاربر واریز میشود.
احتمال انتقال پول به حساب اشتباه کمتر میشود.کاربر در برداشت اول ممکن است مجبور شود حسابش را ثبت کند.حداقل سرمایهگذاری، سقف برداشت، کد ملی، کد پستی، شبا، بانک، حساب تکراری و مالکیت حساب بررسی میشوند.
خطا قبل از ثبت درخواست مالی به کاربر نشان داده میشود.متنها راستبهچپاند، اما شماره موبایل، شبا، تاریخ، مبلغ و شناسهها در قالب مناسب خود نمایش داده میشوند.
هم متن فارسی راحت خوانده میشود و هم شناسههای مالی.یک ساختار برای دو طرح متفاوت
- معرفی رز و افران
- ورود مبلغ و مرور پیشفاکتور
- اطلاعات هویتی و پستی
- وضعیت در انتظار پرداخت
- داشبورد داراییها
- جزئیات بیمهنامه رز و افران
- واریز و برداشت
- پروفایل و حساب بانکی
- حالتهای بارگذاری، خطا، خالی و موفقیت
تعاملهای اصلی
- 01
ورود OTP، حالت غیرفعال و زمان ارسال مجدد
- 02
پیشرفت آنبوردینگ
- 03
جابهجایی میان رز و افران
- 04
ورود و قالببندی مبلغ
- 05
اعتبارسنجی هویت و انتخاب تاریخ شمسی
- 06
ویرایش پیشفاکتور و آمادهسازی پرداخت
- 07
نمایش و پنهانکردن موجودی
- 08
فیلتر تراکنشها
- 09
اعتبارسنجی واریز
- 10
انتخاب واحد و میانبرهای درصدی برداشت
- 11
انتخاب حساب مقصد
- 12
بازخورد بارگذاری، خطا و موفقیت
الگوهای قابلاستفاده مجدد
تایپوگرافی محصول بر پایه Peyda است و محتوا در قابی موبایلی با عرض حداکثر ۴۴۰ پیکسل قرار میگیرد.
سبز ترنج برای اقدامات عمومی استفاده میشود. رز رنگ زرشکی و افران رنگ آبی دارند و این هویت در خرید، جزئیات بیمهنامه، واریز و برداشت ادامه پیدا میکند.

طیف وزنهای Peyda از Thin تا ExtraBlack؛ برای ساخت سلسلهمراتب روشن و خوانا در رابط فارسی.
#006B54سبز ترنجاقدامات عمومی#8E3F4Cزرشکی رزهویت طرح طلا#1769AAآبی افرانهویت درآمد ثابت#E9EEF3خاکستری رابطسطوح و اطلاعات
فقط مسیر موفق را طراحی نکردم
جمعبندی تجربه نهایی
نقاط قوت
- پوشش مسیر کامل از خرید تا مدیریت بیمهنامه
- حفظ تفاوت روشن رز و افران
- نمایش محدودیتها و برآوردها پیش از عملیات مالی
- پوشش بارگذاری، اعتبارسنجی، خطا، انتظار و موفقیت
- استفاده از الگوهای مشترک در هر دو طرح
- توجه به ساختار RTL و شناسههای مالی
فرصتها
- افزایش اندازه و کنتراست متنهای ثانویه
- جداسازی روشنتر خلاصه مالی از جزئیات فنی
- کاهش تنوع کارتها و سطوح
- تعریف دقیقتر رنگ اقدامات عمومی و اختصاصی
- استانداردسازی کنترلهای کوچک و قاب آیکونها
ریسکها
- تراکم اطلاعات بیمهنامه در نمایشگرهای کوچک
- نیاز کنترلهای کوچک به ارزیابی لمسپذیری
- نیاز اطلاعات ترکیبی RTL و LTR به تست دسترسپذیری
- انجامنشدن ارزیابی رسمی کنتراست، فوکوس، صفحهکلید، Screen Reader و بزرگنمایی
چیزهایی که از پروژه یاد گرفتم
- وضعیتهای بین شروع و پایان، بهاندازه مسیر موفق مهماند.
- اطلاعات بیمه و احراز هویت باید در زمان مناسب پرسیده شوند، نه همه در ابتدای مسیر.
- دو محصول مالی میتوانند ظاهر متفاوت و مسیر استفاده یکسان داشته باشند.
- در موبایل باید عددهای اصلی از جزئیات فنی جدا باشند.
- محدودیت و مبلغ تقریبی واریز یا برداشت باید قبل از ثبت دیده شود.
- در رابط فارسی، متن راستبهچپ و شناسههای عددی به قواعد نمایش جداگانه نیاز دارند.