בדיקות שימושיות – זה קל. שווה בדיקה

פורסם לראשונה כאן.

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

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

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

תנו לי לגלות לכם סוד – בדיקות שימושיות זה ממש לא פיזיקת הקוואנטים! זה פשוט וקל!

יש המון מקורות מידע שימושי על מה זה בדיוק בדיקות שימושיות. דבר ראשון- בדיקת שימושיות בויקיפדיה. הנה מאמר על שגיאות בבדיקות שימושיות ועוד מאמר נחמד על בדיקות. הנה פרק על בדיקות שימושיות מתוך ספר של usability.gov – דא"ג זהו מקור טוב ומהימן למידע על שימושיות. והנה מאמר ממש טוב על Usability test toolkit עם המון לינקים טובים ושימושיים לנושא.

נכון שאם רוצים לעשות בדיקות שימושיות  by-the-book אז הם צריכות להיעשות במעבדת שימושיות, בחדר עם מראה חד כיוונית, אולי עם מעקב אחרי תנועות עיניים וכל מיני חרטות שכאלה. אבל למעשה זה ממש פשוט: תעשו פרוטוטייפ – ולא משנה איך – אפילו על נייר. תחליטו מה התרחישים, תראו את זה למשתמשים, תבדקו התנהגות בזמן ביצוע, בקשו מהם לחשוב בקול, תעדו את המתרחש, עד כאן זה ממש קל וזול, לא? לפי נילסן, מספיק לבדוק 5 משתמשים בלבד כדי לעלות על הבעיות הקריטיות של התוכנה שלכם! ואל תשכחו לשתף את אנשי הפיתוח. בכל המקרים שעשיתי בדיקות שימושיות אנשי הפיתוח, שצפו בבדיקות, הופתעו מאוד. התהליך קל, פשוט ותורם המון.

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

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

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

• הכינו תוכנית בדיקה – החליטו מה רוצים לבדוק, את מי, מתי ואיך. זה יכול להיות דיון פשט של שעה וזהו.
• בחרו את סביבת הבדיקה – זה די פשוט – האם רוצים להשתמש במעבדת בדיקה מסודרת? (מראה חד צדדית וכולי?). האמת, לא חייבים ממש. סביבת הבדיקה צריכה להיות דומה לסביבת הבדיקה שבה נמצא משתמש הקצה. לדוגמא: תוכנת ניווט כדאי לבדוק תוך כדי נסיעה ברכב. לא מומלץ לבדוק אותה בישיבה בסלון…
• מצאו נבדקים – זה גם לא נורא, ברוב המקרים. תבדקו קבוצה של אנשים שהם משתמשי קצה רלוונטיים (הם לא חייבים להיות משתמשים בפועל של התוכנה. רק בעלי רקע מתאים). לדוגמא: משחק לוחמה ב-wii  לא הייתי בוחרת לבדוק על פנסיונר עם שפם בשם מוטקה. הייתי בוחרת את השכן שלי, אופק, תלמיד כיתה ו’ עם פוני ופלומת שפם (פחות משל מוטקה ז"א)…
• כתבו תרחישי בדיקה – כתבו בקצרה 3-6 מטלות ברורות שאתם רוצים לבדוק. הנה הסבר קצר. לדוגמא, אם אתם רוצים לבדוק אפליקציית אייפון לחנות מוזיקה: "מצא את האלבום האחרון של ליידי גגה". ניתן גם לאחר הבדיקה להכין שאלון קצר (שם, בניגוד לבדיקת שימושיות שבודקת ביצוע, למשתתפים יש מקום להביע דעה, להציע, להתלונן וכדומה).
  
• הכינו את סביבת הבדיקה: הכינו את החדר (הקפידו לשים שלט "נא לא להפריע" על הדלת), פיתחו את התוכנה במקומות הנכונים מראש, לפי התרחישים, השתמשו בתוכנה המתעדת את הבדיקה (הנה רשימה נחמדה של 24 תוכנות בדיקה שהכין בחור שנראה שפוי חלקית). חשוב מאוד מאוד שצוות הפיתוח יהיה נוכח בזמן הבדיקה. אין כמו מראה עיניים. בדיקת שימושיות תמיד תצליח להפתיע. תמיד.
• ערכו את הבדיקה – טקסט שאני אוהבת לומר בכל תחילת בדיקה למשתתפים: "דבר ראשון המערכת בבדיקה ולא אתם. טעות שלכם היא למעשה טעות שלנו בעיצוב הממשק". הסבירו על כמות התרחישים וזמן הבדיקה. תנו למשתתפים את התרחישים ובקשו מהם לחשוב בקול רם תוך כדי ביצוע (דוגמא לקטע שתוכלו לזכות לשמוע: "אני מחפש את כפתור ה"ביטול". אני לא מוצא אותו כאן. גם לא כאן. גם לא כאן. טוב. אני לא מוצא. אז אני לוחץ ESC. גם זה לא עובד. טוב. אני מחפש אייקון של איקס. אה. זה פח אולי. נראה כמו כובע. אה. לחצתי. הוא עשה ביטול??…"). תעדו את המתרחש – אין כמו לכתוב (אפשר גם על דפים בכתב יד. כן – יש עוד דבר כזה…) את תמצית המתרחש. בסיום הבדיקה ניתן להעביר שאלון משוב. נהוג גם להעניק תמורה לנבדקים, דא"ג. אל תשכחו להודות למשתתף ולהיפרד יפה. לאחר הפרידה, סכמו בכמה מילים את הבדיקה מול שאר הצופים בבדיקה. (לדוגמא: "סרגי, ראיתי שהוא לא הצליח לפתוח את הקובץ? כן, אני יודעת שזה נראה פשוט. אז זהו, שמתברר שלא"…).
• נתח את המידע מהבדיקות – חשוב להבין מה בדיוק קרה בבדיקות. מה הגורם האמיתי לטעויות? מה המשתמש לא הבין? זה החלק הכי חשוב בעיני בבדיקה. לדוגמא – צריך להבין מה גרם למשתמש לטעות בניווט באתר? הוא לא הבין איפה הוא עכשיו? הוא לא הבין איך ממשיכים למסך הבא? אולי הוא ציפה למצוא את המידע באותו המסך? אולי הכפתור קטן מדי? אולי האייקון לא ברור? – זה חלק שבעיני הכי דורש הבנה של המשתמשים ואולי גם קצת ניסיון. אבל בהרבה מקרים אנחנו מקבלים את התשובות תוך כדי הבדיקה מהמשתתפים (לדוגמא: "אני מחפש את המידע על הפריט בדף הזה… אני מחפש כפתור מידע נוסף. אין. אז אני אחפש בתפריט פרטי פריט…").
• תן המלצות להמשך – אז מה כדאי לעשות עכשיו? לשנות את העיצוב על בסיס ההבנות החדשות ולבדוק שוב.

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