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

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

Sam Dutton

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

לפניכם דוגמה לטופס הרשמה פשוט מאוד שמדגים את כל שיטות העבודה המומלצות:

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

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

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

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

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

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

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

הגדרת הכניסה לחשבון בצורה ברורה

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

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

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

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

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

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

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

אין למנוע הדבקת סיסמאות

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

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

לעולם אל תאחסן או תשדר סיסמאות בטקסט פשוט

הקפידו לבצע salt ו-hash של סיסמאות — ואל תנסו להמציא אלגוריתם גיבוב (hashing) משלכם!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שים לב עם שמות המשתמשים

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

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

כמו כן, צריך להקפיד להשתמש ב-autocomplete="username" בשמות משתמשים.

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

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

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

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

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

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

להמשיך ללמוד

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

תמונה מאת @ecowarriorprincess ב-UnFlood.