שיטות מומלצות לשליחת טפסים לכתובת ולתשלום

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

Sam Dutton

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

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

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

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

• משתמשים ברכיבי HTML בעלי משמעות: <form>,‏ <input>,‏ <label> ו-<button>.
• מסמנים כל שדה בטופס באמצעות <label>.
• משתמשים במאפיינים של רכיבי HTML כדי לגשת לתכונות מובנות בדפדפן, במיוחד type ו-autocomplete עם ערכים מתאימים.
• מומלץ להימנע משימוש ב-type="number" למספרים שלא נועדו להגדלה, כמו מספרי כרטיסי תשלום. במקום זאת, צריך להשתמש ב-type="text" וב-inputmode="numeric".
• אם יש ערך השלמה אוטומטית מתאים ל-input,‏ select או textarea, כדאי להשתמש בו.
• כדי לעזור לדפדפנים למלא טפסים באופן אוטומטי, צריך להקצות למאפייני הקלט name ו-id ערכים יציבים שלא משתנים בין טעינת דפים או פריסות של אתרים.
• להשבית לחצני שליחה אחרי שמקישים עליהם או לוחצים עליהם.
• מאמתים את הנתונים במהלך הזנתם – ולא רק כששולחים את הטופס.
• כדאי להגדיר את תשלום כאורחים כברירת מחדל, ולאפשר ליצור חשבון בקלות אחרי השלמת התשלום.
• כדאי להציג את ההתקדמות בתהליך התשלום בשלבים ברורים עם קריאות ברורות לפעולה.
• הגבילו את נקודות היציאה האפשריות מתהליך התשלום על ידי הסרת פריטים מיותרים והסחות דעת.
• הצגת פרטי ההזמנה המלאים בקופה וביצוע שינויים בהזמנה בקלות.
• לא לבקש נתונים שאין בהם צורך.
• בקשו שמות באמצעות קלט יחיד, אלא אם יש לכם סיבה טובה לא לעשות זאת.
• לא לאכוף שימוש בתווים לטיניים בלבד בשמות ובשמות משתמשים.
• לאפשר מגוון פורמטים של כתובות.
• כדאי להשתמש בtextarea יחיד לכתובת.
• להשתמש במילוי אוטומטי של הכתובת לחיוב.
• מתאימים את הקוד לשוק המקומי והבינלאומי לפי הצורך.
• מומלץ להימנע מחיפוש כתובות לפי מיקוד.
• להשתמש בערכים מתאימים של השלמה אוטומטית של מספר כרטיס תשלום.
• להשתמש בקלט יחיד למספרי כרטיסי תשלום.
• הימנעו משימוש ברכיבים מותאמים אישית אם הם משבשים את חוויית המילוי האוטומטי.
• בדיקה בשטח וגם במעבדה: ניתוח נתונים של דפים, ניתוח נתונים של אינטראקציות ומדידה של ביצועים של משתמשים אמיתיים.
• בדיקה במגוון דפדפנים, מכשירים ופלטפורמות.

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

משתמשים ברכיבים ובמאפיינים שנוצרו למשימה:

• <form>, <input>, <label> וגם <button>
• type, בautocomplete ובinputmode

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

שימוש ברכיבי HTML כמתוכנן

הוספת הטופס ל-<form>

יכול להיות שתתפתתו לא להסתבך ולהעביר את הנתונים באמצעות JavaScript בלבד.<input><form>

אל תעשה זאת!

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

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

שימוש ב-<label> כדי לתייג רכיבים

כדי לתייג <input>,‏ <select> או <textarea>, משתמשים ב-<label>.

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

<label for="address-line1">Address line 1</label>
<input id="address-line1" …>

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

איך יוצרים לחצנים מועילים

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

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

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

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

איך להפיק את המקסימום ממאפייני HTML

כדאי להקל על המשתמשים להזין נתונים

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

לדוגמה, משתמשים ב-type="email" לכתובות אימייל וב-type="tel" למספרי טלפון.

בתאריכים, כדאי להימנע משימוש ברכיבי select בהתאמה אישית. אם לא מטמיעים אותן בצורה נכונה, הן משבשות את חוויית המילוי האוטומטי ולא פועלות בדפדפנים ישנים יותר. למספרים כמו שנת לידה, מומלץ להשתמש ברכיב input במקום ברכיב select, כי הקלדה ידנית של ספרות יכולה להיות קלה יותר ומוגבלת פחות לשגיאות מאשר בחירה מתוך רשימה נפתחת ארוכה – במיוחד בנייד. משתמשים ב-inputmode="numeric" כדי לוודא שהמקלדת הנכונה מופעלת בנייד, ומוסיפים תיקוף והנחיות לגבי הפורמט באמצעות טקסט או placeholder כדי לוודא שהמשתמשים מזינים נתונים בפורמט המתאים.

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

שימוש בערכים מתאימים של autocomplete מאפשר לדפדפנים לעזור למשתמשים על ידי אחסון מאובטח של נתונים ומילוי אוטומטי של ערכים של input,‏ select ו-textarea. הדבר חשוב במיוחד בניידים, והוא חיוני כדי למנוע שיעורי נטישה גבוהים של טפסים. להשלמה האוטומטית יש גם מספר יתרונות לנגישות.

אם יש ערך השלמה אוטומטית מתאים בשדה טופס, כדאי להשתמש בו. במסמכי העזרה של MDN Web Docs יש רשימה מלאה של ערכים והסברים על השימוש הנכון בהם.

ערכים יציבים

כתובת לחיוב

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

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

<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

עזרה למשתמשים להזין את הנתונים הנכונים

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

אפשר להוסיף מאפייני אילוצים לרכיבי טפסים כדי לציין ערכים קבילים, כולל min,‏ max ו-pattern. מצב התקינות של הרכיב מוגדר באופן אוטומטי בהתאם לתקינות הערך שלו, וכך גם פסאודו-הקלאסות של CSS‏ :valid ו-:invalid, שאפשר להשתמש בהן כדי לעצב רכיבים עם ערכים תקינים או לא תקינים.

לדוגמה, הקוד הבא ב-HTML מציין קלט לשנה לידה בין 1900 ל-2020. השימוש ב-type="number" מגביל את ערכי הקלט למספרים בלבד, בטווח שצוין על ידי min ו-max. אם תנסו להזין מספר מחוץ לטווח, המצב של הקלט יוגדר כבלתי חוקי.

בדוגמה הבאה נעשה שימוש ב-pattern="[\d ]{10,30}" כדי לוודא שמספר כרטיס התשלום תקין, תוך מתן אפשרות להשתמש במרווחים:

דפדפנים מודרניים מבצעים גם אימות בסיסי של קלט מסוג email או url.

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

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

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

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

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

משתמשים במאפיין required להזנת ערכים חובה.

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

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

תהליך תשלום פשוט יותר

חשוב לשים לב לפערים במסחר בניידים

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

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

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

הגדרת תשלום כאורח כברירת מחדל

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

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

הצגת התקדמות התשלום

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

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

משתמשים במאפיין enterkeyhint בנכסי קלט של טפסים כדי להגדיר את התווית של מקש Enter במקלדת בנייד. לדוגמה, אפשר להשתמש ב-enterkeyhint="previous" וב-enterkeyhint="next" בטופס בן כמה דפים, ב-enterkeyhint="done" בשדה הקלט האחרון בטופס וב-enterkeyhint="search" בשדה הקלט לחיפוש.

יש תמיכה במאפיין enterkeyhint ב-Android וב-iOS. מידע נוסף זמין במאמר הסבר על enterkeyhint.

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

הסרת הסחות דעת

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

חשוב להתמקד בתהליך. זה לא הזמן לפתות את המשתמשים לעשות משהו אחר!

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

מאפשרים להזין שם וכתובת בקלות

בקשו רק את הנתונים שאתם צריכים

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

להשתמש בקלט של שם יחיד

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

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

הפעלת מילוי אוטומטי של שמות

משתמשים ב-name בשביל שם מלא:

<input autocomplete="name" ...>

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

• honorific-prefix
• given-name
• nickname
• additional-name-initial
• additional-name
• family-name
• honorific-suffix

איך מאפשרים שמות בינלאומיים

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

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

<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>

<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>

לאפשר מגוון פורמטים של כתובות

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

איך יוצרים טפסים גמישים לכתובות

אל תאלצו את המשתמשים לנסות לדחוס את הכתובת שלהם בשדות של טפסים שלא מתאימים.

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

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

שימוש בשני שורות גמישות לכתובת יכול להתאים למגוון פורמטים של כתובות.

<input autocomplete="address-line-1" id="address-line1" ...>
<input autocomplete="address-line-2" id="address-line2" ...>

מוסיפים תוויות להתאמה:

<label for="address-line-1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line-1" id="address-line1" ...>

<label for="address-line-2">
Address line 2 (optional)
</label>
<input autocomplete="address-line-2" id="address-line2" ...>

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

כדאי להשתמש בתיבת טקסט אחת לכתובת

האפשרות הגמישה ביותר לכתובות היא לספק textarea יחיד.

הגישה textarea מתאימה לכל פורמט של כתובת, והיא נהדרת לחיתוך ולהדבקה – אבל חשוב לזכור שהיא עשויה לא להתאים לדרישות הנתונים שלכם, ויכול להיות שהמשתמשים לא יוכלו להשתמש במילוי האוטומטי אם הם השתמשו בעבר רק בטפסים עם address-line1 ו-address-line2.

ב-textarea, משתמשים ב-street-address כערך להשלמה האוטומטית.

דוגמה לטופס שבו מוצג השימוש ב-textarea יחיד לכתובת:

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

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

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

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

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

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

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

כדאי להימנע מחיפוש כתובות לפי מיקוד

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

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

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

פשטו את טופסי התשלום

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

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

חשוב להוסיף ערכים מתאימים של autocomplete בטפסים של כרטיסי תשלום, כולל מספר כרטיס התשלום, השם שמופיע בכרטיס וחודש ושנה התפוגה:

• cc-number
• cc-name
• cc-exp-month
• cc-exp-year

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

הימנעו משימוש באלמנטים מותאמים אישית לתאריכים של כרטיסי תשלום

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

שימוש בקלט יחיד למספרי כרטיסי תשלום ומספרי טלפון

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

אימות בקפידה

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

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

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

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

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

הטמעת ניתוח נתונים ו-RUM

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

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

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

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

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

המשך הלמידה

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

תמונה של @rupixen ב-Unsplash.