עיצוב שמיש

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

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

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

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

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

שלב ההכנה

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

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

שלב הביצוע

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

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

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

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

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

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

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

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