נראה שהשאלה האם צריך להכיר את המשתמשים היא שאלה מיותרת, לא?
ברור שאם בונים מוצר שמיועד למשתמשים, כלומר לבני אדם מסוג כלשהו, כדאי להכיר את האנשים האלה. לא רק זאת אלא, שהצלחה של המוצר היא שהמשתמשים ישתמשו בו, יהנו ממנו, ויחזרו להשתמש בו שוב ושוב. אם התפקיד שלנו, כאנשי חוויית משתמש, הוא לגרום למוצר להצליח, הרי שאנחנו חייבים להכיר את המשתמשים כדי לגלות מה "יעשה להם את זה".
מסתבר שהשאלה הזו לא מיותרת בכלל. רבים מהעוסקים בפיתוח של מוצרים – החל מאנשי השיווק, דרך מנהלי מוצר, אנשי חווית משתמש, מעצבים, מפתחים וכל שאר המעורבים בתהליך הפיתוח, יצהירו בפניכם שההכרות עם המשתמשים היא אבן הבסיס של המוצר שלהם. הם לא זזים בלי לשאול את המשתמשים אם הם צריכים או רוצים פיצ'ר זה או אחר. הם מאמינים במחקר, בבדיקה. אבל כשנשאל על העבודה בפועל, אז נקבל מגוון תשובות מפתיעות.
יגידו לנו שזה סטארט-אפ, ואין ממש זמן לבדוק כל פיצ'ר וכל רעיון חדש. אין זמן ואין משאבים, ואנחנו עובדים מהר, ולומדים מהר מטעויות. ועושים מה שמבינים, ומקווים לטוב, ומקסימום תמיד אפשר לשפר בסייקל הבא.
יגידו לנו ש"אצלנו הבנת המשתמשים יושבת בשיווק – אנשי השיווק קרובים לשוק והם אחראים על זה". ואז אם נשאל עד כמה מתקבל מידע שוטף, עד כמה משקיעים בענין, יסתבר שלא ממש. אנשי השיווק פוגשים לקוחות (או מי שיכולים להיות לקוחות, או סתם אנשים שהיו בסביבה) בכנסים, בתערוכות, והם בסך הכל מרגישים שהם בעצמם סוג של משתמשים במערכת וזה מספיק להם.
יגידו לנו שהשוק גדול מדי, ורחוק מדי, ויש מיליוני משתמשים, ואי אפשר ממש לעשות בדיקות שמישות ולהכיר את המשתמשים לעומק- פשוט כי יש כל כך הרבה.
יגידו לנו שבשביל זה יש מומחה שמישות ושהוא ישבור את הראש.
כשמדברים על הכרות עם המשתמשים, תמיד גם יקפוץ אחד שיצטט את הנרי פורד שאמר משהו כמו "אם הייתי שואל את המשתמשים מה הם צריכים, הם היו אומרים סוס מהיר יותר". אז בואו נתחיל את הכתבה הזאת בהבנה שאנחנו מכירים בכך שלהכיר את המשתמשים זה חיוני. נענה למצטטים את פורד בציטוט אחר שלו: "אם יש סוד אחד להצלחה, הוא נמצא ביכולת להבין את עמדתו של האחר ולראות את הדברים מנקודת המבט של האדם האחר בנוסף לנקודת המבט של עצמך."
לשאלה הבאה – מי צריך להכיר את המשתמשים?
מי מתוך המעורבים השונים עליהם דיברנו קודם, צריך להוביל או להיות אחראי על ההכרות עם המשתמשים? האם אנשי השיווק הם אלו הצריכים לאסוף את הדרישות, לדבר עם המשתמשים ולהעביר את המידע לכל שאר המערכת? או שאולי אנשי חווית המשתמש הם אלה שצריכים להבין את המשתמשים בצורה הכי טובה? ומה עם אנשי המוצר? אלה שאמורים להחזיק ביד את החזון של המוצר, להוביל אותו, אם הם לא ידעו מי המשתמשים, איך הם יעשו את זה?
התשובה היא שכולם צריכים להכיר את המשתמשים, כל אחד מהפרספקטיבה שלו.
אנשי שיווק צריכים להבין את המשתמשים כדי לדעת לבנות נכון את אסטרטגיית השיווק, איך המשתמשים לומדים על מוצרים חדשים? מה השיקולים המשפיעים על ההחלטה שלהם באיזה מוצר לבחור? ממי הם מוכנים לקבל המלצות?
אנשי המוצר צריכים להכיר את המשתמשים כדי להוביל את המוצר כך שיענה על הצרכים של המשתמשים, אפילו הצרכים שהמשתמשים לא בהכרח מודעים להם. המענה על צרכים צריך להיות ממוקד וריבוי של פיצ'רים הנובע מחוסר היכרות עם המשתמשים פוגע בסיכוי להצלחת המוצר.
אנשי חוויית המשתמש צריכים להכיר את המשתמשים מעבר לפרופיל שלהם ולתחומי העניין שלהם. הם אלו הצריכים ליישם את כל גוף הידע המחקרי יחד עם הידע המקצועי, לבדוק את תקפות הידע עבור פרופיל משתמש ספציפי בכדי לאפיין את הפתרון, מרמת התהליכים ועד אחרון המסכים.
המפתח להכרת המשתמשים בכל הרמות האלה הוא שיתוף הפעולה והתקשורת בין הגורמים השונים, כך שביחד יצטבר גוף ידע רציני ומעודכן שכולם יוכלו להנות ממנו.
ולשאלה הגדולה – איך עושים את זה?
איך מכירים את המשתמשים באמת, לעומק, ובכל זאת שומרים על הרצון ליצור מוצר חדש, חדשני, מעולה? השוק מלא תאוריות, מתודות וכלים שאמורים לעזור לנו להכיר את המשתמשים.
המודל המרכזי בתחום מחקר משתמשים הוא עיצוב ממוקד משתמש, user centered design (UCD). מדובר במודל שעוגן בתקן ISO המתאר את תהליך העבודה באופן כללי, מבלי להיכנס לפרטים.
שלבי התהליך:
1. הגדרת הקונטקסט – זיהוי המשתמשים הפוטנציאלים, הגדרת מהות השימוש במוצר, ניתוח התנאים לשימוש במוצר.
2. הגדרת דרישות – המטרות של המשתמשים, הדרישות שלהם מהמוצר שצריכות להענות על מנת שהמוצר יהיה מוצלח.
3. עיצוב הפתרונות – שלב היכול להתבצע באופן הדרגתי מקונספט ראשוני ועד עיצוב מלא.
4. הערכת העיצוב – חלק המבוצע על ידי בדיקות שמישות עם משתמשים אמיתיים.
מקור – http://www.upassoc.org/usability_resources/about_usability/what_is_ucd.html
ארגון ה-UPA מגדיר את השלבים ביישום תהליך UCD גם ביחס לשלבי העבודה: שלב הניתוח הראשוני, שלב העיצוב, שלב הבניה, ושלב היישום. בכל אחד מהשלבים האלה חשוב כמובן לזכור את המשתמשים ולשים אותם במרכז (כשמו של המודל), אבל בכל אחד מהשלבים האלה אפשר וכדאי להשתמש בכלים שונים על מנת להבין את המשתמשים.
מאפיינים כלליים של כלי מחקר שונים
כלים איכותניים – כלים המתרכזים במספר קטן של משתמשים אותם לומדים ומתחקרים בצורה מעמיקה. כלים הנכנסים לקטגוריה הזו הם: ראיונות עומק, תצפיות קבוצות מיקוד ובדיקות שמישות. כלים אלו משמשים בעיקר בשלב הניתוח הראשוני של הצרכים, אך גם בשלב התכנון והעיצוב, ולעיתים גם בשלב הבניה וההטמעה נמצא להם מקום.
היתרונות של שימוש בכלים איכותניים הם רבים: כלים אלו מאפשרים הכרות מעמיקה עם המשתמש, והבנה טובה של קונטקסט השימוש במוצר. המידע המתקבל דרך שימוש בכלים אלה הוא מסוג המידע שלא ניתן לאיסוף סטטיסטי או כימות מספרי. הוא מאפשר להבין את המשתמשים ואת השימוש שלהם במוצר בדרכים חדשות שלא בהכרח חשבנו עליהם או צפינו אותם. הקשיים בשימוש בכלים איכותניים נעוצים בזמן הנדרש לעריכת מחקר ממצה, במציאת האוכלוסיה המתאימה להשתתפות בראיונות, בתצפיות או בקבוצות מיקוד .
יש לזכור כי המידע הנאסף בכלים איכותניים אינו בהכרח תקף מבחינה סטטיסטית בגלל כמות נבדקים קטנה. בחירת נבדקים אשר אינם משקפים את אוכלוסיית היעד שלנו עלולה לגרום לפיכך להטיה במסקנות המחקר. בהקשר זה חשוב להדגיש כי ניתן לבצע תהליך מחקר איכותני מהיר וקצר; תצפית על הדרך בה שניים, שלושה, או חמישה אנשים משתמשים במוצר, יכולה ללמד הרבה מאוד על האופן בו המוצר נתפס בעיני משתמשים (ואף לגלות 80% מבעיות השמישות במוצר-ראו לינק בסוף המאמר). כמות הנתונים שאפשר לאסוף בבדיקה מהירה כזו היא אמנם מוגבלת, אך זה לא מפחית מערך הבדיקה.
כלים כמותיים – כלים אלו אוספים מידע ממספר רב של משתמשים בעזרת טכניקות שונות. החל משאלונים/סקרים של משתמשים קיימים או פוטנציאלים, כלים סטטיסטיים ואנליטיים (כמו גוגל אנליטיקס), וכלים המשלבים סטטיסטיקה בניתוחי שמישות (כמו קליקטייל). כלים כאלה משמשים בדרך כלל בשלבים מתקדמים של פיתוח מוצר – שלב הפיתוח ושלב היישום, אך לעיתים גם בשלבי התכנון – ניתוח הצרכים והעיצוב.
למרות שיש צורך בהשקעה ראשונית בהקמה של מערך המחקר הכמותי, בהמשך הנתונים נאספים בצורה אוטומטית ורציפה לאורך זמן. באופן זה מאפשרים הכלים הכמותיים לבחון מגמות בשימוש במוצר (למשל – האם יש הבדלים בין אופן השימוש של משתמשים חדשים לעומת משתמשים חוזרים וכדומה). אופי השימוש בכלים הכמותיים ומספר הנבדקים הגדול מאפשר לנו מהימנות סטטיסטית גבוהה בתוצאות המחקר. יחד עם זאת, נתונים מספריים עשוים לתת רק אינדיקציה של "שורה תחתונה", ולהשאיר אותנו עם השאלה – למה?, בנוסף, כמו בכלים האיכותניים, צריך לדעת לשאול את השאלות הנכונות. קל מאוד להסחף ולהגיע לסוף הניסוי עם הרבה מאוד נתונים, אך מבלי באמת להבין יותר טוב את המשתמשים.
כלים היברידיים – השימוש באינטרנט מאפשר לעשות שימוש בכלים "היברידיים". אלו הם כלים המבוססים על פורמט איכותני (כמו למשל תצפיות על משתמשים), האוספים מידע בצורה פחות או יותר אוטומטית (לדוגמה, אתרים שמקליטים משתמשים בזמן שהם משתמשים במוצר, ומעבירים סרטון עם צילום המסך וההערות של המשתמש). כלים אלו זולים יחסית כך שאפשר להשתמש בהם למספר גדול של משתמשים במחיר סביר, ולאסוף מידע רב בזמן קצר. אפשרות זאת היא מפתה ביותר אך אינה חפה מבעיות. הכלים ההיברידיים אינם זולים מספיק בשביל לבדוק עשרות ומאות משתמשים כדי להגיע למהמינות סטטיסטית, ומצד שני אינם מספקים את כל הערך המוסף של ראיון או קבוצת מיקוד המאפשרים הבנה של אלמנטים רבים מעבר לשימוש במוצר עצמו.
מגבלות כלליות
כשעוסקים בהכרות עם משתמשים ובכלי מדידה של שמישות, חשוב להבין שאין פתרונות קסם. אין כלי אחד שיכול להגיד לנו בדיוק מה עובד ומה לא עובד, ולהוביל את הפיתוח והעיצוב של המוצר. הכלים, כשמם כן הם – כלים, ואנחנו אנשי המקצוע צריכים לדעת להשתמש בהם בצורה מושכלת, ולהסיק את המסקנות הנכונות. בכל כלי יש יתרונות וחסרונות יחודיים לו, אבל בשימוש בכלים כאלה יש כמה טעויות קלאסיות שצריך להזהר מהן:
1. בחירת הכלי – מעבר לחשיבות של בחירת הכלי המתאים לכל שלב בפיתוח המוצר, חשוב גם לבחור כלי שמתאים לצרכים שלנו, שיהיה לנו נח וקל להשתמש בו, ושנהיה בטוחים שהוא בנוי בצורה טובה. כך למשל כשבוחרים כלים אוטומטיים שמודדים שימוש צריך לוודא שיש להם ממשק שנוכל לקבל ממנו את התוצאות שאנחנו באמת צריכים, צריך לוודא שהכלי לא מתנגש או שובר משהו במוצר שלנו כשמתקינים אותו, ושהוא לא מציק או מפריע למשתמשים. חשוב להבין את המגבלות של הכלי, ולוודא שאנחנו לא מצפים ממנו למשהו שהוא לא מסוגל לספק.
2. מקצועיות הכלי והשימוש בו – להעביר ראיונות עומק, לעשות תצפיות, להעביר קבוצת מיקוד, אלה מטלות מורכבות, וחשוב לעשות אותם נכון, אחרת אנחנו עלולים לסכן את התוקף והמהימנות של התוצאות. נכון, אפשר ללמוד הרבה גם פשוט מלדבר עם משתמשים ולשאול אותם מה אהבו ומה לא אהבו, אבל אם רוצים לעשות תהליך מסודר של ראיונות צריך לוודא שיודעים איך לעשות אותו. דוגמא קטנטונת – ניסוח לא נכון של השאלות בראיון יכול להוביל את המשתמשים לתת לנו את התשובות שהם חושבים שאנחנו מצפים להם, במקום את התשובות האמיתיות שלהם, וכל זה בלי שהם מודעים לכך. גם במבחנים כמותיים צריך לדעת לשאול את השאלות הנכונות ולוודא שהכלי בנוי בצורה הנכונה בכדי לאסוף את הנתונים, כך שבסופו של דבר גם נוכל להגיע לתשובות בעלות משמעות.
3. מקצועיות בפענוח הנתונים והסקת המסקנות – אמר לי פעם מנהל של מסד נתונים ענק של אחת החברות הגדולות במשק – "השקענו מיליונים בבניית ה-Data warehouse, אבל למצוא אנליסטים טובים זה הרבה הרבה יותר יקר". להיות מסוגל להסתכל על הנתונים ולהסיק מהם את המסקנות הנכונות זה אחד האתגרים הגדולים של הכלים האלה. בהרבה מקרים מתקבלות הרבה תוצאות, חלקן סותרות זו את זו, חלקן מסיטות אותנו מהשאלה שבעצם רצינו לשאול, ואנחנו, כאנשי מקצוע, צריכים להבין מתי התוצאות מורכבות מפני שהשוק מורכב והמשתמשים מורכבים וצריך אולי לפתח פתרונות שונים למשתמשים שונים, ומתי לא שאלנו את השאלה נכון, או לא את השאלה הנכונה, וצריך להמשיך לחקור כדי להגיע לתשובות הנכונות.
קריאה נוספת:
Jacob Neilsen: Why you only need to test with 5 users
תודה רבה על הכתבה המעניינית! אני לצערי אצטרך להסכים עם החלק הראשון באופן תאורטי כולם יודעים כמה זה חשוב להכיר את המשתמש ואת הצרכים שלו אבל בפועל יוצא לי לראות חברות אפילו כאלה שמתימרות להציג את עצמן כידידותיות למשתמש רצות אחרי מגבלות הזמן והרצון לשחרר את המוצר כמה שיותר מהר גם אם לא בוצע הכרות מסודרת ומעמיקה עם המשתמשים אלא רק איסוף דרישות בסיסי.