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

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

Sam Dutton

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

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

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

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

שימוש ב-HTML משמעותי

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

שימוש ב-<form>

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

שימוש ב-<label>

כדי לתייג קלט, משתמשים ב-<label>.

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

יש שתי סיבות:

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

אל תשתמשו בפלייסהולדרים כתוויות קלט. אנשים עלולים לשכוח מה היה הקלט אחרי שהם התחילו להזין טקסט, במיוחד אם דעתם מוסחת ("האם הזנתי כתובת אימייל, מספר טלפון או מזהה חשבון?"). יש עוד הרבה בעיות פוטנציאליות עם פלייסהולדרים: אם אתם לא משוכנעים, כדאי לקרוא את המאמרים Don't Use The Placeholder Attribute ו-Placeholders in Form Fields Are Harmful.

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

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

שימוש ב-<button>

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

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

איך לוודא שהטופס נשלח בהצלחה

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

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

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

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

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

אל תזינו את אותם נתונים פעמיים

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

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

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

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

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

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

הצגת המקלדת המתאימה למשתמשים בנייד

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

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

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

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

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

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

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

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

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

במאמר Autofill: What web devs should know, but don't יש הרבה יותר מידע על השימוש ב-name וב-autocomplete. במפרט ה-HTML מפורטים כל 59 הערכים האפשריים.

הדפדפן יכול להציע סיסמה חזקה

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

ככה עושים את זה ב-Safari במחשב.

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

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

עוזרים למשתמשים לא לפספס בטעות קלט

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

עיצוב שמתאים לאצבעות ולאגודלים

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

מוודאים שהשדות והכפתורים גדולים מספיק

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

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

הבדיקה Tap targets are not sized appropriately ב-Lighthouse יכולה לעזור לכם להפוך את תהליך הזיהוי של רכיבי קלט קטנים מדי לאוטומטי.

עיצוב שמתאים ללחיצה עם האגודל

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

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

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

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

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

הבדיקה Document doesn't use legible font sizes ב-Lighthouse יכולה לעזור לכם להפוך את תהליך הזיהוי של טקסט קטן מדי לאוטומטי.

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

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

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

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

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

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

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

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

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

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

שימוש ב-JavaScript במקומות שבהם זה נדרש

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

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

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

ניתוח נתונים ו-RUM

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

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

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

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

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

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

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

לומדים בכיף

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