לבדיקות שימושיות יש מוניטין לא מוצדק של תהליך יקר ואיטי. כשאנשים שומעים "מחקר משתמשים", הם מדמיינים מראה חד-כיוונית, מנחה עם לוח כתיבה ולוח זמנים של שבועיים. גרסה כזו של בדיקות אכן קיימת ויש לה שימושים — אבל היא לא הגרסה שרוב צוותי המוצר צריכים רוב הזמן.
הגרסה שרוב הצוותים צריכים פשוטה יותר: חמישה משתמשים, אב-טיפוס ב-Figma או סביבת staging, שיחת וידאו ו-45 דקות לכל סשן. כשעושים זאת היטב, היא חושפת את רוב בעיות השימושיות החמורות לפני שהן מגיעות לייצור. כשעושים זאת באופן עקבי — אפילו פעם בכל ספרינט — היא מניבה שיפור מצטבר באיכות המוצר שאף כמות של אנליטיקס אחרי ההשקה לא יכולה לשחזר.
הנה איך מריצים אותה מאפס.
חמישה משתתפים הם המספר הנכון לרוב בדיקות השימושיות. המחקר של יעקב נילסן קבע שחמישה משתמשים חושפים כ-85% מבעיות השימושיות, ואחרי זה התועלת פוחתת. הרצת שלושה סבבים של חמישה משתמשים בנקודות שונות בתהליך העיצוב שווה יותר מסבב אחד עם חמישה עשר.
קריטריוני הגיוס חשובים יותר מהמספר. בדיקת שימושיות עם חמישה אנשים שמתאימים היטב למשתמש היעד שלך תחשוף בעיות אמיתיות. בדיקה עם חמישה עשר אנשים שלא מתאימים תייצר רעש. הגדר שניים או שלושה קריטריוני סינון — תפקיד, הקשר שימוש, רמת נוחות טכנולוגית — והיצמד אליהם.
דרך הגיוס המהירה ביותר לרוב הצוותים היא שליחת דוא"ל למשתמשים קיימים שנתנו הרשאה ליצירת קשר. הצע תמריץ צנוע — שובר מתנה של £20 מספיק לסשן של 45 דקות. שאף לקבוע את הסשנים בתוך אותו שבוע; ככל שהפער בין הגיוס לבדיקה גדול יותר, כך שיעור אי-ההגעה גבוה יותר.
הטעות הנפוצה ביותר בכתיבת תסריט היא ניסוח משימות כהוראות: "לחץ על הגדרות, עבור להתראות ושנה את ההעדפה שלך ל..." כך אתה אומר למשתמש מה לעשות, ולכן אתה בודק אם הוא יכול לבצע הוראות, ולא אם הממשק אינטואיטיבי.
במקום זאת, כתוב משימות כתרחישים: "דמיין שאתה מקבל יותר מדי התראות ואתה רוצה לקבל התראה רק כשמישהו מתייג אותך ישירות. הראה לי מה היית עושה." כך המשתמש מקבל מטרה ריאליסטית, ואתה יכול לצפות איך הוא באמת מנווט — כולל המקומות שבהם הוא מתבלבל.
החלק הקשה ביותר בהנחיית בדיקת שימושיות הוא לעמוד בפני הדחף לעזור. כשמשתמש מבולבל, כל אינסטינקט אומר לקפוץ ולהראות לו איפה ללחוץ. אבל הבלבול הוא הנתונים. משתמש שמתקשה אומר לך שמשהו בממשק לא בסדר — וברגע שאתה מתערב, אתה מאבד את האות.
בקש מהמשתמשים לחשוב בקול לאורך כל הסשן: "תוך כדי התקדמות, פשוט ספר לי על מה אתה מסתכל ומה אתה חושב." כך מתקבל זרם רציף של נתונים על המודל המנטלי שלהם. ציין לא רק שגיאות אלא גם היסוסים — משתמש שעוצר לשלוש שניות לפני שהוא לוחץ על הכפתור הנכון חשף בעיית עיצוב, גם אם בסופו של דבר הצליח.
שלב הסינתזה הוא המקום שבו נוצר רוב הערך — ובו רוב הצוותים עושים קיצורי דרך. הערות גולמיות מחמישה סשנים אינן ממצאים. הן הופכות לממצאים כשעורכים תחקיר כצוות, מקבצים תצפיות לפי נושא וקובעים דירוגי חומרה.
בצע את התחקיר באותו יום של הסשנים, כשהתצפיות עדיין טריות. קבץ את הבעיות לשלוש קטגוריות: קריטיות (המשתמשים לא הצליחו להשלים את המשימה), בינוניות (המשתמשים השלימו את המשימה אבל בקושי משמעותי או עם שגיאה), וקלות (חיכוך שלא מנע השלמה). את הבעיות הקריטיות יש לתקן לפני ההשקה. את הבעיות הבינוניות יש לתעדף בספרינט הבא. הבעיות הקלות עוברות לבקלוג.
כתוב את הממצאים בעמוד אחד: שלוש הבעיות הקריטיות המובילות, עם ראיות מלפחות שני משתתפים לכל אחת, והצעה לשינוי עיצובי לכל בעיה. כל מה שדורש יותר מקום שייך למסמך נפרד.