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

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

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

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

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

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

איך להפיק את המקסימום ממאפייני 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.

עבור אזור טקסט, צריך להשתמש ב-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.