שימוש בתכונות דפדפן בפלטפורמות שונות כדי ליצור טופסי כניסה מאובטחים, נגישים וקלים לשימוש.
אם המשתמשים יצטרכו להיכנס לאתר שלכם, חשוב מאוד שהעיצוב של טופס הכניסה יהיה טוב. זה נכון במיוחד לאנשים עם חיבור גרוע, בנייד, בלחץ או במצוקה. טופס כניסה שמעוצב בצורה גרועה גורם לשיעורי עזיבה גבוהים. כל עזיבה מהדף הראשון יכולה להיות סימן למשתמש מאוכזב שאבד, ולא רק הזדמנות להצטרפות שהוחמצה.
זו דוגמה לטופס כניסה פשוט שמציג את כל השיטות המומלצות:
רשימת המשימות
- משתמשים ברכיבי 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של הקלט. - קוראי מסך מכריזים על טקסט התווית כשהמיקוד הוא על התווית או על הקלט של התווית.
אין להשתמש בערכי placeholder כתוויות קלט. אנשים עשויים לשכוח למה הם הקלידו טקסט אחרי שהם התחילו להקליד, במיוחד אם הם מוסחים ('האם הקלדתי כתובת אימייל, מספר טלפון או מזהה חשבון?'). יש הרבה בעיות פוטנציאליות אחרות שקשורות ל-placeholders: אם אתם עדיין לא משוכנעים, כדאי לעיין במאמרים אל תשתמשו במאפיין placeholder ושימוש ב-placeholders בשדות טופס מזיק.
מומלץ למקם את התוויות מעל לשדות הקלט. כך אפשר לשמור על עיצוב עקבי בנייד ובמחשב, ולפי מחקר בנושא AI של Google, כך המשתמשים יכולים לסרוק את התמונות מהר יותר. התווית והקלט מוצגים ברוחב מלא, ואין צורך לשנות את רוחב התווית והקלט כך שיתאימו לטקסט של התווית.
כדי לראות את הבעיה בעצמכם, תוכלו לפתוח את הבאג label-position במכשיר נייד.
שימוש ב-<button>
אפשר להשתמש ב-<button>
ללחצנים. אלמנטים של לחצנים מספקים התנהגות נגישה ופונקציונליות מובנית לשליחת טפסים, ואפשר לעצב אותם בקלות. אין טעם להשתמש ב-<div> או במרכיב אחר שמתחזה ללחצן.
מוודאים שהלחצן לשליחה מציין את הפעולה שהוא מבצע. לדוגמה, יצירת חשבון או כניסה, ולא שליחה או התחלה.
מוודאים שהטופס נשלח בהצלחה
כדאי לעזור למנהלי הסיסמאות להבין שנשלח טופס. יש שתי דרכים לעשות זאת:
- עוברים לדף אחר.
- מעתיקים את הניווט באמצעות
History.pushState()אוHistory.replaceState(), ומסירים את טופס הסיסמה.
בבקשה מסוג XMLHttpRequest או fetch, חשוב לוודא שההצלחה של הכניסה תדווח בתגובה ותטופל על ידי הסרת הטופס מה-DOM, וגם להציג למשתמש הודעה על הצלחה.
כדאי להשבית את הלחצן כניסה אחרי שהמשתמש הקיש עליו או לחץ עליו. משתמשים רבים לוחצים על לחצנים כמה פעמים גם באתרים מהירים ותגובתיים. הפעולה הזו מאטה את האינטראקציות ומוסיפה לעומס על השרת.
לעומת זאת, אל תשביתו את שליחת הטופס בזמן שממתינים לקלט מהמשתמש. לדוגמה, אל תשביתו את הלחצן כניסה אם המשתמשים לא הזינו את מספר הלקוח שלהם. יכול להיות שמשתמשים יפספסו משהו בטופס, ואז ינסו להקיש שוב ושוב על הלחצן כניסה (המושבת) ויחשבו שהוא לא עובד. לפחות, אם אתם חייבים להשבית את שליחת הטופס, הסבירו למשתמש מה חסר כשהם לוחצים על הלחצן המושבת.
לא להכפיל את ערכי הקלט
באתרים מסוימים המשתמשים נאלצים להזין כתובות אימייל או סיסמאות פעמיים. הפעולה הזו יכולה להפחית את מספר השגיאות למספר משתמשים בודדים, אבל לגרום עבודה נוספת לכל המשתמשים ולהגדיל את שיעורי הנטישה. גם לא הגיוני לשאול פעמיים איפה דפדפנים מילוי אוטומטי של כתובות אימייל או הצעות סיסמאות חזקות. עדיף לאפשר למשתמשים לאשר את כתובת האימייל שלהם (תצטרכו לעשות זאת בכל זאת) ולהקל עליהם לאפס את הסיסמה שלהם במקרה הצורך.
איך להפיק את המקסימום ממאפייני רכיבים
כאן מתחיל הקסם! לדפדפנים יש כמה תכונות מובנות שימושיות שמשתמשות במאפיינים של רכיבי קלט.
לשמור על פרטיות הסיסמאות, אבל לאפשר למשתמשים לראות אותן אם הם רוצים
צריך להוסיף את התו type="password" לשדות קלט של סיסמאות כדי להסתיר את הטקסט של הסיסמאות ולעזור לדפדפן להבין שהקלט מיועד לסיסמאות. (שימו לב שדפדפנים משתמשים במגוון שיטות כדי להבין את התפקידים של הקלט ולהחליט אם להציע לשמור סיסמאות או לא).
כדאי להוסיף מתג הצגת הסיסמה כדי לאפשר למשתמשים לבדוק את הטקסט שהם הזינו, ולא לשכוח להוסיף קישור לשכחת סיסמה. ראו הפעלת תצוגת סיסמאות.
איך מספקים למשתמשים בניידים את המקלדת המתאימה
אפשר להשתמש ב-<input type="email"> כדי לתת למשתמשים בנייד מקלדת מתאימה ולהפעיל אימות בסיסי של כתובת האימייל באמצעות הדפדפן... אין צורך ב-JavaScript!
אם אתם צריכים להשתמש במספר טלפון במקום בכתובת אימייל, הקש על <input
type="tel"> כדי להציג מקלדת טלפון בנייד. אפשר גם להשתמש במאפיין inputmode במקרים הנדרשים: המאפיין inputmode="numeric" אידיאלי למספרי PIN. כל מה שרציתם לדעת במצב הקלט כולל עוד פרטים.
מניעת חסימת הלחצן כניסה על ידי מקלדת בנייד
לצערנו, אם לא תהיו זהירים, מקלדות של מכשירים ניידים עלולות לכסות את הטופס או, במקרה הגרוע ביותר, לחסום חלקית את הלחצן כניסה. המשתמשים עלולים לוותר לפני שהם מבינים מה קרה.
כדי להימנע מכך, מומלץ להציג רק את הפרטים של כתובת האימייל/הטלפון והסיסמה, ואת הלחצן כניסה בחלק העליון של דף הכניסה, כשהדבר אפשרי. מוסיפים תוכן אחר למטה.
בדיקה במגוון מכשירים
תצטרכו לבדוק את המודעות במגוון מכשירים של קהל היעד שלכם, ולבצע התאמות בהתאם. ב-BrowserStack אפשר לבדוק בחינם פרויקטים בקוד פתוח במגוון מכשירים ודפדפנים אמיתיים.
כדאי להשתמש בשני דפים
אתרים מסוימים (כולל Amazon ו-eBay) נמנעים מהבעיה על ידי בקשת כתובת אימייל/טלפון וסיסמה בשני דפים. הגישה הזו גם מפשטת את החוויה: המשתמש יכול להקצות רק דבר אחד בכל פעם.
באופן אידיאלי, צריך להטמיע את זה באמצעות <form> יחיד. משתמשים ב-JavaScript כדי להציג בהתחלה רק את הקלט של כתובת האימייל, ואז מסתירים אותו ומציגים את הקלט של הסיסמה. אם אתם חייבים לאלץ את המשתמש לנווט לדף חדש בין הזנת כתובת האימייל והסיסמה, צריך לכלול בטפס שבדף השני רכיב קלט מוסתר עם ערך האימייל, כדי לאפשר למנהלי הסיסמאות לאחסן את הערך הנכון. בדף סגנונות של טפסים לסיסמאות ש-Chromium מבין מופיעה דוגמה לקוד.
עוזרים למשתמשים להימנע מהזנה מחדש של נתונים
אתם יכולים לעזור לדפדפנים לאחסן נתונים בצורה נכונה ולמלא אוטומטית את הקלט, כדי שהמשתמשים לא יצטרכו לזכור להזין את כתובת האימייל והסיסמה. הדבר חשוב במיוחד בניידים, והוא חיוני בשדות להזנת כתובת אימייל, שבהם יש שיעורי נטישה גבוהים.
יש שני חלקים בתהליך:
המאפיינים
autocomplete,name,idו-typeעוזרים לדפדפנים להבין את התפקיד של מקורות הקלט לאחסון נתונים שאפשר להשתמש בהם בהמשך למילוי אוטומטי. כדי לאפשר אחסון נתונים למילוי אוטומטי, בדפדפנים מודרניים נדרש גם שהערכים של השדות להזנה יהיו יציבים (לא נוצרים באופן אקראי בכל טעינת דף או פריסה של אתר) ושהשדות יהיו בתוך <form> עם לחצןsubmit.המאפיין
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. כל 59 הערכים האפשריים מפורטים במפרט HTML.
איך מפעילים את הדפדפן כדי להציע סיסמה חזקה
דפדפנים מודרניים משתמשים בהיוריסטיקה כדי לקבוע מתי להציג את ממשק המשתמש של מנהל הסיסמאות ומציעים סיסמה חזקה.
כך זה עובד ב-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>
כשמוסיפים את הפונקציונליות הצגת הסיסמה, חשוב לכלול את התג 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 כדי לנסות גישות שונות להרשמה ולכניסה, וגם השקות מדורגות כדי לאמת את השינויים בקבוצת משנה של משתמשים, לפני שמשיקים את השינויים לכל המשתמשים.
הנחיות כלליות
ממשק משתמש וחוויית משתמש שתוכננו היטב יכולים לצמצם את מספר המשתמשים שנטשו את טופס הכניסה:
- אל תאלצו את המשתמשים לחפש את הכניסה! מומלץ להוסיף קישור לטופס הכניסה בחלק העליון של הדף, עם ניסוח ברור כמו כניסה, יצירת חשבון או הרשמה.
- כדאי להתמקד! טפסים להרשמה הם לא המקום להסיח את דעת המשתמשים באמצעות מבצעים ותכונות אחרות באתר.
- צמצום המורכבות של תהליך ההרשמה. אוספים נתוני משתמשים אחרים (כמו כתובות או פרטי כרטיס אשראי) רק כשהמשתמש רואה תועלת ברורה במתן הנתונים האלה.
- לפני שהמשתמשים מתחילים למלא את טופס ההרשמה, הסבירו להם מהי הצעת הערך. איך אתם מפיקים תועלת מכניסה לחשבון? כדאי לתת למשתמשים תמריצים קונקרטיים כדי להשלים את ההרשמה.
- אם אפשר, כדאי לאפשר למשתמשים לזהות את עצמם באמצעות מספר טלפון נייד במקום כתובת אימייל, כי יכול להיות שמשתמשים מסוימים לא משתמשים באימייל.
- חשוב לאפשר למשתמשים לאפס את הסיסמה בקלות, ולהציג את הקישור שכחת את הסיסמה? באופן בולט.
- הוספת קישור למסמכי התנאים וההגבלות ולמדיניות הפרטיות: חשוב להבהיר למשתמשים כבר מההתחלה איך אתם מגינים על הנתונים שלהם.
- עליכם לכלול בדפי ההרשמה והכניסה את הלוגו ואת השם של החברה או הארגון שלכם, ולוודא שהשפה, הגופנים והסגנונות תואמים לשאר חלקי האתר. לפעמים הטפסים לא שייכים לאותו אתר כמו תוכן אחר, במיוחד אם יש להם כתובת URL שונה באופן משמעותי.
להמשיך ללמוד
- יוצרים טפסים מדהימים
- שיטות מומלצות לעיצוב טפסים לנייד
- אמצעי בקרה מתקדמים יותר לטופס
- יצירת טפסים נגישים
- ייעול תהליך הכניסה באמצעות Credential Management API
- אימות מספרי טלפון באינטרנט באמצעות WebOTP API
תמונה של Meghan Schiereck ב-Unsplash.