יש דרכים רבות להגדיר שמישות. כן, שמישות, לא שימושיות. זהו מושג מורכב המכיל בתוכו אינספור רעיונות, מתודולוגיות, גישות ותחומי ידע (פסיכולוגיה קוגניטיבית, תקשורת חזותית, מדעי המחשב, ארגונומיה ועוד). בפוסט הזה אנסה להגדיר את המושג שמישות באמצעות המטרות והיעדים שחשוב להציב כשבוחנים שמישות במוצר קיים, או כשמתכננים מוצר חדש ורוצים שהוא יהיה שמיש. יש לשמישות, כמובן, רבדים נוספים.
שמישות, לא שימושיות
הרבה אנשים משתמשים בטעות במושג שימושיות במקום שמישות, בתור התרגום העברי של המושג usability. שימושיות היא התרגום של המילה usefullness – עד כמה משהו הוא בעל תועלת, מועיל, ולא של המילה usability– עד כמה משהו הוא בר-שימוש, האם ניתן להשתמש בו בקלות.
אפילו האיגוד הישראלי קורא לתחום העיסוק הזה שימושיות – שוב, בטעות.
שמישות: הגדרה
פעם היו קוראים לזה "ידידותי למשתמש" – User Friendly. היום זה "שמישות" – Usability, או "שימושיות" למי שמתעקש לטעות. הכוונה היא אותה כוונה.
סטנדרט ISO 9241 (או בשמו המלא: Ergonomics of Human System Interaction) מגדיר את המושג כך – בתרגום חופשי:
שמישות היא המידה שבה יכולים משתמשים ספציפיים להשתמש במוצר על-מנת להשיג יעדים של אפקטיביות, יעילות וסיפוק בקונטקסט שימוש ספציפי.
הסטנדרט מגדיר, אם כן, שלושה יעדים לשמישות:
- אפקטיביות (effectiveness): עד כמה המוצר מבצע בצורה טובה את מה שהוא אמור לעשות? עד כמה המוצר מבצע את המטרות שלשמן הוא נוצר?
- יעילות (efficiency): אחרי שמשתמשים זמן מה במוצר, עד כמה ניתן לבצע בו משימות במהירות?
- סיפוק (satisfaction): האם השימוש במוצר נעים ומספק? או במילים אחרות – עד כמה המשתמש מרוצה?
נילסן מגדיר את המושג דרך 3 יעדים נוספים:
- קלות לימוד (learnability): כמה קל למשתמשים חדשים לבצע משימות פשוטות? כמה קל להם ללמוד את המוצר לבד?
- זכירוּת (memorability): כשחוזרים למוצר אחרי שלא משתמשים בו פרק זמן מסויים, כמה זמן נדרש כדי לחזור ולשלוט בו?
- שגיאות (errors) או בטיחות (safety): כמה שגיאות משתמשים עושים? עד כמה הן חמורות? כמה קל למשתמשים להתאושש מהשגיאות הללו? איך המערכת מונעת מהמשתמשים לטעות?
Sharp, Rogers ו-Preece מרחיבים את מושג השמישות באמצעות יעד אחד נוסף:
- תועלת (utility): עד כמה המוצר מספק את היכולות שנדרשות למשתמשים כדי לעשות את מה שהם רוצים או צריכים לעשות?
יעדי שמישות
אציג כאן בפירוט את היעדים שמגדירים את השמישות של המוצר, כפי שסיכמתי כאן למעלה. כל יעד מוצג באמצעות שאלה, ודוגמא שממחישה את המימוש או אי-המימוש של היעד.
אפקטיביות Effectiveness
שאלה: עד כמה המוצר מבצע בצורה טובה את מה שהוא אמור לעשות? עד כמה המוצר מבצע את המטרות שלשמן הוא נוצר?
דוגמא: אתר הביטוח הלאומי אמור לספק מידע לכלל הציבור בישראל על השירותים שלו, הקצבאות שהוא מספק, והתנאים לקבלתם. האם הוא מצליח בכך?
כתבה שלי על אתר הביטוח הלאומי אמורה לעלות בקרוב במדור ביקורשת ב-Ynet אז אני לא אהרוס לכם את ההפתעה. אתם מוזמנים להציץ בעצמכם בעמוד שמסביר איך לחשב את דמי האבטלה, לנסות להבין אותו ולהחליט – האם אתר הביטוח הלאומי אפקטיבי? (רמז: לא מאוד!)
בהזדמנות זו אני רוצה לבקש חמלה מפקידי הביטוח הלאומי :)
יעילות Efficiency
שאלה: אחרי שמשתמשים זמן מה במוצר, עד כמה ניתן לבצע בו משימות במהירות?
דוגמא: כספומט, נראה במבט ראשון מוצר יעיל מאוד. בכמה צעדים פשוטים הוא מסייע לאנשים רבים, בגילאים שונים עם יכולות מגוונות מאוד, לבצע משימות מרכזיות מול הבנק. לכאורה נראה שאי אפשר לקצר את התהליך של עבודת הכספומט במשיכה: סיסמא –> בחירת פעולה (משיכה) –> סכום למשיכה –> סיום. רצוי גם לקחת את הכסף והכרטיס בחזרה. אבל האם באמת אי אפשר לשפר את היעילות של המוצר הזה?
אפשר היה, למשל, לוותר על בחירת הפעולה. רוב האנשים משתמשים בכספומט למשיכת כסף. במקום בחירת פעולה, היה אפשר להציג מייד רשימת סכומים למשיכה, ובסוף הרשימה להציג "פעולה אחרת" ו"סכום אחר".
בכדי להיות ממש יעילים, אפשר היה לדאוג שהמערכת תזכור את סכומי המשיכות ותציע את הסכום הנפוץ ביותר בתור האפשרות הראשונה. כך חסכנו זמן על הלחיצה ושליפת המסך הנוסף (ברוב המקרים), וגם על סריקת רשימת הסכומים למשיכה (שוב, ברוב המקרים), ושיפרנו את היעילות.
סיפוק Satisfaction
שאלה: האם השימוש במוצר נעים ומספק? או במילים אחרות – עד כמה המשתמש מרוצה?
המושג "סיפוק" הוא די חמקמק בהרבה מקרים. הוא סובייקטיבי מאוד, ויכול להיות מושפע בקלות ממצב הרוח של המשתמש, כאב הבטן שיש לו מהבוקר או הדיון המשעמם שהוא היה בו קודם. כמו כל אחד מהיעדים כאן, הסיפוק הוא חלק מהתמונה הכוללת.
דוגמא: יש מקרים שבהם זה ממש קל למצוא משתמש מסופק. קחו למשל מישהו שעוסק בממשק משתמש וקנה אייפון, ותשאלו אותו אם כיף לו להשתמש במכשיר החדש.
במקרים אחרים, כמו תוכנה להנהלת חשבונות, אלמנט הסיפוק נראה קצת פחות ברור מאליו. הנהלת חשבונות היא משימה פחות כייפית מלהשתעשע עם צעצוע דיגיטלי. מצד שני, אם התוכנה חוסכת למנהל החשבונות הרבה עבודה ידנית, יש סיכוי טוב שהוא ירים שני אגודלים נלהבים למעלה כשישאלו אותו אם הוא מרוצה. כך או כך, זהו יעד שמישות שחשוב להתבונן בו.
קלוּת לימוד Learnability
שאלה: כמה קל למשתמשים חדשים לבצע משימות פשוטות? כמה קל להם ללמוד את המוצר לבד?
דוגמא: קל מאוד להבין את החשיבות של היעד הזה דרך שתי תוכנות לעריכת תמונות: פוטושופ ופיקאסה.
כדי לעשות פעולות בסיסיות בפוטושופ, כמו חיתוך תמונה (crop), צריך הדרכה לא קצרה. בפיקאסה צריך רק להציג את התמונה, ומיד כל הפעולות מופיעות בצד, גלויות, ועבור משתמשים רבים השימוש בהן לאחר מכן הוא מאוד אינטואיטיבי.
בפוטושופ הממשק לטיפול בתמונות מורכב, ומפוזר בין התפריטים והפאלטות (palettes) השונות. בפיקאסה הממשק הפשוט, שמאפשר לבטול (undo) בקלות, קורא למשתמשים להשתעשע עם המוצר וללמוד אותו לבד.
כמובן שלא כל מוצר חייב להיות קל ללימוד. למשל, במוצר בלעדי בתחומו, שמשמש בעיקר אנשי מקצוע מומחים, יהיה קשה להצדיק השקעה בקלות הלימוד, מכיוון שממילא הם "קהל שבוי". אבל ברוב המוצרים משתמשים חדשים ירצו להשתמש בהם מיד, ולא ישמחו לבלות זמן רב בלימוד. הדבר בולט במיוחד באתרים שמספקים שירותים ברשת, לקהל רחב. קלות לימוד עשויה להיות גורם מכריע בהצלחתו של אתר כזה.
זכירוּת Memorability
שאלה: כשחוזרים למוצר אחרי שלא משתמשים בו פרק זמן מסויים, כמה זמן נדרש כדי לחזור ולשלוט בו?
מטרת יעד הזכירות היא לבדוק עד כמה קל לחזור להשתמש במוצר שנלמד בעבר, אחרי פרק-זמן שלא השתמשו בו. הדבר נכון במיוחד במוצרים או חלקים במוצר שלא משתמשים בהם באופן תדיר. כשהפעולות הן לא ברורות, לא הגיוניות או מופעלות ברצף לא מובן, הסיכוי לזכור אותן יורד דרמטית.
דוגמא: בפוטושופ מסייעים לזכירוּת בכך שמקבצים בקבוצה אחת אייקונים של פעולות שונות שקשורות לאותו הנושא. למשל, בתמונה משמאל כל הפעולות הווקטוריות מופיעות ביחד. הקיבוץ ההגיוני מאפשר למשתמש שזוכר רק את אחד מהאייקונים מאותו נושא לאתר את האחרים בקלות בתוך ארגז הכלים של פוטושופ.
שגיאות ובטיחות Errors & Safety
שאלה: כמה שגיאות משתמשים עושים? עד כמה הן חמורות? כמה קל למשתמשים להתאושש מהשגיאות הללו? איך המערכת מונעת מהמשתמשים לטעות?
כדי לקיים את היעד הזה, מוצר צריך לסייע למשתמש להימנע מביצוע פעולות שגויות. עליה לצמצם את הפחדים של המשתמשים מלעשות טעויות. למשל, אם הם כבר טועים, המוצר צריך לסייע להם להתגבר על הטעות.
דוגמאות: הדוגמא של ה-undo בפיקאסה (ב"קלות למידה" למעלה) ממחישה מצויין איך אפשר לממש את היעד הזה. לשים את הפקודות Save ו-Close (או Exit או Delete) רחוק אחת מהשנייה זו דוגמא מצויינת נוספת. ב-Outlook דווקא לא עשו את זה – כמו שרואים כאן משמאל. לעומת זאת, כמו בכל מוצר דומה, הם הגנו על המשתמש צעד אחד אחרי כן, ואם יש שינויים שלא נשמרו, הם שואלים את המשתמש האם לשמור אותם לפני שמוחקים.
תועלת Utility
שאלה: עד כמה המוצר מספק את היכולות שנדרשות למשתמשים כדי לעשות את מה שהם רוצים או צריכים לעשות?
דוגמאות: דוגמא למוצר עם תועלת גבוהה היא למשל Google Reader. הוא מאפשר למשתמש לקרוא פידים רבים של RSS (רססים) במקום אחד מרוכז, ולגלות בקלות את הפידים שבהם מופיעים פריטים חדשים.
דוגמא למוצר עם תועלת נמוכה הוא כלי שמאפשר לשלוח אימייל שיווקי לרשימת תפוצה גדולה, אך לא בודק אם האימייל יהיה חשוד כספאם, אם הוא יראה נכון במוצרי אימייל שונים (Outlook, Gmail, Yahoo), או אם הוא עומד בחוקים ובתקנות של מדינות שונות בנוגע לאימיילים שיווקיים.
סיכום
יעדים הם אחת הדרכים להגדיר את המושג שמישות – usability. היעדים כלליים, נדרשות שאלות הרבה יותר ממוקדות כדי לבדוק את השמישות של מוצר, או לתכנן מוצר שמיש – אבל הם נקודת התחלה מצויינת. חשוב לבדוק את החשיבות של היעדים בהתאם למוצר שרוצים לבדוק. המשקל של כל אחד מהם עשוי להיות שונה במוצרים מסוגים שונים.
כתבה מצויינת! תודה!
הדוגמאות שאתה מביא הן נכס! דוגמא מאלפת ל "זכירות" :)
תודה, נעמה! :)
הי ברק.
איזה הבדל אתה מוצא בין Effectiveness ל – Utility ?
רן,
Effectiveness מדבר על ביצוע מוצלח של היעדים שהמוצר מציב לעצמו.
Utility מדבר על הערך של המוצר עבור המשתמש. בתהליך תכנון נכון, היעדים שהמוצר יציב לעצמו יהיו בעלי ערך למשתמשים, אבל זה לא בהכרח יקרה.
למשל, קח למשל חברת ביטוח. יכול להיות שאחד היעדים שהאתר של חברת הביטוח מציב לעצמו הוא להקשות על הלקוחות להבין את הזכויות שלהם במקרה של תביעה, על-מנת לשמור על הקופה של החברה. במקרה כזה, אם היעד מושג, יעד הUtility לא יושג כי המוצר יהיה בעל ערך נמוך עבור המשתמש, אבל ה-Effectiveness יושג.
עוד פוסט מצוין, תודה!
תכונה ששחסרה לי במוצרים, בעיקר בתוכנות, זה התאמה לרמת המשתמש.
משתמשים מתקדמים לא זקוקים להרבה מהתכונות האוטומטית שרק "מנדנדות" להם. למשל, הדבר הראשון שאני עושה אחרי התקנת Word זה לנטרל את כל הדברים האוטומטיים למיניהם ולהתאים את סרגלי הכלים והתפריטים לצרכים שלי (יש לי קובץ Template מוכן מראש לרוב הדברים).
לעומת זאת, משתמש לא מנוסה זקוק להרבה יותר הנחיות, וזה חסר.
הייתי רוצה ומצפה שמוצר (תוכנה או טלפון סלולרי למשל) בשימוש הראשון יבקש ממני לדרג את הרמה שלי (מאחד עד חמש, או משהו בסגנון) ולפי זה יתאים את הממשק וגם יספק הדרכה (Tutorials). אז היעילות והאפקטיביות יהיו מרביים.
יוסי –
ממשק שמנדנד בשאלות עשוי קצת להציק.
ניתן להשיג (בתיאוריה לפחות) יעילות משופרת של ממשק,
דרך ממשק שלומד על הרגליך בלי שאלות –
ומתאים את עצמו אליך.
יוסי,
קלות לימוד היא יעד חשוב, אבל ריבוי הנחיות יכול להיות מסוכן. אחד הדברים שמייקרוסופט מוזכרת שוב ושוב בגללו – לרעה – הוא ה-Office Assistant המפורסם. מטרתו היתה טובה, לתת למשתמשים לא מנוסים עזרה מדמות ידידותית, ולא מספר עבה-כרס או דף עזרה יבש. הוא "ניסה" לנחש מה המשתמש רוצה לעשות והציע עזרה בשפה חברותית. הסכנה שרן מציג היא אמיתית, הנה מה שכתבו על ה-Office Assistant בוויקיפדיה:
The program was widely reviled among users as intrusive and annoying, and was criticized even within Microsoft. Smithsonian Magazine called Clippy "one of the worst software design blunders in the annals of computing".
לדרוש ממשתמש לא מנוסה לדרג את רמת הידע שלו זה סוג של בוחן פתע, ואף אחד מאיתנו לא אוהב כאלה. מה שהרבה מוצרים עושים הוא לתת הנחיות למשתמשים חדשים לגמרי על דברים שייחודיים למכשיר, קיצורי דרך, התנהגויות לא סטנדרטיות. כך הן מסייעות למשתמשים חדשים לנצל את היכולות המיוחדות של המכשיר. למשל, בסלולרי k800i של אריקסון זה נעשה כך. דברים דומים נעשים גם במוצרי תוכנה אחרים, על-מנת להציג מוצרים חדשים או תכונות חדשות בגירסאות מעודכנות של מוצרים קיימים, כמו יכולת הגרירה של מיילים לתוויות בג'ימייל.
עוד על התוויות בג'ימייל, בפוסט הראשון שלי בבלוג "חורים ברשת":
http://tinyurl.com/napz6c
דרך נוספת לאפשר למשתמש להתאים את המערכת לצרכיו (ולהיפך)
היא באמצעות המתודולוגיה של progressive disclosure –
חושפים למשתמש רק מה שהכי חיוני לעבודה עם המערכת, ומאפשרים לו לקבל ע"פ דרישה
גישה לאלמנטים מתקדמים יותר או כלים שמהווים הרחבה לעבודה הבסיסית עם המערכת.
ע"ע http://www.useit.com/alertbox/progressive-disclosure.html
תודה, רן. חשיפה הדרגתית היא דרך מצויינת להקל על כניסה למערכת חדשה בכך שהיא מאפשרת למשתמש עם ניסיון מועט להשתמש רק בחלקים שהוא זקוק להם במערכת, ובכך מקטינה את העומס הקוגניטיבי עליו. משתמשים מנוסים יותר יכולים לגשת גם לחלקים מתקדמים יותר. כך ניתן לספק שני צרכים סותרים לכאורה – לשמור על המערכת פשוטה מצד אחד, ולתת יכולות מתקדמות מצד שני.
הצורך שיוסי העלה הוא התאמה בין רמת העזרה לרמת הידע של המשתמש, וכאן חשיפה הדרגתית לא תעזור. נדרש מהממשק לספק עזרה נוספת למשתמשים חדשים. בעבר התמודדו עם הבעיה הזו באופיס ובמוצרים אחרים בעזרת טיפ יומי ("Tip of the Day") שניתן היה לכבות. הוא כבר לא קיים היום באופיס, להערכתי בגלל שהוא נתן עזרה שמנותקת מקונטקסט בעיה שהמשתמש נתקל בה באותו רגע, ולכן רוב המשתמשים לא השתמשו בו כדי ללמוד. במקרה הזה עזרה מיוחדת, שניתנת רק בפעם הראשונה שמפעילים איזור מסויים במוצר, יכולה להתאים. למשתמש צריכה להיות אפשרות להפסיק לראות הודעות כאלה, למקרה שהוא כבר מנוסה בחלק הזה של המערכת.
אני לא דיברתי על נדנוד בלתי פוסק של התוכנה שתשאל שאלות, אלא רק בשימוש הראשון.
לאחר שהמוצר ידע באופן כללי מה הרמה של המשתמש, אז הוא יוכל להשתמש בדרכים חכמות יותר, כמו חשיפה הדרגתית, בצורה מושכלת. אחרת, זה לרוב יהיה או יותר מדי או פחות מדי.
בפוסט הבא נדבר על ממשק לעומת מִנשַק? ;-)
מנשק משתמש
מי מנשק משתמשים מי?
אני מקווה ששלי יהיו מרוצים גם בלי ההתחנפויות האלה :-)
מנשק דומה מדי לממשק בשביל שמי שלא בתחום יבדיל בין המילים, או ינחש שהכוונה היא לא לנשיקה. במילים אחרות, המלה מִנשק לא שמישה! למילה "שמישות", לעומת זאת, יש קיום גם מחוץ לעולם המקצועי של usability.
כן, אבל מחוץ לעולם הזה הכוונה היא לתקינותו של ציוד. אם לפני כמה שנים היו אומרים לי שהאתר לא שמיש, רוב הסיכויים שהייתי מסיק מזה שהוא לא עולה או לא עובד בצורה אחרת כלשהי.
רעיון מצויין לסקר הראשון של הבלוג.
בקרוב…
שמחתי לשמוע על שיטת בדיקת אתרים באמצעות שמירה של העמוד ובדיקת המרכיבים שלו
עשיתי זאת ואכן ראיתי הרבה תמונות
אבל, שמתי לב רק חלק מן התמונות רלוונטיות לדיון ואלו התמונות הכוללות דמויות וכאלו אין הרבה
מענין לקרוא את המאמרים בנושא – אמנם אני לא מבין הרבה בזה
שלום רב,
במסגרת קורס מסויים התבקשנו לעלות בעיות שמישות באינראקציה כולשהי שיש לנו נסיון בה והיא מוכרת.יש לבחור פן מסוים באינטראקציה שהוא בעייתי מבחינת שמישות ואז לתאר את הבעייתיות ולהסביר ממה לדעתינו נובעת הבעייתיות- מה מקור הבעייתיות באינטראקציה ולבסוף עלינו לתת עצות לשיפור האינטראקציה שיפתרו את הבעייתיות.
הבעיה היא :) שכרגע לא עולה לי שום רעיון לראש למרות שזכור לי שהיו מספיק דוגמאות בחיי :(