לקוח יכול להבין את השירות, לרצות ליצור קשר ולהיתקע דווקא ברגע הפנייה. תווית שנעלמת בזמן הקלדה, מקלדת שמסתירה את הכפתור או הודעה שאינה מסבירה מה השתבש עלולות להשאיר אותו בלי דרך ברורה לסיים. כדי לזהות את הבעיה, צריך לבצע את הפעולה בטלפון ולבדוק גם מה התקבל בצד של העסק.
בדיקת UX לאתר עסקי מתחילה כאן במשימה מוגדרת: אדם ממלא טופס, מתקן מידע במידת הצורך ומקבל אישור שמתאים למה שהמערכת אכן ביצעה. נבחן את הדרך הזו באמצעות תרחישים ונתוני בדיקה מלאכותיים, עם כרטיס תקלה שאפשר להעביר למי שמתקן. אין מספר שדות שמתאים לכל עסק, ואין הבטחה ששינוי מסוים יגדיל פניות בשיעור קבוע.
הדוגמאות מתייחסות לעסק היפותטי של תחזוקת גינות למשרדים. הן אינן דיווח על תקלה באתר אנשים מדיה או על מערכת של לקוח. ההנחיות הנוגעות לנגישות מבוססות על מקורות טכניים של W3C; הבדיקות הממוקדות כאן אינן הערכת נגישות מלאה או חוות דעת משפטית.
המחשה שנוצרה בבינה מלאכותית: טופס דוגמה לבקשת שיחת בירור. זה אינו טופס פעיל או תיעוד של מערכת שנבדקה.
תוכן עניינים
מתעדים את הדרך מכפתור הפנייה ועד אישור הקבלה
מתחילים במקום שבו המשתמש מתחיל
פתחו בטלפון את העמוד שממנו אמורים לפנות והשתמשו בכפתור הרגיל שלו. כניסה ישירה לכתובת הטופס עלולה לפספס קישור לא נכון, חלון שאינו נפתח או מעבר שממקם את המשתמש באמצע העמוד. רשמו מה המשתמש רואה אחרי הלחיצה, היכן מתחיל הטופס ואיך הוא יודע שהגיע למקום הנכון.
בדוגמה ההיפותטית, מנהלת משרד לוחצת על ״בקשת שיחת בירור״ בעמוד תחזוקת גינות. הטופס צריך להמשיך את אותה ציפייה. אם הכותרת מבקשת פתאום ״הזמנת עבודה״, כדאי לבדוק אם הנוסח מתאר התחייבות אחרת או פשוט אינו מעודכן. גם כשהשליחה אפשרית מבחינה טכנית, שינוי לא מוסבר במשמעות הפעולה מקשה לדעת מה מאשרים.
מגדירים מראש מה נחשב סיום מוצלח
תעדו את כל התחנות: פתיחת הטופס, מילוי, ניסיון שליחה, תיקון במקרה הצורך, אישור למשתמש ורישום במערכת היעד שהעסק הגדיר. לכל תחנה כתבו מה מצופה לקרות. אל תתחילו למדוד ״נטישה״ לפני שהוגדרו תחילת המשימה וסופה; אחרת קל לערבב אדם שרק פתח את העמוד עם אדם שניסה להשלים פנייה ונחסם.
בדיקה ראשונה אפשר לבצע יחד עם מי שמטפל בפניות. הוא יכול לומר איזה מידע נדרש באמת ואיפה אמור להופיע הרישום. השתמשו בסביבת בדיקה כשיש כזאת. אם בודקים במסלול פעיל, תאמו את הבדיקה עם העסק וסמנו את הנתונים כמלאכותיים, כדי שלא יתפרשו כפנייה אמיתית או יפעילו טיפול מיותר.
בודקים תוויות ושדות חובה לפי הצורך העסקי
לכל שדה צריך להיות תפקיד שאפשר להסביר
עברו על השדות עם מי שקולט את הפניות. שאלו מה עושים עם כל פרט מיד לאחר קבלתו, והאם הוא חיוני לשלב הזה. בדוגמת הגינון, דרך לחזור לפונה ותיאור קצר של הצורך עשויים להספיק לבירור ראשוני; כתובת מלאה או מידע נוסף עשויים להידרש רק בהמשך. זו דוגמה לקבלת החלטה, ולא המלצה אחידה לכל שירות.
שדה שנאסף ״כי אולי נצטרך״ דורש בחינה, אבל הסרת כל שדות החובה אינה פתרון אוטומטי. בלי דרך חזרה ייתכן שלא ניתן לטפל בפנייה. המטרה היא לבקש מידע נחוץ, להסביר מדוע הוא נדרש ולהימנע מעומס שאינו משרת את המשימה. אם שדה תלוי בבחירה קודמת, ודאו שהדרישה החדשה ברורה כשהוא מופיע.
התווית צריכה להישאר מובנת גם בזמן הקלדה
בדקו שלכל שדה יש תווית משמעותית ושברור לאיזה רכיב היא שייכת. המדריך של W3C לתוויות בטפסים מדגיש גם את הקשר התכנותי בין התווית לפקד. טקסט לדוגמה בתוך השדה, שנעלם בהקלדה, אינו תחליף לתווית. הצוות הטכני צריך לבדוק את הקישור בפועל, ולא להסתפק בכך שהמסך נראה מסודר.
ודאו ששדות חובה מסומנים ומוסברים לפני השליחה. אם מציגים דוגמת פורמט, היא צריכה להתאים לפורמטים שהטופס באמת מקבל. בדקו גם מונחים: ״מספר״ יכול להיות מספר טלפון, מספר לקוח או מספר בניין. שם שדה מדויק חוסך ניחוש. ליד שדה חריג אפשר להוסיף הסבר קצר במקום לצפות מהמשתמש לגלות את הדרישה רק לאחר הודעת שגיאה.
בודקים טלפון מקלדת והגדלה בתנאי שימוש אמיתיים
בודקים מה קורה כאשר המקלדת פתוחה
הקלידו במכשיר אמיתי ועברו בין כל השדות. האם רואים מה כותבים? האם אפשר להגיע לשדה הבא ולכפתור? האם המקלדת מאפשרת להקליד בקלות את התווים הנדרשים, למשל בכתובת דואר אלקטרוני? בדקו גם בחירה מרשימה, סגירת המקלדת וחזרה לתיקון שדה קודם. צילום מסך של טופס ריק אינו מגלה את המצבים האלה.
נסו את הכיוון ואת הגדלת התצוגה שבהם משתמש יכול לעבוד, ובדקו אם מידע חשוב נחתך או אם צריך לגלול בצורה מבלבלת כדי למצוא את הפעולה. אל תסיקו מטלפון אחד שכל המכשירים מתנהגים באותו אופן. בחרו שילוב נוסף של מכשיר ודפדפן לפי הקהל הידוע לעסק, ותעדו במדויק היכן נבדק כל תרחיש.
בודקים לחיצה ומעבר באמצעות מקלדת
בדקו שנוח להפעיל את הכפתורים ושאפשר להבחין בין מטרות סמוכות. ל־W3C יש הסבר על גודל מטרות הפעלה וחריגים רלוונטיים; בדיקה חזותית כללית אינה מחליפה בדיקת הקריטריון והחריגים החלים. כאן מטרת הבדיקה המעשית היא לזהות כפתור שקשה לבחור או פעולה סמוכה שנלחצת בטעות.
בבדיקה עם מקלדת, עקבו אחר הרכיב הפעיל, כלומר הרכיב שיקבל את הפעולה הבאה. ודאו שסדר המעבר הגיוני ושאפשר לזהות היכן נמצאים. W3C מתייחס להסתרת רכיב שמקבל פוקוס, למשל בידי רכיבים דביקים. כפתור קבוע או פס תחתון דורשים בדיקה גם כשהם נראים מועילים במצב הרגיל. אין צורך להסיר כל רכיב דביק; צריך לוודא שהוא אינו חוסם את המשימה.
מתכננים שגיאות שאפשר להבין ולתקן
אומרים מה קרה ומה צריך לעשות
נסו לשלוח טופס שחסר בו שדה נדרש. בדקו אם ברור איזה שדה חסר, היכן נמצאת הבעיה ומה נדרש לתיקון. הודעה כמו ״אירעה שגיאה״ אינה מספיקה כאשר המערכת יודעת להצביע על פרט מסוים. גם צבע בלבד אינו מסביר את הבעיה למי שאינו מבחין בו או משתמש בדרך קריאה אחרת.
W3C מפרט כיצד לתת משוב מובן על הצלחה ושגיאות. תרגמו את העיקרון לנוסח מתאים: ״הזינו דרך לחזור אליכם״ ברור יותר מקוד תקלה שאינו מיועד למשתמש. בדוגמה ההיפותטית, אם נדרש מספר טלפון בפורמט מסוים, הודעת השגיאה צריכה להסביר את הדרישה בפועל. אין להציג פורמט מומלץ שהטופס עצמו דוחה.
בודקים שהמשתמש יכול להמשיך מאותה נקודה
לאחר הודעת שגיאה, בדקו אם הפרטים שכבר הוזנו עדיין נמצאים בשדות ואם ברור מאיפה ממשיכים. מומלץ לבחון את התיקון בלי למלא שוב את כל הטופס. שימו לב להודעה שמופיעה מחוץ לאזור הנראה בטלפון, או לשדה שמסומן כשגוי בלי שניתן להגיע אליו. תעדו גם את המצב אחרי התיקון: הודעת שגיאה ישנה לא צריכה להמשיך לבלבל כשהבעיה נפתרה.
נסו גם ערכים סבירים בצורות שונות, בהתאם לכללי העסק: רווחים בתחילת ערך, מקפים במספר טלפון או שם ארוך. החליטו אילו צורות צריכות להתקבל ורק אז השוו להתנהגות בפועל. המדריך של W3C לאימות קלט עוסק בזיהוי דרישות ובסיוע בתיקון; הוא גם מבהיר שבדיקת קלט בדפדפן אינה מספיקה כשכבת אבטחה. בדיקת השימושיות כאן אינה מחליפה בדיקה טכנית של המערכת.
מבדילים בין לחיצה לשליחה ולקליטה במערכת
הודעת האישור צריכה לתאר את מה שידוע
לחיצה על כפתור אינה בהכרח שליחה מוצלחת. ייתכן שהטופס נעצר בבדיקת שדה, שהרשת התנתקה או שהשירות שקולט פניות החזיר שגיאה. בדקו באיזה שלב מופיעה הודעת ההצלחה, ועל סמך איזה אישור. אם ההודעה מבטיחה שיחה, זמן תגובה או קבלת הצעה, ודאו שהנוסח תואם את תהליך העבודה האמיתי.
יש להבחין גם בין קבלת הפנייה באתר לבין העברתה ליעד עסקי נוסף. לדוגמה, ייתכן שרישום התקבל בשירות הקליטה אך טרם הגיע ל־CRM. בבדיקה צריך לדעת מה המערכת מאשרת למשתמש ואיפה נשמרת הפנייה לצורך המשך טיפול. אין צורך לחשוף פרטי מערכת למשתמש, אבל אסור להציג שלב שלא קרה כאילו הושלם.
מאמתים קבלה בנפרד מאירועי מדידה
בתיעוד המדידה המשופרת של Google Analytics מתוארים אירועי תחילת מילוי ושליחת טופס. צריך לבדוק שהם אכן נאספים בתצורה ובטופס המסוימים. אירוע מדידה לבדו אינו מאשר שהרישום הגיע למקום שבו העסק מטפל בפניות, ואינו קובע שמדובר בלקוח מתאים.
בתהליך בדיקה מתואם, התאימו בין ניסיון בדיקה לבין רישום ביעד באמצעות סימון בדיקה בטוח שהוגדר מראש. השתמשו בנתונים מלאכותיים, ואל תשלחו לכלי המדידה ערכים גולמיים של שמות, טלפונים, כתובות דואר או תוכן חופשי של פניות. מספיק לתעד שהפעולה התרחשה ואת סטטוס הבדיקה הנדרש, בהתאם להגדרות המאושרות של העסק. המדריך הזה אינו מפרט הטמעת מדידה או חיבור מערכות; הוא מגדיר מה צריך לאמת.
כרטיס בדיקה שאפשר להעביר למי שמתקן
מתעדים פעולה שאפשר לשחזר
דיווח ״הטופס לא נוח״ מצביע על תחושה, אבל קשה לעבוד ממנו. כרטיס בדיקה טוב מאפשר לאדם אחר לבצע את אותם צעדים ולראות אם קיבל אותה תוצאה. מלאו אותו בזמן הבדיקה, כדי לא להסתמך על זיכרון. אפשר לשמור אותו במסמך העבודה של הצוות בלי לכלול בו מידע אישי אמיתי.
השתמשו בשדות הבאים:
- מזהה ותרחיש: שם קצר שמבדיל את הבדיקה מאחרות.
- תנאים: מכשיר, דפדפן, כיוון מסך, מצב רשת ועמוד כניסה.
- צעדים: הפעולות שבוצעו, לפי הסדר, עם נתוני בדיקה מלאכותיים.
- תוצאה צפויה: מה המשתמש צריך לראות ומה אמור להיקלט ביעד.
- תוצאה בפועל: תיאור מדויק של מה שקרה, גם אם הבדיקה הצליחה.
- חומרה: האם המשימה נחסמה, הוטעתה או רק נעשתה פחות נוחה.
- ראיה: צילום או הקלטה נקיים ממידע אישי, ותיעוד קליטה אם הוא רלוונטי.
- אחריות ובדיקה חוזרת: מי מטפל, מה שונה ומתי הורץ אותו תרחיש שוב.
דוגמה היפותטית לכרטיס מלא
תרחיש: תיקון שדה טלפון חסר. תנאים: טלפון בדיקה ודפדפן שנרשמו בכרטיס, תצוגה לאורך ומקלדת פתוחה. צעדים: פתיחת הטופס מהעמוד, מילוי יתר השדות בנתונים מלאכותיים ולחיצה על שליחה. צפוי: הסבר לצד השדה החסר ואפשרות לתקן בלי לאבד את יתר הנתונים.
תוצאה לדוגמה לצורך ההמחשה בלבד: הטופס מציג הודעה כללית ומרוקן את שדה התיאור. חומרה מוצעת: פגיעה משמעותית בהשלמת המשימה, משום שהמשתמש נדרש להקליד מחדש. ראיה: צילום מסך עם נתוני הבדיקה. אימות לאחר תיקון: חזרה על אותם צעדים ובדיקה שהתיאור נשמר וההודעה מסבירה את החסר. זהו כרטיס מומצא שמדגים תיעוד, ולא ממצא מאתר שנבדק.
תרחישי בדיקה לטופס פנייה במובייל
בודקים גם שימוש רגיל וגם התאוששות מטעות
- שדה חובה חסר: משאירים שדה נדרש ריק ושולחים. מצפים לזהות מה חסר, להגיע אליו ולתקן בלי לאבד את יתר הפרטים. בודקים שהודעת השגיאה מתעדכנת לאחר התיקון.
- פורמט חלופי סביר: מזינים ערך בפורמט שהעסק החליט לתמוך בו, למשל טלפון עם מקפים. מצפים לקבלה או להנחיה ברורה שתואמת את הכללים. אין לדרוש שכל ערך יתקבל; הדרישה צריכה להיות מוצדקת ומובנת.
- מעבר באמצעות מקלדת: עוברים בין הרכיבים בלי להסתמך על לחיצה במסך. מצפים לסדר הגיוני, לזיהוי הרכיב הפעיל וליכולת להשלים את הפעולה. מתעדים מקום שבו הסמן נעלם או המעבר נעצר.
- רכיב דביק ומקלדת פתוחה: מגיעים לשדה התחתון ולכפתור כאשר פס קבוע מוצג. מצפים לראות ולהפעיל את הרכיב הדרוש בלי מחסום. בודקים גם פתיחה וסגירה של המקלדת, ולא רק מצב סטטי.
- תקלה ברשת: בסביבת בדיקה מתואמת מדמים אובדן חיבור בזמן ניסיון שליחה. מצפים להודעה שמשקפת את המצב ולדרך בטוחה להמשיך. בודקים שלא הוצגה הצלחה ללא אישור ושניסיון חוזר אינו יוצר בלבול לגבי הקבלה.
- שליחה מוצלחת: ממלאים נתונים תקינים, שולחים ומוודאים הודעה מתאימה למשתמש ורישום ביעד שהוגדר. בודקים את התאמת הפרטים ואת ההמשך הצפוי, ולא מסתפקים בצילום של מסך תודה.
מוסיפים תרחיש כאשר עולה סיבה ממשית
אם הטופס מכיל בחירה שמשנה שדות, קובץ מצורף או מעבר בין שלבים, הוסיפו בדיקה ייעודית לכל יכולת כזאת. אין צורך לבנות רשימה עצומה של מצבים שאינם קיימים. התחילו במסלול העיקרי ובכשלים שימנעו פנייה, ואז הרחיבו לפי מבנה הטופס והמידע שמגיע ממשתמשים.
בבדיקות של רשת ושליחה חוזרת, הגדירו עם הצוות הטכני מה אמור לקרות אם לא ברור האם הניסיון הקודם נקלט. ההתנהגות הנכונה תלויה במערכת. המשימה של הבודק היא לחשוף אי־בהירות ולתעד אותה, כדי שהפתרון ייבחן מול תרחיש ממשי ולא רק מול מסך ההצלחה הרגיל.
מתעדפים תקלות וחוזרים לבדוק את התיקון
מדרגים לפי הפגיעה ביכולת להשלים פנייה
התחילו בתקלה שחוסמת שליחה תקינה, מציגה אישור שגוי או גורמת לאובדן מידע שכבר הוזן. אחריה טפלו במכשול שדורש ניסיונות חוזרים או יוצר טעות משמעותית בהבנת הפעולה. בעיות ניסוח וריווח חשובות גם הן, אך כדאי להבחין בינן לבין מסלול שאינו מאפשר למשתמש לסיים.
לצד חומרת התקלה ציינו באילו תנאים היא נמצאה. תקלה שנצפתה במכשיר אחד אינה בהכרח קיימת אצל כולם, אבל אין בכך סיבה להתעלם מחסימת משימה ברורה. מנגד, דיווח יחיד שאי אפשר לשחזר דורש בירור נוסף לפני שמייחסים לו היקף רחב. תיעוד מדויק מאפשר לקבל החלטה בלי לנחש שיעור נטישה או הפסד כספי.
סוגרים את התקלה רק אחרי בדיקה חוזרת
לאחר תיקון הריצו את אותו תרחיש באותם תנאים, ואז בדקו מסלול רגיל סמוך. תיקון הודעת שגיאה צריך להשאיר שליחה תקינה פעילה; שינוי בכפתור צריך להיבדק גם כשהמקלדת פתוחה וגם כשהיא סגורה. שמרו את התוצאה החדשה לצד הישנה כדי שהצוות יוכל להבין מה אומת ומה עדיין פתוח.
אם משנים כמה דברים יחד, תעדו זאת. אפשר לוודא שהבעיה נפתרה, אבל קשה להסיק איזה שינוי גרם להשפעה עסקית. הצלחת בדיקת שימוש מוגדרת אינה הוכחה לעלייה במכירות, וגם אינה אישור לנגישות מלאה. כשהטופס הוא חלק מאתר חדש או משינוי רחב, שלבו את הממצאים עם בדיקות לפני עליית אתר לאוויר, בלי להחליף בהן את הבדיקה הממוקדת של הפנייה.
שאלות נפוצות על חוויית משתמש בטפסים
האם צריך להסיר את כל שדות החובה?
לא. צריך להשאיר מידע שחיוני לטיפול בשלב הפנייה ולהסביר מדוע הוא נדרש. בדקו כל שדה עם מי שקולט את הפניות. שדה שאינו משרת צורך ברור ראוי לבחינה, אבל טופס שאין בו דרך לחזור לאדם עלול להיות חסר שימוש לעסק.
האם placeholder יכול להחליף תווית?
לא. טקסט לדוגמה בתוך השדה יכול לסייע בהסבר הפורמט, אבל הוא אינו תחליף לתווית ברורה ומקושרת לשדה. בדקו שהתווית נשארת מובנת גם לאחר שהמשתמש התחיל להקליד, ושאפשר לזהות את מטרת השדה בטכנולוגיות המסייעות הרלוונטיות.
למה אירוע שליחה אינו מוכיח שהפנייה התקבלה?
כי אירוע המדידה עשוי לתאר פעולה בטופס בלי לאשר את הקליטה ביעד העסקי. צריך לבדוק כיצד האירוע מופעל ולהשוות ניסיון בדיקה לרישום בפועל. גם רישום שהתקבל אינו מוכיח שהפנייה רלוונטית או שכבר טופלה.
האם בדיקה בטלפון אחד מספיקה?
היא יכולה לחשוף בעיה, אבל אינה מכסה את כל שילובי המכשירים והדפדפנים. בחרו מצבים נוספים לפי קהל האתר, מבנה הטופס והנתונים הזמינים. רשמו בדיוק מה נבדק, והימנעו מהכרזה שהטופס תקין בכל מצב על סמך ניסיון יחיד.
מה צריכה לכלול הודעת הצלחה?
אישור ברור של הפעולה שהושלמה והסבר מציאותי על ההמשך. אם העסק מתחייב לזמן תגובה, הוא צריך להיות מאושר וישים. בדקו שההודעה מופיעה רק לאחר האישור המתאים מהמערכת, ושאינה מבטיחה שלב נוסף שטרם בוצע.
האם כדאי למחוק את הפרטים אחרי הודעת שגיאה?
בדרך כלל כדאי לאפשר תיקון בלי להזין שוב מידע תקין שכבר מולא. בדקו מה נשמר, מה דורש תיקון והאם ברור היכן ממשיכים. אם קיימת סיבה טכנית מיוחדת להתנהגות אחרת, צריך לבחון אותה ולתכנן הסבר ודרך המשך מתאימים.
האם הבדיקות במדריך מוכיחות שהאתר נגיש?
לא. אלו בדיקות שימושיות ממוקדות עם הפניות להנחיות טכניות של W3C. הן אינן מכסות את כל דרישות הנגישות או את כל רכיבי האתר, ואינן קובעות עמידה בחובה משפטית. הערכה מלאה דורשת בדיקה מקצועית נפרדת לפי ההקשר הרלוונטי.
באילו נתונים משתמשים לבדיקת הטופס?
השתמשו בנתונים מלאכותיים שסומנו ותואמו מראש, ובסביבת בדיקה כשאפשר. אין צורך בפרטי לקוח אמיתי כדי לבדוק שדה חסר, תיקון שגיאה או הודעת קבלה. ודאו שגם צילומי המסך והמדידה אינם כוללים תוכן אישי גולמי מהטופס.
משלימים פנייה אחת מתחילתה ועד סופה
בחרו טופס מרכזי, הגדירו מה נחשב הצלחה והריצו את ששת התרחישים עם כרטיס בדיקה מסודר. תקנו תחילה את מה שחוסם או מטעה, ולאחר מכן חזרו על אותו מסלול כדי לאמת את השינוי. כך אפשר לעבור מתחושה כללית שהטופס ״לא עובד טוב״ לרשימת ממצאים שהצוות מסוגל לבדוק ולסגור.
לבדיקת האפשרות להתקדם עם האתר העסקי שלכם, אפשר להכיר את שירות בניית אתרים לעסקים של אנשים מדיה ולהגיע לשיחה עם מסלול פנייה מתועד ושאלות ממוקדות.