שיחה עם יניב שריג, ראש צוות חוויית משתמש בסטודיו Uniq UI
לפני כחודש, ציוץ קטן בטוויטר התניע דיון UX סוער במיוחד. הציוץ עסק בסרטון יו-טיוב שפרסם מאפיין חוויית משתמש בשם Graeme Pyle, בו הוא מספר על תגלית מפתיעה בנוגע לחוויית השימוש באתר הבנק שלו. הוא מתאר כיצד הוא הרגיש מרומה על ידי ה-progress bar בממשק, אחרי שהבין שהוא אינו מתאר התקדמות אמיתית של תהליך. הדבר עורר דיון סוער כשרבים דווקא הסכימו שלגרום למשתמש להמתין (גם אם זה בצורה מלאכותית) יכול לתרום לחוויה במקרים מסוימים. יניב שריג, ראש צוות חוויית משתמש אצלנו ב-Uniq UI, מספר שהדיון גרם לו לחקור, לקרוא ואפילו כבר ליישם את התובנות בשטח.
Graeme Pyle מציג את התגלית המפתיעה שלו בסרטון קצר שמלווה בקריינות נרעשת.
בסרטון הוא מספר שבמהלך ביקור באתר הבנק שלו, הוא גילה ש-progress bar, שציין התקדמות טעינה, היה שקר מוחלט. המחשב לא היה מחובר כלל לאינטרנט ולכן לא הייתה יכולה להתצבע טעינה. ובכל זאת, הוצגה התקדמות ואפילו היה נסיון לחקות קצת התקדמות אמיתי (עם האטה לקראת הסוף). כשהסרטון הגיע לרשת הוא קצר שלל תגובות הזדהות עם תחושת הבגידה ש-Pyle מתאר. תחושת הבגידה מבוססת על ההנחה הבסיסית שיש קשר ישיר בין מה שמוצג למשתמש על המסך, לבין הפעולות האמיתיות שמתרחשות "מאחורי הקלעים". אבל האם כך נכון באמת לאפיין?
חוויית המשתמש מורכבת מגורמים נוספים מלבד שמישות, שיוצרים חבילה שלמה. הדיון בטוויטר הציף שניים מהשיקולים האלה: תפישת זמן וערך נתפש. השניים כמובן קשורים זה בזה ומשפיעים זה על זה, והמגיבים לדיון הביאו קישורים למאמרים שמחזקים את טענותיהם. הנה שתי דוגמאות:
איך אנחנו תופשים את הזמן?
המאמר הראשון, The perception of speed, דן במושג זמן נתפש. הוא מציע כמה דרכים למילוי זמני ההמתנה של המשתמשים, כמו פעולות שהם נדרשים לבצע או תוכן מעניין. אלה, אמורים לגרום לאותו פרק זמן להיתפש כקצר יותר. דוגמא לכך היא תכנון שדות תעופה כך שהנוסעים הנוחתים יצטרכו לצאת למסע ארוך עד למסוע המזוודות ובכך יתקצר לכאורה זמן ההמתנה למזוודה. העיקרון הוא שזמן שעובר בפעולה נתפש כקצר יותר מהזמן שעובר בהמתנה סטטית. בהקבלה לעולם הדיגיטלי, כשמשתמש ממתין לטעינת עמוד תוך כדי בהייה במסך לבן ש'ממתין' להיטען, הוא ירגיש שהוא נמצא בהמתנה סטטית. לעומת זאת, כשהמשתמש ממתין לטעינת עמוד במקביל להתבוננות בעמוד המוצא, הזמן הנתפש הוא קצר יותר בגלל שיש מה שמעסיק אותו.
יכול להיות שזה מה שניסו לעשות באתר הבנק וכל כך הכעיס את הרשת. ה-progress bar הוא בסך הכל אנימציה שאמורה לתת למשתמש גירוי ויזואלי שיעסיק אותו במהלך הטעינה. הבעיה עם היישום הייתה שהמטרה של הפעולה – טעינת מידע – נדחקה לשוליים ולא יוצגה על ידי האנימציה. עם זאת, אפילקציות רבות עשו זאת טוב יותר, על ידי פעולות שהמשתמש נדרש לבצע או קיצור הזמן הנתפש על ידי פעולות ויזואליות שונות. בנוסף, גם לאופן ההתקדמות של ה-progress bar יש השפעה על המהירות הנתפשת של הפעולה על ידי המשתמש, כפי שתוכלו לראות במאמר הזה.
איך מיישמים? על-מנת ליצור חוויית משתמש חלקה ומהירה יותר, ניתן לקצר את הזמן הנתפש ולאו דווקא את הזמן האמיתי. אפשר למלא אותו על ידי הצגת תוכן למשתמש, אנימציה יצירתית לזמן הטעינה, דרישה לביצוע פעולות נוספות של המשתמש וכו'. עם זאת, אם קיימת בעיה בפעילות שמתרחשת מאחורי הקלעים, יש לעצור את הסחות הדעת ולהתריע על כך בפני המשתמש.
ראו בוידאו המחשה של ההבדלים בין השיטות שונות להצגת התקדמות progress bar.
בשביל דברים טובים צריך להתאמץ
במאמר השני, …Wait for it, שכתב Stephan Anderson, נטען שבניגוד למה שהורגלנו להאמין, מהיר יותר לא תמיד נתפש כטוב יותר. כלומר, לעיתים זמן קצר או זמן-נתפש קצר לא יצליחו לשפר את החוויה, אלא להיפך – על מנת שהמשתמשים יקבלו חוויה טובה יותר יש לגרום להם להמתנה ממושכת יותר. למה? במילוי טופס לוטו למשל, להמתנה יש ערך חשוב מאוד: אם נרדד את חוויית ההגרלה לכדי עניין פיננסי לחלוטין (המשתמש נותן כסף למישהו שבתמורה אומר לו אם הוא זכה או לא), נאבד את הערך המוסף של המתח בעת חשיפת התוצאות. השקלים הבודדים שהשקענו בטופס רכשו עבורנו חלומות ותקוות להיות עשירים, כל עוד פרסום המספרים הזוכים לא הוכיח אחרת.
בדוגמה המפורטת שנותן אנדרסון הוא מתייחס ל'הזדמנות המפוספסת' כהגדרתו, שזיהה באפליקציה שמחשבת ניצול דלק ברכב: אחרי שהמשתמש נדרש להזין את כל הפרטים הרלוונטיים (מרחק נסיעה מאז תדלוק קודם, כמות דלק במילוי נוכחי, מחיר), הוא בהתרגשות מסוימת לקראת פרסום התוצאות, שיעידו על ניצול הדלק במהלך הימים האחרונים. זה רגע עם מתח, הרגע האחד בשבוע שעבורו האפליקציה קיימת. למרות זאת, פרסום התוצאות מגיע ללא כל השהייה. הפספוס הוא בכך שאין שום בניית מתח נוסח תכניות ריאליטי, לא נשמעים תופים, אין פנייה למשתמש על מנת לשאול "יש לך ניחוש מקדים לגבי התוצאות?" – התוצאות מופיעות על המסך בצורה קרה ומכאנית. השורה התחתונה: בדומה לכל היבט של חוויית משתמש, גם את משך הזמן שלוקח לכפתור לעבוד או לפיצ'ר לפעול, יש לעצב מתוך מחשבה ולא להניח שהאפשרות המהירה ביותר היא דווקא הנכונה. לעיתים קיצור זמן המתנה והגברת היעילות עבור המשתמש פוגמת בחוויה הכוללת.
כשאנחנו רעבים מאוד האוכל טעים יותר
השיקול השני הוא הערך הנתפש בעיני המשתמש. בהקשר שלנו חשוב להבין שמידת הציפייה משפיעה על המידה בה המשתמש מעריך את התוצאה. הדבר מקבל חשיבות גדולה אפילו יותר, כאשר התוצאה לה אנחנו מצפים נתפשת בעינינו כמורכבת. לדוגמה, כאשר אנו מבצעים העברת כספים בחשבון בנק, העברה של שקל אחד נתפשת בעינינו כפעולה פשוטה יותר מאשר העברה של 10,000 שקלים. למה? התשובה כנראה טמונה בהיכרות שלנו עם סכומי כסף בעולם האמיתי. שקל בודד ניתן להעברה מיד ליד באמצעות מטבע אחד ואילו 10,000 שקלים מצריכים כמות מכובדת של שטרות ו/או מטבעות. כמובן שההקבלה המתאימה יותר תהיה לצ'ק, שכרוכה בו מידה דומה של מאמץ בין אם אנחנו מעבירים בו שקל אחד או 10,000. יותר מכך, אנחנו מקשרים גם בין כמות הזמן שפעולה לוקחת לבין החשיבות של אותה פעולה. יש כאן הזדמנות לשיפור חוויית השימוש דווקא על ידי הארכת משך הזמן שלוקח לפעולה להתבצע. האתגר הוא לא רק לאפשר העברה בנקאית ולתקשר אותה בצורה ברורה (שמישות), אלא לתת למשתמש את התחושה שהבקשה החריגה נלקחה ברצינות הראויה, ומטופלת על-ידי טובי המומחים בתחום ההעברות הבנקאיות.
אז, איך מיישמים?
"לאחרונה נדרשנו לאפיין ממשק לאפליקציית מובייל" מספר יניב שריג ראש צוות חוויית משתמש בסטודיו. "הממשק כלל תהליך רישום ובו שלב של אימות נתונים. לאחר שאפיינו את המסכים השונים, ומכיוון שלא הגדרנו חוקים ברורים, המפתחים מימשו את התהליך כפשוטו: המעבר בין שלבי הרישום התבצע בהתאם לקבלת משוב מהשרת, שהפעולה נקלטה ללא שגיאות". אך מבדקי שמישות סייעו להציף את הבעיה "גילינו שביותר מ-95% מהמקרים, מגיעה תשובה חיובית מהשרת בפחות משניה. ההשפעה בפועל היתה שמשתמשים לא היו בטוחים האם הנתונים שהוזנו למערכת אכן נקלטו בהצלחה. הפעולה פשוט קרתה מהר מידי!" היו מספר פתרונות אפשריים "יכולנו לפתור את זה על ידי הצגת הודעה שאומרת: "הפעולה נקלטה בהצלחה". עם זאת, הרגשנו ששימוש בפתרון כזה מעמיס על ממשק המובייל מעבר לצורך. מעבר לזה, הרגשנו גם שאנחנו מפספסים הזדמנות לתת למשתמש להרגיש שהאפליקציה מתאמצת עבורו. לכן ההנחייה לצוות הפיתוח היתה לעכב את המעבר למסך הבא למינימום של 2 שניות. בזמן הזה, המשתמש רואה שהכפתור שהוא לחץ עליו אכן נלחץ, המערכת קלטה את הבקשה שלו, היא מעבדת אותה וכשהמעבר לשלב הבא מתבצע, התחושה הכללית המתקבלת יותר נוחה." התגובות מצוות הפיתוח היו ספקניות: "אם אנחנו יכולים לעשות את זה בחצי שניה, למה לעכב את התהליך בעוד שניה וחצי?" אבל במבחן התוצאה הסופית, היעד הוא לא בהכרח קיצור משך הזמן שהתהליך לקח אלא תחושת ההצלחה של המשתמשים באפליקציה.
תגובות