طراحی ورود و ثبت‌نام در موبایل: مرحله حساب کاربری را روشن کنید
راهنمایی کاربردی برای طراحی ورود و ثبت‌نام در موبایل؛ از تشخیص زمان نیاز به حساب کاربری تا ساخت فرم‌های منعطف و مسیرهای بازیابی کارآمد.
صفحه ورود رابط کوچکی با اثری بزرگ است: می‌تواند به فرد کمک کند کارش را ادامه دهد، یا پیش از آنکه بفهمد چرا حساب کاربری اهمیت دارد، مسیرش را قطع کند. طراحی خوب حساب کاربری در موبایل از اینجا آغاز می‌شود که احراز هویت را بخشی از سفر محصول بدانیم، نه دروازه‌ای که همه باید هنگام باز کردن اپلیکیشن از آن بگذرند.
جریان باید هدف و گزینه‌هایش را آسان‌فهم کند، فقط اطلاعاتی را بخواهد که اکنون لازم است و هنگام بروز مشکل، راهی آرام و روشن برای ادامه بدهد. این جزئیات هم برای بازدیدکنندگان نخستین‌بار و هم برای کاربران بازگشتی که شاید روش ورود قبلی خود را فراموش کرده‌اند مهم‌اند.
نکته‌های کلیدی
- در نخستین نقطه معناداری که حساب کاربری مزیتی روشن ایجاد می‌کند یا واقعاً لازم است، آن را درخواست کنید.
- هر گزینه ورود را با زبانی آشنا توضیح دهید و مسیر ساخت حساب جدید را از ورود کاربران بازگشتی متمایز کنید.
- فرم‌ها را متمرکز نگه دارید، فیلدها را روشن برچسب بزنید و بگذارید مدیرهای رمز و جای‌گذاری متن مطابق انتظار کار کنند.
- خطاها را به‌صورت متن همراه با گام بعدی مفید نشان دهید، ورودی معتبر را حفظ کنید و بازیابی را بدون سرزنش ارائه دهید.
زمانی را انتخاب کنید که حساب کاربری مفید می‌شود
از کاری شروع کنید که فرد برای انجامش آمده است. اگر تجربه اصلی بدون حساب هم ممکن است، بگذارید ابتدا محصول را کاوش کند و وقتی به قابلیتی رسید که به ترجیحات ذخیره‌شده، دسترسی میان دستگاه‌ها، همکاری یا تراکنش نیاز دارد، ورود را درخواست کنید. راهنمای رابط انسانی Apple توصیه می‌کند در صورت امکان ورود را به تأخیر بیندازید و وقتی حساب لازم است، مزیت آن را توضیح دهید.
درخواست در بستر کار از مانع ورود هنگام راه‌اندازی فهم‌پذیرتر است. برای نمونه، اپلیکیشن مطالعه می‌تواند اجازه مرور عنوان‌ها را بدهد و وقتی فرد همگام‌سازی فهرست مطالعه را انتخاب کرد، از او بخواهد حساب بسازد. اگر ساخت حساب از آغاز ضروری است، پیش از نشان دادن فیلدها دلیلش را بگویید. توضیح را مشخص و متناسب نگه دارید: «برای ذخیره پروژه‌ها و باز کردنشان در دستگاه دیگر حساب بسازید» از «به جامعه ما بپیوندید» مفیدتر است.
- اطلاعات ضروری را از جزئیات اختیاری نمایه جدا کنید.
- برای خرید بدون حساب یا کار یک‌باره، بررسی کنید آیا ساخت حساب می‌تواند تا پس از ارائه ارزش فوری صبر کند.
- پس از احراز هویت موفق، افراد را به اقدامی برگردانید که قصد انجامش را داشتند.
گزینه‌های ورود را روشن و آشنا کنید
فرد باید بتواند تشخیص دهد که در حال ساخت حساب است یا بازگشت به حساب موجود. برای این دو مسیر برچسب‌های متمایز بگذارید، اقدام اصلی را از نظر بصری روشن کنید و روش‌های جایگزین را جایی قرار دهید که بدون شلوغ کردن صفحه قابل‌مقایسه باشند. هرجا مناسب است از نام ارائه‌دهندگان و ظاهر دکمه مورد تأیید پلتفرم استفاده کنید؛ برچسب کلی «ادامه» به‌تنهایی توضیح نمی‌دهد بعد چه اتفاقی می‌افتد.
فقط روش‌هایی را ارائه کنید که محصول پشتیبانی می‌کند و می‌تواند نگه دارد. ایمیل، کلید عبور یا گزینه هویت پلتفرم ممکن است برای مخاطبان مختلف مناسب باشند. آن‌ها را به‌صورت انتخاب ارائه کنید، نه با ادعای اینکه یک روش برای همه آسان‌ترین یا امن‌ترین است. هر اطلاعات اضافی ضروری را توضیح دهید.
کاربران بازگشتی ممکن است روش ورود خود را به یاد نیاورند. بازیابی و روش ورود جایگزین را پیدا‌کردنی کنید و توضیح دهید اگر ایمیل با روش دیگری مرتبط است چه باید کرد. راهنمایی برای پیوند حساب‌ها می‌تواند به افراد کمک کند دسترسی به حساب موجودشان را حفظ کنند.
فرم‌ها را متمرکز و سازگار با ابزارهای کاربران نگه دارید
فقط فیلدهای لازم برای ساخت حساب یا دسترسی به آن را بخواهید. به‌جای اتکا به متن جای‌نگهدار به‌عنوان تنها برچسب، از برچسب‌های پایدار استفاده کنید، نوع ورودی و صفحه‌کلید مناسب را انتخاب کنید و اقدام بعدی را روشن نشان دهید. اگر ثبت‌نام به چند داده نیاز دارد، فیلدهای مرتبط را گروه‌بندی و ترجیحات اختیاری را به پس از ورود فرد به محصول موکول کنید.
احراز هویت باید با تکمیل خودکار و مدیرهای رمز کار کند. از نام‌ها و معنای استاندارد فیلدها استفاده کنید و از رفتار سفارشی‌ای که پر کردن اطلاعات ورود را مختل می‌کند پرهیز کنید. جای‌گذاری رمز را مسدود نکنید: افراد ممکن است از مدیر رمز یا ابزار دیگری استفاده کنند. راهنمای WCAG بر امکان پر کردن فیلدهای ورود توسط مرورگر و مدیرهای رمز شخص ثالث تأکید می‌کند.
رفتار در دستگاه‌ها و مدیرهای رمز مختلف ممکن است فرق کند؛ بنابراین جریان را در پلتفرم‌های پشتیبانی‌شده بررسی کنید و اصلاح دستی را ممکن بگذارید. پس از تلاش ناموفق، در صورت امکان داده‌های مفید و غیرحساس مانند نشانی ایمیل را حفظ کنید.
- از برچسب قابل‌مشاهده‌ای مانند «نشانی ایمیل» و برچسب روشن رمز عبور استفاده کنید.
- در صورت مناسب بودن، به افراد امکان نمایش یا بررسی رمز را بدهید، بی‌آنکه آن کنترل تنها راه اصلاح ورودی باشد.
- دکمه اصلی را نزدیک فیلدها بگذارید و برچسبی متناسب با اقدام، مانند «ساخت حساب» یا «ورود»، به آن بدهید.
برای اشتباه‌ها، بازیابی و مراجعه بعدی طراحی کنید
خطای مفید، فیلد یا مرحله ناموفق را با متن مشخص می‌کند و می‌گوید چگونه ادامه دهند. وقتی قالب ایمیل نامعتبر است یا فیلدی خالی مانده، «مشکلی پیش آمد» کافی نیست. معیار موفقیت ۳.۳.۱ در WCAG 2.2 می‌خواهد خطاهای ورودی شناسایی‌شده، در متن مشخص و توصیف شوند؛ رنگ یا نماد نباید به‌تنهایی پیام را منتقل کند.
از زبانی خنثی استفاده کنید و راهنمایی مربوط به هر فیلد را نزدیک همان فیلد بگذارید. برای مثال، متن فرضی برای نشانی نادرست می‌تواند چنین باشد: «نشانی ایمیل را در قالب [email protected] وارد کنید.» برای ورود ناموفق، محصول می‌تواند بگوید: «با این مشخصات نتوانستیم واردتان کنیم. ایمیل و رمزتان را بررسی کنید یا رمز را بازنشانی کنید.» از افشای اطلاعات حساس حساب در پیام‌های خطا پرهیز کنید؛ عبارتی انتخاب کنید که با نیازهای حریم خصوصی و پیشگیری از سوءاستفاده محصول سازگار باشد.
توضیح دهید پس از درخواست بازنشانی چه می‌شود، راهی برای بازگشت به ورود فراهم کنید و به افراد کمک کنید روش قبلی ورودشان را پیدا کنند. در مراجعه‌های بعدی، وضعیت واردشده را روشن نشان دهید و راه دسترسی به تنظیمات حساب، خروج و راهنما را فراهم کنید. اگر ساخت حساب در اپلیکیشن ممکن است، پیدا کردن حذف حساب را هم آسان کنید.
- خطا را به فیلدی که توصیف می‌کند پیوند دهید و آن را بدون اتکا به رنگ قابل‌درک کنید.
- اقدام‌های بازیابی را نزدیک فرم ورود بگذارید و کاربران را بی‌دلیل مجبور به شروع دوباره نکنید.
- وضعیت‌های استفاده نخست و بازگشت کاربر را بررسی کنید، از جمله ایمیل تغییرکرده و روش‌های ورود در دسترس نبود‌ه.
بازبینی کاربردی جریان حساب کاربری
جریان را از دید فردی تازه‌وارد، کاربر بازگشتی و کسی که دسترسی‌اش را بازیابی می‌کند طی کنید. صفحه‌ها را در بستر خود بررسی کنید. کتابخانه الگوهای موبایل می‌تواند به تیم‌ها کمک کند شیوه سازمان‌دهی ورودی‌ها، برچسب‌ها و اقدام‌ها را در فرم‌ها مقایسه کنند.
- وقتی حساب ضروری نیست، آیا افراد می‌توانند پیش از ورود به ارزش مفید محصول برسند؟
- آیا صفحه دلیل نیاز به حساب و اطلاعات ضروری را بیان می‌کند؟
- آیا فرد می‌تواند ثبت‌نام، ورود، روش‌های جایگزین و بازیابی حساب را از هم تشخیص دهد؟
- آیا برچسب‌های فیلد قابل‌مشاهده می‌مانند و تکمیل خودکار و جای‌گذاری می‌توانند اطلاعات ورود را پر کنند؟
- آیا خطاها مشکل را در متن نام می‌برند، ورودی مفید را حفظ می‌کنند و گام بعدی را پیشنهاد می‌دهند؟
- پس از موفقیت، آیا فرد به کاری که آغاز کرده بود برمی‌گردد؟
پرسش‌های رایج
آیا اپلیکیشن موبایل باید پیش از کاوش محصول حساب کاربری بخواهد؟
فقط وقتی کارکرد اصلی واقعاً به حساب نیاز دارد. اگر افراد می‌توانند ابتدا محصول را مرور یا امتحان کنند، اجازه دهید چنین کنند و زمانی ورود را درخواست کنید که مزیتی روشن ایجاد می‌کند یا برای اقدامی مشخص لازم است.
آیا فیلدهای رمز باید جای‌گذاری و تکمیل خودکار مدیر رمز را مجاز کنند؟
بله. از برچسب‌ها و معنای فیلدهای آشنا استفاده کنید و جای‌گذاری یا تکمیل خودکار را مسدود نکنید. این قابلیت‌ها کمک می‌کنند افراد از ابزار دلخواه خود برای اطلاعات ورود استفاده کنند؛ البته رفتار ممکن است در دستگاه‌ها و مدیرهای رمز متفاوت باشد، پس جریان را در پلتفرم‌های پشتیبانی‌شده بررسی کنید.
پیام خطای ورود باید شامل چه چیزهایی باشد؟
مشکل را در متن شرح دهید، فیلد یا مرحله مربوط را مشخص کنید و اقدامی کاربردی برای ادامه پیشنهاد دهید. لحن را خنثی نگه دارید و جزئیات حساس حساب را آشکار نکنید.
