صفحه ورود باید کاربر را به حساب درست برساند و صفحه ثبت‌نام باید توضیح دهد چرا ساخت حساب لازم است. این دو مسیر را صرفاً به دلیل داشتن چند فیلد مشابه یکی نکنید. مشتری قدیمی دنبال ادامه کار است؛ کاربر تازه هنوز درباره مزیت حساب و اطلاعات مورد نیاز تصمیم می‌گیرد. اگر خرید مهمان یا مشاهده محتوا بدون حساب ممکن است، آن مسیر را روشن نشان دهید. درخواست حساب در هر موقعیت، الزام عمومی طراحی نیست.
ساده‌سازی فرم به معنی حذف همه توضیحات یا کاهش امنیت نیست. هدف این است که داده لازم در زمان مناسب گرفته شود و خطا قابل اصلاح باشد. ادعای «هر فیلد اضافه حتماً کاربر را فراری می‌دهد» رفتار همه افراد را توضیح نمی‌دهد. فیلدی که برای دریافت خدمت ضروری است باید باقی بماند و علتش روشن باشد. شماره تماس برای هماهنگی تحویل با تاریخ تولد بی‌ارتباط تفاوت دارد؛ طراحی باید این تفاوت را به کاربر منتقل کند.
مسیر ورود و ثبت‌نام را از مقصد شروع کنید
ابتدا فهرست کنید کاربر پیش از ورود چه کاری انجام داده است. ممکن است سبد خرید آماده کرده، متنی نوشته یا لینک خصوصی دریافت کرده باشد. پس از ورود باید به همان مقصد معتبر برگردد، نه همیشه به داشبورد عمومی. مسیر بازگشت نیازمند بررسی سمت سرور است تا نشانی خارجی دلخواه به مقصد تبدیل نشود. در رابط، توضیح کوتاهی مثل «برای ذخیره درخواست وارد شوید» بهتر از پیامی است که بدون زمینه فقط ساخت حساب را مطالبه می‌کند.
ورود و ساخت حساب را با عنوان و اقدام اصلی قابل تشخیص کنید. دو دکمه هم‌وزن در یک کارت، تصمیم را مبهم می‌کنند. اگر تب دارید، وضعیت انتخاب‌شده باید با نام و ساختار قابل فهم مشخص شود. انتقال میان دو مسیر نباید اطلاعات غیرحساس واردشده را بی‌دلیل پاک کند. در موبایل، بخش تبلیغاتی بلند را بالای فرم قرار ندهید؛ کاربر قدیمی نباید برای رسیدن به فیلد ورود، هر بار توضیح محصول را مرور کند.
داده و رضایت را در زمان مناسب بگیرید
برای هر فیلد یک دلیل عملیاتی بنویسید. اگر نام کامل فقط هنگام صدور فاکتور لازم است، دریافت آن در همان مرحله می‌تواند مناسب‌تر باشد. همه محصولات با ایمیل و رمز شروع نمی‌شوند؛ بعضی به شماره تلفن یا هویت سازمانی نیاز دارند. انتخاب شناسه ورود باید با بازیابی، تغییر اطلاعات و دسترسی مخاطب سازگار باشد. به کاربر بگویید کدام داده برای حساب است و کدام برای شخصی‌سازی اختیاری، تا یک درخواست اختیاری به صورت شرط اجباری جلوه نکند.
پذیرش شرایط خدمت را از دریافت پیام تبلیغاتی جدا کنید. متن لینک‌ها قابل خواندن باشد و کاربر پیش از تأیید بتواند جزئیات را ببیند. Checkbox اختیاری خبرنامه نباید از پیش انتخاب شود و دکمه ثبت‌نام نباید موافقت‌های نامرتبط را پنهان کند. اگر ثبت‌نام چند مرحله دارد، محدوده مراحل و داده لازم را زود توضیح دهید. گرفتن تدریجی اطلاعات وقتی مفید است که مراحل واقعاً با کار مرتبط باشند؛ پراکنده کردن همان فرم طولانی در چند صفحه به تنهایی بهبود محسوب نمی‌شود.
رمز و Password Manager را پشتیبانی کنید
برچسب پایدار، امکان Paste و Autocomplete مناسب به ورود کمک می‌کنند. در مستندات input رمز در MDN، مقدارهای current-password برای ورود و new-password برای رمز تازه توضیح داده شده‌اند. شناسه ورود هم باید با کاربردش هماهنگ باشد. جلوگیری از Paste یا دستکاری رفتار تکمیل خودکار معمولاً کار Password Manager را سخت می‌کند. پنهان کردن کاراکترها وظیفه کنترل ورودی است و نباید به جلوگیری از استفاده ابزارهای کمکی تبدیل شود.
دکمه نمایش رمز باید نام و وضعیت روشن داشته باشد و مقدار واردشده را تغییر ندهد. کاربر باید بتواند آن را با صفحه‌کلید فعال کند. راهنمای سیاست رمز پیش از خطا دیده شود و با قواعد واقعی سرور مطابق باشد. نشانگر Strength به تنهایی توضیح کافی نیست؛ اگر رمزی پذیرفته نمی‌شود، دلیل قابل اقدام لازم است. از نمایش نمره‌ای که بدون روش معلوم امنیت را تضمین می‌کند پرهیز کنید. مسئول فنی باید سیاست رمز و روش ذخیره آن را جدا از ظاهر فرم تعیین کند.
خطای ورودی را از خطای احراز هویت جدا کنید
خالی بودن فیلد یا قالب نامعتبر ایمیل را می‌توان دقیق توضیح داد. خطای احراز هویت موضوع دیگری است: نمایش اینکه یک ایمیل در سیستم وجود دارد ممکن است به کشف حساب‌ها کمک کند. راهنمای Authentication در OWASP درباره پاسخ‌های عمومی و جلوگیری از افشای وجود حساب توضیح دارد. متن باید هم امکان اصلاح را بدهد و هم اطلاعات غیرضروری آشکار نکند؛ مثلاً کاربر را به بررسی اطلاعات یا استفاده از مسیر بازیابی هدایت کند.
هنگام خطا، شناسه واردشده را بی‌دلیل پاک نکنید و وضعیت ارسال را روشن نگه دارید. پیام شبکه با رمز نادرست فرق دارد؛ «ارتباط برقرار نشد، دوباره تلاش کنید» نباید به عنوان شکست حساب معرفی شود. در حالت انتظار، ارسال تکراری مدیریت شود. اگر محدودیت تلاش فعال شد، راه اقدام بعدی و زمان تقریبی فقط بر اساس رفتار واقعی سیستم اعلام شود. عدد شمارش معکوس نمایشی که با وضعیت سرور تطابق ندارد باعث تلاش ناموفق و بی‌اعتمادی می‌شود.
بازیابی حساب را بخشی از طراحی بدانید
لینک فراموشی رمز نزدیک مسیر ورود باشد. صفحه بازیابی توضیح دهد چه چیزی دریافت می‌شود و پس از آن چه باید کرد. برای حفظ حریم خصوصی، پاسخ ارسال درخواست می‌تواند مستقل از وجود حساب یکسان باشد؛ اما کاربر همچنان به راهنمای بررسی پوشه Spam و تلاش دوباره نیاز دارد. درخواست دوباره باید محدودیت مشخص داشته باشد. هیچ پیام رابطی نباید از کاربر بخواهد رمز قبلی را در ایمیل یا گفت‌وگوی پشتیبانی ارسال کند.
لینک منقضی، لینک استفاده‌شده و نبود دسترسی به شناسه قبلی حالت‌های جدا هستند. برای هر کدام مسیر بعدی تعریف کنید. بازیابی نباید به سؤال‌های شخصی آسان برای حدس متکی شود. اگر پشتیبانی انسانی وارد فرایند می‌شود، داده و مسئولیت آن روشن باشد. تغییر ایمیل و شماره تماس نیز مسیر حساسی است و باید با کنترل مناسب انجام شود. دکمه خوش‌ظاهر «بازیابی» بدون فرایند پشت آن، تجربه ورود را کامل نمی‌کند و می‌تواند نقطه ضعف حساب باشد.
روش‌های جایگزین را با محدودیت معرفی کنید
Social Login برای بعضی مخاطبان مسیر آشناست، اما به دسترسی به ارائه‌دهنده و حساب او وابسته است. نام ارائه‌دهنده را روشن بنویسید و خطای لغو مجوز را از شکست شبکه جدا کنید. کاربر باید بداند آیا حساب جدید ساخته می‌شود یا حساب موجود پیوند می‌خورد. یک ایمیل مشابه به تنهایی نباید در رابط وعده ادغام امن حساب‌ها بسازد؛ سیاست پیوند حساب موضوع فنی مستقلی است و باید از پیش تعیین شود.
Passkey هم به طراحی ایجاد، استفاده و بازیابی نیاز دارد. معرفی آن را به «ورود بدون رمز» محدود نکنید؛ بگویید دستگاه یا مدیر اعتبارنامه چه نقشی دارد و برای دستگاه تازه چه مسیری موجود است. نبود پشتیبانی یا لغو عملیات باید پیام قابل فهم داشته باشد. اگر راه جایگزین ارائه می‌کنید، امنیت آن باید با هدف محصول سازگار بماند. اضافه کردن نام یک فناوری جدید بدون رسیدگی به این حالت‌ها، فقط تعداد دکمه‌های ورود را افزایش می‌دهد.
دسترسی‌پذیری و نشست را کنار هم طراحی کنید
معیار Accessible Authentication در WCAG 2.2 به آزمون‌های شناختی در ورود و امکان استفاده از سازوکارهای کمکی می‌پردازد. CAPTCHA و الزام به حفظ یا رونویسی اطلاعات باید با این الزامات بررسی شوند. Label، ترتیب Focus و توضیح خطا را از ابتدای طراحی در نظر بگیرید. متن ریز و کم‌رنگ شرایط یا خطای قرمز بدون توضیح، برای بسیاری از کاربران قابل استفاده نیست؛ رنگ نباید تنها حامل معنی باشد.
گزینه Remember Me باید معنی مشخص داشته باشد. کاربر باید بفهمد روی دستگاه مشترک چه انتخابی می‌کند؛ این گزینه نباید ذخیره رمز خام تلقی شود. پایان نشست، خروج و نیاز به ورود دوباره را طراحی کنید تا کار در حال انجام بی‌اطلاع از بین نرود. مقاله طراحی فرم وب برای وضعیت‌ها و Onboarding برای مسیر پس از ساخت حساب مفید است. پیش از تحویل، همه مسیرهای ورود، بازیابی، لغو و بازگشت به کار قبلی را با مسئول فنی مرور کنید.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!