שיטות מומלצות לטופס כניסה לחשבון

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

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

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

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

• השתמשו ברכיבי HTML משמעותיים: <form>, <input>, <label> ו-<button>.
• מוסיפים לכל קלט את התווית <label>.
• אפשר להשתמש במאפייני רכיבים כדי לגשת לתכונות הדפדפן המובנות: type, name, autocomplete ו-required.
• צריך להזין ערכים יציבים במאפייני הקלט name ו-id שלא משתנים בין טעינות של דפים או פריסות של אתרים.
• מוסיפים את אפשרות הכניסה אלמנט <form> משלה.
• לוודא שהטופס נשלח בהצלחה
• משתמשים ב-autocomplete="new-password" וב-id="new-password" להזנת הסיסמה בטופס ההרשמה, ולסיסמה החדשה בטופס לאיפוס סיסמה.
• מזינים את הסיסמה לכניסה באמצעות autocomplete="current-password" ו-id="current-password".
• מספקים את הפונקציונליות הצגת סיסמה.
• משתמשים ב-aria-label וב-aria-describedby להזנת סיסמאות.
• אל תכללו ערכים כפולים של קלט.
• עיצוב הטפסים כך שהמקלדת לנייד לא תסתיר קלט או לחצנים.
• חשוב לוודא שאפשר להשתמש בטפסים בנייד: להשתמש בטקסט קריא ולוודא שפריטי הקלט והלחצנים גדולים מספיק בשביל לשמש כמשטחי מגע.
• שמירה על מיתוג וסגנון בדפי ההרשמה והכניסה שלכם.
• בדיקה בשטח ובשיעור ה-Lab: תוכלו לשלב ניתוח נתונים של דפים, נתונים על אינטראקציות ומדידת ביצועים שממוקדת במשתמשים, בתהליך ההרשמה והכניסה.
• בדיקה בדפדפנים ובמכשירים שונים: התנהגות הטופס משתנה באופן משמעותי בפלטפורמות השונות.

צריך להשתמש ב-HTML עם משמעות

צריך להשתמש ברכיבים שמיועדים למשימה: <form>, <label> ו-<button>. האפשרויות האלה מאפשרות פונקציונליות מובנית של הדפדפן, משפרות את הנגישות ומוסיפים משמעות לתגי העיצוב.

שימוש באפליקציה <form>

ייתכן שתתפתו לעטוף קלטים ב-<div> ולטפל בשליחת נתוני קלט אך ורק באמצעות JavaScript. בדרך כלל עדיף להשתמש ברכיב <form> ישן ופשוט. כך האתר שלכם יהיה נגיש לקוראי מסך ומכשירים מסייעים אחרים, להפעיל מגוון תכונות מובנות בדפדפן, לבנות בקלות כניסה פונקציונלית בסיסית לדפדפנים ישנים יותר ולהמשיך לעבוד גם אם JavaScript נכשל.

שימוש באפליקציה <label>

כדי להוסיף תווית לקלט, יש להשתמש בתו <label>.

<label for="email">Email</label>
<input id="email" …>

שתי סיבות:

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

אין להשתמש ב-placeholders כתוויות קלט. אנשים עלולים לשכוח את קלט הקלט אחרי שהתחילו להזין טקסט, במיוחד אם דעתם מוסחת ("האם הזנתי כתובת אימייל, מספר טלפון או מספר חשבון?"). יש הרבה בעיות אפשריות נוספות ב-placeholders: אל תשתמשו במאפיין Placeholder ובמאמר placeholders בשדות טופס הם מזיקים.

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

פתחו את הגליץ' label-position במכשיר נייד כדי לראות בעצמכם.

שימוש באפליקציה <button>

השתמשו ב-<button> ללחצנים! רכיבי הלחצן מספקים התנהגות נגישה ופונקציונליות מובנית של שליחת טפסים, וניתן לעצב אותם בקלות. אין טעם להשתמש ב-<div> או ברכיב אחר שמתחזה ללחצן.

מוודאים שלחצן השליחה מציין את הפעולה הרצויה. לדוגמה: Create account או Sign in, ולא Submit או Start.

איך מוודאים שהטופס נשלח

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

• צריך לעבור לדף אחר.
• אמולציה של הניווט באמצעות History.pushState() או History.replaceState() והסרת טופס הסיסמה.

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

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

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

אין להכפיל את אפשרויות הקלט

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

הפקת התועלת המרבית ממאפייני הרכיב

זה המקום שבו הקסם קורה באמת! דפדפנים כוללים מספר תכונות מובנות מועילות שמשתמשות במאפיינים של רכיבי קלט.

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

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

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

איך לספק למשתמשים בנייד את המקלדת הנכונה

כדאי להשתמש ב-<input type="email"> כדי לתת למשתמשים בנייד מקלדת מתאימה ולהפעיל אימות בסיסי של כתובת אימייל מובנית בדפדפן... ללא צורך ב-JavaScript!

אם צריך להשתמש במספר טלפון במקום בכתובת אימייל, אפליקציית <input type="tel"> מפעילה לוח מקשים טלפוני בנייד. אפשר גם להשתמש במאפיין inputmode במקרה הצורך: inputmode="numeric" הוא אידיאלי למספרי PIN. בכל מה שרציתם לדעת על מצב קלט יש יותר פרטים.

המקלדת של הנייד לא תסתיר את הלחצן כניסה

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

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

בדיקה במגוון מכשירים

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

מומלץ להשתמש בשני דפים

אתרים מסוימים (כולל Amazon ו-eBay) נמנעים מהבעיה על ידי בקשת אימייל/טלפון וסיסמה בשני דפים. הגישה הזו גם מפשטת את החוויה: משימת המשתמש היא רק בנושא אחד בכל פעם.

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

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

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

יש כאן שני חלקים:

1. המאפיינים autocomplete, name, id וגם type עוזרים לדפדפנים להבין את תפקיד הקלט כדי לאחסן נתונים שבהמשך יוכלו לשמש למילוי אוטומטי. כדי לאפשר אחסון של נתונים למילוי אוטומטי, דפדפנים מודרניים דורשים גם שרכיבי קלט יספקו ערך יציב של name או id (שלא נוצר באופן אקראי בכל טעינת דף או פריסה של אתר), והם צריכים להופיע בתג <form> עם לחצן submit.

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

כדי להזין את כתובות האימייל צריך להשתמש ב-autocomplete="username", כי מנהלי הסיסמאות של דפדפנים מודרניים מזהים את username, למרות שכדאי להשתמש ב-type="email", ומומלץ גם להשתמש ב-id="email" וב-name="email".

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

יש להשתמש ב-autocomplete="new-password" וב-id="new-password" לסיסמה חדשה

• באמצעות autocomplete="new-password" ו-id="new-password" מזינים את הסיסמה בטופס ההרשמה, או את הסיסמה החדשה בטופס לשינוי הסיסמה.

יש להשתמש ב-autocomplete="current-password" וב-id="current-password" לסיסמה קיימת

• אפשר להשתמש ב-autocomplete="current-password" וב-id="current-password" להזנת הסיסמה בטופס הכניסה, או בקלט של הסיסמה הישנה של המשתמש בטופס לשינוי סיסמה. ההודעה הזו מציינת לדפדפן שאתם רוצים שהוא ישתמש בסיסמה הנוכחית שהוא אחסן באתר.

לטופס הרשמה:

<input type="password" autocomplete="new-password" id="new-password" …>

כדי להיכנס:

<input type="password" autocomplete="current-password" id="current-password" …>

מנהלי סיסמאות לתמיכה

דפדפנים שונים מטפלים במילוי אוטומטי של אימייל והצעות סיסמה באופן שונה, אבל ההשפעות זהות. ב-Safari 11 ואילך במחשב, למשל, מוצג מנהל הסיסמאות, ונעשה שימוש באימות ביומטרי (טביעת אצבע או זיהוי פנים) אם זמין.

Chrome במחשב מציג הצעות לאימייל, מציג את מנהל הסיסמאות וממלא באופן אוטומטי את הסיסמה.

סיסמאות הדפדפן ומערכות המילוי האוטומטי אינן פשוטות. האלגוריתמים לניחוש, לאחסון ולהצגה של ערכים לא סטנדרטיים, ומשתנים מפלטפורמה לפלטפורמה. לדוגמה, כפי שציינו Hidde de Vries: "מנהל הסיסמאות של Firefox משלים את ההיוריסטיקה שלו באמצעות מערכת מתכונים".

מילוי אוטומטי: מה שמפתחי אינטרנט צריכים לדעת, אבל אין להם הרבה יותר מידע על השימוש ב-name וב-autocomplete. ב-HTML Spec מפורטים כל 59 הערכים האפשריים.

הפעלת הצעה לסיסמה חזקה בדפדפן

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

כך עושה זאת Safari במחשב.

(הצעה חזקה לסיסמה ייחודית זמינה ב-Safari מגרסה 12.0.)

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

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

צריך להוסיף את המאפיין required גם לשדות של האימייל וגם לשדות הסיסמה. דפדפנים מודרניים שולחים בקשה אוטומטית ומוגדרים למיקוד נתונים חסרים. לא נדרש JavaScript!

עיצוב המתאים לאצבעות ולאצבעות

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

יש לוודא שפריטי הקלט והלחצנים גדולים מספיק

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

לפי הנחיות הנגישות של Android, גודל היעד המומלץ לאובייקטים עם מסך מגע הוא 7 עד 10 מ"מ. לפי ההנחיות בממשק של Apple, הגודל המומלץ הוא 48x48 פיקסלים, וההמלצות של W3C כוללות לפחות 44x44 פיקסלים של CSS. על הבסיס הזה, כדאי להוסיף (לפחות) כ-15 פיקסלים של מרווח פנימי לרכיבים ולחצנים לנייד, וכ-10 פיקסלים במחשב. נסו להשתמש במכשיר נייד אמיתי באצבע או באגודל אמיתי. אמורה להיות לכם אפשרות להקיש על כל קלט ולחצנים בקלות.

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

עיצוב לאגודלים

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

הטקסט צריך להיות גדול מספיק

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

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

פירוש הדבר הוא שעליך להשתמש בפיקסלים גדולים יותר בנייד: 16px ב-Chrome למחשב קריא למדי, אבל גם עם ראייה טובה, קשה לקרוא את הטקסט של 16px ב-Chrome ל-Android. אפשר להגדיר גדלים שונים של פיקסלים של גופנים לגדלים שונים של אזור התצוגה באמצעות שאילתות מדיה. 20px פועל בנייד - אבל כדאי לבדוק את זה עם חברים או עמיתים עם ליקויי ראייה.

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

יש לספק מספיק מרווח בין אפשרויות הקלט

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

חשוב לוודא שהקלט מוצג בבירור

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

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

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

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

אפשר להשתמש בסלקטור ב-CSS :invalid כדי להדגיש נתונים לא חוקיים. השימוש ב-:not(:placeholder-shown) מאפשר להימנע מבחירת מקורות קלט שאין בהם תוכן.

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}

כדאי לנסות דרכים שונות להדגשת קלטים עם ערכים לא חוקיים.

שימוש ב-JavaScript במידת הצורך

הצגה או הסתרה של תווי הסיסמה

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

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

HTML:

<section>
  <label for="password">Password</label>
  <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
</section>

הנה שירות ה-CSS כדי שהלחצן ייראה כמו טקסט פשוט:

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}

קוד ה-JavaScript להצגת הסיסמה:

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}

זוהי התוצאה הסופית:

הזנת הסיסמה לגישה

אפשר להשתמש ב-aria-describedby כדי לקבוע כללי סיסמה על ידי ציון המזהה של הרכיב שמתאר את האילוצים. קוראי מסך מספקים את טקסט התווית, את סוג הקלט (סיסמה) ואת התיאור.

<input type="password" aria-describedby="password-constraints" …>
<div id="password-constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>

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

<button id="toggle-password"
        aria-label="Show password as plain text.
                    Warning: this will display your password on the screen.">
  Show password
</button>

אפשר לראות את שתי תכונות ה-ARIA בפעולה בתקלה הבאה:

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

אימות בזמן אמת ולפני השליחה

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

שלב 5 בטופס הכניסה codelab משתמש באימות אילוצים ממשק ה-API (שנתמך באופן נרחב) כדי להוסיף מיקוד ולהציג הודעות אימות בדפדפן באמצעות ממשק משתמש מוגדר.

מידע נוסף: שימוש ב-JavaScript לאימות מורכב יותר בזמן אמת.

Analytics ו-RUM

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

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

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

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

הנחיות כלליות

ממשק משתמש וחוויית המשתמש מעוצבים היטב יכולים לצמצם נטישה של משתמשים מטופסי כניסה:

• אל תגרום למשתמשים לעקוב אחר הכניסה! הוסיפו קישור לטופס הכניסה בראש הדף, תוך שימוש בניסוח מובן כמו Sign In (כניסה), Create Account (יצירת חשבון) או Register (הרשמה).
• כדאי לשמור על ריכוז. טופסי הרשמה הם לא המקום להסיח את דעתם של אנשים באמצעות הצעות ותכונות אחרות של האתר.
• מזער את המורכבות של ההרשמה. כדאי לאסוף נתוני משתמשים אחרים (כמו כתובות או פרטי כרטיס אשראי) רק אם להמשתמשים יש יתרון ברור שהם מספקים.
• לפני שהמשתמשים מתחילים את טופס ההרשמה, חשוב להבהיר מה הצעת הערך שלכם, ואיך הם תורמים מכניסה לחשבון? צריך לתת למשתמשים תמריצים ממשיים להשלמת ההרשמה.
• במידת האפשר, המשתמשים יכולים להזדהות באמצעות מספר טלפון נייד במקום כתובת אימייל, מכיוון שחלק מהמשתמשים לא משתמשים באימייל.
• כדאי להקל על המשתמשים לאפס את הסיסמה שלהם, ולציין בבירור את הקישור שכחת את הסיסמה?.
• קישור למסמכי התנאים וההגבלות ולמדיניות הפרטיות: הבהירו למשתמשים כבר מההתחלה איך אתם מגנים על הנתונים שלהם.
• צריך לכלול את הלוגו ואת השם של החברה או הארגון בדפי ההרשמה והכניסה, ולוודא שהשפה, הגופנים והסגנונות תואמים לשאר הדפים באתר. חלק מהטפסים לא מרגישים שייכים לאותו אתר כמו תוכן אחר, במיוחד אם כתובת ה-URL שלהם שונה באופן משמעותי.

להמשיך ללמוד

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

תמונה מאת Meghan Schiereck ב-Unwash.