כיצד להסביר להורים מה זו חוויית משתמש

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

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

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

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

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

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

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

---

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

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

שלב הבנת הבעיה יכלול בדרך-כלל מחקרי שוק, מחקרי משתמשים מקדימים (formative research) וניתוח מקיף של המשתמשים המרכזיים והמשניים. מתודות כמו ניתוחי תפקיד ופעולה (task-analysis), ניתוחי סביבה, מפות מסע, פרסונות ושאר ירקות יקרו בשלב זה. חברות ומוצרים עם תפיסה uxית חזקה, מבצעים את כל התהליכים דנן במהלך השלבים הראשונים של פיתוח המוצר. כך הם יוצרים בסיס חזק לכלל ההחלטות שיילקחו בהמשך. ישנם מוצרים רבים שבוחרים לבצע מחקרונים מקדימים בתחילת כל ספרינט או רבעון, אך אלו, לרוב, אינם עמוקים דיים. תהליך בניית הפרסונה, למשל, אינו עניין של מה בכך. פרסונות, כפי שהציג ד"ר עופר מונר במאמר החשוב הזה, הן הרבה יותר מפרסונות. הן אנשים. הן הדרך שלנו המאפיינים להבין את המשתמשים טוב יותר ולעצב עבורם חוויית שימוש מדויקת יותר. הן הדרך שלנו לגרום לצוות לייצר אמפתיה עבור אותן קוואזי-משתמשים. בשונה מסגמנטציות (segmentations), פרסונות נועדו להביא לידי ביטוי את האופי האמיתי של המשתמשים, לא רק את המאפיינים הברורים שלהם כמו גיל, מיקום בעולם ורמת היכולת הטכנולוגית שלהם. האופי האמיתי, כלומר הצרכים, המטרות, המוטיבציות, נקודות הכאב וכל מה שהופך אותנו לאנושיים.

בשלב התיעדוף, בדרך-כלל, נשב עם אנשי מוצר ועם בעלי העניין (stakeholders), כדי שיעזרו לנו להבין את חשיבות אותו תיקון (=פיתרון), עלותו וזמינות שאר אנשי הצוות ליישומו, תוך שהם מסתמכים על ה- roadmap של המוצר ("תוכנית החומש" או ה- vision של המוצר בעיני מנהלת המוצר). שיטה מעניינת ויעילה להניע ישיבות שכאלו היא LUMA (ראשי תיבות: Looking, Understanding, Making). לומה היא מתודולוגיה שנועדה להפוך את מחקר המשתמשים, תהליך הרודמאפינג, או הבריינסטורמינג, ליעילים יותר בכך שהם מקבלים משמעות גדולה יותר ונעשים כחלק מתכנית מחקר ענפה יותר הכוללת כמה מתודות אחת אחרי השנייה. Autodesk אימצה את המתודולוגיה של LUMA ברמה, ככל שידוע לי, הגבוהה ביותר בשוק ההייטק ומשתמשת בשיטותיה (כמעט) בכל הישיבות שנעשות (בכל הדרגים). אגב, אין לי מניות ב- LUMA, ואני לא מנסה לומר שהיא טובה יותר ממתודולוגיית עיצוב-מוכוון-משתמשים (UCD) אחרת, אבל אני חושב שלאלו מאיתנו שמרגישים שהישיבות או הדיונים לא ממש ממוקדים או מובילים לתוצאה הרצויה, LUMA מספקת פתרון נהדר.

התהליך בשלב הפתרונות משתנה בין חברה לחברה ובין מוצר למוצר, וכולל בדרך-כלל איטרציות רבות של ניסוי וטעייה (או בעצם ניסוי ותהייה). לאור המחקר הענף שנעשה עד כה, המאפיינת מגיעה לשלב זה כשהיא מבינה לעומק את הגורם לבעיה, כלומר את מה ש: (1) חסר למשתמשים כדי להשלים את שטף הפעולות השלם שלהם בהצלחה, או (2) הגורם שמוביל את המשתמשים לתסכול משום שהוא לא אפוי עד הסוף. היא יודעת זאת, למשל, משום שניתוח התפקיד של המשתמש העיקרי של הפלטפורמה העלה שעליו לבצע פעולה מסוימת (כמו העברת הודעת אישור על ביצוע פעולה מסוימת לגורם האחראי) אולם ניתוח המשימות שלו מראה שאו שהפעולה הזו לוקחת זמן רב מדי ובכך מעכבת את כל שטף הפעולות, או שהיא נעשית בצורה שכוללת הרבה-יותר-מדי שלבים ובכך מעכבת את שטף הפעולות. אנקדוטה חשובה, אגב, היא שיש להבחין בין פעילות-activity, לפעולה/מטלה-task. קחו את הדוגמה של רכיבה על אופניים למשל. זוהי פעילות (activity). הפעולות (tasks) שמרכיבות את הפעילות הזו הן החזקת הכידון, דיווש ושמירה על שיווי משקל. כשאנחנו מבצעים ניתוח פעולות או משימות, הפעילות (רכיבה על אופניים) תהווה את היעד שאנחנו חותרים אליו ולשמה נבצע את כל הפעולות (דיווש, שמירה על שיווי משקל).

משהבינה את הגורם לבעיה, תנסה המאפיינת למצוא פתרונות טובים יותר מהקיים. כל פתרון יעוצב ברמה מינימלית תוך שהוא מספר את הסיפור של המשתמש ומציג כיצד הפתרון החדש פותר את הבעיה הקיימת. לעיצובים הללו קוראים Wireframes. לאופן הצגתם בצורה הסיפורית שמתארת את הפתרון קוראים Storyboard. חשוב להגיד - שני אלו אינם ייחודיים לחוויית משתמש (אבל ממש לא). בהנחה ופתרון מסוים יעבור את שלב ההכרעה מול שאר הפתרונות, תידרש המאפיינת, יחד עם המעצבת, לעצב Mockup שהוא Wireframe ברמה עיצובית גבוהה (high fidelity) תוך שהיא משתמשת בשפה העיצובית של המוצר (אם קיימת). אבל לפני כן, על המאפיינת להוכיח שהפתרון הזה טוב יותר מהאחרים. איך? על ידי ניסוי וטעייה כאמור. כל פתרון ייבחן מול משתמשים או משתמשים פוטנציאליים (המייצגים את הפרסונות) ויתחרה מול הפתרונות האחרים על הישגים טובים יותר במדדי ההצלחה שהוגדרו מראש כמשתנים התלויים של הניסוי הספציפי הזה. המשתנים הבלתי תלויים, כמובן, הם ההבדלים בין העיצובים (הפתרונות) השונים. הפתרונות יכולים להיבחן כ- Wireframes, כ- Mockups או כ, השם ישמור, Prototypes. פרוטוטייפים, או בשפת הקודש: אֲבוֹת-טִיפוּס (כולם רואים שאין דגש ב- פ', נכון? היקום קורס לתוך עצמו) הם גרסה "עובדת" של הפתרון שלכם. אני כותב "עובדת" משום שרמת הגימור של הפרוטוטייפ היא שתקבע כיצד יעבוד אותו אב-טיפוס (מי קרא/ה את זה עכשיו עם פ' לא דגושה? אה, אף אחד? מעניין..). במידה ומדובר על רמת גימור גבוהה מאוד, קרי עיצוב ופיתוח של הפתרון והטמעתו בגרסא צדדית של המוצר לצורך המחקר, הגזמתם. אלא אם כן אתם פייסבוק. ואז אתם גם עושים את זה וגם נשאר לכם כמה דקות לשמוקוצ'ינו לפני החוג ג'ודו בקומה ה- 25 של רוטשילד 22. אם אתם מוצר רגיל, אתם בדרך-כלל תבחרו לבחון גרסה מעוצבת-אך-לא-מפותחת (#meetoo) במבחני שמישות (Usability Testing) ישירים או באמצעות פלטפורמות לבדיקת שמישות אינטרנטית שבלי שישלמו חסות לבלוג לא אזכיר את שמן. אבל לינק זה בסדר. ועוד אחד. ואחרון. חביב.

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

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

חברות גדולות, כמו פייסבוק למשל, יכולות להרשות לעצמן לבחון הרבה מאוד פתרונות בזמן קצר יחסית (משום שמספר המשתמשים כה גבוה) ולכן ייתכן שראיתם את הממשק הפייסבוקי שלכם משתנה תכופות. הבעיה בסגנון עבודה שכזה היא שהרצון לשפר מדדים "פייסבוקיים" כמו צפייה בהתראות (notifications) או שימוש בפיצ'ר חדש כמו ה- Marketplace, משפיעה על המשתמשים בצורה שלא תמיד עולה בקנה אחד עם הצרכים שלהם, מה שעלול ליצור תסכול ונטישה. באוקטובר 2017, גילה לוק רובלסקי (Luke Wrobelsky) שישנן 66 גרסאות שונות של ממשק הפייסבוק, לאחר שהזמין אנשים לשלוח לו את תמונת המסך שלהם באפליקציה. 66 גרסאות! זה פי 3 אותיות לבחון ממה שהא'-ב' מאפשר!

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

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

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

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

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

אני הופך אנשים לטובים יותר.

(ההקדמה למאמר הזה מבוססת על ההקדמה של ג’סי ג’יימס גארת’ לספרו The Elements Of UX)