בחודש יולי האחרון העביר אודי מצגת העשרה לעובדי חברת Tipalti, איתם הסטודיו עובד מעל לשלוש שנים. חברת Tipalti היא יוניקורן מוביל בתחום הפינטק בארץ ובעולם. ההרצאה עסקה בבדיקות משתמשים / שמישות (User Testing) ושמה דגש על איך עושים בדיקות משתמשים בצורה נכונה ואלו תובנות חשובות אפשר וצריך להפיק מהם. המתודולוגיה שהוצגה משקפת את ההליכים המבוצעים בסטודיו סלנט איי די. ההרצאה התקיימה במשרדי החברה בגליל ים וכתבה זו מתמצתת את עיקרי הדברים של ההרצאה.
כשאנחנו עובדים על מערכת עבור לקוח, ולא משנה באיזו מידה אנחנו מכירים את עולמות התוכן, אחד מהעקרונות החשובים ביותר שמנחים אותנו הם הידיעה שאומנם יש לנו ניסיון וידע רחב, אך ישנה גם הצניעות שאנחנו לא יודעים טוב יותר מהמשתמש עצמו. לעיתים אנחנו מייצרים מערכת (במידת גימור מה בהתאם לצורך) שאנחנו מאמינים בה, נותנים את המירב, בוחנים את המוצר אל מול משתמשים פוטנציאליים ומקבלים פידבקים שונים לחלוטין ממה שציפינו. הקו המנחה תמיד יהיה מהמשתמש עצמו, ואם המשתמש איננו מצליח להשתמש במערכת נכונה, המערכת איננה נגישה מספיק עבורו. כתוצאה מכך נעשה שינויים במערכת ונבדוק זאת שנית.
כולנו בני אדם, וכולנו מושפעים לא מעט מהטיות קוגניטיביות מובנות. הטיה שכזו יכולה להיות the false consensus effect- הטיה מובנית לחשוב שמה שאנחנו מאמינים בו הוא אמונה רווחת גם אצל אחרים. הטיה זו יוצרת בקרבנו מעיין "התאהבות" ברעיונות שלנו ומקשה עלינו להיכנס לנעליים של האחר ולהבין שאולי הוא תופס את הדברים שונה. על כן ישנה חשיבות גדולה להקשיב למשתמשים שלנו בבדיקות ולשקול את כל המסקנות החשובות שצפות ועולות במהלך הסשנים.
אז מה הן בדיקות משתמשים ומה עושים בהן בפועל?
בדיקות המשתמשים כוללות בתוכן שני צדדים- צד החוקר והצד המבצע. הצד החוקר נותן את הוראות הפעולה לצד המבצע והצד המבצע בתורו עושה את המשימות המוכתבות מראש. בזמן שהנסיין מתנסה במערכת דרך המשימות השונות, החוקר עוקב אחר התנהגותו וכן מקשיב ומסכם את המשובים.
לבדיקות המשתמשים יתרונות רבים:
- ניטור בעיות: בדיקות המשתמשים מאפשרות לעלות על בעיות ותקלות שאנו כמאפיינים וכמעצבים לא שמנו לב אליהם, אם כי פספסנו ואם כי נשבנו לתוך הנרטיב הספציפי אליו חתרנו.
- חשיפת הזדמנויות: לפעמים הזדמנויות צצות שלא חשבנו עליהן קודם.
- ללמוד על המשתמשים הפוטנציאליים: תמיד חשוב לדעת כיצד הם מתנהגים ומה הם מעדיפים.
את בדיקות המשתמשים ניתן לחלק לארבע קטגוריות שונות:
- בדיקות משתמשים סינכרוני מתון: הנסיין מקיים מפגש עם המשתתף ומנחה אותו לפעול על פי רשימת משימות שנכתבה מראש. הדבר יכול להיעשות במפגש פיזי או במפגש בשיחת וידאו. הנסיין יכול לשנות ולכוון את המשתתף על פי הצורך.
- בדיקות משתמשים א-סינכרוני ולא מתון: בדומה לבדיקות סינכרוניות רק שאת ההוראות אינו מעביר נסיין אלא המחשב שהוכנסו אליו המשימות השונות והמשתמש יכול לבצע אותן בזמנו הפנוי. את הביצועים ניתן לשמור ולהקליט ולצפות בהן בשלב מאוחר יותר. הדבר לעיתים בעייתי מכיוון שלא תמיד המשתמש מבין כראוי את המשימה או מעביר מידע לא רלוונטי שגובה בהמשך זמן יקר של ניתוח הממצאים.
- בדיקות משתמשים גרילה: בחינה של האפיונים והעיצובים ברמת גימור משתנה על קולגות בעבודה וקבלת פידבק מהם על שימושיות ונראות בהתאם.
- בדיקה מול לקוחות קיימים: בחינה של המערכת בעולם האמיתי מול לקוחות אמיתיים שמשתמשים בה.
סוגי משתמשים והרמות השונות לבחינה
המשתמשים יכולים להיות אוכלוסייה מאוד מגוונת או מאוד מצומצמת גם יחד. המשתמשים יכולים להיות שונים בפרמטרים יבשים כגון מין, גיל, מוצא או מגזר, או בהעדפותיהם האישיות כגון תחומי עניין, רמת שליטה טכנולוגית ומגוון של הבדלים בין-אישיים שקיימים בכל אחד מאיתנו. כל אדם נבדל מרעהו והמטרה שלנו היא ליצור מערכת שתהיה קלה ונגישה בצורה המיטבית לכל אחד מהמשתמשים. אז כמובן שלא נאפיין מערכת שתקלע במאת האחוזים לכל אחד ואחת, אך ניצור מכנה מספיק משותף על מנת לענות על הצרכים של רוב המשתמשים וניצור מערכת תמיכה לאלו שמתקשים (ממש כמו גלגלי עזר באופניים לילדים).
את בדיקות המשתמשים ניתן לעשות בכמה רמות ורבדים בהתאם לצרכים ובהתאם להשקעה הנפשית והכספית – ניתן לבחון את המערכות על קולגות בעבודה או על עובדים בחברה ביחידות אחרות, ניתן לאסוף משתמשים פוטנציאליים, לתת להם משימות ולבחון את הביצועים. רמות גבוהות יותר כבר יכללו גרסאות בטא ובחינה שלהן בעולם האמיתי או בחינת ביצועים של לקוחות שכבר משתמשים במערכות.
בעזרת כמה משתמשים נרצה לבדוק את המערכת?
נילסן נורמן, האב הרוחני של עולמות חוויית המשתמש יסכם את זה בצורה הברורה ביותר- "התשובה היא 5, חוץ ממצבים שבהם זה לא המצב". גוגל יבואו ויטענו בין 5-8, תלוי בסיטואציה. כך או כך, ישנה הסכמה שמדובר במספר חד ספרתי קטן. הרעיון העומד מאחורי המספרים הללו הם ש-80% מהבעיות שיהיו במערכת יצופו בחמשת המפגשים הללו וה-20% הנותרים יצופו רק לאחר משתמשים רבים ולכן ביחס ההשקעה אל מול האפקט אין זה מקדם את המערכת בצורה קוסט-אפקטיבית.
השאלות המרכזיות שנשאל עצמנו בבדיקות משתמשים
-
הצעת ערך: האם אתה תורם משהו למשתמשים הפוטנציאליים שלך שאכן נצרך עבורנו ולא מקבל מענה הולם במקומות אחרים?
-
רלוונטיות: האם המערכת מעבירה את מה שהלקוחות הפוטנציאלים מצפים לו? האם זה תואם לצרכים ולרצונות שלהם?
-
בהירות: בכמה קלות הצעת הערך שלך מתוקשרת? בא לידי ביטוי בזרימתיות, תמונות, קופירייטינג והנעה לפעולה.
-
דחיפות: כיצד אתה נפגש ומנצל את הדחפים הפנימיים של המשתמשים הפוטנציאליים שלך אל מול יצירת תמריצים חיצוניים.
-
הפרעות: האם הפלטפורמה שלך מושכת החוצה את המשתמשים מהמטרה העיקרית אליה נכנסו?
-
חרדה: האם ישנם תהליכים שיוצרים בקרב המשתמשים חוסר ודאות וחשש לבצע פעולות שאתה רוצה שיבצעו?
מה לא לעשות בבדיקות משתמשים
אז אחרי שדיברנו על מה הן בדיקות משתמשים וכיצד מבצעים אותם, נשמח לתת דגשים חשובים לעבודה עם בדיקות משתמשים על מנת שתוכלו להפיק מהם את המיטב:
- לבחון כל משתמש בנפרד ממשתמשים אחרים- יש לנו כבני אדם הנטיה לחקות התנהגויות של אחר ולהסכים עם טיעונים שהוא מעלה. כך למעשה לא נוכל לגבש את התמונה המלאה של הבעיות והתקלות שיש לנו במערכת.
- לשבת נסיין אחד בלבד ובסמוך למשתמש (ולא מולו)- נבדקים צריכים להרגיש כמה שיותר בסיטואציה נוחה ונעימה ולא במבחן, ועל כן תייצרו להם סביבה שתרגיש כמה שפחות שבוחנים אותם.
ופרקטית- איך מתכוננים לבדיקות משתמשים?
בדיקות משתמשים זה לא תהליך של מה בכך. לבדיקות משתמשים צריך להתארגן ולהכין תסריט ידוע מראש על מנת למנוע משתנים שעלולים להפריע לקבלת הפידבקים נקיים כמה שניתן מהפרעות. ישנה חשיבות עצומה לבצע הליך דומה בין כל המשתמשים, לשאול את אותן השאלות ולספק את אותו הסטינגס כמה שניתן. אלו הם השלבים שצריך לבצע על מנת לבנות בדיקות משתמשים בצורה הנכונה:
- הכנה והערכות:
- הכנת מסמך תוכנית הבדיקות
- הגדרת פרופיל משתמשים
- בניית תסריטי משתמש עבור הבדיקות
- ניהול הבדיקות:
- חלופות ליצירת אבטיפוס אינטראקטיבי עבור הבדיקות
- התנהלות, השיח מול הנבדק
- איסוף הממצאים תוך כדי הסשן
- ניתוח וממצאים:
- ריכוז ממצאים למסמך מאוחד
- ניתוח ממצאים
- מסקנות ותוכנית פעולה לשינוי ולשיפור
על סביבת הבדיקות להיות סביבה שקטה, שנוכחים בה הנבדק והנסיין בלבד. קיים הצורך לתת תדרוך ראשוני לנבדק ולהסביר שבודקים את המוצר ולא את הביצועים שלו ולתת לו לקרוא את המשימות השונות ולשאול שאלות הבהרה. שיטה שמאוד תורמת להבנה של התנהגות הנבדק היא לבקש ממנו לדבר את מה שעובר לו בראש בכל רגע נתון (Think aloud).
מי אמור לבצע את בדיקות המשתמשים?
זוהי שאלה טובה. בענקיות הטכנולוגיה הגדולות והמוכרות יש מחלקות שלמות שזה תפקידם, לערוך בדיקות משתמשים, לרכז את הממצאים ולהעביר הלאה. תפקיד זה מוגדר לרוב כ-ux research והוא מבוצע על ידי אנשים שזו היא התמחותם.
במקומות קטנים יותר, נושא זה תמיד נופל בין מספר תפקידים וכל אחד יכול לקחת על עצמו את האחריות- החל ממנהל/ת הדיגיטל, דרך מנהלי המוצר וכלה במאפיינ/ת ובמעצב/ת.