طراحی وب

طراحی Onboarding؛ رساندن کاربر به نخستین نتیجه مفید

راهنمای طراحی Onboarding بدون آمار بی‌منبع؛ تعریف نتیجه اولیه، کاربران مختلف، Empty State، Checklist، مجوزها، دسترسی‌پذیری و سنجش رفتار واقعی.

1404/11/10 1 دقیقه مطالعه 1,281 بازدید

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

نخستین نتیجه مفید را تعریف کنید

ثبت‌نام موفق همیشه به معنی رسیدن به ارزش محصول نیست. کاربر ممکن است حساب بسازد و هنوز نداند چه کاری باید انجام دهد. یک نتیجه مشخص انتخاب کنید که به نیازش مربوط باشد. «دیدن dashboard» نتیجه‌ای ضعیف است اگر dashboard خالی باشد. «ساخت نخستین فهرست کار و افزودن یک مورد» روشن‌تر است. این تعریف به تیم کمک می‌کند مراحل لازم را از معرفی قابلیت‌های کم‌اولویت جدا کند. هدف Onboarding باید از کار کاربر بیاید و به تعداد صفحه‌های tour وابسته نباشد.

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

کاربران تازه تجربه یکسانی ندارند

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

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

Empty State را به اقدام واقعی وصل کنید

تعریف Empty State در Atlassian Design به نبود داده و توضیح کار بعدی اشاره می‌کند. این حالت جای مناسبی برای راهنمای شروع است، چون کاربر در همان محل نیاز قرار دارد. توضیح دهید چرا بخش خالی است و چه کاری می‌تواند انجام دهد. نبود نخستین پروژه با نبود نتیجه جست‌وجو یکسان نیست. اگر برای هر دو یک تصویر و دکمه «شروع کنید» می‌گذارید، احتمالاً دلیل واقعی وضعیت را به کاربر نمی‌رسانید.

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

Checklist وقتی مفید است که کارها واقعی باشند

فهرست کارهای شروع می‌تواند پیشرفت را نشان دهد، به‌ویژه وقتی مراحل مستقل‌اند. الگوی Complete multiple tasks در GOV.UK درباره سازمان‌دهی کارها راهنمایی دارد. فهرست باید نام کار و وضعیتش را روشن کند. اگر مرحله‌ای به مرحله دیگر وابسته است، دلیل غیرقابل دسترس‌بودن را توضیح دهید. یک checkbox نمایشی که با دیدن یک صفحه خودکار کامل می‌شود، اگر انجام واقعی کار را نشان ندهد، اطلاعات نادرستی درباره پیشرفت می‌دهد.

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

راهنمای زمینه‌ای را کوتاه و قابل بازگشت کنید

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

امکان بازکردن دوباره راهنما مفید است. کاربر ممکن است هنگام نخستین نمایش آماده خواندن نباشد. «Skip» نباید مجازات داشته باشد و کار اصلی را ببندد، مگر آموزش واقعاً برای ایمنی یا انجام درست مرحله ضروری باشد. در آن حالت، دلیل و معیار را توضیح دهید. مسیر کمک را در navigation یا همان component قابل یافتن نگه دارید. آموزش زمان‌مند بدون راه بازگشت، دانش را به حافظه لحظه‌ای کاربر وابسته می‌کند و بعد از وقفه فایده کمی دارد.

مرحله‌های طولانی به ساختار روشن نیاز دارند

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

خطا را نزدیک مرحله مربوط نشان دهید و روش اصلاح را بگویید. اگر اتصال قطع شد، کاربر نباید همه مراحل را دوباره انجام دهد. ذخیره پیش‌نویس باید با نوع داده و محل نگهداری هماهنگ باشد. مقاله طراحی Multi-step Wizard ادامه این بحث است. یک مسیر Onboarding ممکن است از نظر ظاهر کوتاه باشد و در عمل به چند درخواست و انتظار وابسته شود؛ زمان و وضعیت واقعی را در طراحی ببینید.

مجوز و دعوت را با اختیار روشن همراه کنید

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

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

دسترسی‌پذیری بخشی از شروع استفاده است

Tour و modal باید با صفحه‌کلید قابل استفاده باشند و focus را درست مدیریت کنند. کاربر نباید بعد از بستن راهنما موقعیتش را گم کند. متن، کنتراست و اندازه کنترل‌ها را در نمایش کوچک و بزرگ‌نمایی در نظر بگیرید. حرکت راهنما می‌تواند برای بعضی افراد مزاحم باشد؛ حالت بدون حرکت غیرضروری لازم است. مقاله دسترسی‌پذیری سایت فارسی درباره این مسیر توضیح می‌دهد. آموزش غیرقابل دسترس می‌تواند همان کاربران نیازمند راهنما را از کار اصلی دور کند.

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

نتیجه را با رفتار اصلی بسنجید

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

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

واکنش به این مقاله

اشتراک‌گذاری این مقاله:
دیدگاه‌ها 0
۰ / ۲۰۰۰

هنوز دیدگاهی ثبت نشده

اولین نفری باشید که نظر می‌دهد!