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

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

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>

יכול להיות שאתם מתפתים לא לטרוח לעטוף את רכיבי ה-<input> ב-<form>, ולטפל בשליחת הנתונים רק באמצעות JavaScript.

אל תעשה זאת!

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

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

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

const form = document.querySelector('form');
const submitButton = form.querySelector('button[type="submit"]');

form.addEventListener('submit', () => {
  submitButton.disabled = true;
  submitButton.textContent = 'Placing order…';
});

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

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

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

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

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

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

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

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

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

ערכים יציבים

כתובת לחיוב

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

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

<input autocomplete="shipping address-line1" ...>
<!-- Other fields omitted. -->
<input autocomplete="billing address-line1" ...>

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

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

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

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

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

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

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

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

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

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

איך לעזור למשתמשים להימנע ממצב שבו חסרים נתונים נדרשים

השתמשו במאפיין 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, וודאו שה-backend שלכם תומך ב-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} \-]+" ...>

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

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

טופסי כתובת גמישים

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

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

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

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

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

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

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

<label for="address-line2">
Address line 2 (optional)
</label>
<input autocomplete="address-line2" 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, או cc-exp-month ו-cc-exp-year לשדות נפרדים
• cc-csc

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

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

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

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

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

חשוב לבדוק את הפרטים בקפידה

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

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

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

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

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

הטמעת Analytics ו-RUM

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

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

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

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

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

לומדים בכיף

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

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