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

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

Sam Dutton

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

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

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

• שימוש ברכיבי HTML משמעותיים: <form>, <input>, <label> ו-<button>.
• מתייגים כל קלט באמצעות <label>.
• שימוש במאפייני הרכיבים כדי לגשת לדפדפן המובנה תכונות: type, name, autocomplete, required.
• צריך להזין למאפייני הקלט name ו-id ערכים יציבים שלא משתנים בין טעינות דפים או פריסות של אתרים.
• צריך להזין את פרטי הכניסה ב<טופס> משלהם רכיב.
• מוודאים שהטופס נשלח בהצלחה.
• שימוש ב-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 כתוויות קלט. אנשים אחראים לשכוח את מה שהקלט היה עבור אחרי שהם התחילו להזין טקסט, במיוחד אם הם הסחת דעת ("האם הזנתי כתובת אימייל, מספר טלפון או חשבון ID?"). יש עוד הרבה בעיות פוטנציאליות אחרות עם placeholders: ראו אין שימוש ב-placeholder מאפיין וגם placeholders בשדות טופס מזיק אם לא משוכנעים.

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

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

שימוש ב-<button>

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

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

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

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

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

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

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

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

לא להכפיל את ערכי הקלט

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

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

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

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

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

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

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

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

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

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

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

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

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

תצטרכו לבצע בדיקות במגוון מכשירים עבור קהל היעד שלכם, ולהתאים בהתאם. 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 משתנה: "מנהל הסיסמאות של Firefox משלימה את היוריסטיקה שלו באמצעות recipe system."

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

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

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

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

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

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

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

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

עצבו את האצבעות והאצבעות

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

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

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

לפי נגישות ב-Android הנחיה גודל היעד המומלץ לאובייקטים במסך מגע הוא 7-10 מ"מ. הממשק של Apple ו-W3C מציע גודל של לפחות 44x44 פיקסלים. פיקסלים. על זה מומלץ להוסיף (לפחות) מרווח פנימי של כ-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 במקרה הצורך

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

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

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

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

Analytics ו-RUM

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

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

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

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

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

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

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

להמשיך ללמוד

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

צילום: מייגן שיירק (Meghan Schiereck) ב-Unbounce.