שיעור חשוב ממבדק המשתמשים ב– JW Player

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

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

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

תיאור מקרה

שאנון קופפר ברייס (Copfer Brace) עובדת בחברת JW Player שעוזרת לחברות אחרות (במודל B2B, עסק לעסק) ולמפתחים להגיע ליותר לקוחות וקהלים באמצעות סרטונים ולתרגם אותם להכנסות. בשלב מסוים נוצר הצורך להפוך את הפלטפורמה לתוכנה כשירות (Software as a Service) שמאפשרת לנתח ביצועים של סרטונים על פי המכשיר בו הצופה משתמש והמיקום הגאוגרפי שלו. מכיוון שהכלי הוא מורכב יחסית ומיועד לאנשי IT ואנליסטים, גם המבדקים לא היו סטנדרטים.

live v

 

השאלות החשובות ביותר שהיה צורך למצוא להן תשובות היו מהם המדדים השימושים ביותר, מיהם המשתמשים שירצו להשתמש במוצר והאם יש התאמה בין מה שהכלי מציג לבין מה שהמשתמשים מצפים למצוא.

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

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

כיצד הם עשו זאת?

תכנון והגדרת יעדים

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

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

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

מיקוד, הגעה לקהל היעד ותיאום

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

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

עריכת המבדקים עצמם

הציוד שנדרש עבור המבדקים היה לפטופ, תוכנה לשיחות וועידה ושיתוף מסך (GotoMeeting), תוכנה ללכידה והקלטה של המסך (Jing  או Camtasia), הכלי הפנימי של Jw Player ומספר כלים של גוגל (ג’ימייל, שיתוף מסמכים בדרייב, יומן וכלי שמאפשר לאחד הודעות דואר עם גיליונות אלקטרוני).

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

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

Charts

 

תדרוך, לכידה ושיתוף

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

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

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

יישום המסקנות וביצוע פעולות

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

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

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

לאחר השלב הזה, מאגר המערך של זרימת המידע עבר עוד שיוף, הסכמות של הקווים הכללים שימשו לסקיצת העיצוב הסופית ובסופו של דבר הפכו לכלי “Right Now Analytics” של החברה כפי שהוא מוצע כיום.

סיכום

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