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

לקחים מביצוע בדיקת שמישות מבוססת היוריסטיקות בקבוצה

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

אבחון שיטתי

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

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

גיבוש הרשימה

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


חלק מהשאלות שהכנו לבדיקה

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

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

מה למדנו?

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

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

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

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

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

גמישות היא מילת המפתח

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

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

7 תגובות על “לקחים מביצוע בדיקת שמישות מבוססת היוריסטיקות בקבוצה”

  1. 09/02/2009 בשעה 8:05 asaf

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

    יהיה מסקרן עוד יותר לשמוע איך יילך הניסויי בטא של זה בעתיד הרחוק או הקרוב.

  2. 10/02/2009 בשעה 14:07 אמיר דותן

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

  3. 12/02/2009 בשעה 0:02 asaf

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

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

  4. 12/02/2009 בשעה 1:09 אמיר דותן

    אסף, אני יודע ששותפים אחרים בפרוייקט עובדים על נושא העתיד של הפרוייקט ואני לא בקיא בפרטים.

    לגבי שיפור הפריון, זהו אחד הדברים שאנו רוצים ומתכוונים לבדוק בשלב האבחון הסופי לקראת סוף השנה. מכיוון שהמערכת היא בראש ובראשונה מערכת למידה (Advanced Process- Oriented Self- Directed Learning Environment) אחד היעדים שלנו הוא גם למדוד העשרת ידע לצד פריון כאשר השניים כמובן מאוד קשורים היות וידע חדש תורם לפריון. העסק לא פשוט אבל מאוד מעניין. יש מספר שיטות לאיסוף מידע שאנו מגבשים בכדי לאסוף מידע איכותני וכמותי שממנו ננסה להסיק כיצד המערכת השפיעה על המשתמשים בסביבת העבודה.

  5. 02/03/2009 בשעה 10:31 ברק

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

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

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

    (האתר שבלינק עם השם שלי יעלה בימים הקרובים)

  6. 02/03/2009 בשעה 12:19 אמיר דותן

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

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

    אני מחכה בכיליון עיניים לראות את הבלוג שתעלה לאור הלינק :)

  7. 05/03/2009 בשעה 13:21 ברק

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

    הבלוג שלי עלה, אין בו עוד הרבה תוכן, אבל זה בוודאי ישתנה בקרוב :-)
    http://www.usable.co.il

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

הוספת תגובה