فرض کنید برای توسعه یک اپلیکیشن آموزش برنامه‌نویسی هزینه کرده‌ایم. کمپین جذب کاربر هم موفق بوده و تعداد نصب‌ها رو به افزایش است. اما وقتی رفتار کاربران را بررسی می‌کنیم، می‌بینیم بخش زیادی از آن‌ها حتی اولین درس را تمام نکرده‌اند.
تیم بازاریابی پیشنهاد می‌دهد با ارسال اعلان‌های بیشتر کاربران را برگردانیم. تیم طراحی معتقد است مسیر شروع آموزش پیچیده است و تیم محتوا می‌گوید باید درس اول را کوتاه‌تر کنیم.
هر سه پیشنهاد می‌توانند منطقی باشند، اما هنوز نمی‌دانیم مشکل اصلی چیست.
اگر جای مدیر محصول بودیم، قبل از تغییر محصول باید چه چیزی را بررسی می‌کردیم؟
این دقیقا موضوع سوال چهارم مجموعه هزار سوال مصاحبه مدیر محصول است:
«اگر کاربران یک ابزار آموزشی را نصب کنند، اما درس اول را به پایان نرسانند، چه کار می‌کنید؟»
مصاحبه‌کننده دنبال چه پاسخی است؟
این سوال بیشتر از اینکه دانش طراحی رابط کاربری را بسنجد، توانایی تشخیص مسئله، تحلیل رفتار کاربران و تصمیم‌گیری بر اساس شواهد را ارزیابی می‌کند.
مصاحبه‌کننده می‌خواهد بداند آیا می‌توانیم تفاوت بین نشانه یک مشکل و علت واقعی آن را تشخیص دهیم یا نه.
ناتمام ماندن درس اول یک نشانه است. اما علت آن می‌تواند پیچیدگی تجربه کاربری، نامناسب بودن محتوا، مشکل فنی، تفاوت انتظار کاربر با محصول یا حتی محدودیت زمانی او باشد.
پاسخ قوی باید نشان دهد که می‌توانیم مسئله را محدود کنیم، یک گروه مشخص از کاربران را انتخاب کنیم، چند راه‌حل را مقایسه کنیم و در نهایت تصمیمی بگیریم که بتوان نتیجه‌اش را سنجید.
۱. ابتدا مشخص کنیم واقعا کدام کاربران ریزش می‌کنند
یکی از اشتباهات رایج این است که تمام کاربران نصب‌کننده را یک گروه در نظر بگیریم.
کاربری که اپلیکیشن را نصب کرده و هنوز آن را باز نکرده، مسئله متفاوتی با کسی دارد که درس اول را شروع کرده، ده دقیقه مطالعه کرده و بعد خارج شده است.
پس قبل از ارائه راه‌حل باید مسیر واقعی کاربر را بشناسیم.
این مسیر می‌تواند از نصب و اولین ورود شروع شود، به انتخاب هدف یادگیری و مشاهده درس برسد و با شروع، تعامل و تکمیل اولین درس ادامه پیدا کند.
برای هر مرحله باید بدانیم چه تعداد کاربر وارد آن شده‌اند، چند نفر جلو رفته‌اند و در چه نقطه‌ای متوقف شده‌اند.
اما یک نکته مهم وجود دارد: نصب اپلیکیشن به‌تنهایی نشانه قصد جدی برای یادگیری نیست.
ممکن است کاربر صرفا از روی کنجکاوی آن را نصب کرده باشد. بنابراین نباید تمام فاصله بین نصب و تکمیل درس را به ضعف تجربه آموزشی نسبت دهیم.
سوال‌های اولیه من این‌ها هستند:
- چند درصد از نصب‌کنندگان واقعا درس اول را شروع می‌کنند؟
- چند درصد از شروع‌کنندگان آن را تکمیل می‌کنند؟
- کاربران معمولا در چه مرحله‌ای خارج می‌شوند؟
- آیا بعدا برمی‌گردند و درس را ادامه می‌دهند؟
- آیا الگوی ریزش در گروه‌های مختلف یکسان است؟
آخرین سوال اهمیت زیادی دارد. شاید کاربران مبتدی بیش از کاربران باتجربه خارج شوند، یا مشکل فقط در نسخه اندروید، یک زبان خاص یا اتصال اینترنت ضعیف دیده شود.
بدون این تفکیک، ممکن است برای همه کاربران راه‌حلی ارائه کنیم که فقط مشکل گروه کوچکی را حل می‌کند.
۲. بین داده رفتاری و علت واقعی مشکل تفاوت بگذاریم
فرض کنیم داده‌ها نشان می‌دهند تعداد زیادی از کاربران در ابتدای درس اول خارج می‌شوند.
این مشاهده هنوز به ما نمی‌گوید چرا.
برای فهمیدن علت، داده‌های کمی را با پژوهش کیفی ترکیب می‌کنیم.
از یک طرف مسیر ورود، مدت تعامل، خطاهای فنی، زمان بارگذاری، انتخاب محتوا و نقطه خروج را بررسی می‌کنیم. از طرف دیگر با تعدادی از کاربرانی که درس را نیمه‌کاره رها کرده‌اند گفت‌وگو می‌کنیم یا از آن‌ها می‌خواهیم مسیر شروع یادگیری را در یک آزمون کاربردپذیری طی کنند.
در این بررسی باید چند فرضیه را از هم جدا کنیم.
فرضیه اول: شروع استفاده از محصول بیش از حد پیچیده است.
شاید کاربر پیش از دیدن اولین محتوای آموزشی مجبور باشد حساب بسازد، چند فرم پر کند و هدف یادگیری خود را تعیین کند. در این حالت، مسئله حتی ممکن است پیش از شروع درس ایجاد شده باشد.
فرضیه دوم: محتوا با انتظار کاربر هم‌خوانی ندارد.
ممکن است تبلیغ محصول وعده یادگیری سریع و عملی داده باشد، اما درس اول با توضیح‌های طولانی و نظری شروع شود.
فرضیه سوم: اولین تجربه آموزشی بیش از حد دشوار است.
اگر کاربر مبتدی در همان چند دقیقه اول با اصطلاحات پیچیده مواجه شود و نتواند پیشرفت خود را احساس کند، احتمالا انگیزه ادامه‌دادن کاهش پیدا می‌کند.
فرضیه چهارم: مانع فنی یا محدودیت دسترسی وجود دارد.
ممکن است ویدئو درست بارگذاری نشود، پیشرفت کاربر ذخیره نشود یا آزمون آموزشی با صفحه‌خوان قابل استفاده نباشد.
فرضیه پنجم: کاربر قصد دارد آموزش را در چند نوبت کامل کند.
ناتمام ماندن درس در یک نشست لزوما به معنی شکست محصول نیست. شاید کاربر انتظار دارد بتواند آموزش را متوقف کند و بعدا از همان نقطه ادامه دهد.
این فرضیه‌ها را نباید صرفا از پشت میز تایید کنیم. باید ببینیم کدام‌یک با رفتار واقعی و توضیحات کاربران سازگارتر است.
۳. راه‌حل را متناسب با علت انتخاب کنیم
حالا می‌توانیم چند مسیر متفاوت را بررسی کنیم.
اگر مشکل از پیچیدگی ورود باشد، کاهش مراحل غیرضروری یا انتقال بخشی از تنظیمات به بعد از اولین تجربه ارزشمند می‌تواند کمک کند.
اگر کاربران درک نمی‌کنند چرا باید درس اول را بخوانند، بهتر است نتیجه مورد انتظار آموزش را شفاف‌تر کنیم و امکان تجربه یک موفقیت کوچک را زودتر فراهم کنیم.
اگر طول درس یا فشار شناختی مانع اصلی باشد، می‌توان محتوا را به بخش‌های معنادار تقسیم کرد، تمرین‌های کوتاه‌تری ارائه داد و امکان ادامه از نقطه قبلی را در نظر گرفت.
اصل «نمایش تدریجی اطلاعات» یا Progressive Disclosure در طراحی تجربه کاربری هم بر همین ایده استوار است که لازم نیست تمام پیچیدگی محصول را از ابتدا به کاربر نشان دهیم. البته اجرای درست آن به شناخت کارهای اصلی کاربر وابسته است، نه صرفا پنهان‌کردن امکانات.
از طرف دیگر، پژوهش‌های Nielsen Norman Group درباره راهنمای شروع استفاده از محصولات نشان می‌دهد آموزش‌های اجباری و خارج از زمینه استفاده ممکن است مزاحم کار اصلی کاربران شوند. راهنمایی در همان لحظه نیاز، برای بعضی مسائل انتخاب مناسب‌تری است.
با این حال، نباید نتیجه بگیریم که کوتاه‌کردن درس اول همیشه بهترین راه‌حل است.
یک درس کوتاه‌تر که هیچ یادگیری معناداری ایجاد نمی‌کند، شاید نرخ تکمیل را افزایش دهد، اما ارزش محصول را بیشتر نمی‌کند.
در تصمیم‌گیری باید میان سه موضوع تعادل برقرار کنیم: کاهش اصطکاک شروع، حفظ کیفیت یادگیری و هزینه اجرای تغییر.
۴. یک مثال واقعی‌نما از محصول نرم‌افزاری
سناریوی فرضی
فرض کنیم یک اپلیکیشن آموزش زبان داریم که اولین درس آن شامل معرفی مفاهیم، پخش فایل صوتی، تمرین و آزمون پایانی است.
تحلیل اولیه نشان می‌دهد بخش قابل‌توجهی از کاربران تازه‌وارد پس از ورود به تمرین شنیداری، درس را رها می‌کنند.
در این مرحله سه گزینه داریم.
گزینه اول این است که با ارسال اعلان، کاربران را به ادامه درس تشویق کنیم. این روش ممکن است تعدادی از افراد را برگرداند، اما اگر مشکل اصلی سختی تمرین یا اختلال پخش صوت باشد، علت ریزش را برطرف نمی‌کند.
گزینه دوم ساده‌کردن همه درس‌هاست. این تغییر دامنه بزرگی دارد و بدون شواهد کافی ممکن است به کیفیت آموزشی آسیب بزند.
گزینه سوم بررسی دقیق همان مرحله و ساخت یک آزمایش محدود است.
من گزینه سوم را انتخاب می‌کنم.
تیم محصول ابتدا با همکاری طراح، پژوهشگر و توسعه‌دهنده بررسی می‌کند که آیا فایل صوتی به‌درستی اجرا می‌شود، دستور تمرین واضح است و سطح تمرین با دانش اولیه مخاطب تناسب دارد یا نه.
فرض کنیم در پژوهش متوجه می‌شویم کاربران مبتدی نمی‌دانند بعد از شنیدن فایل صوتی دقیقا باید چه کاری انجام دهند.
در این صورت نسخه آزمایشی می‌تواند یک راهنمای کوتاه در محل تمرین و یک نمونه حل‌شده داشته باشد، بدون اینکه استاندارد آموزشی تغییر کند.
این نسخه را با تجربه فعلی مقایسه می‌کنیم تا ببینیم کاربران بیشتری تمرین را با موفقیت انجام می‌دهند یا نه.
اگر شواهد بعدی نشان دهد مسئله اصلی قطع‌شدن پخش صوت در اینترنت ضعیف بوده، تصمیم را عوض می‌کنیم و رفع مشکل فنی را در اولویت قرار می‌دهیم.
ارزش این رویکرد در آن است که به‌جای بازطراحی کل محصول، یک فرضیه مشخص را با هزینه و ریسک کمتر آزمایش کرده‌ایم.
۵. موفقیت را چطور اندازه بگیریم؟
مهم‌ترین اشتباه در این مرحله، انتخاب یک معیار ظاهرا جذاب و بی‌توجهی به کیفیت تجربه است.
اگر فقط نرخ تکمیل درس اول را بسنجیم، تیم ممکن است با کوتاه‌کردن افراطی محتوا یا ساده‌کردن غیرمنطقی آزمون‌ها عدد بهتری تولید کند.
برای جلوگیری از این اتفاق، سه سطح معیار تعریف می‌کنیم.
معیار اصلی: تکمیل موفق اولین تجربه آموزشی
نرخ تکمیل درس اول در هفت روز اول را می‌توان این‌طور تعریف کرد:
تعداد کاربران تازه‌واردی که درس اول را تا هفت روز پس از شروع تکمیل کرده‌اند ÷ تعداد کاربران تازه‌واردی که درس اول را شروع کرده‌اند.
این تعریف یک پیشنهاد تحلیلی برای سناریوی ماست، نه استاندارد اجباری صنعت.
در کنار آن، نرخ شروع درس از میان نصب‌کنندگان واجد شرایط را جداگانه بررسی می‌کنیم. این دو نرخ به دو مسئله متفاوت پاسخ می‌دهند و نباید با هم اشتباه شوند.
معیارهای تشخیصی
زمان رسیدن به اولین موفقیت آموزشی، ریزش در هر مرحله، تعداد خطاهای تمرین، استفاده از راهنما و نرخ بازگشت برای ادامه درس را بررسی می‌کنیم.
برای ثبت رویدادها می‌توان از الگوی رویدادمحور استفاده کرد. Google Analytics رویدادهایی مانند tutorial_begin و tutorial_complete را برای سنجش تکمیل فرایند راه‌اندازی اولیه معرفی کرده است.
البته این رویدادها مخصوص آموزش اولیه استفاده از اپلیکیشن هستند و نباید بدون تعریف مستقل، معادل شروع و پایان «درس آموزشی» فرض شوند.
معیارهای محافظتی
باید مطمئن شویم که بهبود نرخ تکمیل به بهای کاهش یادگیری، افزایش خطا یا نارضایتی کاربران تمام نشده است.
برای همین، نتیجه یک تمرین سنجش درک مطلب، شروع درس دوم، بازگشت در روزهای بعد، خطاهای فنی و بازخورد کاربران را هم بررسی می‌کنیم.
معیارها، گروه‌های مقایسه و بازه سنجش باید پیش از آزمایش مشخص شوند. اگر تعداد کاربران کافی نباشد، به‌جای ادعای نتیجه قطعی، یافته‌ها را مقدماتی گزارش می‌کنیم.
۶. اگر فقط دو هفته فرصت داشته باشیم چه می‌کنیم؟
این یکی از دو سوال تکمیلی مطرح‌شده در منبع اصلی مصاحبه است.
در چنین شرایطی، هدف من بازطراحی کامل محصول نیست. می‌خواهم در دو هفته عدم قطعیت مهمی را کاهش دهم.
در چند روز اول، درستی داده‌ها و تعریف رویدادها را بررسی می‌کنم و گروهی را که بیشترین ریزش قابل‌اقدام را دارد مشخص می‌کنم.
بعد از آن، با چند کاربر همان گروه گفت‌وگو و آزمون کاربردپذیری برگزار می‌کنم تا ببینم مشکل از کجا شروع می‌شود.
در ادامه، یک تغییر محدود را با همکاری طراحی و توسعه آماده می‌کنیم و در اختیار گروه آزمایشی قرار می‌دهیم.
در پایان دو هفته انتظار ندارم حتما تاثیر بلندمدت بر یادگیری اثبات شده باشد. خروجی قابل‌قبول می‌تواند شناسایی یک علت معتبر، رفع یک مانع آشکار یا رسیدن به شواهد اولیه برای تصمیم بعدی باشد.
اگر حجم نمونه برای نتیجه‌گیری کافی نباشد، آزمایش را ادامه می‌دهیم.
۷. چه شواهدی باعث می‌شوند راه‌حل پیشنهادی را کنار بگذاریم؟
این دومین سوال تکمیلی موجود در منبع است و از نظر من یکی از مهم‌ترین بخش‌های مصاحبه محسوب می‌شود.
فرض کنیم پیشنهاد داده‌ایم درس اول را به قسمت‌های کوتاه‌تر تقسیم کنیم.
اگر آزمایش نشان دهد کاربران بیشتری درس را تکمیل می‌کنند، اما در تمرین مفهومی عملکرد ضعیف‌تری دارند یا احتمال شروع درس دوم کاهش پیدا می‌کند، نمی‌توانیم آن را موفقیت قطعی بدانیم.
همچنین اگر متوجه شویم ریزش بیشتر در دستگاه‌هایی اتفاق می‌افتد که مشکل پخش محتوا دارند، باید اولویت را از بازطراحی آموزشی به رفع اختلال فنی تغییر دهیم.
مدیر محصول نباید از راه‌حل خودش دفاع کند؛ باید بتواند توضیح دهد چه شواهدی آن را تایید یا رد می‌کنند.
۸. پاسخ پیشنهادی در جلسه مصاحبه
نمونه پاسخ شفاهی یک نامزد مدیر محصول:
«اول مطمئن می‌شوم که مسئله را درست تعریف کرده‌ایم. می‌خواهم بدانم کاربران درس اول را اصلا شروع نمی‌کنند یا شروع می‌کنند و وسط مسیر خارج می‌شوند. این دو وضعیت راه‌حل یکسانی ندارند.
بعد قیف استفاده را بررسی می‌کنم و کاربران را بر اساس سطح تجربه، محتوا و شرایط فنی تفکیک می‌کنم. در کنار داده‌ها با چند کاربر گفت‌وگو می‌کنم تا بفهمم مانع اصلی چیست.
اگر مثلا مشخص شود کاربران مبتدی به خاطر پیچیدگی تمرین اول آن را رها می‌کنند، یک راهنمای کوتاه در همان مرحله را آزمایش می‌کنم، نه اینکه بلافاصله کل دوره را تغییر بدهم.
موفقیت را هم فقط با نرخ تکمیل نمی‌سنجم. باید ببینم کاربران واقعا چیزی یاد گرفته‌اند و برای ادامه آموزش برمی‌گردند یا نه.
اگر داده‌ها فرضیه‌ام را تایید نکنند، راه‌حل را تغییر می‌دهم. هدف من افزایش یک عدد نیست؛ می‌خواهم کاربر با کمترین مانع ممکن به اولین تجربه یادگیری ارزشمند برسد.»
۹. پاسخ‌های ضعیف چه ویژگی‌هایی دارند؟
«درس اول را کوتاه می‌کنم.» این پاسخ پیش از شناسایی علت، راه‌حل انتخاب کرده است. شاید مشکل اصلا طول درس نباشد.
«برای همه کاربران اعلان می‌فرستم.» چنین تصمیمی تفاوت نیازها را نادیده می‌گیرد و ممکن است به مزاحمت بیشتر و غیرفعال‌کردن اعلان‌ها منجر شود.
«تعداد تکمیل درس را بالا می‌برم.» اگر معیار موفقیت و کیفیت یادگیری روشن نباشد، امکان دارد فقط عدد بهتر شود و تجربه واقعی تغییری نکند.
«همه قابلیت‌های موردنیاز را اضافه می‌کنم.» در این پاسخ مشخص نیست کدام گروه از کاربران اولویت دارد و چه شواهدی هزینه توسعه را توجیه می‌کند.
یک پاسخ حرفه‌ای باید علاوه بر پیشنهاد، محدودیت‌ها، ریسک انتخاب و شرایط تغییر تصمیم را هم توضیح دهد.
جمع‌بندی
وقتی کاربران یک ابزار آموزشی را نصب می‌کنند اما درس اول را به پایان نمی‌رسانند، اولین اقدام درست بازطراحی درس، ارسال اعلان یا اضافه‌کردن قابلیت جدید نیست. باید بفهمیم چه کسانی در کدام مرحله متوقف می‌شوند و چه چیزی مانع رسیدن آن‌ها به اولین تجربه یادگیری موفق شده است.
من ابتدا مسیر کاربر را اندازه می‌گیرم، یک گروه مشخص و یک علت محتمل را انتخاب می‌کنم و کم‌هزینه‌ترین آزمایشی را اجرا می‌کنم که بتواند درستی فرضیه را روشن کند. هم‌زمان کیفیت یادگیری و بازگشت کاربران را زیر نظر می‌گیرم تا بهبود ظاهری یک شاخص ما را گمراه نکند.
اگر شواهد نشان دهند علت ریزش چیز دیگری است یا راه‌حل پیشنهادی به ارزش آموزشی آسیب می‌زند، تصمیم را اصلاح می‌کنم.
مدیریت محصول یعنی قبل از سریع‌تر ساختن راه‌حل، مطمئن شویم داریم مسئله درستی را حل می‌کنیم.
