بازطراحی رایتل من

۰۱: معرفی پروژه

یک تجربه منسجم برای مدیریت خط

رایتل من محل بررسی مصرف، خرید و تمدید بسته و پرداخت صورتحساب است. کارهایی روزمره که هم روی درآمد محصول اثر دارند، هم روی اعتماد کاربر.

هر بخش اپ با منطق خودش رشد کرده بود. اطلاعات مرتبط از هم جدا بودند و کنترل‌هایی که کار مشابهی انجام می‌دادند، ظاهر و رفتار یکسانی نداشتند. هدف من این بود که کاربر وضعیت خطش را بفهمد و بداند قدم بعدی چیست.

مسئولیت من

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

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

۰۲: شواهد تجربه قبلی

کاربر کجا متوقف می‌شد؟

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

مشکل‌هایی که تکرار می‌شدند

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

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

آنچه از کاربران و تیم‌ها شنیدیم

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

دسترسی به داده و محدودیت‌های کسب‌وکار

به دلایل امنیتی و قواعد دسترسی به داده، تیم طراحی دسترسی مستقیم به ابزارهایی مثل Microsoft Clarity و Google Analytics نداشت. تیم کسب‌وکار داده‌های رفتاری و تجاری را بررسی می‌کرد و یافته‌های مرتبط را در اختیار ما می‌گذاشت.

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

از بررسی رقبا چه برداشتیم؟

بررسی ایرانسل من و همراه من کمک کرد الگوهایی را بشناسیم که کاربران اپ‌های اپراتوری با آن‌ها آشنا بودند. تمرکز روی دسترسی به بسته، فهم وضعیت مصرف و انتخاب روش پرداخت بود.

راهنمای مصاحبه و تست کاربردپذیری

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

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

سه مسئله‌ای که در اولویت قرار گرفتند

بررسی محصول، گفت‌وگو با کاربران، داده‌های منتقل‌شده از کسب‌وکار و مقایسه رقبا، سه مسئله تکرارشونده را مشخص کردند.

۰۳: اصول طراحی

چهار اصل برای تصمیم‌های روزمره

این اصول هم در طراحی صفحه‌ها به کار آمدند، هم در ساخت کامپوننت‌ها.

تغییرهای اصلی در چهار مسیر

داده در اپ وجود داشت، اما پیدا‌کردن معنای آن آسان نبود. کاربر برای پاسخ به «اینترنتم رو به تمام‌شدن است؟» باید چند بخش را بررسی می‌کرد.

۱. داشبورد

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

اقدام مرتبط هم کنار وضعیت قرار گرفت. هدف این بود که کاربر با یک نگاه وضعیتش را بفهمد و برای قدم بعدی دنبال مسیر نگردد.

۲. انتخاب بسته

در خود صفحه فهرست بسته‌ها، بخش اصلی کار خواناترکردن کارت‌ها و هماهنگی با دیزاین‌سیستم بود. اما مسیر رسیدن به این صفحه هم تغییر کرد: خرید بسته به نوار پیمایش پایین منتقل شد و کاربر پیش از ورود به فهرست، دسته بسته را انتخاب می‌کرد.

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

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

آنچه تغییر دادم: برای خرید بسته یک دکمه مشخص در نوار پیمایش پایین گذاشتیم. با زدن آن، پنل انتخاب دسته‌بندی از پایین باز می‌شود و کاربر نوع بسته، مثل اینترنت یا مکالمه، را انتخاب می‌کند و بعد وارد فهرست همان دسته می‌شود. تاریخچه بسته‌ها هم در همین پنل، به‌عنوان گزینه‌ای جدا در دسترس است.

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

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

۳. نمایش مصرف

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

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

۴. تجربه پرداخت

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

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

نقطه مشترک این دو کار، پرداخت مبلغ برای مدیریت وضعیت مالی همان خط است: یکی برای تسویه بدهی و دیگری برای بالا‌بردن سقف اعتبار. به همین دلیل، آن‌ها را در یک صفحه با دو تب صورتحساب و افزایش سقف اعتبار قرار دادم. کاربر از همان جایی که قبضش را بررسی می‌کند، به مدیریت سقف اعتبار هم دسترسی دارد و لازم نیست آن را در بخش دیگری از اپ پیدا کند. هر تب جزئیات و اقدام خودش را دارد تا هدف پرداخت روشن بماند.

۰۶: دیزاین‌سیستم

پایه مشترک برای صفحه‌های بعدی

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

چه چیزهایی پوشش داده شد؟

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

۰۷: ارزیابی و نتایج

بررسی فرض‌ها پیش از توسعه

تست پروتوتایپ

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

تعداد شرکت‌کنندگان، نتایج تکمیل کار و تغییرهای بین دورهای تست هنوز در این کیس‌استادی مستند نشده‌اند. بنابراین نمی‌توانم از آن‌ها نتیجه عددی ارائه کنم.

چه چیزی هنوز اندازه‌گیری نشده؟

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

بهترشدن ظاهر صفحه، اثبات افزایش فروش نیست. برای نسبت‌دادن تغییر این معیارها به طراحی، به داده رفتاری و مقایسه کنترل‌شده نیاز داریم.

پروتوتایپ

۰۸: آنچه یاد گرفتم

سادگی باید در کل مسیر دیده شود

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

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

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