چگونه کاربران خود را هنگام انتشار یک نسخه اصلی از برنامه خود راضی نگه داریم
تنش ذاتی در توسعه محصول بین بهبود و ثبات وجود دارد. از یک طرف، کاربران انتظار ویژگی های جدید، عملکرد و شاید حتی ظاهر جدید را دارند. از سوی دیگر، هنگامی که رابط های آشنا به طور ناگهانی ناپدید شوند، تغییرات می توانند نتیجه معکوس داشته باشند. این تنش زمانی بیشتر است که یک محصول به شیوهای چشمگیر تغییر میکند - به حدی که حتی میتوان آن را یک محصول جدید نامید.
At CaseFleet ما برخی از این درس ها را به سختی آموختیم، البته در مراحل اولیه رشدمان. در ابتدا، پیمایش برنامه ما در ردیفی از نمادها در بالای صفحه قرار داشت:
علیرغم ارزش زیبایی شناختی این انتخاب، ما تا حدودی به دلیل فضای در دسترس احساس محدودیت کردیم، به ویژه زمانی که کاربران ما برنامه را در صفحه نمایش های کوچکتر یا دستگاه های تلفن همراه مشاهده می کردند. یک روز، یکی از توسعه دهندگان ما در صبح روز دوشنبه با ثمره یک پروژه اعلام نشده آخر هفته به محل کار آمد: اثبات مفهوم تغییر در چیدمان. هسته اصلی تغییر، ناوبری را از یک ردیف در امتداد بالای صفحه به ستونی در سمت چپ منتقل می کند:
تیم ما فکر میکرد که طراحی فوقالعاده به نظر میرسد و پس از اضافه کردن چند کار تکمیلی، آن را در آن هفته برای کاربران خود منتشر کردیم و انتظار داشتیم که هیجانزده شوند. ما اشتباه کردیم.
در حالی که تعداد کمی از کاربران بلافاصله این تغییر را پذیرفتند، تعداد قابل توجهی اصلا راضی نبودند و گزارش دادند که در حرکت در برنامه مشکل دارند. با این حال، بزرگترین شکایت آنها این نبود که از چیدمان جدید خوششان نمی آمد، بلکه این بود که آنها را غافلگیر کرد.
درس های آموخته شده: تغییر درست انجام شد
دفعه بعد که برنامه خود را تغییر دادیم، از فرآیند بسیار متفاوتی استفاده کردیم. بینش کلیدی ما این بود که کاربران دوست دارند سرنوشت خود را در دست داشته باشند. وقتی آنها برای درخواست شما پول می پردازند، به دلیلی این کار را انجام می دهند و نمی خواهند ویژگی های ارزشمند آنها از آنها گرفته شود.
پس از اینکه رابط کاربری تازه طراحی شده خود را تکمیل کردیم، آن را به سادگی منتشر نکردیم. در عوض، ما یک پست وبلاگی در مورد آن نوشتیم و اسکرین شات هایی را با کاربران خود به اشتراک گذاشتیم.
در مرحله بعد، یک دکمه به صفحه خوش آمدگویی در برنامه خود اضافه کردیم که یک عنوان بزرگ، تعدادی کپی با دقت ساخته شده و یک دکمه نارنجی بزرگ که از کاربران برای آزمایش نسخه جدید استقبال می کند. ما همچنین اشاره کردیم که آنها می توانند در صورت تمایل (به هر حال برای مدتی) به نسخه اصلی برگردند.
هنگامی که کاربران در نسخه جدید قرار گرفتند، مراحل مورد نیاز برای بازگشت به عقب با چند کلیک در تنظیمات پروفایل کاربر قرار داشت. ما نمیخواستیم دکمه را برای برگرداندن مخفی کنیم، اما همچنین فکر نمیکردیم که جابجایی مکرر به عقب و جلو برای افراد مفید باشد، که اگر دکمه فوراً قابل مشاهده بود ممکن بود وسوسهانگیز باشد. در واقع، تنها یک کاربر تا به حال در طول دوره یک ماهه ثبت نام، بازگشته است. علاوه بر این، تا زمانی که ما سوئیچ را برگرداندیم و نسخه جدید را اجباری کردیم، تقریباً همه فعالترین کاربران ما تغییر کاربری داده بودند و بازخورد خوبی در مورد نسخه جدید به ما داده بودند.
علاوه بر مشوقهای درونبرنامهای که برای جابجایی ارائه کردیم، چندین ایمیل ارسال کردیم که به کاربران اطلاع میداد دقیقا چه زمانی تغییر به نسخه جدید دائمی میشود. هیچ کس غافلگیر نشد و کسی شکایت نکرد. در واقع، اکثر کاربران از ظاهر جدید بسیار راضی بودند.
چالش های ارزشمند
با این حال، مهم است که توجه داشته باشید که انتشار به روز رسانی به این روش رایگان نیست. تیم توسعه شما باید دو نسخه جداگانه از یک پایگاه کد را حفظ کند و همچنین باید مشکلات پیچیده ای را در مورد نحوه ارسال نسخه ها به کاربران نهایی حل کنید. تیم های توسعه و تضمین کیفیت شما در پایان فرآیند خسته خواهند شد، اما احتمالاً موافقت خواهید کرد که سرمایه گذاری زمان و منابع هوشمندانه بوده است. در بازارهای نرم افزاری فوق رقابتی، باید کاربران را راضی نگه دارید و هیچ راهی سریعتر از تغییر ناگهانی رابط کاربری خود برای ناراضی کردن آنها وجود ندارد.