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

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

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 המתאים כדי לספק את המקלדת המתאימה בנייד ולהפעיל אימות בסיסי מובנה בדפדפן. מידע נוסף זמין במאמר שיטות מומלצות ליצירת טפסים של כתובות ואמצעי תשלום.

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

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

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

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

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

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

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

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

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

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

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

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

חשוב להוסיף מלח (salt) ולבצע גיבוב (hash) של הסיסמאות – ולא לנסות להמציא אלגוריתם גיבוב משלכם.

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

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

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

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

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

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

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

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

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

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

הצעת כניסה דרך ספקי זהויות של צד שלישי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המשך הלמידה

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

תמונה של @ecowarriorprincess ב-Unsplash.