גרילה סטייל

פורסם במקור על-ידי עילי שריג בבלוג שמונים:עשרים ב-13 בינואר 2012

תהליך UX בריא עומד על שלוש רגליים: מחקר, עיצוב ובדיקות שמישות. פחות רגליים מזה, הוא צולע, ואם יש יותר מדי רוח הוא גם עלול ליפול.

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

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

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

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

בחיים הכל זה טיימינג

את הבעייה שראס תיאר אני מכיר היטב.

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

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

איך מגייסים בגרילה

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

אבטיפוס

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

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

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

תיעוד

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

תוצרי הבדיקה

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

מינוף תוצרי הבדיקה

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

לסיכום

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