*** תודה גדולה לרעות מלובני, לאמיר גבירץ ולסתיו מורן לשם על העזרה ועל ההערות המצוינות.
כשאני ניגשת לכתוב מיקרו-קופי למוצר דיגיטלי חדש, אני עושה מחקר על הנושא, שומעת או קוראת את כל מה שיש למשתמשים להגיד בעניין, יודעת באילו מילים הם משתמשים (ולכן באילו מילים אני אשתמש), לומדת היטב את המטרות של בעלי המוצר ומה הם רוצים להשיג באמצעותו, וכמובן מכירה כל כפתור ושדה ומילה שמופיעים בו.
אני ניגשת לכתיבה אחרי הכנה מדוקדקת, כדי שהבחירות שלי במילים ובניסוחים יהיו הכי מדויקות שאפשר וישרתו היטב את המשתמשים והמשתמשות.
אז למה כדאי לעשות גם בדיקות שמישות אחרי הכתיבה?
כי עדיין, אני תמיד תוהה איך משתמשים יקראו את זה:
הם יבינו?
זה ברור מספיק?
אולי עדיף לשים את המילה הנרדפת?
זה סלנגי מדי? זה רציני מדי?
הם יבינו מה מסתתר מאחורי השם שנתתי לקטגוריה?
ההסבר בטולטיפ מספיק או שקיצרתי אותו יותר מדי?
ומה אם פספסתי איזה יוז-קייס, איזה מסך, איזו אפשרות לא צפויה?
לא משנה כמה מחקר אשקיע לפני הכתיבה, עדיין חלק ממנה יהיה מבוסס, תמיד, על ניסיון העבר שלי, על ניחושים מושכלים ואפילו על אינטואיציה. ככה זה, וזה בסדר גמור. כל מוצר דיגיטלי הוא עולם חדש לגמרי שצריך לגלות.
בסופו של דבר גיליתי שהדרך היחידה לקבל יותר ודאות היא בבדיקות שמישות, אחרי שהמיקרו-קופי כבר משולב במוצר (או בפיילוט או ב-MVP כמובן).
במילים אחרות:
נדע אם בחרנו את המילים הנכונות רק אחרי שנראה באמת, בשטח, משתמשים ומשתמשות אמיתיים שמתמודדים עם המיקרו-קופי שכתבנו.
ולזה בדיוק נועדו בדיקות שמישות.
את בדיקות השמישות עושים בדרך כלל כדי לבדוק את ה-UX ואת ה-UI. בבדיקות מבקשים ממשתמשים לבצע משימות במוצר שלנו וצופים בהם כשהם מנסים להשלים אותן, בעיקר כדי לזהות את המקומות שלא עובדים כמתוכנן. יש אסכולה שאומרת שכדאי לבקש מהמשתמשים לספר תוך כדי הבדיקה מה הם מנסים לעשות, מה הם מצפים שיקרה וכו', כדי שנבין את הסיבות לבחירות שלהם, ויש אסכולה שאומרת שהדיבור מטה את אופן השימוש שלהם ולכן צריך רק לצפות בשקט. לצרכים שלנו ככותבים וככותבות נעדיף כמובן שהמשתמשים ידברו, ובהמשך נראה דוגמאות רבות איך זה עוזר לנו.
איך עושים בדיקות שמישות? בדיקות שמישות אפשר לעשות במעבדת שמישות ייעודית (יש כאלה עם חלון-מראה למשל, כדי שנוכל לצפות במשתמשים בלי שהנוכחות שלנו תשפיע עליהם, או עם מצלמות שמכוונות למסך או לתנועת האצבע וכו'), אבל אפשר גם לעשות אותן במשרד רגיל, בפלטפורמות מיוחדות (כמו www.usertesting.com), בזום ואפילו ברחוב, עם משתמשים אקראיים. זה תלוי באמצעים שיש לכם ובמוצר.
כדי ללמוד איך עושים בדיקות שמישות כדאי לקרוא במקורות נוספים, למשל כאן, כי הפוסט הזה מתמקד יותר במה שאפשר ללמוד מהן, ופחות בפרוצדורה.
רגע, למה לא לעשות (רק) איי-בי טסטינג?
כי לבדיקות שמישות לא צריך שום דבר חוץ ממשתמשים. אפילו לא מעבדת שמישות. נכון, עדיף שתהיה, אבל גם מבדיקות שמישות הכי פשוטות שיש – מה שנקרא בדיקות גרילה – אפשר ללמוד המון. המון!
אי אפשר לעשות איי-בי טסטינג על כל כותרת, כפתור וטולטיפ במוצר, ואילו בדיקות שמישות מגלות מידע על הרבה מאוד רכיבים שלו בבת אחת.
איי-בי טסטינג (ומפות חום, שזה סוג של בדיקות שמישות מרחוק ובלי לתקשר עם משתמשים) יגידו לנו אם משתמשים לחצו או לא, הבחינו או לא, השתמשו או לא – אבל לא נוכל לדעת למה: איזו מילה גרמה לבלבול, איזה ניסוח היה יכול לעשות יותר סדר. בבדיקות שמישות שבהן שומעים את המשתמשים כשהם מתלבטים, חושבים, מתבלבלים, מבינים – אנחנו יכולים ללמוד הרבה יותר על המיקרו-קופי שכתבנו (או שלא כתבנו וחבל).
לפני התכלס, שלוש המלצות
1. תהיו נוכחים בעצמכם בבדיקות
אם יש לכם אפשרות תקציבית להריץ בדיקות שמישות מיוחדות למיקרו-קופי, בנפרד מה-UX, זה כמובן אידיאלי, אבל זה בדרך כלל לא המצב... על פי רוב, יש תקציב לסט אחד בלבד של בדיקות, במקרה הטוב, והוא יהיה ל-UX (בהמשך אכתוב מה לעשות אם אין בכלל תקציב או זמן לבדיקות).
בכל מקרה, כדאי להגיד בעוד מועד לצוותי ה-UX והמוצר שכאשר יתקיימו בדיקות השמישות – אתם רוצים להיות שם לכל אורך הדרך. לא תמיד זה זורם. לפעמים כדאי לתזכר אותם בעניין, ואז גם להתעקש, ומדי פעם להגיד באגביות "כדאי שנבדוק את הקופי הזה בבדיקות השמישות", ובקיצור: לעשות כל מאמץ כדי להיות שם. אם הבדיקות נעשות מרחוק בזום – אפשר לקבל הקלטות (וחשוב לוודא שאכן מקליטים).
לא כדאי לבקש מצוותי המוצר וה-UX שישימו לב במקומכם לשפה, כי הם עסוקים מדי – ובצדק – במוצר עצמו, לא במילים. למשל, הם יבחינו שמשתמשים לא מצליחים להשתמש בפקד מסוים, אבל לא בטוח שהם יחלצו מדברי המשתמשים את המילה הבעייתית או החסרה - וזו בדיוק המילה שאנחנו רוצים לשים עליה את האצבע.
וזה נכון גם מהצד שלנו: בבדיקות יעלו המון ממצאים שקשורים למוצר עצמו ולא למיקרו-קופי, שהם אומנם מעניינים מאוד, אבל לא באחריותנו, ואנחנו רשאים לסמוך על הצוותים האחרים ולהתמקד במילים.
וזה בדיוק מה שאעשה בפוסט הזה:
אתמקד רק במה שאפשר ללמוד מבדיקות שמישות על המיקרו-קופי, על השפה ועל בחירת המילים והניסוחים.
אכתוב כאן על דברים שלמדתי מבדיקות שמישות של מוצר מסוים, אבל הדברים נכונים ממש לכל מוצר.
2. התערבו בבחירת הנבדקים ובתסריט
המתכננים של בדיקות השמישות, שיהיו בדרך כלל צוותי המוצר וה-UX, יקפידו על פי רוב שיהיו נבדקים ונבדקות מגוונים על פי דמוגרפיה: מגדר, גיל, פיזור גאוגרפי וכו'.
אנחנו צריכים לשים לב שיש גם נבדקים מגוונים מבחינת תפיסת השפה. למשל, מאחר שאני כותבת בשפת האם שלי, עברית, אני מבקשת שידאגו לנבדקים ששפת אימם אחרת, בעיקר ערבים וערביות, עולים ועולות. ומאחר שאני בשנות ה-40 שלי, אני מבקשת שיהיו גם נבדקים מעל גיל 65 או טינאייג'רים, שחווים בדרך אחרת את המוצר ואת האופן שבו הוא מדבר אליהם.
לגבי התסריט: לבדיקות שמישות יש תסריט, כלומר סט מוכן של תרחישים ושאלות ששואלים את הנבדקים לפני, תוך כדי ואחרי שהם משתמשים במוצר. כדאי להיות מעורבים בבחירת התרחישים ולהכניס לתסריט גם שאלות על מיקרו-קופי שאנחנו מתלבטים לגביו. למשל:
מה יקרה לדעתך כשתלחצי על הכפתור הזה?
או: לאן תגיע לדעתך אם תלחץ על הכותרת הזאת?
או: מה הבנת מזה?
או: מה לדעתך ההבדל בין שתי הקטגוריות?
3. אם לא עושים אצלכם בדיקות – תעשו לבד, זה קל
גם בדיקות גרילה (כאלה שעושים במינימום תכנון ומשאבים) גילו לי מידע חשוב מאוד, וזה ממש פשוט להוציא אותן לפועל.
זה כל מה שצריך לעשות:
קבעו עם 5 אנשים מגוונים ככל האפשר פגישת זום. צריך בין חצי שעה לשעה לכל אחד ואחת, כדאי גם להשאיר לפחות רבע שעה ביניהם.
בקשו מהם לפתוח את המוצר אצלם במחשב (או במובייל) ולשתף מסך.
תנו להם כמה משימות לביצוע במוצר. כדאי לבקש את המשימות המרכזיות או את אלה שאתם הכי פחות בטוחים לגביהן.
בקשו מהם לתאר את מה שהם רואים ועושים (ואם הם לא כל כך מדברים - תשאלו מדי פעם).
שאלו על ניסוחים ספציפיים שאתם לא בטוחים לגביהם, כמו שפירטתי למעלה לגבי התסריט.
הקליטו הכל, כדי שתוכלו להתרכז בבדיקה בזמן אמת ולהאזין לה אחר כך ביתר תשומת לב כדי לקלוט דיוקים ולכתוב ניסוחים.
נכון, יש דרכים טובות ויעילות יותר לעשות בדיקות שמישות, אבל גם מבדיקות כאלה תפיקו ים של ערך באפס תקציב וביום-יומיים של עבודה.
אז איך בדיקות שמישות יכולות לעזור לנו לשפר את המיקרו-קופי?
1. בדיקות שמישות יגידו לנו חד-משמעית אם מה שכתבנו ברור מספיק או לא ברור בכלל
האם הניסוח הסופי שלנו – שהגענו אליו אחרי שהזזנו, הוספנו, ערכנו, קיצרנו ושמענו עוד 17 דעות – האם בסופו של דבר הניסוח הזה ברור מספיק?
ככל שהמוצר או הפיצ'ר מורכבים יותר, כך השאלה הזאת תהיה נוכחת יותר ותעלה יותר פעמים ברחבי המוצר. זה בלתי נמנע, לגמרי חלק מהעבודה, ורק בדיקות שמישות יכולות לענות עליה.
דוגמה א
בגלל מורכבות הנתונים מחד והמחויבות המשפטית מאידך, נאלצנו לפעמים לכתוב הנחיות סופר-מורכבות. ההנחיות האלה היו אמורות: 1) להסביר את הנתון; 2) לסייג אותו; 3) להנחות לפעולה מתאימה, וכמובן, 4) להיות קצרות. אחרי ניסוחים רבים הגעתי לניסוח שקיוויתי שהוא טוב וברור, או לפחות שמי שיקרא אותו בעיון יבין.
בבדיקות השמישות ראינו חד-משמעית שמשתמשים לא מבינים אותו, ולכן לא משתמשים נכון בפקדים הרלוונטיים. הטעות שלי הייתה שניסחתי את ההנחיות בצורה מדויקת מדי, וזה דווקא סיבך את המשתמשים במקום לעזור להם. התיקון הוא לנסח את ההנחיות מעיני המשתמשים. למשל, במקום לכתוב: 'הראו לי רק נתונים שעשויים להתאים ל-X' (שמבחינה מקצועית זה הכי מדויק), כתבתי עכשיו רק: 'מעניין אותי x'.
למעשה, זה היה פספוס שלי כבר בשלב הכתיבה (מה יותר בייסיק מלכתוב מעיני המשתמשים?), ורק בדיקות השמישות הציפו לי אותו. בדיקות שמישות הן שיעור גדול בצניעות, וכדאי לקחת אותו בשתי ידיים.
דוגמה ב באחד המסכים היה לנו טולטיפ קצת מורכב, וראינו שמשתמשים מתייאשים ומפסיקים לקרוא אותו אחרי המשפט הראשון. אילו היו ממשיכים לקרוא, היו מקבלים תשובה, אבל הם פשוט סגרו אותו ונשארו ללא מענה. בעקבות זאת, ההמלצה שלי הייתה לשנות את סדר הדברים ולהעלות לתחילת הטולטיפ את השורה התחתונה שלו. יש מקרים שצריך לתת קצת הקשר לפני שמגיעים לשורה התחתונה, ויש מקרים שבהם השורה התחתונה צריכה להיות ראשונה – ורק בדיקות שמישות יכולות להגיד לנו מה נכון במקרה המסוים שלנו. דוגמה ג
לפעמים משתמשים מפספסים הסבר חשוב שנראה לנו, כמעצבים או ככותבים, שאף אחד או אחת לא יוכלו לפספס אותו לעולם. והינה, ברוך השם, בדיקות השמישות מגלות שאף אחד לא קורא אותו. יותר מזה, הן מגלות שאף אחד בכלל לא מוצא אותו, אפילו כשהוא ממש ממש מחפש. קרה לי יותר מפעם אחת וגם יותר מפעמיים. הפתרונות יכולים להיות ויזואליים (כמו להגדיל את הפונט) או טקסטואליים (כמו להוסיף את המידע החשוב בתוך אלמנט אחר שאותו כן קוראים).
2. בדיקות שמישות יחשפו בעיות שבכלל לא חשבנו עליהן
יש מקומות שאין לנו שום התלבטות לגביהם. הם נראים פשוטים וחד-משמעיים ואנחנו מרגישים שהגענו לניסוח מצוין.
ואז, בבדיקות השמישות, הפתעה!
דוגמה א
המילה 'טווח' שהופיעה בהנחיה מעל סליידר גרמה למשתמשים להשתמש בו לא נכון. חלק מהמשתמשים ממש אמרו את זה במפורש: "היה כתוב 'טווח' אז חשבתי ש...". דוגמה ב
במוצר שיש בו המון נתונים סטטיסטיים, השימוש במילה 'ממוצע' בכמה וכמה מקומות גרמה למשתמשים להשוות בין ממוצעים לא רלוונטיים זה לזה. המסקנה הייתה שבכל פעם שמופיעה המילה 'ממוצע' יש לדייק אותה במילה נוספת, גם אם זה מאריך או מסרבל. למשל: ממוצע במשק, ממוצע בתחום, ממוצע שנתי וכו'. במקומות שאפשר, כדאי אפילו להוריד אותה לגמרי. דוגמה ג
בדרופ-דאון נתנו אפשרות ראשונה, ברירת מחדל, של 'כל האפשרויות', כלומר שלא חייבים לבחור כלום ואפשר להשאיר ככה. הסיבה הייתה שידענו שיהיו משתמשים שעוד לא קיבלו החלטה בעניין הזה וירצו להשאיר את כל האפשרויות פתוחות. בבדיקות השמישות ראינו שוב ושוב שגם משתמשים שעוד לא קיבלו החלטה הרגישו שהם צריכים לבחור. הם לא הבינו את אפשרות ברירת המחדל.
זה היה סופר-מפתיע מבחינתי, כי זה נשמע לי ניסוח סטנדרטי לגמרי בשימוש סטנדרטי לגמרי, אבל בדיוק בשביל זה עשינו בדיקות שמישות, אז שינינו את אפשרות ברירת המחדל, ועכשיו כתוב שם 'עוד לא החלטתי'.
דוגמה ד
באתר יש סט של מסננים שבו המשתמשים מסמנים את ההעדפות האישיות שלהם ובסופו מופיעות תוצאות. לכן הכותרת שנתנו הייתה: 'תוצאות שמתאימות להעדפות שלך'.
אבל בבדיקות השמישות גיליתי שני דברים שלא ידעתי קודם לכן: ראשית, הכותרת מופיעה גם מעל לתוצאות של החיפוש החופשי, שאין בו בכלל סימון העדפות. שנית, בגלל מגבלה טכנית בטיוב התוצאות, יכול להיווצר מצב שבו התוצאות הראשונות יתאימו במידה חלקית מאוד.
כך או כך, ההבטחה ל'תוצאות שמתאימות להעדפות שלך' לא תמיד יושבת בול, ורק בדיקות השמישות חשפו את המקרים האלה. ההמלצה הייתה כמובן לשנות לכותרת בסיסית שתתאים לכל המקרים: 'נמצאו X תוצאות'.
3. בדיקות שמישות יציפו את המילים הנכונות
דוגמה א
הייתה כותרת אחת שבכל פעם שמשתמשים הסבירו מה היא אומרת – צחקתי מאוד (אל דאגה, הם לא ראו, זה היה בהקלטות זום).
כדי לתאר את הנתונים שהם רואים, כולם כולם בחרו את אותה המילה בדיוק, והיא ממש לא הייתה המילה שאני בחרתי.
זה היה ברור: צריך להחליף אותה, והיה ברור גם לאיזו מילה צריך להחליף אותה. קל!
דוגמה ב
במקום אחר סיווגנו פריטים לכמה קטגוריות ונתנו לקטגוריות שמות. המשתמשים לא הצליחו להבין מה ההבדל ביניהן והשתמשו במילים אחרות כדי להסביר אותן. רשמנו לנו לשבת על זה כצוות ולבדוק אם אפשר בכלל לשנות את הסיווגים ואת ההגדרות כך שיעבדו גם בשפה המקצועית וגם בשפת המשתמשים.
לא כל דבר שמגלים בבדיקת שמישות אפשר מייד לתקן. לפעמים יש מגבלות מקצועיות ואחרות. אבל לפחות אנחנו יודעים שיש כאן בעיה ושהדברים לא עובדים כמו שקיווינו. עכשיו נשאר למצוא פתרון.
4. בבדיקות שמישות נגלה איך משתמשים מתארים את האתר, לטוב ולרע
כדי לתאר בעמוד הבית מה בדיוק עושה המוצר ומה הערך שלו – חיפשנו את המילים הכי טובות והגענו לתוצאה שהיינו מרוצים ממנה. אבל אין כמו לשמוע את המשתמשים ולהבין ישירות מהם מה חשוב להם ואיך הם אומרים את זה.
שני דברים היו מאוד ברורים:
האחד, שמשתמשים ממש נהנים מהמוצר.
הם אמרו: "היה כיף לשחק עם המספרים" "אני הולכת עכשיו להמשיך לחפור בו, זה כיף" "כיף לראות את זה" "כיף לחפש ככה" וזה היה מפתיע. אומנם ידענו שהמוצר מצוין, וידענו שהוא יסקרן משתמשים, אבל לא תיארנו בשום שלב כ-כיף, עד שהמשתמשים אמרו את זה. אני גם לא בטוחה אם ואיך נשתמש במידע החדש, אבל זה בהחלט מעניין וגם משנה קצת את האווירה.
הדבר השני שבלט היה שכולם התייחסו למהירות: "תקתקתי את זה, ישר מצאתי" "אין מה להתבלבל. זה צ'יק-צ'ק לחפש" "אתה ישר מוצא את מה שחיפשת" "היה קל למצוא מה שאני רוצה"
"צ'יק-צ'ק, ממש קליל" תיק-תק, צ'יק-צ'ק, קל – יהיה מעניין לנסות לשלב אותם בטקסטים של האתר ולראות מה קורה.
5. בדיקות שמישות מראות איפה עשינו עבודה טובה
בדיקות שמישות יכולות בקלות לבאס אותנו, כי הן מפנות זרקור למקומות שפספסנו, אבל סביר להניח שלרוב המיקרו-קופי שכתבנו כנראה לא תהיה התייחסות בבדיקות השמישות. משתמשים פשוט יקראו אותו ולא יעצרו, ובדרך כלל זה סימן טוב.
דוגמה א
כשמשתמשים שואלים שאלה בקול רם וניגשים לקבל תשובה בטולטיפ – הלב שלי נעצר לשנייה. האם הוא יענה בדיוק לשאלה שלהם? האם הוא יהיה ברור בקריאה אחת, ראשונה ורצופה? האם הם יבינו בדיוק את מה שרציתי שיבינו?
ואז, כשהם קוראים אותו, מבינים מייד ועושים בעקבותיו את הבחירה הנכונה בלי לעצור לרגע – אני נושמת לרווחה. איזה סיפוק זה.
דוגמה ב
כשמשתמשים קוראים כותרת בקול וממש שומעים שהיא מדויקת, שהיא יושבת להם בול, שהם מבינים בדיוק מה הם עומדים לראות עכשיו – אז אני יכולה לסמן לי שם וי גדול.
דוגמה ג
בגלל מגבלות המגדר בעברית, אחרי התלבטויות וניסיונות רבים החלטתי שההנעה הראשית לפעולה תהיה בגוף שני יחיד, את/ה, ובלי מגדר כמובן, ואילו שורת ההנחיות שאחריה יהיו בגוף שני רבים (בחרו, לחצו, גררו, תרצו, ולא יש לבחור, יש ללחוץ וכו'). למרות חוסר האחידות, זו הייתה הדרך האופטימלית בעיניי להניע לפעולה מצד אחד, ולהבטיח שההנחיות הרבות יהיו ישירות ופשוטות, מצד שני. חשוב להגיד שאילו היו שם רק הנחיה אחת או שתיים, ברור שהייתי מעדיפה לנסח בגוף שני בלי מגדר, אבל כשיש הרבה הנחיות, וכשהן ממילא מורכבות, אני מעדיפה לעבור לציווי ברבים. בכל מקרה, תהיתי אם משתמשים יבחינו בזה ואם זה יבלבל אותם באיזושהי דרך, אבל זה עבר חלק. אם היו לזה השפעות שליליות – הן היו ברובד לא נצפה, שאולי צריך לתכנן מבדק אחר כדי לגלות אותו.
אז אל תשכחו לשים לב גם למקומות האלה, שבהם הכל מתקתק כמו שציפינו, כי בדיקות שמישות לא נועדו רק לחשוף את מה שלא עובד, אלא גם לאשש את ההשערות שלנו ולהזכיר שאנחנו בסך הכל ממש בסדר.
Comments