שיטות מומלצות לשימוש בטופס ההרשמה

עזרו למשתמשים להירשם, להתחבר ולנהל את פרטי החשבון שלהם בקלות.

Sam Dutton

אם המשתמשים יצטרכו להתחבר לאתר שלכם, חשוב שתעצבו את טופס ההרשמה בצורה טובה. זה נכון במיוחד לאנשים עם חיבור חלש, בנייד, בזמן ובלחץ. טופסי הרשמה שלא מעוצבים כראוי מקבלים שיעורי עזיבה גבוהים. כל עזיבה מהדף הראשון עלולה להיות משתמש שאבד ומאוכזב - ולא רק הזדמנות להרשמה שפוספסה.

זו דוגמה לטופס הרשמה פשוט מאוד שמציג את כל השיטות המומלצות:

רשימת המשימות

• אם אפשר, כדאי להימנע מכניסה לחשבון.
• חשוב להסביר בבירור איך יוצרים חשבון.
• חשוב להבהיר איך ניגשים לפרטי החשבון.
• הסרת רכיבים מיותרים מהטופס.
• משך הסשן
• עזרה למנהלי סיסמאות להציע ולאחסן סיסמאות בצורה מאובטחת.
• אין לאפשר סיסמאות שנחשפו.
• צריך לאפשר הדבקת סיסמה.
• אף פעם לא שומרים או מעבירים סיסמאות בטקסט ללא הצפנה.
• לא לאלץ עדכוני סיסמה.
• שינוי או איפוס של סיסמאות בקלות.
• מפעילים את הכניסה המאוחדת.
• הופכים את המעבר בין החשבונות לפשוט יותר.
• כדאי להציע אימות רב-שלבי.
• חשוב להיזהר עם שמות משתמשים.
• בדיקה בשטח וגם במעבדה.
• בדיקה במגוון דפדפנים, מכשירים ופלטפורמות.

אם אפשר, כדאי להימנע מכניסה לחשבון

לפני שמטמיעים טופס הרשמה ומבקשים מהמשתמשים ליצור חשבון באתר, כדאי לשקול אם באמת צריך לעשות זאת. ככל האפשר, כדאי להימנע מחסימת תכונות מאחורי התחברות.

טופס ההרשמה הטוב ביותר הוא כלל לא טופס הרשמה!

כשאתם מבקשים ממשתמש ליצור חשבון, אתם נמצאים בתווך בין המשתמש לבין המטרה שהוא מנסה להשיג. אתם מבקשים טובה מהמשתמש ומבקשים ממנו לסמוך עליכם עם מידע אישי. כל סיסמה ופריט נתונים שאתם מאחסנים נושאים בחוב פרטיות ואבטחה, והם הופכים לעלויות ולחבויות של האתר.

אם הסיבה העיקרית שבגללה אתם מבקשים מהמשתמשים ליצור חשבון היא כדי לשמור מידע בין אירועי ניווט או סשנים של גלישה, כדאי לכם להשתמש באחסון בצד הלקוח במקום זאת. באתרי קניות, אחת הסיבות העיקריות לנטישה של עגלות קניות היא אילוץ המשתמשים ליצור חשבון כדי לבצע רכישה. עליכם להגדיר תשלום כאורח כברירת המחדל.

להפוך את הכניסה לחשבון לברורה

חשוב להבהיר איך יוצרים חשבון באתר, למשל באמצעות לחצן כניסה או התחברות בפינה הימנית העליונה של הדף. יש להימנע משימוש בסמל דו-משמעי או בטקסט לא ברור ('נכנסים לעניינים', "הצטרפו אלינו") ואל תסתירו את אפשרות ההתחברות בתפריט הניווט. מומחה הנוחות Steve Krug סיכם את הגישה הזו לנוחות השימוש באתרים: אל תאלצו אותי לחשוב! אם אתם צריכים לשכנע אנשים אחרים בצוות האינטרנט, תוכלו להשתמש בניתוח נתונים כדי להראות את ההשפעה של אפשרויות שונות.

חשוב לקשר חשבונות של משתמשים שנרשמו דרך ספק זהויות כמו 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 משתמשים בגרסה של הפתרון הזה.

כמו בכניסה מאוחדת, היתרון הנוסף הוא שאתם לא צריכים לנהל את הסיסמאות של המשתמשים.

כדאי להביא בחשבון את משך הסשן

לא משנה באיזו גישה תבחרו לזהות המשתמש, תצטרכו לקבל החלטה מושכלת לגבי משך הסשן: כמה זמן המשתמש יישאר מחובר, ומהם הגורמים שעשויים לגרום לכם להוציא אותו מהחשבון.

כדאי לבדוק אם המשתמשים שלכם משתמשים בנייד או במחשב, ואם הם משתפים במחשב או במכשירים שונים.

עזרה למנהלי סיסמאות להציע סיסמאות ולאחסן אותן בצורה מאובטחת

אתם יכולים לעזור למנהלי הסיסמאות של צד שלישי ולמנהלי הסיסמאות המובנים בדפדפן להציע סיסמאות ולאחסן אותן, כדי שהמשתמשים לא יצטרכו לבחור סיסמאות, לזכור אותן או להקליד אותן בעצמם. מנהלי הסיסמאות פועלים היטב בדפדפנים מודרניים, מסנכרנים חשבונות בין מכשירים, בין אפליקציות אינטרנט לאפליקציות ספציפיות לפלטפורמה, וגם במכשירים חדשים.

לכן חשוב מאוד לכתוב את הקוד של טפסי ההרשמה בצורה נכונה, ובמיוחד להשתמש בערכי ההשלמה האוטומטית הנכונים. בטופסי הרשמה צריך להשתמש ב-autocomplete="new-password" לסיסמאות חדשות, ולהוסיף ערכים נכונים של השלמה אוטומטית לשדות טופס אחרים ככל האפשר, כמו autocomplete="email" ו-autocomplete="tel". אפשר גם לעזור למנהלי הסיסמאות על ידי שימוש בערכים שונים של name ו-id בטפסים של ההרשמה והכניסה, לרכיב form עצמו ולכל רכיבי input,‏ select ו-textarea.

כדאי גם להשתמש במאפיין type המתאים כדי לספק את המקלדת המתאימה בנייד ולהפעיל אימות בסיסי מובנה בדפדפן. מידע נוסף זמין במאמר שיטות מומלצות ליצירת טפסים של כתובות ואמצעי תשלום.

לוודא שהמשתמשים מזינים סיסמאות מאובטחות

האפשרות הטובה ביותר היא לאפשר למנהלי הסיסמאות להציע סיסמאות, ומומלץ לעודד את המשתמשים לאשר את הסיסמאות החזקות שהדפדפנים ומנהלי הסיסמאות של צד שלישי מציעים.

עם זאת, משתמשים רבים רוצים להזין את הסיסמאות שלהם, לכן צריך להטמיע כללים לחוזק הסיסמה. במכון הלאומי לתקנים וטכנולוגיה (National Institute of Standards and Technology) מוסבר איך להימנע מסיסמאות לא מאובטחות.

לא לאפשר סיסמאות שנחשפו

לא משנה אילו כללים תבחרו לסיסמאות, לעולם אל תאפשרו סיסמאות שנחשפו בפרצות אבטחה.

אחרי שמשתמש מזין סיסמה, צריך לבדוק שהיא לא סיסמה שכבר נחשפה. באתר Have I Been Pwned יש ממשק API לבדיקת סיסמאות, או שאפשר להריץ אותו כשירות בעצמכם.

מנהל הסיסמאות של Google מאפשר לכם גם לבדוק אם אחת מהסיסמאות הקיימות שלכם נחשפה.

אם תדחו סיסמה שמשתמש מציע, ספרו לו באופן ספציפי למה היא נדחתה. מציגים בעיות בתוך השורה ומסבירים איך לתקן אותן, מיד לאחר שהמשתמש הזין ערך – לא אחרי שהוא שלח את טופס ההרשמה ונצטרך להמתין לתגובה מהשרת שלכם.

לא לאסור הדבקת סיסמאות

בחלק מהאתרים אסור להדביק טקסט בשדות של סיסמאות.

איסור הדבקת סיסמאות מרגיז את המשתמשים, מעודד שימוש בסיסמאות שקל לזכור (ולכן קל יותר לפרוץ אליהן) ולפי ארגונים כמו המרכז הלאומי לאבטחת סייבר בבריטניה, הוא עלול למעשה לפגוע באבטחה. המשתמשים מבינים שאסור להדביק רק אחרי שהם מנסים להדביק את הסיסמה, ולכן איסור הדבקת סיסמאות לא מונע נקודות חולשה בלוח העריכה.

לעולם לא לשמור או להעביר סיסמאות בטקסט ללא הצפנה

חשוב לבחון ולגבב סיסמאות, ואל תנסו להמציא אלגוריתם גיבוב משלכם.

לא לאלץ עדכוני סיסמה

לא לאלץ משתמשים לעדכן את הסיסמאות שלהם באופן שרירותי.

אכיפת עדכוני סיסמאות עשויה להיות יקרה למחלקות ה-IT, מעצבנת את המשתמשים ולא משפיעה הרבה על האבטחה. כדאי גם לעודד אנשים להשתמש בסיסמאות לא מאובטחות שקל לזכור, או לשמור תיעוד פיזי של הסיסמאות.

במקום לאלץ עדכוני סיסמאות, כדאי לעקוב אחרי פעילות חריגה בחשבון ולהזהיר את המשתמשים. אם אפשר, כדאי גם לעקוב אחרי סיסמאות שנחשפו בגלל פרצות באבטחת מידע.

כדאי גם לתת למשתמשים גישה להיסטוריית הכניסות לחשבון שלהם, כדי שיראו איפה ומתי התרחשה כניסה.

שינוי או איפוס של סיסמאות בקלות

חשוב להבהיר למשתמשים איפה ואיך לעדכן את הסיסמה לחשבון. באתרים מסוימים, זה יכול להיות קשה להפתיע.

כמובן, חשוב גם לאפשר למשתמשים לאפס את הסיסמה שלהם אם הם שוכחים אותה. ב-Open Web Application Security Project יש הנחיות מפורטות בנושא טיפול במקרים של סיסמאות שאבדו.

כדי לשמור על בטיחות העסק והמשתמשים, חשוב במיוחד לעזור למשתמשים לשנות את הסיסמה שלהם אם הם מגלים שהיא נחשפה. כדי להקל על התהליך, מומלץ להוסיף לאתר כתובת URL מסוג /.well-known/change-password שתופנה לדף ניהול הסיסמאות. כך מנהלי הסיסמאות יכולים לנווט את המשתמשים ישירות לדף שבו הם יוכלו לשנות את הסיסמה שלהם לאתר. התכונה הזו מוטמעת עכשיו ב-Safari וב-Chrome, ותגיע בקרוב לדפדפנים אחרים. במאמר איך עוזרים למשתמשים לשנות סיסמאות בקלות על ידי הוספת כתובת URL ידועה לשינוי סיסמאות מוסבר איך מטמיעים את התכונה הזו.

כדאי גם להקל על המשתמשים למחוק את החשבון שלהם, אם זה מה שהם רוצים.

הצעת התחברות דרך ספקי זהויות של צד שלישי

משתמשים רבים מעדיפים להתחבר לאתרים באמצעות כתובת אימייל וסיסמה בטופס הרשמה. עם זאת, כדאי גם לאפשר למשתמשים להתחבר דרך ספק זהויות של צד שלישי, שנקרא גם התחברות מאוחדת.

לגישה הזו יש כמה יתרונות. משתמשים שיוצרים חשבון באמצעות התחברות מאוחדת לא צריכים לספק סיסמאות, לא צריך לשלוח אותן ולא צריך לאחסן אותן.

יכול להיות שתוכלו לגשת למידע נוסף של פרופיל מאומת מהתחברות מאוחדת, כמו כתובת אימייל, כך שהמשתמש לא יצטרך להזין את הנתונים ואתם לא צריכים לבצע את האימות בעצמכם. כניסה מאוחדת יכולה גם להקל על המשתמשים כשהם מקבלים מכשיר חדש.

במאמר שילוב של כניסה באמצעות חשבון Google באפליקציית האינטרנט מוסבר איך להוסיף כניסה מאוחדת לאפשרויות ההרשמה. יש פלטפורמות זהויות רבות נוספות.

מעבר פשוט בין חשבונות

משתמשים רבים משתפים מכשירים ומחליפים בין חשבונות באמצעות אותו דפדפן. בין שהמשתמשים נכנסים באמצעות כניסה מאוחדת ובין שלא, חשוב שהמעבר בין החשבונות יהיה פשוט.

כדאי להציע אימות רב-גורמי

אימות רב-שלבי הוא אמצעי שמבטיח שהמשתמשים מספקים אימות ביותר מדרך אחת. לדוגמה, דרישה מהמשתמשים להגדיר סיסמה, יכולה לאכוף את האימות גם באמצעות קוד גישה חד-פעמי שנשלח באימייל או בהודעת טקסט ב-SMS, או באמצעות קוד חד-פעמי, מפתח אבטחה או חיישן טביעות אצבע. שיטות מומלצות ל-SMS OTP והפעלת אימות חזק באמצעות WebAuthn מסבירות איך להטמיע אימות רב-שלבי.

אם האתר שלכם מטפל במידע אישי או רגיש, מומלץ להציע (או לאכוף) אימות רב-גורמי.

חשוב להיזהר עם שמות משתמשים

אל תתעקשו על שם משתמש אלא אם (או עד) שאתם צריכים אחד. מאפשרים למשתמשים להירשם ולהיכנס לחשבון באמצעות כתובת אימייל (או מספר טלפון) וסיסמה בלבד, או באמצעות כניסה מאוחדת אם הם מעדיפים. אל תאלצו אותם לבחור שם משתמש ולזכור אותו.

אם באתר שלכם נדרש שם משתמש, אל תטילו על המשתמשים כללים לא סבירים ואל תנסו למנוע מהם לעדכן את שם המשתמש. בקצה העורפי, צריך ליצור מזהה ייחודי לכל חשבון משתמש, ולא מזהה שמבוסס על נתונים אישיים כמו שם משתמש.

כמו כן, חשוב להשתמש ב-autocomplete="username" לשמות משתמשים.

בדיקה במגוון מכשירים, פלטפורמות, דפדפנים וגרסאות

כדאי לבדוק את טופסי ההרשמה בפלטפורמות הנפוצות ביותר בקרב המשתמשים שלכם. הפונקציונליות של רכיבי הטפסים עשויה להשתנות, והבדלים בגודל של אזור התצוגה עשויים לגרום לבעיות בפריסה. BrowserStack מאפשר בדיקה בחינם לפרויקטים של קוד פתוח במגוון מכשירים ודפדפנים.

הטמעת ניתוח נתונים וניטור של משתמשים אמיתיים

כדי להבין את חוויית השימוש של המשתמשים בטפסים להרשמה, אתם צריכים נתונים מהשדה וגם נתונים מהמעבדה. מערכת Analytics ומעקב אחר משתמשים אמיתיים (RUM) מספקות נתונים לגבי החוויה בפועל של המשתמשים, כמו משך הזמן שלוקח לדפי ההרשמה להיטען, אילו רכיבי ממשק משתמש המשתמשים יוצרים איתם אינטראקציה (או לא) וכמה זמן לוקח למשתמשים להשלים את ההרשמה.

• ניתוח נתונים של דפים: צפיות בדפים, שיעורי עזיבה ויציאות בכל דף בתהליך ההרשמה.
• ניתוח אינטראקציות: משפך מטרות עסקיות ואירועים מציינים איפה המשתמשים נוטשים את תהליך ההרשמה ואיזה אחוז מהמשתמשים לוחצים על לחצנים, קישורים ורכיבים אחרים בדפי ההרשמה.
• ביצועי האתר: מדדים שמתמקדים במשתמש מאפשרים לכם לדעת אם תהליך ההרשמה שלכם נטען לאט או אם הוא לא יציב מבחינה ויזואלית.

שינויים קטנים יכולים להשפיע מאוד על שיעורי ההשלמה של טפסי ההרשמה. בעזרת Analytics ו-RUM תוכלו לבצע אופטימיזציה של שינויים, לקבוע להם סדר עדיפויות ולעקוב אחרי בעיות באתר שלא נחשפו בבדיקות מקומיות.

להמשיך ללמוד

• שיטות מומלצות לטופס כניסה
• שיטות מומלצות לטופס תשלום ולטופס כתובת
• יצירת טפסים מדהימים
• שיטות מומלצות לעיצוב טפסים לנייד
• אמצעי בקרה מתקדמים יותר לטופס
• יצירת טפסים נגישים
• ייעול תהליך ההרשמה באמצעות Credential Management API
• אימות מספרי טלפון באינטרנט באמצעות WebOTP API

תמונה מאת @ecowarriorprincess ב-Un אימייל.