הספר, Rocket Surgery Made Easy, הינו ספר שני בסדרת הספרים שהוציא Steve Krug, מומחה עולמי לשימושיות וחוויית משתמש. הספר, מתמקד במשימה אחת מוגדרת היטב: ללמד אנשים שאינם מומחים לשימושיות, כיצד לבצע בדיקות שימושיות שוטפות בארגונים לאתרי ה- WEB עליהם אמונים. ניתן ליישם חלק גדול מההמלצות גם למערכות אחרות, אך הספר תוכנן ונכתב בראיית WEB. מחבר הספר בהחלט גורס שאם ארגון יכול להרשות לשכור מומחה לנושא- אזי עדיף; אך במידה ולא, כדאי לדעת כיצד לבצע בדיקות שימושיות גם באופן עצמאי.
עיקרי הספר:
הספר כתוב באופן נהיר, נעים והינו בהחלט קל לקריאה. מומלץ לכל מי שאחראי על אתרים/פורטלים פנימיים או חיצוניים.
בדיקות שימושיות
בדיקות שימושיות הינן תהליך של תצפית על אנשים המנסים להשתמש במערכת שפותחה, כאשר מטרת המבדקים היא:
א. להקל על השימוש של אנשים במערכת.
ב. להוכיח שהמערכת שפותחה נוחה דיה לשימוש.
המבדקים המתוארים להלן – מבדקי "עשה זאת בעצמך" ללא מומחים, הינם מבחנים איכותניים (ולא כמותיים).
בדרך כלל קשה לאנשים המתכננים/מעצבים/בונים אתרים לראות בעצמם את בעיות השימושיות במערכות שפיתחו, שכן אנשים אלו רגילים כבר למערכת ויודעים מה תכולתה ולמה ניתן לצפות בה.
יש לקחת כהנחת יסוד שבכל מערכת, ובפרט, בכל אתר WEB- יש בעיות שימושיות.
ואמירה אחרונה (אולי אפילו מפתיעה): תהליך בדיקות שימושיות אינו חד פעמי. בלי שאנחנו מרגישים, תכני האתרים משתנים כל הזמן. מומלץ לבצע בדיקות שימושיות באופן קבוע אחת לחודש!
מסגרת הבדיקות:
1. מטרה: איתור רשימה קצרה של בעיות השימוש המשמעותיות ביותר.
2. היקף ותדירות: חצי יום, אחת לחודש.
3. מתי בתהליך הפיתוח: מוקדם ככל האפשר (כולל בדיקת Wireframes ותוכניות מקדימות).
4. מספר המשתמשים הנבחנים: 3.
5. הנבדקים: אנשים אקראיים, מייצגים, ככל הניתן.
6. מיקום: במשרדי החברה; אין צורך במעבדה ייעודית.
7. המתצפתים: מנהלים, מפתחים ושותפים נוספים לאתר.
8. דו"ח. 1-2 עמודים מסכמים.
9. גורם המחליט על הבעיות: כלל השותפים המתצפתים.
10. עלויות כוללות: כאלף ₪ (כולל ציוד, תשלום לנבדקים וארוחת צהריים למתצפתים).
חזרה
היערכות לקראת
היערכות ראשונית לקראת מבדקי שימושיות הינה תרגול. מומלץ לתרגל בדיקת שימושיות על אתרי חברות מתחרות. קל יותר לקבל את הממצאים ולהבין אותם באופן אובייקטיבי, לפני שניגשים לבחון את האתר שלנו.
עיקרי ההיערכות לקראת מפגש מבדקים:
א. גיוס שלושה נבדקים: פנימיים או חיצוניים, ובלבד שאינם קשורים לצוות הפיתוח. ישנה עדיפות לחיצוניים באתר חוץ ארגוני, ופנימיים באתר פנימי.
במידת הצורך, ניתן לגייס מועמדים טובים שאינם יכולים להגיע, ולבצע בדיקה מרוחקת (פחות טוב).
אין להשתמש באותם מועמדים במבדקים חוזרים.
מומלץ שיהיה נבדק זמין נוסף שניתן להפעילו בקריאת זמן אפס, למקרה שמישהו לא הגיע.
ב. הגדרת המשימות הנבדקות. יש כמובן להעדיף משימות קריטיות ומשימות שנראות פחות קלות לביצוע. קבלת משוב מהשותפים (צוות פיתוח האתר) לגבי המשימות.
ג. יצירת תרחישים פרטניים למשימות. בכתיבת התרחישים יש להבטיח שאין רמזים מנחים. יש להימנע בהוראות משימוש במילים שהינן גם שמות תפריטים באתר (מכוון).
מומלץ לבצע פיילוט מקדים אישי על המשימות על פי התרחישים, לוידוא רישומם הנכון והמדויק.
את התרחישים יש להדפיס (כדי להגיש לנבחנים ולמתצפתים במהלך המבדק).
ד. היערכות לוגיסטית: תיאום ותזכור הנבחנים והמתצפתים, ציוד, זימון חדרי ישיבות, ארוחת צהריים, הכנת חדר הבדיקה (מחשב, מסך, מקלדת, עכבר, מיקרופון, רמקול), הכנת חדר המתצפתים (מחשב, מקרן, רמקולים, טלפון עם רמקול לגיבוי, ו..חטיפים).
הכנת סימניות לדפים הראשונים עמם מתחילים; הגדלת סימן החץ כדי שייראה באופן ברור יותר במבדק.
לפני כל מבדק:
א. ניקוי היסטוריית הדפדפן.
ב. פתיחה מחודשת.
בסיום כל מבדק:
א. הפסקת ההקלטה ושמירתה.
ב. רישום הערות.
חזרה
המבדקים
מוביל האירוע הינו גם המנחה ומוטלת עליו האחריות בתחומים הבאים:
א. הנחיית הנבדקים מה לעשות.
ב. ווידוא שהנבדקים מרוצים ולא נלחצים מידי תוך כדי.
ג. עידוד הנבדקים לדבר בקול רם ולהביע את מחשבותיהם לגבי הניווט באתר והתחושות הנלוות לו.
המבדק יתוכנן לשעה:
|
4 דקות |
פתיחה והסבר התהליך. מומלץ בחום לקרוא מהכתב כדי לא לשכוח פרטים ודגשים |
|
2 דקות |
מקדימות לנבדקים, גם כדי להכירם, אך בעיקר כדי לגרום להם לחוש בנוחות ולחוש שמקשיבים להם |
|
3 דקות |
היכרות הנבדק עם דף הבית של האתר |
|
35 דקות |
מילוי המשימות (יש לוודא התקדמות, כדי שלא לפספס במידה ונתקעים במשימה) |
|
5 דקות |
שאלות הבהרה לנבדק (עדיף לא לשאול תוך כדי המשימה) |
|
5 דקות |
סיכום |
|
5 דקות |
היערכות לנבדק הבא |
הנחיות חשובות למנחה:
· אסור להגיד לנבדק מה לעשות או לרמוז להם איך לבצע את המשימה
· אסור לענות על שאלות הנבדקים
· אסור להביע דעה אישית לגבי האתר והפונקציונאליות שבו
· יש להשתדל לשמור על פנים חתומות.
· יש לוודא שהנבדק עוזב את המבדק, במצב לא יותר גרוע מזה בו הגיע למבדק.
חזרה
שיפורים בעקבות
בעת המבדקים עצמם, יושבים המתצפתים בחדר אחר ואמורים לרשום הערות בלבד, ללא שאילת שאלות.
עצם התצפית הינה שלב ראשון בשיפור- היא גורמת למתצפתים להאמין כי אכן נדרש שיפור.
מעבר לכך, פעמים רבות, הנבדקים מצביעים על פתרונות אפשריים.
ובכל זאת, אין בכך די. לאחר שלושת המבדקים, השלב הבא הינו התחקור.
ההמלצה החמה של כותב הספר היא לקיים את התחקור כארוחת צהריים. יגדיל את כמות המשתתפים התצפית, יחסוך זמן לכל מי שהחליט אכן להשתתף, ויבטיח אווירה נעימה.
מטרת התחקור:
א. להסכים על בעיות השימושיות המשמעותיות ביותר כפי שעלו במבדקים.
ב. להחליט, על בסיס הרשימה דנן, מהן בעיות השימושיות שיטופלו (עד מפגש המבדקים בחודש הבא).
הנחות היסוד בעת התחקור הנן:
- לכל האתרים יש בעיות שימושיות.
- לכל הארגונים יש משאבים מוגבלים שניתן להשקיע בטיפול בבעיות השימושיות.
- תמיד יש יותר בעיות שימושיות מזמן להשקיע בהם.
- קל להסיח את הדעת ע"י בעיות שקל לפתור, ולא להתמקד בבעיות החשובות שאולי יותר קשות.
- חייבים לפעול באופן אקטיבי להבטיח שהבעיות המשמעותיות אכן תהיינה אלו שתטופלנה.
מומלץ לנהל את התחקור בהתאם למתווה הבא:
א. לבקש מכל אחד שירשום את כלל הבעיות ששם אליהן לב. לבקש תעדוף של 3 בעיות.
ב. לקיים הצבעה לגבי רשימת הבעיות שתטופל על סמך התעדופים.
לאחר התחקור יש להפיק דוח קצר הכולל:
א. תיאור מה שנבדק.
ב. תיאור המשימות שבוצעו.
ג. רשימת הבעיות שהוחלט לטפל בהן.
טיפים לשיפורים:
- מינימום שינוי. כל שינוי משמעותי ייצר בעיות שימושיות חדשות (ויגזול יותר משאבים).
- עדיף להפחית דברים מהמסך/חלון. יש להשתדל לעולם לא להוסיף שכן מרע את השימושיות.
ולמרות זאת, לא תמיד השיפורים מתבצעים – מכל הסיבות הארגוניות (קשה לנהל שינויים, דברים דחופים יותר צפים) ומסיבות מחשוביות (השינויים מסתברים כקשים למימוש).
אך למרות הכול- לא להתייאש. ניתן לשפר, וכדאי. אל תוותרו.
חזרה