https://virgool.io/feed/@Mehrdad_Design طراح محصول fa 2026-06-16 05:00:44 https://files.virgool.io/upload/users/4843519/avatar/8ILsKY.png?height=120&width=120 https://virgool.io/@Mehrdad_Design https://virgool.io/@Mehrdad_Design/%D8%A8%D9%84%D9%88%D8%A8%D8%A7%D9%86%DA%A9-%D9%88%DB%8C%DA%98%DA%AF%DB%8C-%D8%A7%D9%86%D8%AA%D9%82%D8%A7%D9%84-%D8%AE%D9%88%D8%AF%DA%A9%D8%A7%D8%B1-qahn30dsgrek-qahn30dsgrek در سال ۱۴۰۱، هنگام بررسی رفتار کاربران در مسیر انتقال پول، متوجه شدیم بخشی قابل توجهی از کاربران الگوی مشخصی از انتقال‌های تکرارشونده دارند. برای مثال، بعضی کاربران هر ماه اجاره پرداخت می‌کردند، برای اعضای خانواده پول می‌فرستادند یا بین حساب‌های خودشان جابه‌جایی منظم انجام می‌دادند. با این حال، استفاده از قابلیت «انتقال خودکار» در بلو کمتر از چیزی بود که انتظار داشتیم.به همین دلیل تصمیم گرفتیم تجربه کشف و افزودن انتقال خودکار را بررسی کنیم و ببینیم چه چیزی مانع استفاده کاربران از این قابلیت می‌شود.در این کیس‌استادی توضیح می‌دهم چطور با بهبود کشف‌پذیری ویژگی انتقال خودکار، کاربران بیشتری وارد مسیر استفاده از این ویژگی شدند و نرخ Activation از 0.43٪ به 0.63٪ رسید؛ یعنی حدود 46.5٪ رشد نسبی.فرآیند انتقال خودکار: وارد کردن مبلغ - تنظیمات انتقال - بررسی و تاییدنقش منمن به‌عنوان طراح محصول، هدایت بازطراحی ویژگی انتقال خودکار را برعهده داشتم؛ از شناسایی مسئله و تحلیل یافته‌های پژوهش تا طراحی راه‌حل، همکاری در اعتبارسنجی و آماده‌سازی نسخه نهایی برای اجرا.در ابتدای پروژه، همراه با الهام و سارینا از تیم پژوهش کاربر، تست کاربردپذیری را طراحی و اجرا کردیم تا بفهمیم کاربران چطور دنبال این قابلیت می‌گردند و در کدام نقاط مسیر دچار ابهام می‌شوند.بعد از تحلیل نتایج، با همکاری پرنیا، مدیر محصول، دامنه تغییرات فاز اول، اولویت‌ها و معیارهای موفقیت را مشخص کردیم.بینش‌های اولیهما می‌دانستیم که بعضی کاربران انتقال‌های مالی تکرارشونده دارند. اما سؤال اصلی این بود:اگر نیاز وجود دارد، چرا استفاده از انتقال خودکار پایین است؟برای پاسخ به این سؤال، با همکاری تیم پژوهش کاربر، یک تست کاربردپذیری با ۱۰ کاربر اجرا کردیم.هدف ما این بود که ببینیم کاربران چطور قابلیت انتقال خودکار را پیدا می‌کنند.یافته‌ها نشان دادند که کشف‌پذیری ویژگی انتقال خودکار پایین است:۳ نفر بدون کمک پژوهشگر اصلاً موفق به پیدا کردن این ویژگی نشدند.۵ نفر در تلاش اول نتوانستند قابلیت انتقال خودکار را پیدا کنند.۴ نفر پس از چند تلاش وارد لیست انتقال‌های خودکار شدند، اما چون نقطه شروع مشخصی برای ساخت انتقال جدید وجود نداشت، نتوانستند کار را ادامه دهند.علاوه بر این، در ارزیابی اکتشافی (Heuristic Evaluation) که با همراهی سایر اعضای تیم انجام شد، مشخص شد این ویژگی از منظر «آزادی و کنترل کاربر» و «انعطاف‌پذیری و کارایی» ضعف‌های جدی دارد؛ به‌ویژه در وظایفی مثل ویرایش یا غیرفعال‌کردن یک انتقال خودکار.نتایج ارزیابی اکتشافی و تست کاربردپذیری، با حفظ محرمانگی دادهتعیین تمرکز پروژهبعد از مرور یافته‌ها، واضح بود که نمی‌توانیم همه مشکلات تجربه انتقال خودکار را هم‌زمان حل کنیم. این قابلیت در بخش‌های مختلفی نیاز به بهبود داشت. بنابراین همراه با پرنیا، مدیر محصول، دامنه فاز اول را محدود کردیم و تمرکز فاز اول را روی ایجاد یک نقطه شروع واضح برای ساخت انتقال خودکار قرار دادیم.این تصمیم کمک کرد به‌جای بازطراحی کامل همه سناریوها، روی بخشی تمرکز کنیم که هم برای کاربر مانع اصلی بود، هم می‌توانست بیشترین اثر را روی KPIهای محصولی داشته باشد.چرا این مسئله مهم بود؟برای کاربرانی که انتقال‌های تکرارشونده انجام می‌دادند، انتقال خودکار می‌توانست چند ارزش اصلی ایجاد کند:اصطکاک کمتری در انجام کارهای مالی تکراری تجربه کنند.احتمال فراموشی یا تأخیر در پرداخت را کاهش دهند.تجربه‌ای قابل‌اعتمادتر و راحت‌تر در مدیریت مالی شخصی داشته باشند.از سمت کسب‌وکار هم استفاده بیشتر از این قابلیت اهمیت داشت، چون می‌توانست:تعامل معنادارتر کاربر با محصول را افزایش دهدبه بهبود retention کمک کند.ارزش روزمره بلو را در زندگی مالی کاربر پررنگ‌تر کند.بنابراین سؤال اصلی ما این بود:چطور می‌توانیم کاربرانی را که الگوی انتقال دوره‌ای دارند، در لحظه مناسب، به استفاده از انتقال خودکار هدایت کنیم؟راه‌حل اول: بهبود کشف‌پذیری و دسترسی‌پذیری با معرفی زمینه‌ای(Contextual Feature Discovery)در تست کاربردپذیری، وقتی از کاربران خواستیم یک انتقال خودکار بسازند، بسیاری از آن‌ها به صفحه Hub رفتند و آنجا دنبال این قابلیت گشتند. در نگاه اول، اضافه‌کردن «انتقال خودکار» به Hub می‌توانست ساده‌ترین راه‌حل باشد؛ چون با مدل ذهنی بخشی از کاربران هم‌خوانی داشت.صفحه Hub - سرویس‌های پرتکرار بلوبانکاما این راه‌حل با استراتژی محصول هم‌راستا نبود.صفحه Hub جای سرویس‌های اصلی و پرتکرار بلو بود. داده‌های تیم Data نشان می‌داد انتقال خودکار با وجود ارزشمند بودن، پتانسیل استفاده پرتکرار روزانه یا هفتگی ندارد. از نظر اولویت محصولی هم به‌اندازه‌ای نبود که یک جایگاه مستقل در Hub بگیرد.بنابراین تصمیم گرفتیم به‌جای اضافه‌کردن قابلیت به یک نقطه عمومی، آن را در جایی نشان دهیم که کاربر واقعاً به آن نیاز نزدیک می‌شود:مسیر انتقال پولفرض ما این بود که کاربر هنگام انجام انتقال، در لحظه تصمیم‌گیری قرار دارد. او همان‌جا تصمیم می‌گیرد که این انتقال فقط یک‌بار انجام شود یا قرار است در آینده تکرار شود. پس بهترین زمان برای معرفی انتقال خودکار، همان لحظه‌ای بود که کاربر در حال ساخت یک انتقال عادی است.برای این کار، چند Variant طراحی کردیم تا بفهمیم کدام نقطه ورود:بهتر دیده می‌شودکمتر مزاحم مسیر انتقال عادی استکاربران بیشتری را به ساخت انتقال خودکار موفق می‌رساندطرح‌های انتخاب شده برای تست A/Bاعتبارسنجی با A/B Testبرای انتخاب بهترین نسخه، یک A/B Test طراحی کردیم. هدف تست این بود که عملکرد Variantها را روی دو شاخص اصلی بسنجیم:کشف‌پذیری قابلیت انتقال خودکارتعداد انتقال‌های خودکار موفق ساخته‌شدهاین تست به‌مدت یک ماه و با سطح اطمینان ۹۵٪ اجرا شد. برای اینکه گروه‌ها قابل مقایسه باشند، رفتارهای مرتبط با انتقال خودکار، مثل داشتن انتقال‌های تکرارشونده یا سابقه استفاده از این قابلیت، در بالانس گروه‌ها لحاظ شد.نتایج نشان داد Variant B بیشترین کشف‌پذیری را دارد و تقریباً ۲.۵ برابر بیشتر از سایر Variantها توسط کاربران انتخاب می‌شود. البته یک نکته مهم وجود داشت: نرخ تکمیل Variant B نسبت به بعضی گزینه‌ها پایین‌تر بود. اما چون KPI اصلی ما فقط ورود به مسیر نبود، بلکه تعداد انتقال‌های خودکار موفق ساخته‌شده بود، Variant B در نهایت بهترین عملکرد را داشت./*برخی از داده‌های این بخش، به‌دلیل رعایت قرارداد محرمانگی، از محتوای کیس‌استادی حذف شده است. */انتخاب Variant B به‌عنوان نقطه شروع ویژگی انتقال خودکارراه‌حل دوم: نقطه شروع از Empty Stateدر تست کاربردپذیری دیدیم که بعضی کاربران بعد از چند تلاش، وارد لیست انتقال‌های خودکار می‌شوند؛ اما چون هنوز انتقالی نساخته‌اند، با یک صفحه خالی روبه‌رو می‌شوند. مسئله این بود که Empty State فقط خالی‌بودن لیست را نشان می‌داد و هیچ مسیر واضحی برای شروع ساخت انتقال خودکار نداشت. به همین دلیل، ۴ نفر از کاربران با وجود اینکه به صفحه درست رسیده بودند، نتوانستند کار را ادامه دهند.برای حل این مشکل، Empty State را به یک نقطه شروع تبدیل کردیم. یک CTA واضح با عنوان «انتقال خودکار جدید» به صفحه اضافه کردیم تا کاربر بتواند همان‌جا اولین انتقال خودکارش را بسازد.افزودن دکمه CTA در Empty State کاربر را از بن‌بست نجات می‌دهدنتایجیک ماه بعد از انتشار تغییرات، شاخص‌های اصلی استفاده از انتقال خودکار رشد قابل‌توجهی داشتند.نرخ Activation انتقال خودکار از ۰.۴۳٪ به ۰.۶۳٪ رسید؛ یعنی حدود ۴۶.۵٪ رشد نسبی. همچنین نرخ تبدیل کاربران به انجام تراکنش موفق از ۰.۲۵٪ به ۰.۳۶٪ افزایش پیدا کرد؛ معادل حدود ۴۴٪ رشد نسبی.این رشد نشان داد که مشکل اصلی، نبود نیاز یا کم‌ارزش بودن قابلیت نبود. کاربران رفتارهای تکرارشونده داشتند و انتقال خودکار می‌توانست برایشان مفید باشد؛ اما قابلیت در جای مناسبی دیده نمی‌شد. مهرداد کشوری مهرداد کشوری Mon, 25 May 2026 09:10:47 +0330 https://virgool.io/@Mehrdad_Design/%D8%A8%D9%84%D9%88%D8%A8%D8%A7%D9%86%DA%A9-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D9%88%DB%8C%DA%98%DA%AF%DB%8C-%D8%AF%D9%8F%D9%86%DA%AF-c4g7s3khkv1f-c4g7s3khkv1f سفر، کافه رفتن و شام خوردن با دوستان، لحظه‌هایی‌اند که دوست داریم بی‌دغدغه از آن‌ها لذت ببریم. اما معمولاً در پایان این لحظات خوب، جملات تکراریِ «کی حساب می‌کنه؟» یا «سهم من چقدر شد؟»، سر و کله‌شان پیدا می‌شود و خیلی راحت حال‌وهوای دورهمی را به یک چالش مالی تبدیل می‌کند.ویژگی دُنگ در بلوبانک برای حل همین مسئله طراحی شد؛ پاسخی به یک نیاز واقعی کاربر و فرصتی برای ایجاد تعامل و بازگشت بیشتر کاربران به محصول. در این کیس‌استادی توضیح می‌دهم که چگونه مسئله را دقیق‌تر صورت‌بندی کردیم، ایده‌های اولیه را سنجیدیم و به طراحی نسخه‌ی MVP رسیدیم.لیست گروه‌ها، لیست هزینه‌ها و صفحه تقسیم دُنگنقش منمن به‌عنوان طراح محصول، هدایت طراحی MVP دُنگ را از مرحله‌ی تعریف مسئله تا تحویل نهایی برعهده داشتم.تعریف MVP و اولویت‌بندی سناریوهاهمراه با پرنیا، مدیر محصول، محدوده‌ی MVP، معیارهای موفقیت، سناریوهای اصلی و نحوه‌ی انتشار را مشخص کردیم.سنجش فرضیات و پیدا کردن نقاط ابهامبا همکاری الهام، پژوهشگر تجربه کاربری، فرضیه‌های اصلی را از طریق تست کاربردپذیری و ارزیابی اکتشافی سنجیدیم و نقاط اصطکاک تجربه را شناسایی کردیم.طراحی جریان‌های اصلیبا بازبینی چندباره‌ی وایرفریم‌ها و دریافت بازخورد تیم، جریان‌ها را ساده‌تر کردم و الگوهای تعاملی را با زبان طراحی بلو هم‌راستا نگه داشتم.هماهنگی با تیم توسعه در اجرااز ابتدای مسیر با تیم توسعه در ارتباط بودم تا راه‌حل‌ها با محدودیت‌های فنی سازگار باشند و کیفیت اجرا حفظ شود.بینش‌های اولیه از رفتار کاربرانتقریباً همه‌ی اعضای تیم تجربه‌ی پرداخت‌های گروهی را داشتیم، اما نمی‌خواستیم مسئله را فقط بر اساس تجربه‌ی شخصی تعریف کنیم. برای همین، همراه با الهام، پژوهشگر تجربه کاربری، با ۱۵ کاربر در موقعیت‌های واقعی مصاحبه کردیم تا ببینیم مردم در عمل هزینه‌های مشترک را چگونه مدیریت می‌کنند.در اغلب گفتگوها، الگوی پرداخت تقریباً یکسان بود: یک نفر هزینه را پرداخت می‌کرد، عکس رسید را در گروه می‌فرستاد و بقیه سهم‌شان را می‌دادند.اما مسئله‌ی اصلی بعد از پرداخت شروع می‌شد:۱۲ نفر تمایلی به نقش مادرخرج نداشتند؛ نه به‌خاطر خودِ پرداخت، بلکه به‌خاطر پیگیری بعد از آن.۵ نفر تجربه‌ی تسویه‌ی دیرهنگام داشتند که در بیشتر موارد از فراموشی می‌آمد.۶ نفر گفتند تقسیم ناعادلانه هزینه یا پرداخت‌نشدن سهم بعضی افراد، گاهی به روابط دوستانه آسیب زده است.۲ نفر هم در سفرهای گروهی از Splitwise برای ثبت و تسویه‌ی هزینه‌ها استفاده کرده بودند.چالشیافته‌ها نشان داد مسئله فقط محاسبه‌ی سهم افراد نیست؛ تعارف، رودربایستی و پیگیری پرداخت هم بخش مهمی از ماجراست.برای بلو فرصتی بود تا فراتر از ابزارهای مالی فردی حرکت کند و یکی از سناریوهای پرتکرار مالی، که معمولاً بیرون از محصول مدیریت می‌شد، به یک تجربه‌ی یکپارچه درون محصول تبدیل کند.چطور می‌توانستیم به کاربران کمک کنیم خرج‌های گروهی را بدون دردسر تقسیم و تسویه کنند؟تعریف دامنه مسئلهبرای تعریف دامنه‌ی MVP، همراه با الهام و پرنیا سناریوهای هزینه‌ی مشترک را به سه دسته تقسیم کردیم:رستوران یا کافهمعمولاً یک نفر پرداخت می‌کند و بعد سهم بقیه را می‌گیرد. تعداد افراد کم است، اما سهم‌ها می‌تواند مساوی یا متفاوت باشد. چون این موقعیت اغلب بین دوستان رخ می‌دهد، حساب‌وکتاب در آن می‌تواند معذب‌کننده باشد.سفر گروهیهزینه‌ها متنوع‌اند؛ از اقامت و بنزین تا غذا، بلیط و خرید. همچنین ممکن است چند نفر در نقاط مختلف سفر پرداخت کرده باشند، بنابراین جمع‌بندی هزینه‌ی هر نفر اهمیت زیادی پیدا می‌کند.خانه و هم‌خانههزینه‌ها متنوع‌اند؛ از اقامت و بنزین تا غذا، بلیط و خرید. همچنین ممکن است چند نفر در نقاط مختلف سفر پرداخت کرده باشند، بنابراین جمع‌بندی هزینه‌ی هر نفر اهمیت زیادی پیدا می‌کند.این دسته‌بندی کمک کرد تصمیم‌های طراحی را بر اساس نیازهای هر موقعیت بررسی کنیم.تصمیم طراحی اول: مدل اشتراک‌گذاریدر قدم اول باید مشخص می‌کردیم کاربران هزینه‌های مشترک را در چه ساختاری مدیریت کنند.گزینه اول: تقسیم یک تراکنشدر این مدل، کاربر بعد از پرداخت می‌توانست از داخل جزئیات تراکنش، مبلغ را با دوستانش تقسیم کند.نسخه اول - مدل اشتراک‌گذاری تک تراکنشاین مسیر سریع و ساده بود و برای هزینه‌های موردی خوب عمل می‌کرد، اما یک ضعف مهم داشت: هر تقسیم به همان یک تراکنش محدود می‌ماند و فضایی ماندگار برای پیگیری هزینه‌ها شکل نمی‌گرفت.گزینه‌ی دوم: ساختن گروهدر این مدل، کاربر یک گروه می‌ساخت، دوستانش را دعوت می‌کرد و همه‌ی هزینه‌های مشترک در همان فضا ثبت و مدیریت می‌شد.نسخه دوم: مدل به اشتراک‌گذاری هزینه‌ها در گروهاین مسیر در شروع کمی پرزحمت‌تر بود، اما برای سفر و دورهمی‌های تکرارشونده ساختاری منظم‌تر و قابل‌پیگیری‌تر فراهم می‌کرد.انتخاب نهایی: مدل گروهیمصاحبه‌ها نشان داد بخش زیادی از هزینه‌های مشترک در یک جمع نسبتاً ثابت تکرار می‌شود؛ بنابراین تقسیم یک‌باره برای این الگو کافی نبود. از طرف دیگر، یکی از معیارهای موفقیت این ویژگی افزایش بازگشت کاربر بود و مدل گروهی می‌توانست فضایی مشترک و ماندگار بسازد که کاربر برای پیگیری و تسویه به آن برگردد. این تصمیم با الگوی محصولاتی مثل Revolut و Google Pay هم هم‌راستا بود.در نهایت، با جمع‌بندی این بینش‌ها با پرنیا و تیم، تصمیم گرفتیم MVP را بر پایه‌ی مدل گروهی طراحی کنیم.تصمیم طراحی دوم: دعوت به گروهبعد از انتخاب مدل گروهی، سؤال بعدی این بود که کاربر چطور دوستانش را به گروه اضافه کند؟بلو از قبل قابلیتی برای انتقال پول از طریق شماره تلفن داشت؛ اگر دو نفر شماره‌ی هم را ذخیره کرده بودند و هر دو کاربر بلو بودند، می‌توانستند فقط با شماره تلفن برای هم پول بفرستند. به همین دلیل، استفاده از فهرست مخاطبان در نگاه اول سریع‌ترین گزینه به نظر می‌رسید.گزینه‌ی اول: دعوت از طریق مخاطباناین مسیر برای گروه‌های کوچک و صمیمی بسیار مناسب بود. کاربر می‌توانست فرد موردنظرش را سریع پیدا کند و تقریباً بی‌زحمت او را به گروه اضافه کند.دعوت به گروه - مخاطبین بلوییاما بررسی داده‌ها با کمک سحر، از تیم دیتا، نشان داد بخش قابل‌توجهی از کاربران دسترسی به مخاطبان را فعال نکرده‌اند. علاوه بر این، کاربران PWA به‌دلیل محدودیت‌های پلتفرم اساساً به این قابلیت دسترسی نداشتند. بنابراین اگر فقط به مخاطبان متکی می‌ماندیم، بسیاری از کاربران در همان قدم اول متوقف می‌شدند.گزینه‌ی دوم: دعوت از طریق لینکلینک دعوت انعطاف بیشتری داشت؛ به‌ویژه برای کاربران PWA یا کسانی که همگام‌سازی مخاطبان را فعال نکرده بودند. این روش در گروه‌های موقت یا بزرگ‌تر، مثل سفرها و دورهمی‌ها، هم طبیعی‌تر به نظر می‌رسید.دعوت به گروه - لینک دعوتتصمیم نهاییدر نهایت هر دو مسیر را کنار هم قرار دادیم تا کاربر بسته به شرایطش انتخاب کند و هیچ‌کس از همان ابتدا به بن‌بست نخورد.تصمیم طراحی سوم: ثبت و نمایش هزینه‌هاپیچیده‌ترین بخش طراحی دُنگ، نحوه‌ی ثبت و نمایش هزینه‌های مشترک در گروه بود.در مصاحبه‌ها دیدیم مادرخرج معمولاً رسید یا مبلغ را در گروه تلگرام یا واتساپ می‌فرستاد تا بقیه سهم‌شان را پرداخت کنند. همین الگو برای ما به یک سرنخ طراحی تبدیل شد: به‌جای نمایش هزینه‌ها در قالب یک لیست خشک، آن‌ها را در فضایی شبیه چت نشان دادیم؛ جایی که خرج مشترک بیشتر شبیه یک گفت‌وگوی جمعی بود تا یک جدول بدهی.مدل نمایش لیست هزینه‌ها به‌صورت چتدر طراحی اولیه‌ی ثبت هزینه هم تلاش کردم همه‌چیز سریع و ساده باشد:کاربر تراکنشی را از لیست تراکنش‌ها انتخاب می‌کردند یا مبلغ را دستی وارد می‌کردخودش به‌طور پیش‌فرض به‌عنوان مادرخرج در نظر گرفته می‌شدسیستم مبلغ را میان اعضای گروه تقسیم می‌کرد.در صورت نیاز هم کاربر می‌توانست سهم هر نفر را تغییر دهد یا بعضی اعضا را از تقسیم حذف کند.جریان افزودن تراکنش به گروه: انتخاب تراکنش و مشخص کردن سهم‌هااما تست‌ها نشان داد سادگی همیشه به معنای وضوح نیست.با همکاری الهام، در دو مرحله تست کاربردپذیری با ۱۰ کاربر، متوجه شدیم وقتی پرداخت‌کننده شخص دیگری بود، بعضی کاربران فراموش می‌کردند مادرخرج را از حالت پیش‌فرض تغییر دهند. برای کاهش این خطای مفهومی، انتخاب مادرخرج را به یک مرحله‌ی مستقل تبدیل کردیم. این تصمیم یک قدم به فرایند اضافه می‌کرد، اما در عمل خطای کاربر را به‌طور معناداری کاهش داد.بهبود جریان انتخاب مادرخرجمسئله‌ی دوم به گزینه‌ی «تقسیم دوباره» مربوط می‌شد. این گزینه زمانی به کار می‌آمد که کاربر در وارد کردن سهم‌ها اشتباه کرده بود و می‌خواست مبلغ دوباره بین اعضا تقسیم شود. اما ۴ نفر از ۱۰ کاربر فقط با دیدن آیکن، متوجه عملکرد آن نمی‌شدند. برای همین، کنار آیکن یک برچسب متنی اضافه کردیم تا کاربر مجبور به حدس‌زدن نباشد.بهبود کشف‌پذیری دکمه تقسیم دوبارهتصمیم طراحی چهارم: یادآوری پرداخت دُنگدر پژوهش اولیه، یادآوری بدهی یکی از دغدغه‌های پرتکرار کاربران بود. از یک طرف، به‌خاطر تعارف و رودربایستی، یادآوری مستقیم برایشان معذب‌کننده بود؛ از طرف دیگر، بعضی‌ها هم می‌گفتند واقعاً فراموش می‌کنند که به کسی بدهکارند.برای همین، یکی از اهداف اصلی ما این بود که پیگیری بدهی داخل محصول انجام شود. زیرا در غیر این صورت:کاربران باید بدهی‌ها را بیرون از محصول دنبال می‌کردندارزش واقعی ویژگی دُنگ به‌خوبی درک نمی‌شد و این ویژگی بیشتر به ابزار ثبت هزینه تبدیل می‌شداحتمال کاهش نرخ تسویه وجود داشتچالش اصلی این بود که یادآوری، حس طلب‌کاری ایجاد نکند.در قدم اول روی لحن پیام‌ها کار کردیم و متن نوتیفیکیشن‌ها را کوتاه، مستقیم و تا حد ممکن خنثی نگه داشتیم. اما بازخورد کاربران نشان داد یادآوری جمعی همیشه مناسب نیست؛ گاهی مادرخرج نمی‌خواهد برای همه‌ی اعضا نوتیفیکیشن بفرستد. به همین دلیل، کنترل ارسال یادآوری را به خودِ کاربر دادیم تا مشخص کند این پیام برای چه کسانی فرستاده شود.یادآوری پرداخت دُنگتصمیم طراحی پنجم: پرداخت و محدودیت‌هادر تجربه‌ی ایده‌آل، دوست داشتیم کاربر با یک دکمه تمام بدهی‌اش را با گروه تسویه کند. اما این ایده در MVP با یک محدودیت مهم روبه‌رو شد: تسویه با کل گروه در پشت‌صحنه به چند پرداخت جداگانه به افراد مختلف تبدیل می‌شد، در حالی که الزامات بانکی ایجاب می‌کرد هر پرداخت به یک شخص مشخص و با رسید مستقل انجام شود.به همین دلیل، تصمیم گرفتیم مسئله را در سطح فردبه‌فرد حل کنیم: کاربر بتواند وضعیت مالی خود را با هر عضو گروه ببیند و بدهی‌اش را با همان فرد تسویه کند.این راه‌حل یک قدم با تجربه‌ی ایده‌آل فاصله داشت، اما همچنان فرایند پرداخت را ساده و قابل‌فهم نگه می‌داشت.تسویه با افراد گروهانتشار نسخه MVPبرای کاهش ریسک، دُنگ ابتدا به‌مدت دو ماه فقط برای کارکنان شرکت فعال شد. هدف این مرحله شناسایی باگ‌ها، بررسی رفتار واقعی کاربران، تست نوتیفیکیشن‌ها و اطمینان از صحت جریان پرداخت بود.در این دوره، شاخص‌هایی مثل ساخت گروه، ثبت هزینه، دعوت اعضا و پرداخت‌ها روزانه پایش می‌شد. پس از رفع مسائل اصلی، دُنگ در بهمن ۱۴۰۲ برای همه‌ی کاربران بلو منتشر شد.در ماه اول لانچ عمومی، نرخ استفاده اولیه یا Adoption حدود ۱.۲٪ بود. از آنجا که کمی بعد از لانچ عمومی از تیم جدا شدم، به داده‌های بلندمدت‌تر دسترسی نداشتم؛ بنابراین تحلیل نتایج را به همین داده اولیه محدود می‌کنم.سپاس‌گزاریطراحی و پیاده‌سازی «دُنگ»، ماحصل تلاش گروهی از متخصصان باانگیزه بود که با چالش‌های فنی و تجربه‌کاربریِ پیچیده‌ای دست‌وپنج نرم کردند. از همکارانم که در این مسیر هم‌قدم من بودند، صمیمانه سپاس‌گزارم:پژوهش و محصول: از الهام تراکمه عزیز بابت پژوهش‌های عمیقِ کاربری که چراغ راهِ طراحی بود، و پرنیا کاملیان بابت مدیریت و هدایت محصول در مسیر درستی که به هدف نزدیک شد.تیم طراحی: از راهنمایی‌های ابی آقاپور (Design Lead) که در چالش‌های دیزاین همیشه راهگشا بود، و همچنین همکاران طراحم دانیال شیرآلی، علیرضا کیان، مهدی مشتاقی، داریوش حبیب‌پور و آناهیتا آقایی که با بازخوردهای سازنده خود، کیفیت خروجی را ارتقا دادند.تیم فنی: پیاده‌سازی بی‌نقصِ این جریان مدیون تلاش‌های بی‌وقفه تیم‌های فنی بود. از امیرعباس موسویان (Chapter Lead) بابت هماهنگی‌های موثر و همچنین همکاران عزیزم رامین بهلولی، مرتضی تقدمی، وحید قدیری، مهشید گنجه، حسین حاجی‌میرزا، رضا اکبری، علیرضا نظری و مهدی دلاور که در پیاده‌سازی سناریوهای پلتفرم‌های iOS، Android و PWA زحمات زیادی کشیدند.در نهایت، از تک‌تک عزیزانی که در این مسیر در کنار من بودند و با همفکری و حمایتشان به این پروژه جان بخشیدند، سپاس‌گزارم. دُنگ نتیجه‌ی یک کار تیمی بود. مهرداد کشوری مهرداد کشوری Thu, 21 May 2026 13:40:50 +0330 https://virgool.io/@Mehrdad_Design/%D8%A8%DB%8C%D9%85%D9%87-%D8%AE%D9%88%D8%AF%D8%B1%D9%88-%D8%B9%D8%A8%D9%88%D8%B1-%D8%A7%D8%B2-%D8%A8%D9%86-%D8%A8%D8%B3%D8%AA-dw3d8okbbhcq-dw3d8okbbhcq در اواسط سال ۲۰۲۴، نسخه MVP لوکین‌شور (LookInsure) در امارات منتشر شد. هدف ما این بود که خرید بیمه خودرو نباید بیشتر از چند دقیقه طول بکشد؛ رانندگان باید بتوانند در یک پلتفرم آنلاین، گزینه‌های مختلف را با هم مقایسه کنند و بیمه مناسب خودروی خود را بخرند.پس از انتشار MVP، با بررسی داده‌ها متوجه شدیم که به‌طور میانگین، هر ماه حدود ۲۱٪ از کاربران چون مالک رسمی خودرو شناخته نمی‌شوند، نمی‌توانند وارد صفحه قیمت شوند.در این کیس‌استادی توضیح می‌دهم که چطور با طراحی یک مسیر ساده برای این سناریو، توانستیم بخشی از این ریزش را کاهش دهیم و میانگین GMV آنلاین ماهانه را ۴٪ افزایش دهیم.نقطه شکست - اگر API پاسخ ندهد، کاربر از مسیر آنلاین خارج می‌شودزمینه: فرایند استعلامبرای اینکه کاربر به صفحه قیمت برسد، به اطلاعات خودروی او نیاز داشتیم.در MVP برگ برنده ما نسبت به رقبا این بود که کاربر مجبور نبود فرم طولانی مشخصات خودرو را پُر کند. به‌جای وارد کردن مدل، سال ساخت، ارزش خودرو و جزئیات دیگر، فقط کافی بود کدملی (Emirates ID) و شمارهٔ پلاک را وارد کند تا اطلاعات خودرو از APIهای دولتی امارات دریافت شود.فرآیند استعلام قیمتنقش مندر May 2025، به مدت دو هفته مسئول طراحی تجربه کاربرانی بودم که هنگام خرید بیمه با مشکل تطابق مالکیت خودرو مواجه می‌شدند.در ابتدا، همراه با الهام، مدیر محصول، محدوده مسئله و معیارهای موفقیت را مشخص کردیم. سپس با فاطمه و علیرضا از تیم‌های پشتیبانی و فروش گفت‌وگو کردم تا بهتر بفهمم کاربرانی که داخل محصول به بن‌بست می‌رسند، در تعاملات آفلاین چگونه راهنمایی می‌شوند و تیم فروش معمولاً این مسئله را چطور حل می‌کند.در مرحله طراحی نیز با Nivin، طراح UX Writing، همکاری نزدیکی داشتم. متن‌ها و پیام‌های داخل محصول باید با زمینه فرهنگی و انتظارات کاربران عرب‌زبان هم‌راستا می‌بود.چالشاتصال به سامانه‌های دولتی امارات، مسیر استعلام قیمت را ساده‌تر کرده بود؛ اما یک نقطه حساس داشت:همه‌چیز به دقت اطلاعات ورودی وابسته بود.اگر کاربر حتی یک رقم را اشتباه وارد می‌کرد، یا کدملی‌ وارد شده با شمارهٔ پلاک هم‌خوانی نداشت، مالکیت خودرو تأیید نمی‌شد و کاربر نمی‌توانست مسیر خرید آنلاین را ادامه دهد.در MVP، برای اینکه این کاربران را به‌طور کامل از دست ندهیم، اطلاعات تماسشان را دریافت می‌کردیم تا تیم فروش به‌صورت آفلاین پیگیری کند. اما داده‌ها نشان دادند که فقط ۴۱٪ از این کاربران شمارهٔ تماس خود را ثبت می‌کنند. با وجود این ریزش، همین گروه ۱۰٪ از فروش آفلاین ماهانه را ایجاد می‌کردند. این یعنی بخشی از کاربرانی که احتمال خرید بالایی داشتند، به‌جای ادامه دادن یک مسیر سریع و آنلاین، وارد مسیری کند، پرهزینه‌ و وابسته به پیگیری نیروی انسانی می‌شدند.چطور می‌توانیم تعداد کاربرانی را که به دلیل عدم تطابق کدملی و شمارهٔ پلاک از مسیر خرید آنلاین خارج می‌شوند، کاهش دهیم؟صفحه لید - وارد کردن اطلاعات تماس برای پیگیری آفلاینبینش‌های اولیهدر ابتدا می‌خواستم بفهمم چرا کاربر به‌جای صفحه قیمت، به صفحه عدم تطابق مالکیت می‌رسد. با بررسی ۱۵ تماس فروش و گفت‌وگو با تیم علیرضا از تیم فروش، سه دلیل اصلی مشخص شد:کاربر اطلاعات را اشتباه وارد می‌کردکاربر نمی‌دانست باید کدملی مالک رسمی خودرو را وارد کندکاربر مالک رسمی خودرو نبودنکته مهم این بود که تیم فروش معمولاً می‌توانست این مشکل را در چند دقیقه حل کند. پس مسئله پیچیده یا غیرقابل حل نبود؛ فقط محصول نمی‌توانست این سناریو را درست مدیریت کند.بعد سراغ داده‌ها و ویدیوهای ضبط‌شده از رفتار کاربران رفتم. حدود ۵۹٪ از کاربران وقتی به‌جای دیدن قیمت‌ها وارد صفحه وارد کردن اطلاعات تماس می‌شدند، صفحه را ترک می‌کردند. همچنین حدود ۲۱٪ از کاربران،پس از وارد کردن اطلاعات تماس، دوباره وارد مسیر استعلام می‌شدند؛ احتمالاً چون فکر می‌کردند این دفعه می‌توانند قیمت بگیرند.بر اساس این یافته‌ها، مسئله را به سه بخش تقسیم کردم:جلوگیری از خطای کاربرچطور احتمال ورود اطلاعات اشتباه را کمتر کنیم؟کمک به کاربر برای اصلاح خطااگر خطا رخ داد، چطور به کاربر کمک کنیم بدون ترک مسیر، اطلاعات خود را اصلاح و دوباره تلاش کند؟طراحی مسیر برای کاربری که هنوز مالک خودرو نیستنداگر کاربر واقعاً مالک رسمی خودرو نیست، آیا می‌توانیم برای او یک مسیر معتبر و قانونی طراحی کنیم تا همچنان به قیمت برسد؟فرضیه اول: اشتباه جبران ناپزیرِ کاربراحتمال اشتباه کاربر در وارد کردن اطلاعات زیاد بود؛ چون کاربر باید شمارهٔ پلاک و کدملی ۱۵ رقمی را وارد می‌کرد و کوچک‌ترین خطا در ثبت این اطلاعات، می‌توانست کل فرایند استعلام را با شکست مواجه کند.فکر می‌کردم اگر به‌جای هدایت مستقیم کاربر به فرم اطلاعات تماس، امکان بازبینی و ویرایش اطلاعات را در اختیار او قرار دهیم، احتمالاً می‌تواند اشتباه خود را اصلاح کند و مسیر آنلاین را ادامه دهد.به همین دلیل، صفحه‌ی ویرایش اطلاعات را به‌گونه‌ای طراحی کردم که کاربر بتواند:متوجه بروز خطا شوداطلاعات پلاک یا کدملی خود را بازبینی و اصلاح کنداز سوی دیگر، این احتمال هم وجود داشت که کاربر اطلاعات را درست وارد کرده باشد، اما مالک رسمی خودرو نباشد. در این صورت، کاربر به فرم ثبت اطلاعات تماس هدایت می‌شد.صفحه ویرایش اطلاعات پلاک و کدملیهمچنین داده‌های به‌دست‌آمده از رفتار کاربران نشان می‌داد که بسیاری از آن‌ها متوجه نمی‌شوند باید کدملی مالک خودرو را وارد کنند. به همین دلیل، صفحه‌ی ورود کدملی را با دو تغییر ساده بازطراحی کردم:شفاف کردن عنوان صفحهعنوان صفحه که در نسخه‌ی اولیه روی کدملی راننده متمرکز بود، به کدملی مالک خودرو تغییر کرد.شفاف کردن عنوان فیلد ورودیعنوان فیلد ورودی نیز از کدملی به کدملی مالک خودرو تغییر پیدا کرد.این تغییرات کوچک کمک می‌کردند کاربر زودتر متوجه شود سیستم به دنبال اطلاعات مالک رسمی خودرو است.بهبود تجربه‌نویسی برای کاهش خطای کاربرفرضیه دوم: کاربر هنوز مالک خودرو نیستگروه دیگری از کاربران نیز وجود داشتند که هنوز مالک رسمی خودرو نبودند. این افراد به‌تازگی خودرو را خریداری کرده بودند، اما انتقال مالکیت آن هنوز در سیستم دولت امارات ثبت نشده بود. بررسی داده‌ها نشان می‌داد که این گروه کم‌تعداد نیستند و حدود ۹٪ از کاربران ماهانه ما را تشکیل می‌دهند.فرض من این بود که اگر برای این کاربران مسیر مشخصی طراحی کنیم، می‌توانیم بخشی بزرگتری از موارد عدم تطبیق را کاهش دهیم. با این حال، اجرای چنین راه‌حلی نیازمند بررسی‌های قانونی بود.در گفت‌وگو با اسامه از تیم فنی مشخص شد حتی وقتی Emirates ID و پلاک با هم تطابق ندارند، سرویس دولتی همچنان اطلاعات خودرو را برمی‌گرداند. اما از نظر قانونی، کاربر باید تأیید کند که هنوز مالک رسمی خودرو نیست.با درنظر گرفتن این ملاحظات، صفحه‌ی ویرایش اطلاعات را به‌گونه‌ای بهبود دادم که:اگر کاربر اطلاعات را اشتباه وارد کرده باشد، بتواند آن‌ها را اصلاح کنداگر هنوز مالک رسمی خودرو نباشد، از طریق مسیر جایگزین به صفحه‌ی استعلام قیمت هدایت شودبرای رفع ملاحظات قانونی،در مرحله دریافت مدارک (که پس از پرداخت انجام می‌شد) برای صدور بیمه‌نامه، سندی با عنوان Hiyaza Paper ار کاربر دریافت می‌کردیم که نشان می‌داد کاربر مالک خودرو است.طراحی مسیر جدید برای کاربرانی که مالک رسمی خودرو نیستندنتایجحدود ۸ هفته پس از پیاده‌سازی این تغییرات، نتایج این‌گونه بودند:۴۸٪ از کاربرانی که به صفحه عدم تطابق کدملی و شمارهٔ پلاک می‌رسیدند، با اصلاح پلاک یا کدملی خود، به مسیر آنلاین برگشتند.حدود ۲۲٪ از کاربران این صفحه، مالک رسمی خودرو نبودند. آن‌ها وارد مسیر جایگزین می‌شدند و به صفحه قیمت می‌رسیدند.وابستگی تماس تیم فروش به این کاربران حدود ۸۳٪ کاهش پیدا کرد که موجب کاهش هزینه‌های تیم فروش شد.با افزایش نرخ کاربرانی که به صفحه قیمت می‌رسیدند، GMV ماهانه آنلاین را بیش از ۴٪ افزایش دادیم. مهرداد کشوری مهرداد کشوری Fri, 15 May 2026 12:40:48 +0330 https://virgool.io/@Mehrdad_Design/case-studieslookinsureafter-payment-wqwjkx9hkzwb-wqwjkx9hkzwb-wqwjkx9hkzwb-wqwjkx9hkzwb-wqwjkx9hkzwb در سال 2024، لوکین‌شور (LookInsure) با این ایده‌ وارد بازار بیمه‌ امارات شد:خرید بیمه‌ خودرو نباید بیشتر از چند دقیقه طول بکشد. رانندگان باید بتوانند در یک پلتفرم آنلاین، گزینه‌های مختلف را مقایسه کنند و بیمه‌ی متناسب با خودرو خود را بخرند.سه ماه پس از عرضه‌ MVP، داده‌ها نشان داد محصول در مسیر درستی قرار گرفته و کاربران خریدشان را با موفقیت انجام می‌دهند؛ اما با بررسی داده‌های پشتیبانی مشخص شد ۳۹٪ کاربران بلافاصله پس از خرید، با پشتیبانی تماس می‌گیرند و می‌گویند هنوز بیمه‌نامه‌شان را دریافت نکرده‌اند.در این کیس‌استادی توضیح می‌دهم چگونه با پر کردن شکاف میان انتظار کاربر و واقعیت سیستم، شفافیت و اعتماد را به محصول بازگرداندیم و ۷۲٪ تماس‌های پس از خرید را کاهش دادیم.مسیر بهبود صفحه پرداخت موفقنقش منمن از May تا August سال 2024 (حدوداً ۴ ماه)، مسئولیت بازطراحی تجربه‌ی پس از خرید لوکین‌شور را برعهده داشتم.تعریف استراتژیدر شروع پروژه، همراه الهام (مدیر محصول) محدوده و اولویت‌ فازهای مختلف بازطراحی را مشخص کردم تا تا تمرکز تیم روی مهم‌ترین نقاط اصطکاک باشد.تحلیل دادهدر همکاری نزدیک با علیرضا از تیم عملیات و فاطمه از تیم پشتیبانی، داده‌ها و بازخورد کاربران را جمع‌آوری و تحلیل کردم. این تحلیل‌ها به بینش‌هایی رسید که مستقیماً تصمیم‌های طراحی و توسعه قابلیت‌های جدید را شکل داد.یکپارچگی تجربهبرای حفظ یکپارچگی تجربه، با یک UX Writer عربی‌زبان همکاری کردم تا پیام‌های درون‌محصول با زمینه فرهنگی کاربران عرب‌زبان هماهنگ باشد.چالشتقریبا نیمی از کاربران لوکین‌شور بلافاصله بعد از خرید بیمه خودرو، با پشتیبانی تماس می‌گرفتند و یک سوال تکراری می‌پرسیدند:"من پرداخت کردم، پس بیمه‌نامه من کجاست؟"از نگاه کاربر، پرداخت به معنای پایان سفر بود. او انتظار داشت بعد از پرداخت، بیمه‌نامه خودرو خود را دریافت کند. اما در واقعیت عملیاتی بازار بیمه امارات، صدور بیمه‌نامه آنی نبود. بعد از پرداخت، تیم عملیات باید با کاربر تماس می‌گرفت، مدارک را دریافت می‌کرد و اطلاعات را در پنل شرکت بیمه ثبت می‌کرد تا بیمه‌نامه صادر شود. این فرآیند، به دلیل وابستگی به تعامل انسانی، ممکن بود از چند دقیقه تا چند ساعت زمان ببرد.چالش اصلی ما همین شکاف بین انتظار کاربر و واقعیت سیستم بود.با وجود اینکه در صفحه پرداخت موفق به کاربران اطلاع می‌دادیم "تیم ما تا یک ساعت آینده با آن‌ها تماس می‌گیرد"، اما به‌طور میانگین روزانه ۳۹٪ کاربران پیش از تماس تیم ما، با پشتیبانی تماس می‌گرفتند. برخی هم این ابهام را در قالب بازخورد منفی در Google Reviews بازتاب می‌دادند.از طرفی، با رشد فروش در ماه سوم، این مسئله فشار زیادی بر تیم پشتیبانی ایجاد کرده بود و بخش قابل توجهی از ظرفیت تیم صرف پاسخ دادن به سوالات تکراری کاربران می‌شد.چطور می‌توانیم تجربه پس از خرید را طوری بازطراحی کنیم که کاربر پس از پرداخت، احساس اطمینان داشته باشد و نیازی به تماس با پشتیبانی نداشته باشد؟راه‌حل اولدر اولین قدم، ساده‌ترین فرضیه را آزمایش کردم؛ احتمال می‌دادم اگر کاربر پس از پرداخت، به‌وضوح ببیند که خریدش ثبت شده و از مرحله‌ بعدی مطلع باشد، با اطمینان بیشتری صفحه را ترک می‌کند و کمتر با پشتیبانی تماس می‌گیرد. به همین دلیل صفحه پرداخت موفق را با دو تغییر ساده بازطراحی کردم:برجسته‌کردن متن راهنما متن تیم ما با شما تماس می‌گیرد، در میان سایر محتوای صفحه گم شده بود. آن را از متن اصلی جدا کردم و جایگاه بالاتری به آن دادم تا توجه کاربر را جلب کند.نمایش وضعیت سفارشبخش جدیدی در صفحه اضافه کردم تا وضعیت سفارش را نشان دهد. در این بخش به کاربر اطلاع می‌دادم که سفارش او با موفقیت ثبت شده و باید منتظر تماس ما بماند.افزودن بخش وضعیت سفارش به صفحه پرداخت موفقدو هفته پس از پیاده‌سازی تغییرات، داده‌ها نشان داد نرخ تماس بعد از خرید کاربران تقریباً تغییری نکرده است. بررسی تماس‌ها نشان می‌داد سؤال کاربران همچنان همان است: "من پرداخت کردم، پس بیمه‌نامه‌ام کجاست؟"این نتیجه نشان داد احتمالا مشکل فقط رابط کاربری صفحه یا سلسله مراتب بصری نبود. حتی وقتی پیام واضح‌تر شد، باز هم حس اطمینانی که کاربر بعد از پرداخت نیاز داشت شکل نگرفت. بنابراین در قدم بعدی، به‌جای توضیح بیشتر، سراغ راه‌حلی رفتم که بتواند حس اطمینان را بازسازی کند.بینش‌‌هایی از رفتار کاربرانوقتی نسخه اول اثر معناداری نداشت، گوش دادن به تعدادی تماس پشتیبانی و بررسی بیش از ۶۰ ویدیو ضبط شده از رفتار واقعی کاربران، ما را به بینش‌‌های عمیق‌تری رساند.نیاز به تایید انسانیدر تماس‌های پشتیبانی نکته جالب این بود که کارشناس ما اطلاعات تازه‌ای به کاربران نمی‌داد؛ صرفا همان پیام صفحه پرداخت موفق را تکرار می‌کرد. اما شنیدن این توضیحات از زبان انسان، باعث اطمینان کاربران می‌شد.این رفتار نشان می‌داد متن راهنما در صفحه پرداخت موفق نامفهوم نبود، بلکه به‌تنهایی حس اطمینان را در کاربر ایجاد نمی‌کرد.عدم اطمینان از ثبت سفارشبررسی ویدیوهای ضبط‌شده نشان داد حدود ۱۹٪ از کاربران پس از پرداخت موفق، الگوی رفتاری خاصی دارند. آن‌ها پس از بازگشت به صفحه اصلی و جستجوی بی‌نتیجه برای یافتن تاریخچه سفارش‌ها، مجدداً وارد فرآیند خرید می‌شدند؛ اما این بار پس از رسیدن به مرحله پرداخت، مسیر را رها می‌کردند.این رفتار را به‌عنوان نشانه‌ای از اضطراب یا عدم اطمینان پس از خرید تفسیر کردم؛ کاربران احتمالا برای اطمینان از ثبت سفارش خود، دست به آزمون و خطا می‌زنند.راه‌حل دومبا درک نگرانی کاربران، به این نتیجه رسیدم که اگر بعد از پرداخت، یک تاییدیه‌ی فوری و معتبر به آن‌ها بدهیم تا از ثبت سفارش خود مطمئن شوند، احتمالا اضطرابشان کاهش یافته و کمتر با پشتیبانی تماس می‌گیرند.در MVP، قرار بود ایمیل این نقش را ایفا کند؛ اما داده‌ها نشان داد این روش ناکارآمد است؛ کاربران ایمیل‌ را بلافاصله چک نمی‌کنند.پس از بررسی گزینه‌هایی مثل بهبود مجدد رابط کاربری و یا ارسال پیام در واتساپ، در نهایت ارسال پیامک انتخاب شد؛ راهکاری که سریع‌تر دیده می‌شد، با عادات روزمره کاربران سازگار بود و نقش همان تأیید فوری را ایفا می‌کرد.چالش هزینه و توجیه منطق کسب‌وکارارسال پیامک برای لوکین‌شور هزینه عملیاتی داشت. برای توجیه این تصمیم، هزینه ارسال پیامک به همه خریداران در یک بازه دو هفته‌ای را محاسبه کردم. این هزینه تقریباً معادل هزینه روزانه پاسخ‌گویی تیم پشتیبانی به تماس‌های تکراری بود. بنابراین تصمیم گرفتم در یک دوره دو هفته‌ای تست، بلافاصله پس از پرداخت، به خریداران پیامک ارسال کنیم.طراحی کلماتبرای اثربخشی این راه‌حل، همه‌چیز به کلماتی بستگی داشت که انتخاب می‌کردیم. به دلیل محدودیت کاراکتر، باید در چند جمله کوتاه، هم ثبت سفارش را تأیید می‌کردیم و هم مرحله بعد را توضیح می‌دادیم.با همکاری بابک از تیم محتوا و Nivin (طراح تجربه‌نویسی)، متن پیامک بارها بازنویسی شد تا لحنی شفاف و اطمینان‌بخش داشته باشد:ارسال پیامک بلافاصله بعد از خرید موفقپس از دوره دو هفته‌ای تست، داده‌ موفقیت این راه‌حل را تایید کردند. نرخ تماس‌های پس از خرید از ۳۹٪ به ۲۴٪ کاهش پیدا کرده بود و آمار کاربرانی که از روی نگرانی دوباره اقدام به خرید می‌کردند از ۱۹٪ به حدود ۷٪ رسیده بود.عبور از راه‌حل‌های موقتما با کمک چند راه‌حل سریع، کم‌هزینه و اثرگذار، توانسته بودیم حجم تماس‌های پشتیبانی پس از خرید را کاهش دهیم؛ اما می‌دانستم این راه‌حل‌‌ها تنها یک مُسکن موقت هستند.در واقع ما فقط به کاربر اطمینان داده بودیم که «پول شما گم نشده، نگران نباشد، لطفاً منتظر بمانید!»، اما مشکل همچنان پابرجا بود:کاربر پس از پرداخت، انتظار دریافت فوری بیمه‌نامه‌اش را داشت.بنابراین در قدم بعدی، تمرکزمان روی کاهش زمان صدور بیمه‌نامه بود. با اینکه محدودیت‌های زیرساختی امکان صدور آنی بیمه‌نامه را فراهم نمی‌کرد، اما می‌توانستیم فرآیند صدور را سمت خودمان بهینه کنیم.بینش‌هایی از فرآیند صدور بیمه‌نامهبرای درک بهتر آنچه بعد از پرداخت اتفاق می‌افتاد، یک روز کنار تیم عملیات نشستم و مسیر سفارش‌ها را تا صدور بیمه‌نامه دنبال کردم. در این مشاهده، چند نقطه اصطکاک مهم آشکار شد:وابستگی صدور بیمه‌نامه به تعامل انسانیتیم عملیات برای دریافت مدارک و ارسال بیمه‌نامه با اکثر خریداران از طریق واتساپ در ارتباط بود. هر تبادل پیام به‌طور میانگین حدود ۳ تا ۴ دقیقه زمان می‌برد و در مواردی مثل پاسخ دیرهنگام کاربر یا ارسال مدارک ناقص این زمان طولانی‌تر می‌شد.توقف صدور در خارج از ساعات کاریتحلیل داده‌های فروش نشان داد ۳۱٪ سفارشات در ساعات غیراداری ثبت می‌شوند و فرآیند صدور آن‌ها تا روز کاری بعد متوقف می‌ماند. هم‌زمان، محدودیت منابع در تیم پشتیبانی باعث بی‌پاسخ ماندن تماس‌های شبانه شده بود. پنج بازخورد منفی طی یک ماه در Google Reviews این زنگ خطر را به صدا درآورد که کاربران از یک سرویس آنلاین انتظار خدمت‌رسانی لحظه‌ای دارند و توقف فرآیندها به دلیل اتمام ساعات کاری را نمی‌پذیرند.نگرانی درباره اعتماد و حریم خصوصیتیم عملیات برای تکمیل صدور بیمه‌نامه از خریداران می‌خواست مدارک و اطلاعات هویتی خود را از طریق واتساپ ارسال کنند. با اینکه این روش برای تیم عملیاتی سریع و در دسترس بود، اما برای بخشی از کاربران حس ناامنی ایجاد می‌کرد؛ این موضوع به‌ویژه برای مهاجران می‌توانست به کاهش اعتماد و تعلل در ارسال مدارک منجر شود.بعد از جمع‌بندی این یافته‌ها، با الهام (مدیر محصول) بررسی کردیم که انتقال دریافت مدارک از واتساپ به داخل محصول چه اثری بر زمان صدور و فشار عملیاتی دارد. برآورد ما این بود که اگر فقط ۴۰٪ از این رفت‌وبرگشت‌ها را کم کنیم:میانگین زمان صدور بیمه‌نامه حدود ۵ دقیقه کاهش پیدا می‌کند.روزانه تا ۱۵۰۰ درهم در هزینه‌های تیم عملیاتی صرفه‌جویی می‌شود.با رشد فروش، صدور بیمه‌نامه به بحران عملیاتی تبدیل نمی‌شود.تعریف معیارهای موفقیتطراحی ویژگی آپلود مدارکبرای طراحی نسخه اولیه این قابلیت فقط دو هفته زمان داشتیم، بنابراین تمرکزم روی تجربه‌ای ساده و کم‌اصطکاک بود. یکی از تصمیم‌های کلیدی این بود که دریافت مدارک بعد از پرداخت انجام شود، نه قبل از آن؛ قرار نبود فرایند خرید را طولانی‌ کنیم یا باعث ریزش کاربران قبل از خرید شویم.صفحه پرداخت موفق - نقطه شروع فرآیند آپلود مدارکنسخه اول: آپلود مرحله‌ای مدارکدر اولین قدم، با کمک فاطمه از تیم عملیات، مدارک موردنیاز برای صدور بیمه‌نامه را بررسی کردم. مشخص شد برای تکمیل این فرآیند، باید تصویر پشت و روی سه مدرک اصلی از کاربر دریافت شود.برای طراحی نسخه اولیه، تصمیم گرفتم در هر صفحه فقط یک مدرک را دریافت کنیم. این تصمیم به ما کمک می‌کرد بار شناختی کاربر را کاهش دهیم و فرآیند آپلود را، مخصوصاً در موبایل، ساده‌تر و قابل‌کنترل‌تر کنیم. از طرفی، احتمال سردرگمی، ارسال اشتباه یا رها کردن فرآیند را هم کاهش می‌دادیم.فرآیند آپلود مدارکبینش‌‌هایی از رفتار کاربرانوقتی نسخه اول جریان آپلود را با تیم عملیات به اشتراک گذاشتم، یکی از اعضای این تیم اشاره کرد که بسیاری از کاربران، پشت و روی کارت را در قالب یک فایل PDF ارسال می‌کنند. با بررسی داده‌های واتساپ متوجه شدم حدود ۷۶٪ فایل‌های دریافتی PDF هستند و کاربران معمولاً این فایل‌ها را از قبل در گوشی خود دارند. به همین دلیل تصمیم گرفتم، به‌جای درخواست آپلود تصویر پشت و روی مدارک، تجربه را بر آپلود PDF متمرکز کردم. این تغییر تعداد فایل‌ها را از ۶ عکس به ۳ فایل کاهش داد و احتمال خطا را کمتر کرد. البته این انتخاب بدون ریسک نبود. مثلاً کاربری که فایل PDF مدارک خود را ندارد باید عکس پشت و روی مدارک را آپلود کند.نسخه دوم: آپلود مبتنی بر PDFدر نسخه دوم، کاربر می‌توانست با یک کلیک، فایل PDF شامل پشت و روی کارت را آپلود کند و مرحله را به پایان برساند.با این حال، مسیر کاربرانی که مدرک را به‌صورت عکس‌های جداگانه آپلود می‌کردند هم حفظ شد. وقتی کاربر یک فایل آپلود می‌کرد، بخش جدیدی در همان صفحه نمایش داده می‌شد تا بتواند تصویر سمت دیگر کارت را هم اضافه کند. به این ترتیب، تجربه اصلی ساده و متمرکز بر آپلود PDF باقی ماند، بدون اینکه مسیر آپلود عکس مختل شود.نسخه دوم فرآیند آپلود مدارک؛ مبتنی بر آپلودنسخه سوم: وضعیت بررسی مدارکتجربه‌ی صفحه پرداخت موفق به ما یاد داده بود که هرجا حس پایان فرآیند را منتقل کنیم، ممکن است کاربر انتظار دریافت فوری بیمه‌نامه را داشته باشد. همین ریسک در جریان آپلود مدارک هم وجود داشت؛ بنابراین صفحه موفقیت آپلود را به‌عنوان یک وضعیت میانی طراحی کردم.هدف این بود که کاربر از ثبت موفق مدارک خود مطمئن شود و همچنین بداند باید کمی منتظر بماند تا مدارک بررسی شوند.صفحه آپلود موفقاین وضعیت با مدل ذهنی کاربر هم هم‌خوان بود؛ چون در بسیاری از پلتفرم‌ها، بعد از ارسال مدارک، کاربر انتظار یک مرحله بررسی و تأیید را دارد. بنابراین این موضوع برای او آشنا و قابل‌درک بود.نتایجپس از ۴۵ روز بعد از پیاده‌سازی ویژگی آپلود مدارک، داده‌ها را بررسی کردیم. نتایج نشان داد این راه‌حل به‌خوبی توسط کاربران پذیرفته شد و تأثیر خوبی بر تجربه پس از خرید گذاشته است.۹۶٪ کاربران، بعد از خرید، مدارکشان را هم آپلود کرده بودند. این عدد نشان می‌داد این ویژگی به‌خوبی توسط کاربران پذیرفته شده است.براساس داده‌های تیم عملیات، ۸۸٪ مدارک به‌صورت PDF آپلود شده بودند. این موضوع باعث شده بود نرخ مدارک ناخوانا به حدود ۳٪ برسد و فقط در تعدادی محدود، تیم عملیات برای دریافت مجدد مدارک اقدام کند.ویژگی آپلود مدارک باعث شد فرآیند صدور بیمه‌نامه هم سریع‌تر شود؛ البته این بهبود فقط ناشی از ویژگی آپلود مدارک نبود و تغییرات ساختاری تیم عملیات نیز در آن نقش داشت؛ با این حال، استاندارد شدن نحوه دریافت مدارک یکی از عوامل مهم این نتیجه بود.با شفاف‌تر شدن وضعیت سفارش و روشن شدن انتظار بررسی مدارک برای کاربر، تماس‌های کاربران بلافاصله پس از خرید، از ۲۴٪ به حدود ۹٪ کاهش پیدا کرد.در نهایت، این تغییرات فشار تیم عملیات را کاهش داد و مقدار قابل توجهی در هزینه‌‌های ماهانه این تیم صرفه‌جویی کرد.مهم‌ترین یادگیری من از این پروژه این بود که بخش زیادی از تماس‌های پشتیبانی، نه به‌دلیل خرابی سیستم، بلکه به‌خاطر ابهام در وضعیت‌ها و ناهماهنگی میان مدل ذهنی کاربر و منطق داخلی سرویس شکل می‌گیرند. وقتی کاربر دقیقاً بداند چه اتفاقی افتاده، الان در چه مرحله‌ای است و قدم بعدی چیست، اضطرابش کمتر می‌شود و نیازش به تماس هم کاهش پیدا می‌کند. مهرداد کشوری مهرداد کشوری Mon, 11 May 2026 13:46:36 +0330 https://virgool.io/@Mehrdad_Design/httpsvirgooliomehrdaddesigncase-studieslookinsureplate-g3vigy0epols-g3vigy0epols-g3vigy0epols-g3vigy0epols-g3vigy0epols در سال 2023، تحقیقات داخلی لوکین‌شور (LookInsure) نشان داد که بیشتر رانندگان در امارات، بیمه خودروشان را با مراجعه به دفاتر بیمه خریداری می‌کنند؛ مسیری که گاهی ساعت‌ها زمان می‌بُرد و با گزینه‌های محدودی همراه بود.از طرفی، خرید آنلاین هم هنوز آن‌قدر ساده و بی‌دردسر نبود که بتواند جایگزین مناسبی برای این روش باشد.مدتی بعد، لوکین‌شور با یک ایده ساده وارد بازار بیمه امارات شد:خرید بیمه‌ خودرو نباید بیشتر از چند دقیقه طول بکشد. رانندگان باید بتوانند در یک پلتفرم آنلاین، گزینه‌های مختلف را با هم مقایسه کنند و بیمه مناسب خودروی خود را بخرند.در این مطالعه موردی توضیح می‌دهم که چگونه با کاهش ابهام در فرایند استعلام قیمت، نرخ رسیدن کاربران به صفحه قیمت را ۱۷٪ افزایش دهیم.دریافت اطلاعات پلاک خوردنقش منمن در January 2024 به عنوان طراح محصول به تیم لوکین‌شور پیوستم. مسئولیت من طراحی MVP بود؛ از استعلام قیمت تا خرید بیمه.در ابتدای مسیر، همراه با رامین (مدیر محصول)، محدوده MVP را مشخص کردم. بعد از انتشار MVP، با بررسی داده‌ها، بازخوردها و رفتار واقعی کاربران، تمرکزم را روی ساده‌سازی مسیر استعلام قیمت گذاشتم؛ مسیری که هم برای محصول حیاتی بود و هم بیشترین ریزش کاربر در آن اتفاق می‌افتاد.چالش: رساندن کاربر به قیمت، سریع و مستقیمدر بازار بیمه خودرو امارات، رسیدن به قیمت معمولاً سریع و مستقیم نبود.کاربر باید اطلاعات خودرو را برای نماینده فروش می‌فرستاد، منتظر بررسی می‌ماند و در نهایت چند گزینه محدود دریافت می‌کرد.به‌نظر می‌رسید تجربه آنلاین راحت‌تر باشد، اما تفاوت چندانی نداشت؛ کاربر برای دیدن قیمت، ناچار بود اطلاعات متعددی درباره خودرو، مالکیت و سابقه بیمه را وارد می‌کرد. در بعضی پلتفرم‌ها این ورودی‌ها به ۱۷ مورد می‌رسید.چالش ما شکستن الگوی رایج بازار و ساخت یک تجربه ساده بود.چطور می‌توانستیم کاربر را در کمتر از ۲ دقیقه به لیست قیمت‌ها برسانیم؟تعریف معیارهای موفقیتبینش‌های اولیهبازار بیمه امارات برای من جدید بود. برای درک بهتر منطق بازار و محدودیت‌های عملیاتی، با رامین (مدیر محصول) و علیرضا (مدیر عملیات) صحبت کردم. هم‌زمان، مسیر استعلام قیمت در پنج بازیگر اصلی بازار را بررسی کردم؛ با تمرکز بر نقطه شروع، اطلاعات موردنیاز، فاصله کاربر تا اولین قیمت و میزان قابل‌فهم بودن مسیر.این بررسی‌ها، به چند بینش مهم برای شروع طراحی منجر شد:شروع مسیر برای همه رانندگان یکسان نیستهمه رانندگان در شروع خرید بیمه، اطلاعات یکسانی از خودروی خود در دسترس ندارند. همین تفاوت، بخشی از کاربران را از همان ابتدا دچار سردرگمی می‌کرد.برخی رقبا مسیر بهتری طراحی کرده بودندفرایند استعلام قیمت در همه پلتفرم‌ها یکسان نبود. بعضی رقبا مسیر کوتاه‌تری داشتند و کاربر را سریع‌تر به قیمت می‌رساندند. محبوبیت Shory هم نشان می‌داد که سادگی و سرعت برای کاربران ارزش واقعی دارد.این بینش‌ها نشان می‌دادند که شروع مسیر باید تا حد ممکن ساده، سریع و قابل‌اعتماد باشد.مقایسه مسیر استعلام در رقبای بازارراه‌حلبرای نمایش قیمت به اطلاعات خودرو نیاز داشتیم، اما نمی‌خواستیم کاربر از همان ابتدا با فرم طولانی روبه‌رو شود. به‌دنبال نقطه شروعی بودیم که آشنا باشد و با حداقل اطلاعات، کاربر را وارد فرایند کند.شماره پلاک بهترین نقطه شروع به‌نظر می‌رسید؛ورودی‌ای آشنا که می‌توانست مسیر استعلام را کوتاه‌تر و مستقیم‌تر کند.البته این انتخاب بدون ریسک نبود. مثلاً کاربری که به تازگی خودروی جدید خریده بود، ممکن بود هنوز به پلاک دسترسی نداشته باشد. با این حال، در MVP تصمیم گرفتیم تمرکز اصلی را روی مسیر پلاک بگذاریم؛ چون از نظر فنی و عملیاتی در دسترس‌تر بود و به مدل ذهنی کاربر نزدیک‌تر. در کنار آن، مسیر جایگزینی برای ورود دستی اطلاعات خودرو هم در نظر گرفتیم.طراحی MVP: شماره پلاک به‌عنوان نقطه شروعایده این بود که کاربر با وارد کردن پلاک، سریع و مستقیم وارد فرایند استعلام شود.فرض من این بود که اگر ورودی از نظر ظاهر به پلاک واقعی نزدیک باشد، کاربر راحت‌تر می‌فهمد چه اطلاعاتی باید وارد کند.اما خیلی زود متوجه شدم که ظاهر و ساختار پلاک در امارت‌های مختلف یکسان نیست.مثلاً در ابوظبی کد پلاک عددی بود، اما در دبی و برخی امارت‌های دیگر با حروف انگلیسی نمایش داده می‌شد. بنابراین یک ورودی ثابت نمی‌توانست همه حالت‌ها را پوشش دهد.تفاوت ظاهر و ساختار پلاک‌ خودرو در امارت‌های مختلفبرای حل این مسئله، ورودی پلاک را به سه مرحله تقسیم کردم:انتخاب امارتانتخاب کد پلاکوارد کردن شماره پلاکفرآیند ورودی اطلاعات پلاکفرایند استعلام از کجا شروع شود؟وقتی نسخه اول را با رامین، مدیر محصول، مرور کردم، یک سؤال ساده مطرح شد:این فرایند باید از کجا شروع شود؟در الگوهای رایج، کاربر از طریق CTA وارد مسیر می‌شود. اما چون در MVP می‌خواستیم شروع تا حد ممکن سریع باشد، این فرضیه را مطرح کردم که شاید خودِ ورودی پلاک بتواند نقطه شروع باشد. به همین دلیل، آن را مستقیماً در Hero صفحه Landing قرار دادم.اما این تصمیم یک ریسک مهم داشت: کاربر ممکن بود پیش از آشنایی با محصول، با ورودی‌ای نسبتاً پیچیده روبه‌رو شود؛ آن هم در صفحه‌ای که هنوز برای شروع مردد است.دریافت اطلاعات پلاک در بخش Hero صفحه لندینگ بیمه ماشیندو ماه بعد از انتشار MVP، داده‌ها نشان دادند کاربرانی که مسیر را کامل می‌کردند، در کمتر از ۲ دقیقه به صفحه قیمت می‌رسیدند. این نتیجه امیدوارکننده بود.اما معیار اصلی ما فقط سرعت نبود، بلکه نرخ رسیدن به صفحه قیمت بود. در ماه اول ۲۴٪ کاربران و در ماه دوم، با وجود رشد ترافیک، فقط ۱۹٪ کاربران به صفحه قیمت می‌رسیدند.تحلیل مسیر نشان داد بیشترین ریزش در صفحه Landing رخ می‌دهد؛ جایی که ورودی پلاک قرار داشت. برای فهم علت، ویدیوهای ضبط‌شده و الگوهای تعامل کاربران را بررسی کردم.بینش‌هایی از رفتار کاربرانداده‌ها نشان می‌دادند حدود ۳۵٪ از کاربرانی که وارد Landing می‌شدند، هیچ تعاملی با ورودی پلاک نداشتند.در بازبینی ویدیوها، یک الگوی تکرارشونده دیده می‌شد: بخشی از کاربران روی CTA غیرفعال و بخش‌های مختلف کامپوننت پلاک بارها کلیک می‌کردند. این الگو به‌تنهایی برای نتیجه‌گیری کافی نبود، اما نشان می‌داد که احتمالاً نقطه شروع به‌اندازه کافی روشن نیست و کاربر دقیقاً نمی‌داند باید از کجا شروع کند.همین شکاف بین سرعت خوب و ریزش بالا، باعث شد در مرحله بعد روی شفاف‌تر کردن نقطه شروع تمرکز کنم.نسخه دوم: واضح‌ کردن نقطه شروعبرای سنجش این فرضیه که نقطه شروع به‌اندازه کافی واضح نیست، کامپوننت پلاک را با دو تغییر بازطراحی کردم:فعال‌کردن دکمه CTAدکمه Continue را حتی وقتی که ورودی پلاک خالی بود، فعال نمایش دادم تا کاربر یک نقطه اقدام واضح ببیند.هم‌زمان، رفتار آن را طوری طراحی کردیم که اگر اطلاعات ورودی ناقص بود، کاربر را به تکمیل فیلدهای لازم راهنمایی کند.بزرگ‌تر کردن ناحیه تعاملی ورودی پلاکناحیه کلیک‌پذیر کامپوننت ورودی پلاک را بزرگ‌تر کردم تا کاربر فقط به فیلدهای کوچک محدود نباشد.بهبود کامپوننت ورودی پلاک خودرو با تغییر حالت دکمه CTAبعد از اعمال این تغییرات و بررسی داده‌ها، فقط بخشی از ریزش در قدم اول کاهش پیدا کرد. اما این صفحه همچنان نرخ ریزش بالایی داشت.این نتیجه برای من مهم بود، چون نشان می‌داد مشکل احتمالاً فقط در شفافیت شروع فرایند نیست.پس کاربر دقیقاً کجا دچار اصطکاک می‌شد؟بازگشت به رفتار واقعی کاربرانبرای پیدا کردن مسئله اصلی، دوباره سراغ داده‌ها رفتم. این بار متوجه شدم حتی وقتی کاربر می‌فهمید از کجا باید شروع کند، در وارد کردن اطلاعات پلاک با اصطکاک روبه‌رو می‌شد.براساس داده‌ها، نرخ تکمیل پلاک در موبایل حدود ۳۵٪ بود. بازبینی ویدیوها نشان می‌داد بسیاری از کاربران در اولین برخورد با منطق و ترتیب ورود اطلاعات پلاک دچار ابهام و اشتباه می‌شوند. آن‌ها Bottom Sheet را چند بار باز و بسته می‌کنند، بین گزینه‌ها جابه‌جا می‌شوند، روی بخش‌های اشتباه کلیک می‌کنند و در نهایت مسیر را رها می‌کنند.این الگو با داده‌های کمی هم هم‌راستا بود. نرخ تکمیل پلاک در دسکتاپ حدود ۷۸٪ بود؛ اختلافی معنادار که نشان می‌داد مدل تعامل در موبایل، به‌ویژه Bottom Sheet، اصطکاک بیشتری ایجاد می‌کند.از طرف دیگر، شماره پلاک هرچند برای بیشتر رانندگان آشنا بود، اما وارد کردن آن در قالب موردنیاز سیستم ساده نبود. برای کاربران آماده، این مسیر یک میان‌بر سریع بود؛ اما برای کاربران در حال بررسی، به مانعی زودهنگام تبدیل می‌شد.چون این اصطکاک در ابتدای قیف رخ می‌داد، هر مکث یا خطا می‌توانست به رها کردن کامل مسیر منجر شود. در نتیجه، مسئله را ترکیبی از سه عامل دیدم:ابهام در تعامل با Bottom Sheetنیاز به اطلاعات دقیق در همان قدم اولحساسیت بالای شکست در ابتدای قیفدر مرحله بعد، روی این فرضیه متمرکز شدم که اگر ورود به مسیر از یک نقطه شروع ساده‌تر و شفاف‌تر آغاز شود، احتمالاً کاربران بیشتری مسیر را کامل می‌کنند.نسخه سوم: ساده‌تر کردن نقطه شروعدر نسخه سوم، سه تغییر اصلی با هدف ساده‌تر و شفاف‌تر کردن شروع فرایند انجام شد:تغییر اول: ساده‌سازی نقطه شروعورودی پلاک را از Hero حذف کردم و به‌جای آن یک CTA واضح قرار دادم.منطق این تصمیم ساده بود: کاربر به‌جای روبه‌رو شدن با یک کامپوننت پیچیده، ابتدا با یک نقطه شروع روشن مواجه شود و بعد اطلاعات خودرو را وارد کند.حذف کامپوننت ورودی پلاک از بخش Hero صفحه لندینگتغییر دوم: ورود اطلاعات پلاک در ۳ مرحلهالگوی Bottom Sheet را حذف کردم و اجزای پلاک را در مراحل جداگانه از کاربر گرفتم.این تغییر شاید مسیر را کمی طولانی‌تر نشان می‌داد، اما بار ذهنی هر مرحله را کاهش می‌داد.فرآیند استعلام قیمت – نسخه دومتغییر سوم: حق انتخاب کاربر در شیوه ورود اطلاعات خودرویک صفحه میانی طراحی کردم تا کاربر بتواند براساس اطلاعاتی که در اختیار دارد، روش ورود اطلاعات خودرو را انتخاب کند: شماره پلاک، ورود دستی اطلاعات خودرو یا شماره شاسی.هدف این تغییر، افزایش حس کنترل و جلوگیری از تحمیل یک مسیر واحد به همه کاربران بود.انتخاب نحوه ورود اطلاعات پلاک خوردونتایجسه ماه بعد از پیاده‌سازی این تغییرات، داده‌ها نشان دادند که مسیر استعلام قیمت نسبت به نسخه MVP ساده‌تر شده است:نرخ رسیدن کاربران به صفحه قیمت، با وجود افزایش تعداد کاربران، نسبت به MVP حدود ۱۱٪ رشد کرد و به ۳۹٪ رسید. بخش مهمی از این بهبود، نتیجه ساده‌تر شدن ورود اطلاعات پلاک بود.با دریافت اطلاعات پلاک در مراحل جداگانه، میانگین نرخ تکمیل پلاک از ۵۶٪ به ۶۴٪ رسید.با وجود این تغییرات، کاربرانی که مسیر پلاک را انتخاب می‌کردند همچنان می‌توانستند در کمتر از ۲ دقیقه به قیمت برسند. مهرداد کشوری مهرداد کشوری Mon, 11 May 2026 12:41:15 +0330