דוח רווח והפסד

A slightly abridged English-language version of this article can be found on Medium.

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

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

רוב ההתלבטויות נובעות מהעובדה שכמעט לכל החלטה ממשקית שתתקבל יהיו גם יתרונות וגם חסרונות, ויש לשקול את הראשונים כנגד השניים (הפוך זה גם בסדר). אחת הדוגמאות הקלאסיות והבולטות ביותר היא חוק היק (Hick's Law), שאמור לספק מענה ראשוני לשאלה הקלאסית גם היא "יש פה עוד מקום על המסך, למה שלא נתקע שם את הכפתור שלי?". בתשובה לתהייה התמימה הזו, החוק אומר שככל שמספר אפשרויות הבחירה גדל, הזמן עד לביצוע הבחירה גדל גם הוא. המענה השניוני הוא, אגב, המושג הגאוני analysis paralysis, שמרמז שלא רק שהזמן הזה גדל, אלא יש מצב טוב שלא נבצע את הבחירה כלל אלא נהיה כלואים בהתלבטויות עד שנצא להפסקת צהריים.

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

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

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

לאחר שלוחצים על הכפתור, מופיע הדיאלוג הבא:

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

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

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

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

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

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

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

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

אז נגיד שישבנו, מיפינו את כל השיקולים האלה והצגנו אותם לבעלי העניין. ואז מגיעים "החיים עצמם" בדמות מנהל מוצר, או מפתח, או מנהל שאומר שכל זה רק תיאוריה, ועם כל הכבוד – הוא לא השתכנע. הרי נורא קל לספור קליקים ולהגיד "אני בתור המשתמש לא הייתי מבין שצריך ללחוץ כאן", ולעומת זאת למדוד עומס קוגניטיבי ואת השלכותיו זה מאוד קשה עד בלתי ישים בארגון טיפוסי. זה הזמן לבדוק את הדברים עם משתמשים – אבל יש דברים שניתן לבדוק בקלות, יש כאלה שקשה לבדוק, ושוב יש בלתי ישימים (תנסו להשוות את עקומות הלמידה של משתמשים שפותחים את המוצר פעם ברבעון, למשל). אז יש דברים שקשה להוכיח למי שלא מוכן להשתכנע. אני מזכיר את זה לא בגלל שיש לי איזה פתרון קסם למקרים כאלה, אלא רק כדי לציין את הנקודה הבאה: מניסיוני, בתשעים אחוז מהמקרים, האנשים שדורשים מכם להפוך את הכל לסופר נגיש, חשוף במבט ראשון וזמין במינימום קליקים, הם בדיוק אלו שלפני חודש שיתפו בלינקדאין שלהם את התמונה המצוינת הזו, עם הכיתוב "!!So True!! Every UX/UI designer should see this"