ינו' 26 2010
פ"ק 3א’: העיקר היעילות? לא ממש.
(חלק ראשון מתוך שניים)
גישה רווחת גורסת כי שימושיות (או במינוח המדויק: "שמישות") זהה לחווית משתמש טובה.
על פי גישה זו, התהליך והתוצרים של "עיצוב חווית משתמש" מסתכמים בממשק יעיל. תפיסה זו שגויה.
נכון שבימנו העמוסים והמעמיסים ניתן להתייחס לכל המשתמשים כסובלים מהפרעת קשב וריכוז,
אך חווית משתמש טובה רחוקה מלהסתכם ברצון לסגור עניין כמה שיותר מהר. יתרה מכך -
לפעמים יעילות הממשק עומדת בסתירה לחוויית משתמש טובה.
יש הגדרות רבות לשמישות (Usability) וקריטריונים שונים להערכת שמישות במערכות מידע.
תקן ISO לשמישות ( ;ISO 9421-210 – Human-centered design for interactive systems )
מתמקד ביעילות המערכת, התועלת ושביעות הרצון של המשתמשים.
נילסן מתייחס גם ליכולתו של המשתמש ללמוד ולזכור את המערכת ולטיב ההזהרות שהמערכת מספקת.
תחת המטריה הרחבה של "שמישות" ניתן לכלול גם את נוחות השימוש, עומס המידע, המאמץ הנדרש לתפעול המערכת, ההתאמה לצרכים והרצונות של המשתמש ועוד.
במהלך תהליך הפיתוח, נוטים לפעמים לשכוח שהמטרה איננה ליצור את המוצר ה"טוב ביותר" ע"פ פרמטרים "אובייקטיביים", אלא ליצור את המוצר הטוב ביותר עבור המשתמש. לפעמים משמעות הדבר היא כי עלינו ליצור מערכת עם "טעויות" שפוגעות ביעילות המערכת, בכדי להגדיל את שביעות הרצון של המשתמש מהמערכת.
באילו מקרים עלינו ללכת לקראת המשתמש, על חשבון יעילות המערכת ?
ישנן מספר סיבות שעשויות להצדיק פגיעה ביעילות ממשק, במטרה להטיב עם המשתמש:
- יצירת חווית יעילות (להבדיל מיעילות אמיתית)
- התאמה להרגלים
- חיזוק ומיקוד החוויה הרגשית
- Immersion (איך להגדיר זאת בעברית? "חוויה מציפה" ? "חוויה מוחלטת"?)
- מיצוב
- אמינות
- אסתטיקה
יצירת חווית יעילות, על חשבון יעילות אמיתית
לא פעם, יותר משחשוב שהמערכת תהיה יעילה, חשוב ליצור אצל המשתמש תחושה של יעילות, גם אם האמצעי המשמשים ליצירת תחושה זו פוגע מעט ביעילות הממשית של המערכת. ניתן להשיג זאת באמצעות הסחת דעתו של המשתמש, או באמצעות טכניקות של "לתת למשתמש משהו" עד שמגיע התוכן המלא. דוגמאות: הסיפור על המראות שהוצבו ליד מעליות יש סיפור שמסתובב כבר שנים רבות בחוגי עיצוב הממשק, על מלון שאורחיו התלוננו על המתנה ממושכת למעליות. הבעיה נפתרה ע"י הצבת מראות בסמוך למעליות, שסיפקו לאורחים משהו לעסוק בו בעת ההמתנה. נדמה לי שבסיפור זה יש מוסר השכל שימושי לתחום חווית המשתמש.
(בעיה אחת עם הסיפור הזה: זו כנראה רק אגדה אורבאנית)
Progressive JPG:
לפני מספר שנים, כשטעינה של כל תמונה ב-Web דרשה זמן רב (10-15 שניות לתמונה לא גדולה) היה נפוץ השימוש
ב- Progressive JPG. הרעיון שמאחורי Progressive JPG היה פשוט למדי – אנשים יעדיפו לראות גרסה באיכות נמוכה של התמונה כעבור שניות בודדות, ולקבל גרסה איכותית יותר באופן הדרגתי, מאשר לא לקבל כלום עד סוף הטעינה. קבצים מסוג Progressive JPG שוקלים קצת יותר מ- JPG "רגיל", ובפועל הטעינה שלהם דורשת יותר זמן, אבל החוויה של המשתמש היא שהוא מקבל "משהו" מהר.
Flash Preloader
הרעיון שמאחורי הצגת קטע מקדים בזמן טעינת קבצי Flash דומה לרעיון שבבסיס ה-Progressive JPG: לאנשים יש יותר סבלנות לחכות אם הם רואים משהו מעניין על המסך בזמן ההמתנה. קבצי התצוגה המקדימה ("Preloader") אומנם דורשים אף הם זמן לטעינה, אבל ברמת החוויה, בביצוע נכון, המשתמש מקבל "משהו" – ומהר. יתרה מכך, תצוגת אחוזי ההתקדמות של הטעינה שמופיעה בד"כ כחלק מה- reloader תורמת לתחושת השליטה של המשתמש ולשקיפות התהליך – אנשים מוכנים להמתין יותר זמן , כשמסגרת הזמן ברורה להם.
התאמה להרגלי המשתמש במקום ליעילות
שינויים עשויים לתסכל משתמשים שמיומנים בשימוש במערכת. דברים שעבדו פעם – פתאום לא עובדים. לעיתים זה יכול לנבוע משיפור חיובי במערכת, כגון החלפת צורת עבודה ותהליכים מיושנים ואיטיים בתהליכים אפקטיביים יותר. אבל דווקא ניסיון זה לייעל את המערכת עלול לתסכל, כש"הדרכים הישנות" חדלות פתאום לפעול. תסכול, מן הסתם, יוצר חווית שימוש שלילית. בכדי לחסוך תסכול מצד המשתמשים, נכון לאפשר לפעמים למשתמשים לעבוד בדרכים המוכרות להם, גם אם הן יעילות פחות.
חיזוק החוויה הרגשית על חשבונות נוחותך ויעילות
לפעמים חשוב לייצר חוויה רגשית מסוימת אצל משתמשים. למערכת משתלם לפגוע ביעילות התהליך, במטרה לשמור על מיקוד החוויה הרגשית. דוגמאות:
הסתרת סיסמה ע"י כוכביות
חישבו על התסריט הבא: אתם מנסים לגשת לאתר קופת החולים שלכם מהבית, להזמין תור לרופא. ניסיונות הכניסה לחשבון נכשלים שוב ושוב. אולי הסיסמה שהקשתם שגויה. אבל מה הייתה הטעות? קשה לדעת. הסיסמה מוסתרת בכוכביות. הסתרת הסיסמה המוקלדת נועדה במקור לשמור על סודיות הסיסמה ממי שמביט מעבר לכתפי המשתמש. כלי זה כבר איננו חיוני כל כך כיום. מצד אחד הוא מקשה על משתמשים ("מה כתבתי? למה זה לא עובד?" ) ומצד שני יש כיום מגוון רחב של דרכים לגנוב סיסמאות (ע"ע Phishing ו- Keyboard snooping) שאיננן מושפעות כלל מהסתרת הסיסמה ע"י כוכביות. ברוב המקרים, ברוב המערכות ברשת, ההקלדה העיוורת הזו לא משרתת צורך אמיתי של המשתמשים, אלא רק מקשה עליהם.
אם כך – למה ממשיכים להסתיר סיסמה עם כוכביות? ישנם פתרונות חלופיים ואפקטיביים לא פחות. הסיבה כפולה. ראשית – מכיוון שזו התנהגות ברירת המחדל של שדה מסוג סיסמה, ומאפיינים ומפתחים נוטים לא לשנות אותה. אבל יש נקודה נוספת – תחושת האבטחה. אומנם הכוכביות לא מספקות הגנה אמיתית מפני גנבת הסיסמה, אבל הן תורמות לתחושה של המשתמש של גישה מאובטחת למערכת.
דוגמה נוספת – החוויה המרגשת של משחק
פעמים מנסים לייצר אצל הלקוח תחושה של משחק ולשכפל את המתח והתרגשות שיוצר משחק בעולם האמיתי. לשם כך נעשה שימוש בממשק לא אופטימאלי מבחינת יעילות, אבל אפקטיבי מבחינת יצירת חוויה. דוגמה לכך היא כרטיסי הגירוד בסגנון חיש-גד. הדבר הפשוט והאפקטיבי ביותר שאפשר היה להציע למשתמשים הוא לשלם על השתתפות בהגרלה, ומיד לקבל תשובה האם זכו – ובאיזה סכום. במקום תהליך פשוט, מהיר ויעיל שכזה, מציע החיש- גד טקס שלם: הלקוח מקבל כרטיס, הוא צריך לגרד מספר משבצות, לפענח את הסמלים המתגלים, לבדוק מה משמעות התצוגה של סמל זה או אחר בתדירות כלשהי, ורק אז הוא יכול לתבוע את הפרס. מה ההצדקה לתהליך מסורבל זה? פשוט – יצירת חוויה של משחק, מתח, התרגשות, תחושה של השתתפות פעילה בהגרלה ועוד. לחוויה יש ערך שמשרת את הלקוח ומגדיל את מכירות המוצר, למרות שכל התהליך מתנהל במכוון באופן שאיננו יעיל במיוחד. דוגמה מעניינת לנושא זה בדיוק אפשר למצוא במערכות online שמדמות השתתפות בהגרלה. אם כרטיס הגירוד הוא ניסיון לשחזר חוויה של משחק מזל בקזינו, אזי כרטיסי ההגרלה הוירטואליים מנסים לשחר את החוויה של כרטיס גירוד. לדוגמה:
סוף חלק א.
בחלק ב’ של המאמר אני מציג בהצדקות נוספות לתכנון ועיצוב ממשק "לא יעיל" בשל שיקולים נוספים,
(כגון אמינות, אסתטיקה, ו-Immersion) וקווים מנחים לייצירת ממשק איכותי.
תודה לכל המשתתפים בפורם ux.il ב-Linkedin על ההצעות והדוגמאות!
לפוסט 
מריץ FireStats
חוויית יעילות לא חייבת לבוא על חשבון יעילות אמיתית. גם ב-progress bar וגם עולם ה-pre-loaders שהזכרת – עונים על הצורך של אנשים בזה שייקרה משהו, נותן להם משהו להסתכל עליו בזמן שהם ממתינים. גם שם וגם המראות באגדה האורבנית לא באו על חשבון יעילות, אלא כפיצוי על זמן פעולה ארוך של המחשב, יותר ארוך ממה שאנשים מוכנים לחכות. לכן אני לא בטוח ש"יעילות" היא הדבר הנכון להגיד כאן, כי ייתכן מאוד שפעולות המחשב הן יעילות מאוד, לא ניתן לבצע אותן מהר יותר, הן רק יותר ממה שמשתמש עם הפרעת קשב קלה מסוגל לחכות לו. כך או כך, תשומת הלב לחוויית השימוש בסיטואציות כאלה היא קריטית, במיוחד במערכות ברשת, כי אלה נקודות נטישה פוטנציאליות…
כיוון אחר מעניין שאפשר לדבר עליו בהקשר הזה: שמישות גרועה בצורה מכוונת, משיקולים עסקיים – למשל, הסתרת הקישור "יצירת קשר" והבלטת הקישור "עזרה" או "תמיכה". או להכריח את המשתמש לעבור דרך איזור ה"שאלות הנפוצות" כשהוא לוחץ על "תמיכה", לפני שהוא מגיע לטופס שבו הוא כותב את התקלה שלו (כדי לצמצם את כמות הפונים לתמיכה)
הנה עוד כמה דוגמאות:
http://www.closed-loop-marketing.com/blog/2007/12/19/evil-usability-3-when-business-goals-and-user-goals-collide/
[תגובה]
אגב, אחלה פוסט. הדוגמאות של כרטיס הגירוד ושל הסתרת הסיסמה הן מצויינות, ומעבירות היטב את הרעיון. שמישות היא אחד המדדים לבדיקה של אתרים ומערכות תוכנה, אבל החווייה הרגשית היא לא חלק משמישות. זה מזכיר את הבדיחה הישנה ההיא, על "הניתוח הצליח, החולה מת" – עיסוק בשמישות לבד, בלי לבדוק את חוויית השימוש והאספקטים הרגשיים שלה, מפספס את העיקר.
[תגובה]
רן, מאמר מצוין.
ברק, התנגשות עם אינטרסים עסקיים היא סוגיה מעניינת אבל שונה. לתת למשתמש תחושות בטחון או הנאה כמו שהודגם במאמר זה דבר אחד, אבל להקפיץ פופ-אפים, להסתיר הצעות חינמיות וכו’ זו הליכה נגד המשתמש, גם אם אפשר להבין את השיקולים העסקיים העומדים מאחוריה.
אגב preloaders, הכי מהנים שנתקלתי בהם כללו משחקונים קטנים, אבל לפעמים הם גרמו לי לא לרצות להמשיך לאתר…
[תגובה]
והנה דוגמא לניסיון לשמר חוויה אחת על חשבון היעילות.
http://www.intermediair.nl/epaper/2010/01/index.html#/22/
בעיתון הזה ניסו לתת את חווית העלעול בעיתון אבל הגיעו למשהו שמפריע ביותר לקריאה. בנוסף, לא ממש מובן להיכן האות E שבהתחלה שייכת, ויצא שהיא יכולה לההשתייך לשני הטורים. ללא ספק גרוע.
[תגובה]
ברק, רוני ישי - תודה על התגובות!
ברק - למיטב הבנתי החוויה הרגשית היא בהחלט חלק מהשמישות. יש התייחסות לנושא החוויה הרגשית ברבות מהמסגרות שביקשו להגדיר Usability, תחת הכותרת של satisfaction – " שביעות רצון" (שנילסן הגדיר כ " How pleasant is it to use the design ").
תוכל למצוא התייחסות לשביעות הרצון הסובייקטיבית של משתמשים בתקן ISO 9421-2101 , כמו גם אצל חוקרים רבים –
Hix and Hartson, Wixon and Wilson , Shneidermann , Constantine and Lockwood, וכאמור – נילסן.
רוני, ברק – אכן, לא התייחסתי כאן למצב של התנגשות בין צרכי המערכת לצרכי המשתמש (שראוי לדיון בפוסט משלו) אלא למצב בו חווית השימוש נתרמת מהחלטות ממשקיות שפוגעות ביעילות. ה- pre-loaders אומנם משפר את החוויה – אבל תמיד יש לכך מחיר כלשהו (לפעמים קטן) בזמני טעינה. האגדה על המראות מציגה מסגרת בה החוויה שופרה – בלי להשפיע על היעילות של המערכת בפועל.
ישי –הדוגמה נשמעת מתאימה, אבל לא הצלחתי להצלחתי להפעיל את הקישור.
נדמה לי ש- http://www.ebook.co.il/StaticPages.aspx?PageName=samples או http://www.myalbum.co.il/default.asp?PageId=6 מציגים משהו ברוח אליה התכוונת.
מרוב מאמץ ליצור "חווית עולם אמיתי" נוצרה חווית שימוש לא נעימה
[תגובה]
היי רן
לא דיברתי על שביעות רצון, שהיא בהחלט חלק ממדדי השמישות המוכרים. דיברתי על רגש כמניע לפעולה, על החוויה הרגשית. ברור שחוויה רגשית שלילית תגרום לחוסר שביעות רצון, אבל שביעות רצון הוא מדד גס מדי מכדי להבין את המניעים הרגשיים שעומדים בבסיס קבלת ההחלטות שלנו.
[תגובה]
ברק – אני מסכים ש"שביעות רצון" זה סוג של מדד מסכם, שמציג ממימד סופי של החוויה,
בלי להתייחס למרכיבים. הקביעה שממשק שמיש צריך, בין השאר, לייצר שביעות רצון אצל המשתמשים, זו אמירה נכונה – אבל כוללנית מדי.
הזכרתי בחלק הזה של המאמר מספר ממדים רגשיים שממשקים מנסים לפעמים ליצור, כגון תחושת הביטחון (באמצעות סיסמאות) ותחושת ההתרגשות, המשחקיות והמעורבות של המשתמש (בכרטיסי הגרלה).
בחלק השני של המאמר אתייחס למספר ממדים חווייתיים נוספים שממשקים מנסים ליצור, כגון אמון במערכת, אמפטיה והנאה אסטטית ושלעיתים מתנגשים עם יעילות המערכת.
אשמח לשמוע הצעות ודוגמאות לממדים רגשיים נוספים שממשקים מנסים ליצור.
[תגובה]
הי רן,
פוסט יפה עם הרבה מאוד נקודות למחשבה. שמתי לב שהרבה התרחש סביב הפוסט הזה ושאני פתאום התעוררתי לעולם שקרו בו הרבה דברים ואני לא לקחתי בהם חלק. טוב, אני עסוקה בסיום תואר באוניברסיטה הפתוחה ולאחרונה ראיתי הרבה מותחנים בקורס ז’אנרים של המותחן בקולנוע. אגב, גם קולנוע יוצר חווית משתמש. למה לעזעזל אנשים הולכים לראות סרטי אימה? זה נושא לפוסט אחר.
בנושא פוסט זה, רציתי לשתף אתכם במערכת המאופיינת ומפותחת כיום אצלנו עבור בתי הספר, של מערכת שעות בית ספרית ושילוב שעות לימוד ושעות רפורמת אופק חדש בלוח שעות בית ספרי. כמנהלת צוות ממשק משתמש העוסקת הן בשימושיות והן בנגישות, היה לי קשה לקבל את דרישת הלקוח לשימוש בהרבה צבעים כדי להבדיל בין המקצועות השונים וכן בין המורים השונים וכן לשימוש ברכיב Drag & Drop. התהיות שלי היו: האם כל משתמש יוכל להשתמש ברכיב הגרירה? האם פעולת הגרירה תהיה לו קלה, מובנת? איך יכול משתמש להבדיל בין מקצוע הצבוע בצבע ורוד כהה לבין מקצוע הצבוע בורוד בהיר? איך לכל השדים והרוחות מנגישים דבר כזה? האם לכל המשתמשים תהיה חוויה טובה וחיובית מהמערכת? האם בזה שהסכמתי ללכת עם המאפיינים של המערכת והמערכת כיום כוללת צבעים (יותר מ- 100 צבעים) ורכיב גרירה התפשרתי על עקרונות ממשק משתמש ושימושיות לטובת חווית המשתמש? שאלות רבות. החלטנו ללכת על מהלך של בדיקות שימושיות (תצפיות במשתמשים) ונראה מה יהיו הממצאים.
[תגובה]
תודה טליה.
העלית סוגיה מעניינת (אם כי לא ממש קשורה לפוסט) בנוגע למצב מוכר:
מה עושים כשהלקוח דורש בתוקף מוצר לא טוב?
אני מנסה לתת תשובה לסוגיה זו בדיוק (ולעוד כמה אחרות) פוסט שעומד להתפרסם
בקרוב ב- UXI - "איש ה-UX כספק שירותים"
[תגובה]
הי רן,
אני לא לגמרי מסכימה עם ההנחה הראשונית, אני יותר נתקלת בהנחה של אנשים ששימושיות תביא עמה ממשק נוח ופשוט. בכל מקרה שתי ההנחות הללו אינן נכונות כיון ששימושיות (שבעיני מובנה צר יותר מחויית משתמש, כך שזה בוודאי נכון לגבי חווית משתמש) היא לא זה ולא זה אלא (באופן כללי ובלי להיכנס להגדרה רשמית) התאמה למשתמש וזה לפעמים זקוק לממשק פשוט, לפעמים לממשק יעיל ולעוד דברים רבים… לכן המקצוע הזה, שלנו, מורכב כל כך ואין בו "נוסחה" שמתאימה תמיד.
ולגבי חוסר יעילות – אז הדרישה לפשטות הרבה פעמים באה על חשבון היעילות (למשל ב wizards) וזה לפעמים פתרון טוב ומתאים ולעיתים ממש לא…
[תגובה]
רן לירון
reply on 1 במרץ, 2010 10:59:
הי נורית.
תודה על ההתייחסות המפורטת.
ייתכן שחלק מאי-ההסכמה בייננו נמצא ברמת הטרמינולוגיה.
ממשק אכן צריך לענות על צרכי המשתמשים, ואכן יש משתמשים / מצבים בהם היעילות חשובה יותר מהפשטות, או שהתועלת חשובה יותר או שהלמידות או כל אחד ממדדי השמישות האחרים. דוגמה טובה לזה אפשר לראות אצל ברוקרים שעובדים מול שני מסכים בו זמנית, כאשר כל אחד מהמסכים מציג עשרות, (ואלי לא מאות), פרטי מידע בו זמנית.
התחושה למתבונן מהצד היא שהממשק הזה יכול להיות הרבה דברים – אבל פשוט הוא לא.
ועדין, עלינו לספק למשמש ממשק פשוט ככול שניתן, בהתחשב בצרכיו.
אגב, הזכרת "פשוט" ו"נוח" בנשימה אחת, כנושאים שלא בהכרח נגזרים משמישות.
לעניות דעתי, בעוד ניתן לבצע פשרות בנוגע ל"פשוט", המדד של "נוח" או "משביע רצון" (satisfying) הוא מבחינת "ייהרג ובל יעבור".
אם הממשק לא נוח למשתמש, אם המשתמש מנסה לעבוד עם המערכת והחוויה הראשונית היא שהמערכת איננה נוחה לשימוש, אם הוא עובד עם המערכת לאורך זמן ועדין הוא חש שהמערכת איננה נוחה – נכשלנו.
אז כן, אני בהחלט סבור שב-100% מהמקרים שמיש = נוח.
בהחלט אפשר לומר שהמערכת איננה שמישה עבורמשתמשים שתופסים אובדיוק תה כלא נוחה.
(כדאי רק לבדוק מה בדיוק הופך אותה ללא נוחה).
את מוזמנת להעיף מבט גם בחלק ב’ של המאמר -
הרחבתי שם את ההתייחסות לנושא ההתאמה לצרכים ומצבים שונים.
[תגובה]
נורית
reply on 2 במרץ, 2010 10:22:
אתה צודק לגבי נוח, זו היתה פליטת…. מקלדת
ויהוו ממשק טוב ומוצלח גם אם לא הכי פשוט שאפשר
וגם הדוגמא של הברוקרים נכונה, כמו הרבה בעלי תפקידים שצריכים לעבוד מול הרבה מידע או לבצע הרבה פעולות, בשביל משתמשים כאלה קיצורי דרך, גם אם הם דורשים למידה מסוימת יהיו נוחים
אני מדגישה את הנקודה הזו כי נתקלתי הרבה פעמים בלקוחות שרוצים ממשק פשוט, כשבעצם הם צריכים ממשק *מתאים* .
וכן, קראתי גם את חלק ב’ (האמת שהתחלתי ממנו…) !
[תגובה]