سفر، کافه رفتن و شام خوردن با دوستان، لحظههاییاند که دوست داریم بیدغدغه از آنها لذت ببریم. اما معمولاً در پایان این لحظات خوب، جملات تکراریِ «کی حساب میکنه؟» یا «سهم من چقدر شد؟»، سر و کلهشان پیدا میشود و خیلی راحت حالوهوای دورهمی را به یک چالش مالی تبدیل میکند.
ویژگی دُنگ در بلوبانک برای حل همین مسئله طراحی شد؛ پاسخی به یک نیاز واقعی کاربر و فرصتی برای ایجاد تعامل و بازگشت بیشتر کاربران به محصول. در این کیساستادی توضیح میدهم که چگونه مسئله را دقیقتر صورتبندی کردیم، ایدههای اولیه را سنجیدیم و به طراحی نسخهی MVP رسیدیم.
من بهعنوان طراح محصول، هدایت طراحی MVP دُنگ را از مرحلهی تعریف مسئله تا تحویل نهایی برعهده داشتم.
تعریف MVP و اولویتبندی سناریوها
همراه با پرنیا، مدیر محصول، محدودهی MVP، معیارهای موفقیت، سناریوهای اصلی و نحوهی انتشار را مشخص کردیم.
سنجش فرضیات و پیدا کردن نقاط ابهام
با همکاری الهام، پژوهشگر تجربه کاربری، فرضیههای اصلی را از طریق تست کاربردپذیری و ارزیابی اکتشافی سنجیدیم و نقاط اصطکاک تجربه را شناسایی کردیم.
طراحی جریانهای اصلی
با بازبینی چندبارهی وایرفریمها و دریافت بازخورد تیم، جریانها را سادهتر کردم و الگوهای تعاملی را با زبان طراحی بلو همراستا نگه داشتم.
هماهنگی با تیم توسعه در اجرا
از ابتدای مسیر با تیم توسعه در ارتباط بودم تا راهحلها با محدودیتهای فنی سازگار باشند و کیفیت اجرا حفظ شود.
تقریباً همهی اعضای تیم تجربهی پرداختهای گروهی را داشتیم، اما نمیخواستیم مسئله را فقط بر اساس تجربهی شخصی تعریف کنیم. برای همین، همراه با الهام، پژوهشگر تجربه کاربری، با ۱۵ کاربر در موقعیتهای واقعی مصاحبه کردیم تا ببینیم مردم در عمل هزینههای مشترک را چگونه مدیریت میکنند.
در اغلب گفتگوها، الگوی پرداخت تقریباً یکسان بود:
یک نفر هزینه را پرداخت میکرد، عکس رسید را در گروه میفرستاد و بقیه سهمشان را میدادند.
اما مسئلهی اصلی بعد از پرداخت شروع میشد:
۱۲ نفر تمایلی به نقش مادرخرج نداشتند؛ نه بهخاطر خودِ پرداخت، بلکه بهخاطر پیگیری بعد از آن.
۵ نفر تجربهی تسویهی دیرهنگام داشتند که در بیشتر موارد از فراموشی میآمد.
۶ نفر گفتند تقسیم ناعادلانه هزینه یا پرداختنشدن سهم بعضی افراد، گاهی به روابط دوستانه آسیب زده است.
۲ نفر هم در سفرهای گروهی از Splitwise برای ثبت و تسویهی هزینهها استفاده کرده بودند.
یافتهها نشان داد مسئله فقط محاسبهی سهم افراد نیست؛ تعارف، رودربایستی و پیگیری پرداخت هم بخش مهمی از ماجراست.
برای بلو فرصتی بود تا فراتر از ابزارهای مالی فردی حرکت کند و یکی از سناریوهای پرتکرار مالی، که معمولاً بیرون از محصول مدیریت میشد، به یک تجربهی یکپارچه درون محصول تبدیل کند.
چطور میتوانستیم به کاربران کمک کنیم خرجهای گروهی را بدون دردسر تقسیم و تسویه کنند؟
برای تعریف دامنهی MVP، همراه با الهام و پرنیا سناریوهای هزینهی مشترک را به سه دسته تقسیم کردیم:
رستوران یا کافه
معمولاً یک نفر پرداخت میکند و بعد سهم بقیه را میگیرد. تعداد افراد کم است، اما سهمها میتواند مساوی یا متفاوت باشد. چون این موقعیت اغلب بین دوستان رخ میدهد، حسابوکتاب در آن میتواند معذبکننده باشد.
سفر گروهی
هزینهها متنوعاند؛ از اقامت و بنزین تا غذا، بلیط و خرید. همچنین ممکن است چند نفر در نقاط مختلف سفر پرداخت کرده باشند، بنابراین جمعبندی هزینهی هر نفر اهمیت زیادی پیدا میکند.
خانه و همخانه
هزینهها متنوعاند؛ از اقامت و بنزین تا غذا، بلیط و خرید. همچنین ممکن است چند نفر در نقاط مختلف سفر پرداخت کرده باشند، بنابراین جمعبندی هزینهی هر نفر اهمیت زیادی پیدا میکند.
این دستهبندی کمک کرد تصمیمهای طراحی را بر اساس نیازهای هر موقعیت بررسی کنیم.
در قدم اول باید مشخص میکردیم کاربران هزینههای مشترک را در چه ساختاری مدیریت کنند.
گزینه اول: تقسیم یک تراکنش
در این مدل، کاربر بعد از پرداخت میتوانست از داخل جزئیات تراکنش، مبلغ را با دوستانش تقسیم کند.
این مسیر سریع و ساده بود و برای هزینههای موردی خوب عمل میکرد، اما یک ضعف مهم داشت:
هر تقسیم به همان یک تراکنش محدود میماند و فضایی ماندگار برای پیگیری هزینهها شکل نمیگرفت.
گزینهی دوم: ساختن گروه
در این مدل، کاربر یک گروه میساخت، دوستانش را دعوت میکرد و همهی هزینههای مشترک در همان فضا ثبت و مدیریت میشد.
این مسیر در شروع کمی پرزحمتتر بود، اما برای سفر و دورهمیهای تکرارشونده ساختاری منظمتر و قابلپیگیریتر فراهم میکرد.
انتخاب نهایی: مدل گروهی
مصاحبهها نشان داد بخش زیادی از هزینههای مشترک در یک جمع نسبتاً ثابت تکرار میشود؛ بنابراین تقسیم یکباره برای این الگو کافی نبود. از طرف دیگر، یکی از معیارهای موفقیت این ویژگی افزایش بازگشت کاربر بود و مدل گروهی میتوانست فضایی مشترک و ماندگار بسازد که کاربر برای پیگیری و تسویه به آن برگردد. این تصمیم با الگوی محصولاتی مثل Revolut و Google Pay هم همراستا بود.
در نهایت، با جمعبندی این بینشها با پرنیا و تیم، تصمیم گرفتیم MVP را بر پایهی مدل گروهی طراحی کنیم.
بعد از انتخاب مدل گروهی، سؤال بعدی این بود که کاربر چطور دوستانش را به گروه اضافه کند؟
بلو از قبل قابلیتی برای انتقال پول از طریق شماره تلفن داشت؛ اگر دو نفر شمارهی هم را ذخیره کرده بودند و هر دو کاربر بلو بودند، میتوانستند فقط با شماره تلفن برای هم پول بفرستند. به همین دلیل، استفاده از فهرست مخاطبان در نگاه اول سریعترین گزینه به نظر میرسید.
گزینهی اول: دعوت از طریق مخاطبان
این مسیر برای گروههای کوچک و صمیمی بسیار مناسب بود. کاربر میتوانست فرد موردنظرش را سریع پیدا کند و تقریباً بیزحمت او را به گروه اضافه کند.
اما بررسی دادهها با کمک سحر، از تیم دیتا، نشان داد بخش قابلتوجهی از کاربران دسترسی به مخاطبان را فعال نکردهاند. علاوه بر این، کاربران PWA بهدلیل محدودیتهای پلتفرم اساساً به این قابلیت دسترسی نداشتند. بنابراین اگر فقط به مخاطبان متکی میماندیم، بسیاری از کاربران در همان قدم اول متوقف میشدند.
گزینهی دوم: دعوت از طریق لینک
لینک دعوت انعطاف بیشتری داشت؛ بهویژه برای کاربران PWA یا کسانی که همگامسازی مخاطبان را فعال نکرده بودند. این روش در گروههای موقت یا بزرگتر، مثل سفرها و دورهمیها، هم طبیعیتر به نظر میرسید.
تصمیم نهایی
در نهایت هر دو مسیر را کنار هم قرار دادیم تا کاربر بسته به شرایطش انتخاب کند و هیچکس از همان ابتدا به بنبست نخورد.
پیچیدهترین بخش طراحی دُنگ، نحوهی ثبت و نمایش هزینههای مشترک در گروه بود.
در مصاحبهها دیدیم مادرخرج معمولاً رسید یا مبلغ را در گروه تلگرام یا واتساپ میفرستاد تا بقیه سهمشان را پرداخت کنند. همین الگو برای ما به یک سرنخ طراحی تبدیل شد:
بهجای نمایش هزینهها در قالب یک لیست خشک، آنها را در فضایی شبیه چت نشان دادیم؛ جایی که خرج مشترک بیشتر شبیه یک گفتوگوی جمعی بود تا یک جدول بدهی.
در طراحی اولیهی ثبت هزینه هم تلاش کردم همهچیز سریع و ساده باشد:
کاربر تراکنشی را از لیست تراکنشها انتخاب میکردند یا مبلغ را دستی وارد میکرد
خودش بهطور پیشفرض بهعنوان مادرخرج در نظر گرفته میشد
سیستم مبلغ را میان اعضای گروه تقسیم میکرد.
در صورت نیاز هم کاربر میتوانست سهم هر نفر را تغییر دهد یا بعضی اعضا را از تقسیم حذف کند.
اما تستها نشان داد سادگی همیشه به معنای وضوح نیست.
با همکاری الهام، در دو مرحله تست کاربردپذیری با ۱۰ کاربر، متوجه شدیم وقتی پرداختکننده شخص دیگری بود، بعضی کاربران فراموش میکردند مادرخرج را از حالت پیشفرض تغییر دهند. برای کاهش این خطای مفهومی، انتخاب مادرخرج را به یک مرحلهی مستقل تبدیل کردیم. این تصمیم یک قدم به فرایند اضافه میکرد، اما در عمل خطای کاربر را بهطور معناداری کاهش داد.
مسئلهی دوم به گزینهی «تقسیم دوباره» مربوط میشد. این گزینه زمانی به کار میآمد که کاربر در وارد کردن سهمها اشتباه کرده بود و میخواست مبلغ دوباره بین اعضا تقسیم شود. اما ۴ نفر از ۱۰ کاربر فقط با دیدن آیکن، متوجه عملکرد آن نمیشدند. برای همین، کنار آیکن یک برچسب متنی اضافه کردیم تا کاربر مجبور به حدسزدن نباشد.
در پژوهش اولیه، یادآوری بدهی یکی از دغدغههای پرتکرار کاربران بود. از یک طرف، بهخاطر تعارف و رودربایستی، یادآوری مستقیم برایشان معذبکننده بود؛ از طرف دیگر، بعضیها هم میگفتند واقعاً فراموش میکنند که به کسی بدهکارند.
برای همین، یکی از اهداف اصلی ما این بود که پیگیری بدهی داخل محصول انجام شود. زیرا در غیر این صورت:
کاربران باید بدهیها را بیرون از محصول دنبال میکردند
ارزش واقعی ویژگی دُنگ بهخوبی درک نمیشد و این ویژگی بیشتر به ابزار ثبت هزینه تبدیل میشد
احتمال کاهش نرخ تسویه وجود داشت
چالش اصلی این بود که یادآوری، حس طلبکاری ایجاد نکند.
در قدم اول روی لحن پیامها کار کردیم و متن نوتیفیکیشنها را کوتاه، مستقیم و تا حد ممکن خنثی نگه داشتیم. اما بازخورد کاربران نشان داد یادآوری جمعی همیشه مناسب نیست؛ گاهی مادرخرج نمیخواهد برای همهی اعضا نوتیفیکیشن بفرستد. به همین دلیل، کنترل ارسال یادآوری را به خودِ کاربر دادیم تا مشخص کند این پیام برای چه کسانی فرستاده شود.
در تجربهی ایدهآل، دوست داشتیم کاربر با یک دکمه تمام بدهیاش را با گروه تسویه کند. اما این ایده در MVP با یک محدودیت مهم روبهرو شد: تسویه با کل گروه در پشتصحنه به چند پرداخت جداگانه به افراد مختلف تبدیل میشد، در حالی که الزامات بانکی ایجاب میکرد هر پرداخت به یک شخص مشخص و با رسید مستقل انجام شود.
به همین دلیل، تصمیم گرفتیم مسئله را در سطح فردبهفرد حل کنیم:
کاربر بتواند وضعیت مالی خود را با هر عضو گروه ببیند و بدهیاش را با همان فرد تسویه کند.
این راهحل یک قدم با تجربهی ایدهآل فاصله داشت، اما همچنان فرایند پرداخت را ساده و قابلفهم نگه میداشت.
برای کاهش ریسک، دُنگ ابتدا بهمدت دو ماه فقط برای کارکنان شرکت فعال شد. هدف این مرحله شناسایی باگها، بررسی رفتار واقعی کاربران، تست نوتیفیکیشنها و اطمینان از صحت جریان پرداخت بود.
در این دوره، شاخصهایی مثل ساخت گروه، ثبت هزینه، دعوت اعضا و پرداختها روزانه پایش میشد. پس از رفع مسائل اصلی، دُنگ در بهمن ۱۴۰۲ برای همهی کاربران بلو منتشر شد.
در ماه اول لانچ عمومی، نرخ استفاده اولیه یا Adoption حدود ۱.۲٪ بود. از آنجا که کمی بعد از لانچ عمومی از تیم جدا شدم، به دادههای بلندمدتتر دسترسی نداشتم؛ بنابراین تحلیل نتایج را به همین داده اولیه محدود میکنم.
طراحی و پیادهسازی «دُنگ»، ماحصل تلاش گروهی از متخصصان باانگیزه بود که با چالشهای فنی و تجربهکاربریِ پیچیدهای دستوپنج نرم کردند. از همکارانم که در این مسیر همقدم من بودند، صمیمانه سپاسگزارم:
پژوهش و محصول: از الهام تراکمه عزیز بابت پژوهشهای عمیقِ کاربری که چراغ راهِ طراحی بود، و پرنیا کاملیان بابت مدیریت و هدایت محصول در مسیر درستی که به هدف نزدیک شد.
تیم طراحی: از راهنماییهای ابی آقاپور (Design Lead) که در چالشهای دیزاین همیشه راهگشا بود، و همچنین همکاران طراحم دانیال شیرآلی، علیرضا کیان، مهدی مشتاقی، داریوش حبیبپور و آناهیتا آقایی که با بازخوردهای سازنده خود، کیفیت خروجی را ارتقا دادند.
تیم فنی: پیادهسازی بینقصِ این جریان مدیون تلاشهای بیوقفه تیمهای فنی بود. از امیرعباس موسویان (Chapter Lead) بابت هماهنگیهای موثر و همچنین همکاران عزیزم رامین بهلولی، مرتضی تقدمی، وحید قدیری، مهشید گنجه، حسین حاجیمیرزا، رضا اکبری، علیرضا نظری و مهدی دلاور که در پیادهسازی سناریوهای پلتفرمهای iOS، Android و PWA زحمات زیادی کشیدند.
در نهایت، از تکتک عزیزانی که در این مسیر در کنار من بودند و با همفکری و حمایتشان به این پروژه جان بخشیدند، سپاسگزارم. دُنگ نتیجهی یک کار تیمی بود.
