לעזור למשתמשים שלכם להירשם, להתחבר ולנהל את פרטי החשבון שלהם בפחות מאמץ.
אם אי פעם המשתמשים יצטרכו להתחבר לאתר שלכם, עיצוב טופס הרשמה טוב הוא קריטית. הדבר נכון במיוחד לגבי אנשים שהחיבור שלהם איטי, בנייד, ממהר או בלחץ. טופסי הרשמה שמעוצבים באופן שגוי מניבים שיעורי עזיבה גבוהים. כל עזיבה מהדף הראשון עלולה להיות משתמש שאבד ומאוכזב - ולא רק שההרשמה לא נענתה הזדמנות מצוינת.
לפניכם דוגמה לטופס הרשמה פשוט מאוד שמדגים את כל השיטות המומלצות:
רשימת המשימות
- אם אפשר, יש להימנע מכניסה לחשבון.
- להבהיר איך ליצור חשבון.
- להציג באופן ברור כיצד לגשת לפרטי החשבון.
- גזירה של בלגן.
- מומלץ להביא בחשבון את משך הסשן.
- איך לעזור למנהלי סיסמאות להציע סיסמאות ולאחסן אותן באופן מאובטח
- אין לאפשר סיסמאות שנחשפו.
- לאפשר הדבקה של סיסמאות.
- אין לאחסן או להעביר סיסמאות בטקסט פשוט.
- אין לאלץ עדכוני סיסמה.
- קל לשנות או לאפס סיסמאות.
- הפעלת התחברות מאוחדת.
- הופכים את המעבר בחשבון לפשוט יותר.
- כדאי להציע אימות רב-שלבי.
- חשוב לשים לב לשמות המשתמשים.
- לבצע בדיקות בשטח וגם בשיעור ה-Lab.
- ביצוע בדיקות במגוון דפדפנים, מכשירים ופלטפורמות.
כדאי להימנע מכניסה לחשבון, אם אפשר
לפני שתטמיעו טופס הרשמה ותבקשו ממשתמשים ליצור חשבון באתר שלכם, כדאי להביא בחשבון את אם אתם ממש צריכים. יש להימנע ככל האפשר מהגבלת תכונות באמצעות התחברות.
טופס ההרשמה הטוב ביותר הוא לא טופס הרשמה!
כשאתם מבקשים ממשתמש ליצור חשבון, אתם מפרידים בינו לבין מה שהוא מנסה להשיג. אתם מבקשים טובה ואתם מבקשים מהמשתמש לסמוך עליכם עם מידע אישי. כל סיסמה ופריט של הנתונים שאתם מאחסנים נושאים 'חובות נתונים' שקשורים לפרטיות ולאבטחה, מה שהופך להיות עלות וחבות באתר שלך.
אם הסיבה העיקרית שבגללה אתם מבקשים מהמשתמשים ליצור חשבון היא לשמור מידע בין הניווטים או גלישה באתר, כדאי להשתמש במקום זאת באחסון בצד הלקוח. לקניות אתרים שמאלצים את המשתמשים ליצור חשבון כדי לבצע רכישה הם סיבה עיקרית לקנייה נטישה של עגלת קניות. עליכם להגדיר תשלום כאורח כברירת המחדל.
הבלטת הכניסה
צריך להבהיר איך יוצרים חשבון באתר. לדוגמה, פרטי התחברות או כניסה בפינה הימנית העליונה של הדף. הימנעו משימוש בסמל לא ברור או בניסוח מעורפל ("היכנסו לכאן!", "הצטרפו אלינו") ואל תסתירו את אפשרות ההתחברות בתפריט הניווט. מומחה נוחות השימוש סטיב קרוג מסכם הגישה הזו לנוחות השימוש באתרים: אל תגרמו לי לחשוב! אם צריך לשכנע אחרים בצוות האינטרנט שלכם, כדאי להשתמש בניתוח נתונים כדי להראות את ההשפעה של אפשרויות.
![שני צילומי מסך של הדמיה של אתר מסחר אלקטרוני שנצפו בטלפון Android. הסמל שמשמאל משתמש בסמל של הקישור לכניסה לא ברור. התוצאה מימין רק אומרת 'כניסה'](https://web.developers.google.cn/static/articles/sign-up-form-best-practices/image/two-screenshots-a-mockup-62ee25473e20e.jpg?authuser=7&hl=he)
![צילומי מסך של כניסה ל-Gmail: דף אחד שבו מוצג הלחצן 'כניסה', כשמשתמש לוחץ עליו שמוביל לטופס שיש בו גם קישור ליצירת חשבון.](https://web.developers.google.cn/static/articles/sign-up-form-best-practices/image/screenshots-sign-for-gm-52c4c6c94532a.jpg?authuser=7&hl=he)
כשהחלונות גדולים ממה שמוצג כאן, Gmail מציג קישור לכניסה ויצירת לחצן החשבון.
צריך לקשר חשבונות של משתמשים שנרשמים דרך ספק זהויות, כמו Google להירשם גם באמצעות אימייל וסיסמה. אם יש לך גישה לכתובת האימייל של המשתמש, אפשר לעשות זאת בקלות מנתוני הפרופיל מספק הזהויות, ומתאימים בין שני החשבונות. הקוד הבא מראה איך לגשת לנתוני אימייל של משתמש עם כניסה באמצעות חשבון Google.
// auth2 is initialized with gapi.auth2.init()
if (auth2.isSignedIn.get()) {
var profile = auth2.currentUser.get().getBasicProfile();
console.log(`Email: ${profile.getEmail()}`);
}
להבהיר איך לגשת לפרטי החשבון
לאחר שמשתמש נכנס, בהירו לו איך לגשת לפרטי החשבון. במיוחד, מוסבר איך לשנות או לאפס סיסמאות.
גזירת בלגן
בתהליך ההרשמה, המשימה היא לצמצם את המורכבות ולשמור על ריכוז של המשתמש. להימנע מבלגן. זה לא הזמן לפיתוי וסחות דעת!
בזמן ההרשמה, בקשו כמה שפחות. איסוף נתוני משתמשים נוספים (כמו שם וכתובת) רק כשיש צורך, וכשהמשתמש רואה תועלת ברורה ממתן הנתונים האלה. חשוב לזכור שכל פריט נתונים שאתם מעבירים ומאחסנים כרוך בעלות ובחבות.
לא כדאי להכפיל את הנתונים רק כדי לוודא שהפרטים ליצירת קשר של המשתמשים נכונים. זה מאט מילוי טופס והוא לא הגיוני אם שדות טופס מתמלאים אוטומטית. במקום זאת, שלח אישור למשתמש אחרי שהזין את פרטי הקשר שלו, ולאחר מכן להמשיך ביצירת החשבון ברגע שמגיבים. זהו דפוס הרשמה נפוץ: המשתמשים רגילים אליו.
כדאי לשקול כניסה ללא סיסמה על ידי שליחת קוד למשתמשים בכל כניסה שלהם מכשיר או דפדפן חדש. אתרים כמו Slack ו-Medium משתמשים בגרסה הזו.
בדומה להתחברות מאוחדת, יש יתרון נוסף – אין צורך לנהל סיסמאות של משתמשים.
חשוב להביא בחשבון את משך הסשן
לא משנה איזו גישה תנקוט לגבי זהות המשתמש, יהיה עליך לקבל החלטה זהירה לגבי הסשן length: כמה זמן המשתמש נשאר מחובר ומה עלול לגרום לכם להתנתק ממנו.
חשוב לבדוק אם המשתמשים משתמשים בנייד או במחשב, ואם הם משתפים במחשב או משתפים מכשירים.
עוזרים למנהלי סיסמאות להציע ולאחסן סיסמאות באופן מאובטח
אפשר לעזור למנהלי סיסמאות של צדדים שלישיים ושל דפדפן מובנה להציע ולאחסן סיסמאות, כדי שמשתמשים לא צריכים לבחור, לזכור או להקליד סיסמאות בעצמם. מנהלי סיסמאות עובדים בצורה טובה בדפדפנים מודרניים, סנכרון חשבונות בין מכשירים, באפליקציות אינטרנט ובפלטפורמות ספציפיות — וגם למכשירים חדשים.
לכן חשוב מאוד לקודד את טופסי ההרשמה בצורה נכונה, בייחוד להשתמש
להשלמה אוטומטית של ערכים. לטופסי הרשמה, צריך להשתמש ב-autocomplete="new-password"
לסיסמאות חדשות, ולהוסיף
לתקן ערכים של השלמה אוטומטית בשדות טופס אחרים ככל האפשר, כמו autocomplete="email"
ו-autocomplete="tel"
. כדי לעזור למנהלי הסיסמאות, אפשר גם להשתמש בname
ובid
שונים
שבטופסי ההרשמה והכניסה, עבור הרכיב form
עצמו, וכן עבור כל input
, select
ו-textarea
רכיבים.
צריך גם להשתמש במאפיין type
המתאים
כדי לספק את המקלדת הנכונה בנייד ולאפשר אימות מובנה בסיסי על ידי הדפדפן.
מידע נוסף זמין במאמר בנושא שיטות מומלצות לשימוש בטופסי תשלום וכתובת.
הקפדה על הזנת סיסמאות מאובטחות למשתמשים
האפשרות הטובה ביותר היא לאפשר למנהלי סיסמאות להציע סיסמאות, למשתמשים לקבל סיסמאות חזקות שמוצעות על ידי דפדפנים ומנהלי דפדפנים של צד שלישי.
עם זאת, משתמשים רבים רוצים להזין את הסיסמאות שלהם, לכן צריך להטמיע כללים לסיסמה העוצמה. המכון הלאומי לתקנים וטכנולוגיה (National Institute of Standards and Technology) מסביר איך להימנע מסיסמאות לא מאובטחות
אין לאפשר סיסמאות שנחשפו
ללא קשר לכללים שתבחר עבור סיסמאות, לעולם אל תאפשר סיסמאות שחשפו פרצות אבטחה.
לאחר שמשתמש הזין סיסמה, עליך לבדוק שזו לא סיסמה שכבר הזנת בסיכון. האתר Did I Been Pwned מספק API לסיסמה או מריצים את הקוד כשירות בעצמך.
מנהל הסיסמאות של Google גם מאפשר לך לבדוק אם יש לך סיסמאות קיימות בחשבון בסיכון.
אם תדחו סיסמה שמשתמש מציע, ספרו לו באופן ספציפי למה היא נדחתה. להציג בעיות ולהסביר איך לפתור אותן, ברגע שהמשתמש הזין ערך – לא אחרי ששלח את טופס ההרשמה והיה צריך להמתין לתגובה מהשרת שלך.
אין למנוע הדבקה של סיסמאות
באתרים מסוימים אין אפשרות להדביק טקסט בהזנת סיסמאות.
איסור על הדבקת סיסמאות מפריע למשתמשים, מעודד סיסמאות שקל לזכור (ולכן גם עלולים להיות קל יותר להתפשרות), ולפי ארגונים כמו UK National יכול להיות ש'מרכז אבטחת הסייבר' יפחית את רמת האבטחה. המשתמשים יודעים שההדבקה אסורה רק אחרי שהם מנסים להדביק את הסיסמה שלהם, לכן איסור על הדבקת סיסמאות לא מונעת נקודות חולשה בלוח העריכה.
אף פעם אל תאחסן או תשדר סיסמאות בטקסט פשוט
חשוב לבחון ולגבב סיסמאות, ואל תנסו להמציא אלגוריתם גיבוב משלכם.
אין לאכוף עדכוני סיסמאות
אסור לאלץ את המשתמשים לעדכן את הסיסמאות שלהם באופן שרירותי.
אילוץ עדכוני הסיסמה עלול להיות יקר עבור מחלקות IT, מפריע למשתמשים, ואין ההשפעה על האבטחה. סביר להניח שהוא גם יעודד אנשים כדי להשתמש בסיסמאות לא מאובטחות או לשמור תיעוד פיזי של סיסמאות.
במקום לאלץ עדכוני סיסמה, עליך לעקוב אחר פעילות חריגה בחשבון ולהזהיר את המשתמשים. אם אפשר, כדאי גם לעקוב אחרי סיסמאות שנחשפו בגלל פרצות באבטחת מידע.
כמו כן, עליך לספק למשתמשים שלך גישה להיסטוריית ההתחברות שלהם לחשבון, ולהראות להם איפה ומתי בוצעה התחברות.
![דף הפעילות בחשבון Gmail](https://web.developers.google.cn/static/articles/sign-up-form-best-practices/image/gmail-account-activity-pa-c70c73f9a3264.jpg?authuser=7&hl=he)
שינוי או איפוס סיסמאות בקלות
צריך להבהיר למשתמשים איפה ואיך לעדכן את הסיסמה לחשבון שלהם. באתרים מסוימים היא קשה באופן מפתיע.
צריך כמובן גם להקל על המשתמשים לאפס את הסיסמה שלהם אם הם שכחו אותה. פרויקט Open Web Application Security Project (Open Web Application Security Project) מספק הנחיות מפורטות בנושא טיפול באובדן סיסמאות.
כדי להגן על העסק ועל המשתמשים שלך, חשוב במיוחד לעזור למשתמשים לשנות את
אם הוא יגלה שהוא נפרץ. כדי להקל על התהליך, מומלץ להוסיף
/.well-known/change-password
של כתובת ה-URL של
שמפנה מחדש לדף ניהול הסיסמאות שלכם. כך מנהלי הסיסמאות יכולים לנווט
המשתמשים ישירות לדף שבו הם יכולים לשנות את הסיסמה שלהם לאתר. התכונה הזאת
מיושם עכשיו ב-Safari וב-Chrome, ויגיע גם לדפדפנים אחרים. לעזור למשתמשים להחליף סיסמאות
בקלות באמצעות הוספה של כתובת URL ידועה לשינוי סיסמאות, שמסבירה איך
להטמיע אותו.
צריך גם לעזור למשתמשים למחוק את החשבון שלהם בקלות, אם זו המטרה שלהם.
הצעת התחברות דרך ספקי זהויות של צד שלישי
משתמשים רבים מעדיפים להתחבר לאתרים באמצעות כתובת אימייל וטופס הרשמה עם סיסמה. עם זאת, צריך גם לאפשר למשתמשים להתחבר דרך ספק זהויות של צד שלישי, שנקרא גם התחברות מאוחדת.
![דף כניסה ל-WordPress](https://web.developers.google.cn/static/articles/sign-up-form-best-practices/image/wordpress-login-page-b16b91f2dcb13.jpg?authuser=7&hl=he)
לגישה הזו יש כמה יתרונות. אם אתם יוצרים חשבון באמצעות התחברות מאוחדת, עליכם: לא מצריכות לבקש, לתקשר או לשמור סיסמאות.
ייתכן שתוכלו לגשת לפרטים נוספים של פרופיל מאומת דרך התחברות מאוחדת, למשל ככתובת אימייל – המשתמש לא צריך להזין את הנתונים האלה ולא צריך לעשות את האימות בעצמכם. התחברות מאוחדת יכולה גם להקל על המשתמשים כשהם מקבלים במכשיר החדש.
שילוב של כניסה באמצעות חשבון Google באפליקציית האינטרנט שמסבירה איך להוסיף התחברות מאוחדת לאפשרויות ההרשמה. יש פלטפורמות זהות רבות אחרות.
מעבר פשוט בין חשבונות
משתמשים רבים משתפים מכשירים ועוברים בין חשבונות באמצעות אותו דפדפן. האם המשתמשים יכולים לגשת להתחברות מאוחדת או לא, עליכם להפוך את המעבר בין החשבונות לפשוט יותר.
![Gmail, מוצגת מעבר בין חשבונות](https://web.developers.google.cn/static/articles/sign-up-form-best-practices/image/gmail-showing-account-sw-452d02090bac6.jpg?authuser=7&hl=he)
כדאי להציע אימות רב-שלבי
אימות רב-שלבי מאפשר לוודא שהמשתמשים מספקים אימות בכמה דרכים. לדוגמה, עוד דרישה מהמשתמש להגדיר סיסמה, אתם יכולים לאכוף את האימות באמצעות קוד גישה חד-פעמי שנשלח באימייל או בהודעת טקסט ב-SMS, או באמצעות קוד גישה חד-פעמי מבוסס אפליקציה קוד, מפתח אבטחה או חיישן טביעות אצבע. שיטות מומלצות לשימוש ב-SMS OTP וגם הפעלת אימות חזק באמצעות WebAuthn להסביר איך להטמיע אימות רב-שלבי.
עליך להציע (או לאכוף) אימות רב-שלבי אם האתר שלך מטפל מידע רגיש.
שמור על שמות המשתמשים
אל תתעקשו על שם משתמש אלא אם תצטרכו (או עד) שם משתמש. המשתמשים יכולים להירשם ולהיכנס באמצעות רק כתובת אימייל (או מספר טלפון) וסיסמה, או התחברות מאוחדת. אם הם מעדיפים. אל תאלץ אותם לבחור שם משתמש ולזכור אותו.
אם האתר דורש שמות משתמשים, אל תטילו עליהם כללים בלתי הגיוניים ואל תעצרו את המשתמשים. מעדכון שם המשתמש שלהם. בקצה העורפי צריך ליצור מזהה ייחודי לכל חשבון משתמש, ולא מזהה שמבוסס על מידע אישי, כמו שם משתמש.
כמו כן, צריך להקפיד להשתמש ב-autocomplete="username"
כשם משתמשים.
בדיקה במגוון מכשירים, פלטפורמות, דפדפנים וגרסאות
מומלץ לבדוק טופסי הרשמה בפלטפורמות הנפוצות ביותר של המשתמשים שלכם. הפונקציונליות של רכיב הצורה עשויה להשתנות, והבדלים בגודל אזור התצוגה עלולים לגרום לבעיות בפריסה. BrowserStack מאפשר בדיקה בחינם של פרויקטים של קוד פתוח במגוון מכשירים ודפדפנים.
הטמעת ניתוח נתונים ומעקב אחר משתמשים בפועל
אתם צריכים נתונים בשטח וגם נתוני שיעור Lab להבין איך משתמשים חווים את טופסי ההרשמה שלכם. Analytics ומעקב אחרי משתמשים אמיתיים (RUM) מספקים נתונים לגבי החוויה של המשתמשים בפועל, למשל כמה זמן לוקח לדפי הרשמה טעינה, עם אילו רכיבי ממשק משתמש המשתמשים מקיימים אינטראקציה (או לא) וכמה זמן לוקח למשתמשים להשלים להרשמה.
- ניתוח נתונים של דף: צפיות בדפים, שיעורי העזיבה ויציאות לכל דף בתהליך ההרשמה.
- ניתוח נתונים של אינטראקציות: משפכי יעדים ואירועים לציין היכן משתמשים נוטשים את תהליך ההרשמה ואיזה חלק מהמשתמשים לוחצים על לחצנים, ורכיבים אחרים של דפי ההרשמה שלך.
- ביצועי האתר: מדדים שמתמקדים במשתמשים יכול להודיע לכם אם תהליך ההרשמה שלכם נטען לאט או לא יציב מבחינה חזותית.
שינויים קטנים עשויים להשפיע באופן משמעותי על שיעורי ההשלמה של טופסי הרשמה. Analytics ו-RUM לאפשר אופטימיזציה של שינויים ולתעדף אותם, ולעקוב אחרי בעיות שאינן שנחשפים על ידי בדיקות מקומיות.
להמשיך ללמוד
- שיטות מומלצות לשימוש בטופסי כניסה
- שיטות מומלצות לשימוש בטופסי תשלום וכתובת
- יוצרים טפסים מדהימים
- שיטות מומלצות לעיצוב טפסים לנייד
- אפשרויות מתקדמות יותר ליצירת טפסים
- יצירת טפסים נגישים
- ייעול תהליך ההרשמה באמצעות ממשק ה-API לניהול פרטי כניסה
- אימות מספרי טלפון באינטרנט באמצעות WebOTP API
תמונה מאת @ecowarriorprincess ב-Unbounce.