RSS לפוסטים RSS לתגובות 228 מאמרים ו- 1,974 תגובות עד כה מאז 2005

רשמים מביצוע מבחן משתמשים

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

כאשר אנו רוצים להעריך את מידת השמישות של מערכת ישנן מספר שיטות שניתן ליישם. שיטות אלה פותחו במשך שנים וכל אחת מהן מספקת מידע מסוג מסויים כאשר השילוב של כמה מהן ביחד מספק תמונה רחבה יותר שתאפשר הסקת מסקנות. בין השיטות הללו אפשר למנות את ביקורת המומחה (Expert Review), צעידה קוגנטיבית (Cognitive Walkthrough) ומבחן משתמשים (User Testing). בביקורת מומחה, לפחות שלושה אנשי מקצוע עם רקע רלוונטי סוקרים את הממשק על פי עקרונות וכללים מנחים ידועים כמו אלו של נילסן למשל. הם מנסים לאתר בעיות שמישות פוטנציאליות שיגרמו כתוצאה מאי עמידה בסטנדרטים מוכרים, חוסר עקביות בממשק, טיפול בעייתי בתקלות וכו'. נילסן ממליץ על שימוש בשלושה בוחנים מהסיבה הפשוטה שבוחן אחד שסוקר את הממשק אינו יכול לעלות על כמות מספקת של בעיות.

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

אני לא אנסה לסכם במאמר אחד את הספר של דומאס ורדיש לכן אנסה לתמצת את תיאור התהליך עצמו ולהתמקד במסקנות שלי. מבחן משתמשים מורכב משלושה שלבים עיקריים:
1. שלב ההכנה – מגדירים את קהל היעד של המבחן, מגדירים מטלות ותסריטים מציאותיים שכוללים בתוכם מספר מטלות, מגייסים משתמשים, דואגים לניירת כמו טופס הסכמה ומכינים את סביבת המבחן.
2. שלב הביצוע – בין אם הבוחן נמצא באותו חדר עם המשתמש או בחדר ליד, המשתמש מקבל לידיו מספר תסריטים (Scenarios) ומשתמש בממשק על מנת להגשים את היעד המתואר. אם אנו לא מעוניינים למדוד את הזמן שלוקח לבצע מטלות מסויימות אנו מורים למשתמש לדבר תוך כדי המבחן ולתאר מה הוא עושה ולמה הוא עושה זאת (Think aloud Protocol). כך אנו יכולים ללמוד מה המשתמש חושב ומהם השיקולים המנחים אותו תוך כדי ביצוע הפעולות ("הממממ…. אני רוצה לצאת עכשיו אז אני מחפש משהו שכתוב עליו "יציאה" או "סגירה"… המממממ… אני לא רואה שום דבר כזה בתפריט אז אולי זה למטה.. המממממ…אה.. הנה זה").
3. שלב הניתוח – עוברים על צילומי הוידאו, הקלטות המסך ורשימות הבוחן על מנת לאתר את הבעיות השונות בהן נתקל כל משתמש בכדי ללמוד על בעיות כלליות שדורשות התייחסות ברמת התכנון והעיצוב.

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

שלב ההכנה

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

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

שלב הביצוע

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

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

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

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

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

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

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

5 תגובות על “רשמים מביצוע מבחן משתמשים”

  1. 25/03/2006 בשעה 23:58 איתי

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

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

  2. 26/03/2006 בשעה 0:05 אמיר דותן

    היי איתי,

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

  3. 26/03/2006 בשעה 13:33 איתי

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

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

    ולגבי מה שאמרת: "
    צפייה (Observation) היא שיטה מקובלת במחקר בכדי לאסוף מידע בצורה בלתי גלויה לעיתים שאמורה לתפוס את האנשים במצב הכי טבעי שיכול להיות."

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

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

  4. 26/03/2006 בשעה 14:11 אמיר דותן

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

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

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

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

  5. 07/04/2006 בשעה 8:30 VRider

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

    אחת הדרכים להקטין את העומס הקוגניטיבי בשיטת ה Think-a loud Protocol היא ביצוע המשימה** בזוגות. ככשני אנשים יושבים יחד ופותרים את המשימה, זה מוסיף למורכבות האינרטאקציה מצד אחד, אך פותח ערוץ נוסף של תקשורת אותנטית לגבי ההתנסות עם המנשק בין הנבדקים שניתנ לניתוח מצד שני.
    דרך נוספת לקבל מידע מהנבדק היא באמצעות ביצוע instant recall כשמיד בתום ההתנסות מקרינים את ההתנסות שנלכדה בוידאו לנבדק ומבקשים ממנו לשחזר את חוויית המשתמש שלו.
    דרך זו בשילוב דרכים אחרות מאפשרת טריאנגולציה [הצלבה] של המידע שהתקבל ומכאן להגעה למסקנות טובה יותר.

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

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

RSS לתגובות לפוסט זה

הוספת תגובה