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

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

Sam Dutton

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

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

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

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

שימוש ב-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" למספרי טלפון.

שתי צילומי מסך של טלפונים עם Android, שבהם מוצגת מקלדת שמתאימה להזנת כתובת אימייל (באמצעות 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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הסיבות לנטישת עגלות קניות במהלך התשלום.
מ-baymard.com/checkout-usability

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

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

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

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

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

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

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

שני צילומי מסך של טופס כתובת ב-Android, שבהם מוצג איך מאפיין הקלט enterkeyhint משנה את הסמל של לחצן מקש Enter.
מקישים על לחצני המפתחות ב-Android: 'הבא' ו 'סיום'.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

צילומי מסך של טופס תשלום, payment-form.glitch.me, ב-iPhone 7 וב-iPhone 11. הלחצן &#39;השלמת התשלום&#39; מוצג ב-iPhone 11 אבל לא ב-7
אותו דף ב-iPhone 7 וב-iPhone 11.
כדאי לצמצם את ההפרדה בין הרכיבים בתצוגות קטנות יותר לנייד, כדי לוודא שהלחצן Complete payment לא מוסתר.

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

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

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

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

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

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

המשך הלמידה

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