שימושיות לפני קישוט
UI מתאר את הרכיבים שהמשתמש רואה ומפעיל; UX מתאר את המסע ואת מידת התאמתו למשימה. אתר יכול להיות מעוצב היטב ועדיין להקשות על אדם שרוצה לברר מחיר, לקבוע פגישה או להבין מה יקרה אחרי שליחת טופס. מתחילים ברשימת משימות אמיתיות ובודקים אם אפשר להשלים כל אחת בנייד, במקלדת ובשפה ברורה. בחירת צבע אינה תחליף לשם שדה, הודעת שגיאה מובנת או סדר צעדים הגיוני.
משרטטים מסלול משתמש אחד
נניח שמבקר מגיע לדף שירות מחיפוש ממוקד. הוא צריך להבין תוך קריאה מה השירות כולל, למי הוא מתאים, מה אינו כלול ואיך ממשיכים. רושמים את שאלותיו ליד כל שלב: מה המחיר או דרך חישובו, כמה מידע צריך למסור, ומה קורה אחרי הפנייה. אם התשובות פזורות בין עמודים, מציבים קישור הקשרי במקום לחייב אותו לחזור לתפריט. לאחר מכן מבצעים את המסלול בעצמנו ומבקשים מאדם שאינו מכיר את האתר לתאר בקול מה הוא מצפה שיקרה בכל לחיצה.
טופס טוב אוסף רק מה שנחוץ
שדה שאין לו שימוש בשלב הראשון מוסיף מאמץ וחשש. מסמנים שדות חובה באופן ברור, בוחרים סוג קלט מתאים במובייל ומציגים שגיאה ליד השדה בצירוף דרך לתקן. הודעת הצלחה צריכה לאשר שהפנייה נקלטה ולספר מתי או באיזה ערוץ צפוי המשך, בלי להבטיח זמן מענה שאינו נשמר בפועל. אם שליחה נכשלת, אין למחוק את הטקסט שהמשתמש הקליד. בדיקה עם קורא מסך ומקלדת מגלה מחסומים שלא נראים בצילום עיצוב.
מדידה שאינה מסתפקת בכפתורים
שיעור קליקים על CTA יכול לעלות גם כאשר טופס ההמשך נשבר. לכן מחברים בין חשיפות, התקדמות, שליחות תקינות ואיכות פניות. מתעדים תקופה לפני שינוי ותקופה אחריו, אך בודקים במקביל מקורות תנועה, עונתיות ושינוי בהצעה. מבחן A/B יכול לעזור כאשר יש מספיק נתונים ותנאי ניסוי מסודרים; במדגם קטן עדיף לפעמים להתחיל בבדיקת שימושיות ובתיקון שגיאות ברורות. אין עיצוב שמכפיל המרות מעצם קיומו.
מרכיבי אמון במסך החלטה
עמוד שמבקש פרטי קשר חייב להסביר מי העסק, מה תכלית הטופס ואיך תיעשה פנייה חוזרת. מפרט שירות ברור, דוגמאות מסומנות, תנאים רלוונטיים ופרטי קשר נגישים עוזרים יותר מסמל אמון שאין מאחוריו הסמכה. כאשר משתמש חוזר כדי להשוות חלופות, השוואה עניינית בין מסלולים מועילה מקרוסלה של סיסמאות. עלות ויתרונות שמוצגים באותו מקום מקטינים את הצורך לנחש.
בדיקת נייד ומקלדת
במסכים צרים בודקים שאין גלילה אופקית, שטקסט אינו מוסתר מאחורי כפתור צף וששדות מספיק גדולים להפעלה. במקלדת נעים לפי סדר קריאה, רואים היכן נמצא המיקוד ויכולים לסגור חלונות שנפתחו. במובייל בודקים גם זמן טעינה אמיתי ברשת שאינה אידיאלית, אבל לא מחליפים תיקון של מסר לא ברור בציון מהירות. חוויית משתמש היא שרשרת: עמוד מהיר, תוכן מתאים ופעולה שניתן לסיים.
מידע נגיש גם במצב שגיאה
משתמש שטעה במספר טלפון צריך לדעת מה לא תקין, לשמור את שאר הפרטים שכבר הזין ולחזור לשדה הבעייתי. צבע אדום לבדו אינו הסבר מספק. אם אתר מציג חלון קופץ עם הצעה, בודקים שאפשר לסגור אותו במקלדת ושהמיקוד חוזר למקום הגיוני. תמונה או אייקון שמבצעים פעולה מקבלים שם נגיש שמסביר אותה. שיפורים אלה משרתים אנשים עם צרכים שונים וגם משתמשים שממלאים טופס במהירות במכשיר קטן.
בדיקה לפני העברת עיצוב למפתחים
מסמך מסירה צריך להציג גם מצבי שגיאה, טעינה, הצלחה ורכיב בפוקוס, ולא רק צילום של המסך היפה ביותר. אם כפתור מושבת, צריך להסביר למה ומתי יופעל. אם תוכן משתנה לאחר בחירה, צריך לדעת כיצד יוכרז לקורא מסך ואיך יישמר סדר הקריאה. דוגמת תוכן ארוך בעברית עוזרת לבדוק מה יקרה כשהטקסט אינו נכנס לכרטיס. פערים אלה זולים יותר לתיקון לפני פיתוח מאשר אחרי שמשתמשים נתקעים.
בדיקה עם תוכן אמיתי
מסך דוגמה עם כותרת קצרה ומספר יפה יכול להסתיר בעיית פריסה. מכניסים כותרת שירות ארוכה בעברית, הודעת שגיאה מלאה וטקסט פרטיות אמיתי. בודקים ריווח, חיתוך ושינוי גודל טקסט בנייד. אם כרטיס דורש לקצר תנאי מהותי כדי להתאים לעיצוב, משנים את הכרטיס. תוכן ועיצוב עובדים יחד; ממשק שאינו מסוגל להציג מידע שהלקוח חייב לדעת אינו מוכן לפרסום, גם אם דגם העיצוב נראה מאוזן.
תרחיש בדיקת שימושיות קצר
נותנים לאדם שאינו מכיר את האתר משימה ממשית: למצוא תנאי התאמה, להבין מה מקבלים ולבקש מידע נוסף. מבקשים ממנו להסביר בקול מה הוא מצפה שיקרה אחרי לחיצה, בלי להדריך אותו במסלול הרצוי. מתעדים היכן נעצר, אילו מילים הטעו אותו ומה הצליח להבין. לאחר תיקון בודקים שוב, גם במקלדת ובטלפון צר. בדיקה כזו לא דורשת לטעון ששינוי צבע לבדו יכפיל המרות; היא חושפת פער בין מה שהצוות חשב שהוא ברור לבין מה שמשתמש רואה.
דוגמת עמוד הזמנת שירות
אדם מגיע מדף חיפוש כדי להזמין פגישת ייעוץ. הוא צריך לראות לאיזה סוג שאלה הפגישה מתאימה, מה להכין והאם היא כרוכה בתשלום. אם הכפתור אומר "קבעו פגישה" אך פותח טופס בקשת הצעת מחיר, נוצר פער ציפייה. מסלול UX טוב מתאר את הפעולה בשפה מדויקת ומאשר לאחר שליחה מה התקבל. UI מתאים מציג כפתור קריא, שדות עם תוויות והודעת שגיאה צמודה לבעיה. אלה שתי שכבות של אותה משימה, ואין טעם לשפר אחת תוך שבירת השנייה.
בדיקת שימושיות קטנה
מכינים משימה כגון "מצא כמה זמן לוקח לקבל הצעת מחיר" ומבקשים מאדם שלא מכיר את האתר לבצע אותה ללא הדרכה. מתעדים היכן עצר, אילו מילים פירש אחרת ומה ציפה לראות אחרי לחיצה. אין צורך להציג כמה משתתפים כהוכחה סטטיסטית; בדיקה כזו נועדה למצוא חסם בולט. אחרי תיקון חוזרים על המשימה עם אדם אחר ובודקים שלא נוצרה בעיה חדשה. התבוננות במסלול אמיתי מגלה לעיתים יותר מהצבעה של צוות על העיצוב המועדף עליו.
כרטיסיות, תפריטים וחיפוש
ניווט צריך לקבץ נושאים לפי מה שאנשים מחפשים, לא לפי המבנה הארגוני של העסק. אם שירות חשוב מוסתר תחת שם מחלקה שאיש מבחוץ אינו מכיר, משנים תווית או מוסיפים מסלול ברור. כרטיסיות רבות עלולות להסתיר מידע במובייל; בודקים שאפשר להגיע לתוכן גם במקלדת ושהמצב הנבחר ברור. חיפוש פנימי צריך להציג תוצאות רלוונטיות או דרך חלופית כשאין תוצאה, ולא להשאיר מסך ריק בלי הסבר.
לאחר השקת שינוי
בודקים תקלות טופס, פניות שהגיעו, תלונות על ניווט ומדדי שימוש במשך תקופה מתאימה. אם שיעור השליחה עלה, בודקים גם האם הפניות עדיין מתאימות. שינוי במקורות התנועה יכול להשפיע על המדד בלי קשר לעיצוב. מתעדים החלטות וראיות כדי שלא יחזירו רכיב ישן רק משום שהצוות התרגל אליו. העיצוב נבחן ביכולת להשלים משימה באופן ברור, לא בהבטחה גורפת להכפיל המרות.
להעמקה: בניית אתרים לעסקים: מתכנון ברור לאתר שקל להשתמש בו · מקור רשמי 1 · מקור רשמי 2.
