בדיקות שמישות

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

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

במאמר זה נסקור בהרחבה את הנושא של בדיקות שמישות. מהן בעצם הבדיקות הללו? נבין את ההבדל בין בדיקות שמישות (Usability Testings) לבדיקות משתמשים (User Testing), מתי מבצעים את הבדיקות הללו? ואיך נכון לבצע אותן? יאלה מתחילים.

מהן בדיקות שמישות?

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

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

בדיקות שמישות או בדיקת משתמשים

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

מתי מבצעים בדיקות שמישות?

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

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

איך עושים את זה?

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

  • תכנון 
  • גיוס נבדקים
  • בדיקה
  • ניתוח הנתונים

תכנון

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

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

גיוס נבדקים

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

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

בדיקה

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

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

ניתוח הנתונים

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

שימור ההצלחה

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

תוכן העניינים