אתר שנבנה בעזרת AI יכול להיראות גמור הרבה לפני שאפשר לסמוך על כל הפעולות שבו. יש כרטיסים ותפריט וטופס עם כפתור בולט. אבל מה קורה למי שממלא פרט לא נכון? האם אפשר לחזור ולתקן בחירה בלי להתחיל מחדש? ומה שומע אדם שמשתמש בקורא מסך כאשר הודעת האישור מופיעה בפינה?
כדי לענות על השאלות האלה צריך לצאת לרגע מתפקיד המעצב. במקום לבדוק אם כל האזורים נראים מסודרים, מנסים להשלים פעולה. ניקח דוגמה של אתר לספרייה שמאפשר להזמין עמדת לימוד. המבקר בוחר יום ושעה וממלא פרטים. רק אחרי שההזמנה התקבלה הוא אמור לדעת ששמור לו מקום. זו דוגמה קצרה שמאפשרת לבדוק גם הצלחה וגם תיקון טעויות.
מגדירים מה נחשב סיום ולא רק איך נראה הכפתור
לפני שנוגעים בעיצוב כדאי לנסח תוצאה אחת ברורה: המבקר יודע לאיזו עמדה נרשם ובאיזה מועד. אם המערכת דורשת אישור נוסף מהספרייה, הוא צריך לדעת שהבקשה ממתינה ולא לחשוב שההזמנה סופית. שני המצבים יכולים להשתמש באותו טופס אבל הם זקוקים להודעות שונות.
ההבחנה הזאת חשובה במיוחד כשממשק נוצר מתוך תיאור כללי. קל לקבל מסך הצלחה יפה גם בלי שהוגדר בדיוק מה נחשב הצלחה. טקסט כמו “הכול מוכן” לא מספיק אם הוא מסתיר את מצב ההזמנה. לא צריך עוד פסקה חגיגית. צריך משפט קצר שמתאר מה קרה ומה נדרש מהאדם כעת.
אפשר להתחיל את הבדיקה בנתוני דוגמה ובסביבה שמיועדת לכך. אין סיבה ליצור הזמנות אמיתיות רק כדי לראות איך נראה מצב שגיאה. גם אין להסיק שתהליך עובד מפני שהטופס נעלם אחרי הלחיצה. על ההבדל בין תצוגה לבין מערכת שעובדת כדאי לחשוב כבר כשבוחרים את כלי הבנייה.
מניחים את העכבר בצד ומנסים להזמין מקום
פתחו את העמוד והשתמשו ב־Tab כדי לעבור בין הרכיבים. בכל רגע צריך להיות ברור איזה רכיב נמצא במיקוד. זו יכולה להיות מסגרת או הדגשה אחרת שמובחנת מהמצב הרגיל. אם הכפתור משתנה רק כשעוברים מעליו בעכבר, מי שמנווט במקלדת מפספס את הרמז הזה.
עברו גם לאחור עם Shift ו־Tab. סדר המעבר צריך לשמור על ההיגיון של הטופס. בחירת תאריך ואחריה בחירת שעה היא סדר מובן. מעבר מתאריך לקישור בפוטר ואז חזרה לפרטי ההזמנה עלול לבלבל. אין סדר חזותי יחיד שחייבים להעתיק בכל עמוד אבל אי אפשר להשאיר קפיצות שקוטעות את הפעולה.
בכפתור רגיל בדקו הפעלה באמצעות Enter ובאמצעות מקש הרווח. אם הוא מגיב רק ללחיצת עכבר, כדאי לבדוק אם נבנה כרכיב לחיץ מאולתר במקום ככפתור HTML. שימוש ברכיב מתאים נותן התנהגות בסיסית שהדפדפן כבר מכיר. הוספת מראה של כפתור לריבוע אינה מעניקה לו את אותה משמעות.
אם בחירת השעה פותחת חלון נפרד, המיקוד צריך לעבור לאזור שנפתח. בחלון מודאלי המשתמש אמור לפעול בתוכו ולא להמשיך בטעות לרכיבים שמאחוריו. בסגירה צריך לחזור לנקודה הגיונית בתהליך. בדוגמה שלנו זו בדרך כלל השליטה שממנה נפתחה בחירת השעה. אחרת האדם עלול למצוא את עצמו שוב בראש העמוד בלי להבין מה קרה.
אין צורך להפוך כל שורת טקסט לתחנת Tab. הניווט נעשה מייגע אם עוברים בנפרד על כל תיאור וכל מסגרת דקורטיבית. המטרה היא להגיע לפעולות בסדר מובן ולהשאיר את המידע שסביבן נגיש לקריאה. כשמתקנים מיקוד צריך לבדוק את הרצף כולו ולא רק את הרכיב שבו התגלתה הבעיה.
השדה צריך להסביר את עצמו גם אחרי שמתחילים להקליד
טקסט בהיר בתוך שדה ריק יכול לתת דוגמה אבל הוא אינו תחליף טוב לתווית קבועה. ברגע שמתחילים להקליד הוא נעלם. מי שעצר באמצע הטופס וחזר אליו צריך לזכור מה ביקשו בכל שדה. תווית גלויה כמו “שם מלא” נשארת במקום גם כשהשדה כבר מכיל תוכן.
ב־HTML התווית צריכה להיות משויכת לשדה עצמו. בדרך נפוצה עושים זאת בעזרת רכיב label שהמאפיין for שלו תואם למזהה id של השדה. הקשר הזה מאפשר לטכנולוגיה מסייעת לזהות את מטרת השדה. הוא גם מאפשר בדרך כלל ללחוץ על התווית כדי לעבור לשדה או להפעיל תיבת סימון.
בדקו אם באמת נחוצים כל הפרטים שהטופס מבקש. לצורך הזמנת עמדת לימוד ייתכן שלא צריך כתובת מגורים. שדה שאין לו שימוש ברור מוסיף עבודה למבקר וגם למי שמנהל את המידע. בשדות שנשארים ציינו מה חובה ומה רשות והציגו דרישת פורמט לפני שהאדם נכשל בה.
גם הכפתור זקוק לניסוח שמתאר את הפעולה. “המשך” יכול להתאים כשעוברים לסיכום. “שליחת בקשה” מתאים כששולחים בקשה לאישור. אם כפתור שנראה כמו מעבר לשלב הבא מבצע בפועל הזמנה סופית, הטקסט אינו מכין את האדם למה שעומד לקרות.
בחירה של שעה צריכה להיות מובחנת גם אחרי שהאצבע או סמן העכבר עזבו אותה. גוון שמופיע רק במעבר מעל הרכיב אינו מציין בחירה שנשמרה. הציגו מצב נבחר ברור והשתמשו ברכיב שהמשמעות שלו מתאימה לבחירה. למשל, קבוצת אפשרויות שבה אפשר לבחור שעה אחת שונה מכמה תיבות סימון עצמאיות. גם בלי לראות את הצבע צריך להיות אפשר להבין איזו אפשרות נבחרה.
טעות קטנה היא הזדמנות לבדוק את העמוד כולו
השאירו שדה חובה ריק ונסו לשלוח. הודעה טובה מצביעה על השדה ומסבירה איך לתקן. “נדרש שם מלא” מועיל יותר מ”קלט שגוי”. כאשר הבעיה אינה בטקסט שהוקלד אלא בכך שהשעה כבר אינה זמינה, ההודעה צריכה לומר זאת. אין טעם להחזיר את האדם לשדה השם במקרה כזה.
צבע אדום לבדו אינו מספיק כדי להסביר מה לא תקין. הוסיפו הודעה כתובה שנמצאת ליד השדה. כשמשתמשים בהודעה מותאמת אישית צריך לחבר אותה לשדה גם באופן תוכנתי. aria-describedby יכול לקשור בין השדה להסבר שלו ו־aria-invalid יכול לציין מצב לא תקין. אלה אינם קישוטים לקוד אלא מידע שקורא מסך יכול להשתמש בו.
בטופס עם כמה בעיות אפשר להציג סיכום ברור עם קישורים לשדות המתאימים. אחרי שליחה שלא הצליחה צריך לעזור לאדם למצוא את מקום התיקון. בהתאם למבנה הטופס אפשר להעביר מיקוד לסיכום או לשדה הראשון שדורש תיקון. לא כדאי להציג אוסף התרעות מתחרות שמנסות לדבר כולן באותו רגע.
חשוב גם מתי מציגים שגיאה. אם מתחילים להקליד כתובת דואר והטופס מודיע אחרי האות הראשונה שהיא אינה תקינה, הוא מתקן טעות שעדיין לא התרחשה. אפשר לבדוק חלק מהערכים ביציאה מהשדה או בשליחה. משוב מיידי מועיל כאשר הוא עוזר להתקדם ולא כאשר הוא מפריע להשלים את הפרט.
לאחר תיקון אחד שאר הנתונים התקינים צריכים להישאר ככל שאפשר. אדם שבחר יום ושעה לא צריך לבחור אותם מחדש מפני שחסר פרט אחר. בדקו גם חזרה מהסיכום לטופס. שמירת ההקשר מצמצמת את הסיכוי לטעות נוספת והיא חלק מהתפקוד של התהליך.
בין הלחיצה לאישור יש מצב שהעיצוב נוטה לשכוח
אחרי שליחת הבקשה יש פרק זמן שבו עדיין אין תשובה. הכפתור צריך להראות שהפעולה מתבצעת ולא להישאר כאילו דבר לא קרה. אפשר להציג טקסט כמו “הבקשה נשלחת”. אם מונעים לחיצה נוספת בזמן הזה, צריך עדיין להיות ברור למה הכפתור אינו זמין. אפור חיוור ללא הסבר אינו מצב שימושי.
כפתור שמושבת כבר מתחילת הטופס יכול ליצור קושי אחר. המבקר אינו יודע מה חסר כדי להפעיל אותו. לעיתים עדיף לאפשר ניסיון שליחה ואז להציג הנחיות תיקון ממוקדות. אם הפעולה חייבת להישאר לא זמינה עד לבחירה מסוימת, הסבירו את התנאי ליד המקום הרלוונטי ולא רק בתוך הודעה שאי אפשר להגיע אליה.
כאשר הודעת מצב נוספת לעמוד בלי שהמיקוד עובר אליה, היא צריכה להיות זמינה גם לטכנולוגיה מסייעת. הודעת הצלחה או המתנה יכולה להשתמש באזור שמוגדר כ־status או באזור חי מתאים. כך קורא מסך יכול להודיע על השינוי בלי שהאדם יצטרך לנחש שנוסף טקסט מתחת לטופס.
אין צורך להכריז על כל שינוי קטן. ממשק שמקריא שוב ושוב שהוא עובד עלול להפריע יותר משהוא עוזר. כדאי להודיע על מעבר משמעותי ממצב המתנה להצלחה או לבעיה. גם הסרת סמל טעינה אינה מסבירה לבדה מה קרה. כאשר הפעולה מסתיימת צריך להשאיר תוצאה מובנת.
אם לא התקבל אישור ברור מהמערכת, אין להציג הזמנה מוצלחת רק כדי לסיים את האנימציה. הודעה שמודה שהמצב עדיין אינו ידוע עדיפה על אישור שאינו נכון. דרך ההתאוששות צריכה להתאים למערכת: בדיקת מצב ההזמנה או ניסיון חוזר כאשר ידוע שהוא בטוח לתהליך. זו החלטה על התנהגות ולא רק על ניסוח.
בודקים את אותו תהליך במסך צר ובטקסט מוגדל
בנייד בדקו את הטופס כשהמקלדת פתוחה. האם השדה הפעיל נשאר גלוי? האם כפתור קבוע בתחתית מסתיר הודעת שגיאה? שורת תאריך ושעה שנראית נוחה במסך רחב יכולה להפוך לשתי מטרות צפופות שקשה להפעיל באצבע. צריך לבדוק את הפעולה ולא רק אם העמוד נכנס לרוחב המסך.
הגדילו את התצוגה בדפדפן ל־200% ועברו שוב על התהליך. כותרות והודעות צריכות להישאר קריאות. אם טקסט יוצא מתוך השדה או כפתור מכסה תוכן, ייתכן שהרכיב קשיח מדי. חשוב גם לא לחסום את אפשרות ההגדלה בנייד. הגדלה היא כלי שימוש רגיל עבור אנשים רבים ולא תקלה שצריך למנוע.
בממשק מימין לשמאל כדאי לבדוק במיוחד תאריך ושעה לצד טקסט עברי. הגדרת dir נכונה מתארת את כיוון התוכן. הפיכה חזותית של שורה אינה תחליף לה. בדקו שהסדר נשאר מובן גם במעבר במקלדת ושערך כמו שעה אינו משנה משמעות בגלל מיקום לא צפוי של סימני פיסוק.
נותנים לאדם אחר לנסות בלי להסביר לו לאן ללחוץ
אחרי הבדיקות הטכניות תנו למישהו משימה קצרה: להזמין עמדה למועד מסוים ולבדוק אם ההזמנה אושרה. אל תובילו אותו דרך המסכים. אם צריך להסביר בעל פה מה משמעות הכפתור, העמוד כנראה צריך להסביר זאת בעצמו. שימו לב גם לרגעים שבהם הוא מהסס ולא רק למקום שבו הוא נתקע.
בדיקה עם אנשים שמשתמשים בקורא מסך או בהגדלה יכולה לחשוף דברים שלא רואים בבדיקת עכבר רגילה. בדיקה אוטומטית עדיין מועילה לאיתור בעיות מסוימות אבל אינה מכירה את כוונת ההזמנה. היא לא בהכרח תזהה שהודעת הצלחה מטעה. ההבחנה בין הדגמה לשימוש אמיתי מופיעה גם בהשוואה בין Figma Sites ל־Figma Make.
כשמתעדים בעיה כדאי לרשום את הפעולה ואת התוצאה ולא רק לצלם את המסך. תיאור כמו “אחרי סגירת בחירת השעה המיקוד חוזר לתחילת האתר” מאפשר להבין מה צריך להשתנות. אחר כך אפשר לבדוק את אותו רצף שוב. לעומת זאת, “התפריט לא נוח” משאיר את מי שמתקן לנחש אם הבעיה היא במיקום או בהתנהגות.
שאלות שעולות אחרי בדיקת הממשק
האם תוסף נגישות יכול לתקן לבדו טופס שנבנה עם AI?
לא כדאי להניח זאת. תוסף עשוי להוסיף כלים מסוימים אבל אינו יודע בהכרח מה משמעות השלבים ואילו נתונים צריכים להישמר. תווית לא נכונה או הודעת אישור מטעה דורשות תיקון בטופס עצמו. בדקו את הפעולה לאחר השינוי בלי להסתפק בכך שנוסף כפתור נגישות לעמוד.
האם צריך להקריא כל הודעת שגיאה מיד כשהיא מופיעה?
לא בכל מצב ולא כולן יחד. צריך שהאדם יידע שיש בעיה ויוכל להגיע להסבר המתאים. בטופס עם כמה שגיאות אפשר להודיע שיש תיקונים נדרשים ולהציג פירוט ליד השדות. עיתוי ההודעה וניהול המיקוד צריכים להתאים לתהליך ולא להפריע להקלדה.
מה בודקים שוב אחרי שה־AI משנה רק את העיצוב?
כדאי לחזור לפחות על מסלול ההזמנה המרכזי ועל מצב שגיאה אחד. שינוי של סדר רכיבים או הסתרת אזור בנייד יכול להשפיע גם על מיקוד ועל קריאות ההודעות. אם השינוי נוגע לחלון או לתפריט, בדקו פתיחה וסגירה במקלדת. הגדרה של שינוי כעיצובי אינה מבטיחה שההתנהגות נשארה זהה.
