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

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

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

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

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

• השתמש ברכיבי 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 בשדות טפסים מזיקים.

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

פותחים את הגליץ' 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" כדי להסתיר את טקסט הסיסמה ולעזור לדפדפן להבין שהקלט מיועד לסיסמאות. (שימו לב שהדפדפנים משתמשים במגוון שיטות כדי להבין את תפקידי הקלט ולהחליט אם להציע לשמור סיסמאות או לא).

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

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

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

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

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

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

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

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

יהיה עליך לבדוק מגוון מכשירים בהתאם לקהל היעד שלך ולבצע התאמות בהתאם. 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 מציג את כל 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>

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

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 בטופס הכניסה נעשה שימוש ב-Constraint Validation API (יש תמיכה רחבה) כדי להוסיף אימות מותאם אישית באמצעות ממשק המשתמש המובנה בדפדפן להגדרת הנחיות למיקוד ולהצגה.

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

Analytics ו-RUM

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

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

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

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

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

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

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

להמשיך ללמוד

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

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