מה אודיט UX אמור לגלות?
אודיט UX לא נועד לענות אם האתר “יפה”. הוא נועד לבדוק אם אדם אמיתי מצליח להבין מה מציעים, למצוא מידע, לבצע פעולה ולדעת מה קורה אחר כך. אפשר לבצע את הבדיקה לפני redesign, וגם בלי להחליף את כל האתר.
הצ׳קליסט הבא בודק ארבעה שלבים: הבנה, ניווט, ביצוע ואמון. בכל סעיף רשמו את הבעיה, את העמוד שבו היא מופיעה ואת השינוי הקטן ביותר שיכול לבדוק את ההשערה.
12 בדיקות שכדאי לבצע
1. המסר במסך הראשון
האם מבקר חדש מבין למי העסק עוזר, במה הוא עוזר ומה אפשר לעשות עכשיו — בלי לקרוא עמוד שלם?
2. הפעולה המרכזית
האם יש CTA אחד ברור בעמוד החשוב, והאם הניסוח מתאר פעולה אמיתית כמו קביעת שיחה או שליחת שאלה?
3. ניווט ומבנה
האם אדם יכול להגיע לשירות, למחירון, לשאלות נפוצות וליצירת קשר בלי לנחש איפה הם נמצאים?
4. חיפוש ומציאת מידע
בחרו שלוש שאלות שלקוח באמת שואל. בדקו כמה צעדים נדרשים כדי למצוא תשובה, והאם התשובה מופיעה במקום שבו מצפים לה.
5. מובייל
בדקו במכשיר אמיתי: תפריט, גודל טקסט, אזורי לחיצה, גלילה אופקית, טפסים ושיחות טלפון. “רספונסיבי” אינו בהכרח “נוח”.
6. טופס פנייה
בקשו רק מידע שנחוץ לשלב הראשון. בדקו labels ברורים, סוגי שדות מתאימים, שמירה על טקסט שהוזן והסבר מדויק על שגיאות.
7. מסלול אחרי השליחה
שלחו פנייה אמיתית. האם יש אישור ברור? האם היא מגיעה לאדם הנכון? האם ידוע מהו הצעד הבא — רק אם זה באמת התהליך בעסק?
8. נגישות בסיסית
עברו עם מקלדת בלבד ובדקו focus, מבנה כותרות, ניגודיות, טקסט חלופי ושמות ברורים לשדות. WCAG 2.2 של W3C מספקת קריטריונים טכניים לבדיקה; היא אינה תחליף לבדיקת משתמשים.
9. מהירות ויציבות
בדקו נתוני משתמשים אמיתיים ולא רק ציון מעבדה. Google מתארת חוויית דף כשילוב של ביצועים, אבטחה, מובייל ובהירות — לא מדד יחיד.
10. אמון והפחתת סיכון
האם ברור מי עומד מאחורי העסק, איך נראה התהליך, ואיפה אפשר לקבל תשובות? אל תוסיפו לוגואים, הסמכות או תוצאות שאין להן בסיס אמיתי.
11. שפות וכיווניות
באתר רב־לשוני בדקו כל גרסה בנפרד: ניסוח, RTL, תפריט, טפסים, קישורים, title ודרך יצירת הקשר. תרגום חלקי הוא בעיית UX, לא רק בעיה לשונית.
12. מדידה
חברו כל פעולה למטרה: צפייה ב-CTA, התחלת טופס, שגיאות, שליחה, שיחת טלפון או קביעת פגישה. מספר כניסות לבדו לא אומר איפה המסלול נשבר.
איך להפוך את האודיט לתוכנית עבודה
- בחרו שניים או שלושה מסלולים מרכזיים ובדקו אותם מקצה לקצה.
- הפרידו בין בעיית תוכן, בעיית ממשק, תקלה טכנית וחוסר במדידה.
- דרגו כל ממצא לפי השפעה על משימה, תדירות וסיכון — לא לפי כמה הוא בולט למעצב.
- בדקו קודם שינוי קטן שאפשר למדוד, לפני החלטה על redesign מלא.
אפשר להשוות את התוצאות גם לצ׳קליסט לאתר שמייצר פניות, לשאלות הבריף לפני פיתוח ולמדריך על מתי redesign באמת נחוץ.
השורה התחתונה
אודיט UX טוב לא מייצר רשימת הערות אינסופית. הוא מראה איפה אדם נתקע, מה הסיבה הסבירה ומה אפשר לשנות ולבדוק. אם הבעיה נקודתית — תקנו נקודתית. אם כמה מסלולים נשברים יחד — רק אז יש בסיס רציני לשקול redesign.