כאשר מדברים על שמישות, יש פעמים רבות נטייה להתייחס לפרמטר האיכות החשוב הזה כמשהו אופציונאלי שצריך לשכנע את הלקוחות שלנו ששווה להשקיע בו על ידי הקצאת משאבים לביצוע מחקר, בדיקות שמישות, סבבי עיצוב ועוד. מהסיבה הזאת הופתעתי לטובה לגלות לאחרונה שבמקרה של תכנון מערכות בנקאיות המיועדות ללקוחות בנקים באנגליה, ישנה דרישה של הרגולטור המפקח על הבנקים להבטיח שהסברים בנוגע לשירותים ומוצרים יהיו מאוד ברורים ולא מטעים. הממשק יכול להטעות משתמשים גם אם לא היתה שום כוונת זדון לעשות זאת ברגע שהאופן בו המידע מוצג אינו פשוט להבנה. זה נשמע דבר הגיוני וברור אך כשאנו באים לעצב מידע ורוצים לברוח קצת מטבלאות וגרפים אנו נגלה שזה לא תמיד אפשרי.
cc by ajburgess
אם אתם תאפיינו ממשק לבנק באנגליה, הלקוח מולו תעבדו יהיה מודע היטב לרגולטור שיבדוק את האתר או האפליקציה שהבנק יציע ללקוחות. כאיש UX, ההרגשה הראשונית שלי היתה שהרגולטור הזה הוא החבר החדש הכי טוב שלי כי לשנינו חשוב להבטיח שהממשק יהיה מאוד ברור ופשוט לתפעול. אם לקוח של הבנק יסתבך בתפעול אפליקציית המחשת מוצרים ושירותים או יפרש לא נכון את המידע המוצג בה זהו פתח לתביעות משפטיות מצד אותו לקוח. התוצאה היא שהבנק מאוד חרד להבטיח שהממשק יהיה ברור ובשום פנים ואופן לא יעמת את המשתמש עם אינטראקציה או עיצוב מידע שעלול לבלבל או להטעות.
על פניו נשמע שזהו תסריט מושלם בו אנו לא צריכים להיאבק עם הלקוח בכדי להבטיח את שמישות הממשק כי הציווי מגיע מלמעלה, ובין אם לבנק באמת חשוב להציג ממשק שמיש וברור הוא יודע שאין לו ברירה. החסרון הוא שאנו יכולים למצוא את עצמנו מוגבלים מבחינת האיפיון משום שאין אפשרות להציע ולדחוף רעיונות חדשניים שאינם עולים בקנה אחד עם הסטנדרטים שלקוחות הבנק מכירים. כתבתי לפני מספר שנים על חדשנות מול סטנדרטים, ובמקרה הזה הבנק לא יכול להרשות לעצמו, ואולי אפילו לא שואף, להיות פורץ דרך ולהציע דרכי הצגת מידע חדשניות שחורגות מטבלאות וגרפים.
דמיינו מצב בו לקוח של הבנק רוצה לבדוק הלוואות או פקדונות ונתקל בממשק אינטראקטיבי מרשים בו ניתן לגרור, להזיז ולהצמיד אובייקטים בכדי לראות את ההשפעה של פרמטרים כמו זמן, סכום וריבית. הראציונל שלכם בתכנון הממשק היה להציע דרך אפקטיבית יותר מטבלה, פסקה או גרף לבחון את המוצר בשביל להגיע למסקנה מושכלת. יכול מאוד להיות שגם רציתם לעזור לבנק לבדל את עצמו מהמתחרים על ידי שימוש בכלים שאמורים להיות טובים ומעניינים יותר לשימוש מאשר הסטנדרט הקיים. כאשר הרגולטור יבחן את הממשק הוא עלול לקבוע שהממשק הלא שיגרתי יכול לבלבל את חלק מהלקוחות שלא יפרשו נכון את היחס בין הזמן הנגרר והריבית המנפחת למרות שלכם הוא היה מאוד ברור.
בסופו של דבר הרגולטור שמפקח על הבנקים מפקח בצורה עקיפה גם על עבודת האיפיון שלנו. לעיתים זה מרגיש כאילו הוא חבר שעוזר לקדם עקרונות שמישות מול הלקוח ולפעמים הוא מרגיש כמו מפקח שמרן שחונק את היצירתיות ולא מאפשר לערער על המוסכמות. זהו אילוץ אחד מתוך שלל אילוצים (ספציפים למגזר הפיננסי ובכלל) איתם אנו מתמודדים ביומיום.
לסיכום, מספר מילים שאורן שמיר, חבר צוות UXI ומנהל תחום שימושיות ומנהל פרויקטים בחברת McCann Erickson, כתב בתכתובת מייל שהיתה לנו בנושא הפוסט: "נתקלתי בתופעה דומה מאוד בתחום הביטוח, הן בארצות הברית והן באנגליה (אפילו יותר). בסך הכל ראיתי בזה דבר חיובי. זה נכון שזה קצת הורג יצירתיות (אם כי לדעתי אפשר למצוא כל מיני "מעקפים", אנחנו הישראלים מצטיינים בזה) אבל מצד שני זה אכן גורם לממשקים להיות מאוד פשוטים ומובנים. הרגולטור גם מאוד מקפיד על שימוש בקופי מדוייק, והמעטה בסופרלטיבים ריקניים או לשון מליצית שניתן לפרש אותה בדרכים שונות. גם זה בעצם חלק מהעבודה שלנו ובהרבה מקרים זה יכול לחסוך ויכוחים עם אנשי השיווק. אפשר פשוט לזמן לישיבה גם את אנשי המחלקה המשפטית. בסופו של דבר, אני חושב שהייתי שמח אם השלטונות בישראל היו מאמצים משהו מהגישה הזו. בין אם זה הסטנדרטים לשימושיות של הממשל האמריקאי או הקפדנות של האנגלים. מישהו בארץ צריך להתעורר ולהבין ששימושיות של ממשקים היא חלק מדרישות הסף בכל מערכת ציבורית, בנקאית וכו'."
הי אמיר.
נדמה לי שזה בדיוק המקום בו נכנסים מבחני השמישות –
אם מפתחים ממשק חדשנים ומיוחד,
ניתן (ואפילו חיוני) לגבות אותו בבדיקות שמישות ,
שיאמתו באופן הקפדני ביותר, שהיקף הטעויות בממשק החדש
לא עולה (ורצוי – נופל) מהיקף הטעויות בממשקים קיימים.
{ אחחח… לו רק דברים באמת היו מתנהלים כך בעולם האמיתי….(-; }
רן, במקרה הספציפי הזה אני לא חושב שמבחני שמישות יעזרו כי אין פה עניין של להוכיח לרגולטור על ידי מידע אמפירי שהממשק ברור. הרושם שלי הוא שהפשטות של הממשק בהקשר הזה היא לא משהו שמותר "לשחק" איתו גם אם ניתן להראות בשיטות מחקר תוצאות תומכות כלשהן. ההנחייה היא להציג מידע בצורה הכי ברורה מה שלרוב אומר שימוש בגרפיקה מוכרת תוך הבהרת הסיכונים והחסרונות הכרוכים בכל שירות ומוצר. מבחינת עלות-תועלת, הבנק יעדיף לדעתי ללכת על בטוח כאשר מדובר בהצגת מידע ללקוחות שלו מבלי להסתבך על הרגולטור.
מניסיוני בליווי פיתוח ממשקים שונים בחברת העזר הבנקאית בה אני מועסק למדתי כי 'רגולציה' מסוג זה מתבצעת גם כאן, לא כהנחיה מדרג פוליטי או ציבורי כלשהו אלא כתפישה כללית שהסיבות לה יכולות לנוע בין שיקולים תקציביים לבין האוריינות הטכנולוגית של מזמיני ומנהלי הפרויקט עצמו לבין הבנה ממשית של כל המעורבים כי ממשקים שנועדו לקהל הרחב חייבים להיות נקיים מפיצ'רים מורכבים – ברמת הניווט, האלמנטים, הקופי והשאר.
פתרון אחד הוא לבנות ממשק כפול שיציג למשתמשים שירצו בכך תצוגה נקיה מ"רעש" ולמשתמשים תאווי טכנולוגיה תצוגה עמוסת פיצ'רים. במציאות הנוכחית הפתרון הזה מתקיים בעיקר במוחו הקודח של איש ה-UX שניה לפני שמנהל הפרויקט מחייך אליו, טופח על כתפו ואומר לו "מעניין, מעניין…אבל שכח מזה".
מאמר מצוין אמיר, מקווה שהרגולטור לא קורא עברית
כמעצב אני נתקל לא פעם בגישות שמרניות ובחשש מפני חדשנות עיצובית וממשקית.
מצד שני, יש לקוחות שרוצים חדשנות בכל מחיר…
אני מניח שהדרך האידיאלית היא דרך האמצע, המפשרת בין שני אלה. הבעיה היא שבפרויקטים המוכרים לי, אין "בורר" לדברים מהסוג הזה. יש אותך מול הלקוח.
המצב המתקבל הוא שאתה צריך להיות מספיק נטול אגו וקשוב ללקוח כדי לשמוע את האינפוט הלגיטימי שלו, מצד שני עליך לעודד חדשנות במידת האפשר כיוון שלרוב, זה לטובת הפרויקט והלקוח עצמו.
מאור, אני בטוח שהרגולטור ישמח לקרוא שלוקחים אותו ברצינות
שימושיות וכלכלה עדיין לא הולכים ביחד.
הבנקים זה מילא, תנסו לעצב (וקדם כל לקרוא) מחדש את הטפסים של הביטוח הפנסיוני.
בתכנית של גיא ואורלי עסקו בנקודה הרגישה הזו, הביאו אפילו מומחה לשפה העברית שלא הצליח לפענח את ה"שפה" שבה הם עושים שימוש.
נילסן דיבר על יוריסטיקת השפה הטבעית שתקל על המשתמש- חבל שחברות הביטוח השונות לא שמעו על זה.
היי אסף. לא הייתי מרחיק לכת ואומר ששמישות וכלכלה לא הולכים ביחד, אבל אכן לא מדובר בצמד שמקפץ ומדלג לו ביחד בשדות אל תוך השקיעה. כל הפואנטה של הפוסט היתה שבדיוק משום שכלכלה יכולה להיות מורכבת או לא מוכרת להרבה אנשים, הרגולטור באנגליה דורש מהבנקים לספק הסברים נהירים שיצמצמו אי וודאות וטעויות מצד לקוחות הבנק. עיצוב טפסים פיזים מהבחינה הזאת אינו שונה מטופס באתר לצורך העניין. הדרך עוד ארוכה ובכל תחום תמצא דוגמאות לפשעי שמישות מזעזעים אבל לפחות כאשר הרגולטור לצידך קל יותר לקדם את החשיבות של ממשק שמיש כלפי הבנק.
אגב גם בארץ היה ניסיון של הרגולטור לפשט החשבונות, שיהיו יותר ברורים לאנשים. זה מה שאני זוכר מניסיונות לחדש את החשבון החודשי של הטלפון הסלולרי.
).
אבל החשבון הסלולרי זה כסף קטן לעומת ביטוח פנסיוני.
אני לא מכיר את כל העולם הפיננסי ולכן מתוך נקודת המבט השלי והנסיונות האישיים שלי, זה נראה ששימושיות וכלכלה לא הולכים ביחד.
אגב, מאוד ייתכן שזו מסיבה בכלל פוליטית- לנסות ולשמר על שפה גבוהה ולא ברורה כך שיהיה צורך באנשים חיצוניים (בנקאים, יועצים פנסיונים וכד') על מנת לשמר את כוחם (עד כאן לתאוריות סוצאיליסטיות
הצורך לצמצם מאמץ קוגנטיבי קיים בכל תחום, בין אם מדובר במשתמשים מומחים או "אנשים מן הישוב" שבמקרה של כלכלה וביטוח למשל מוצאים את עצמם בעולם לא מוכר, לעיתים מורכב וזה התפקיד שלנו להקל עליהם. באותה מידה אפשר להגיד ששמישות ומערכות צבאיות או רפואיות לא הולכים ביחד
מה כן הולך ביחד? אם הדברים היו הולכים ביחד אז רובנו היו מחוסרי עבודה.
אני מסכים שכמו בהרבה תחומים אחרים ישנה הרבה פוליטיקה ואינטרסים מנוגדים, אך במקרה הספציפי הזה הרושם שלי הוא שהרגולטור נמצא שם בשביל להבטיח שהבנקים לא ינצלו את חוסר הידע של הלקוחות על ידי שימוש בשפה גבוהה וממשקים שעלולים להקשות.
כמישהו שעובד לא מעט עם מגבלות רגולטוריות אני חייב לציין שההתנסות שלי מלמדת שלאנשים היקרים ב FSA או ב CFTC אין מושג ירוק בממשק או חווית משתמש. רוב הדגש בעבודה נכונה מול רגולציה צריכה (ובצדק) להתחיל מהשיווק ושם לרוב נעשות הטעויות והקנסות בהתאם.
לפני שנתיים ניהלתי שיחה הזויה של חצי שעה עם נציג הרגולציה בארה"ב וניסיתי להסביר לו למה אי אפשר לשים 1,700 מילה בחלון מודלי של אפליקציה וחייבים לעשות קישור ללינק בחלון אחר. לא היה לו מושג מה זה לינק או חלון…
אותי מעניין מיהו אותו רגולטור (או מיהו נציגו), ואיך נראית העבודה מולו. מה ההכשרה שלו? האם הוא איש UX או בנקאי או פקיד? האם הוא עובר על האפיונים ומשתתף בתהליך בניית האתר, או שהוא רק נכנס לאתר המוגמר אחרי השקתו? יש שם עם מי לדבר, או שיום אחד מגיע מכתב נייר שרשום בו "ראינו את האתר החדש שלכם, הוא בלאדי מבלבל, תשנוּ בשם המלכה!"?
ויטלי, אין קשר ל-UX וההתרשמות שלי עד כה היא שאין שום מעורבות בתהליך אלא פיקוח כלשהו לאחר מעשה. אני אשתדל לבדוק ולספק פרטים נוספים. ברגע שהבנק מודע לפיקוח ולאפשרות שמישהו יבוא וידפוק על הדלת הוא עושה את המאמצים בעצמו לאורך התהליך ומזכיר לך המאפיין אם חס וחלילה שכחת שישנן הנחיות שחייבים להתחשב בהן. ההנחיות אינן קשורות ל-UX בצורה ישירה עד כמה שיצא לי להתרשם. יכול להיות שהבנק לפעמים מפרש אותן בצורה קיצונית יותר אבל זה לא ממש משנה כי בשורה התחתונה, אתה שומע את הלקוח שלך מתייחס לרגולטור בישיבות כאשר אתה מציג רעיונות ובזה מבחינתי נגמר הסיפור. אין פה עם מי להתווכח ואת מי לשכנע. ברגע שהבנק מציין שהוא חייב להציג מידע בצורה ברורה ופשוטה אתה יכול לפרש את זה כראות עיניך ואולי אפילו תוכל לשכנע את אותו לקוח שהממשק שאתה מציע עושה בדיוק את זה. מה קורה אחר כך ומי בודק? אין לי מושג כרגע אבל הוא קיים
אלא אם כן הממשלה המציאה גוף דמיוני רק בשביל להפחיד את הבנקים.
מאור, אני קצת חולק על המשפט הזה: "עליך לעודד חדשנות במידת האפשר כיוון שלרוב, זה לטובת הפרויקט והלקוח עצמו."
אני הולך לעשות פה לא מעט הכללות (וקצת לסטות מנושא הדיון), אבל מכיוון שזאת הכנה להרצאה בכנס עתידי…
חדשנות היא מילת באזז בעלת קונוטציה חיובית, אבל היא לא תמיד אכן חיובית.
היא לא תמיד לטובת הפרויקט, לא תמיד לטובת הלקוח, ובוודאי לא תמיד לטובת המשתמשים.
שמרנות היא מילה מרוטה, בעלת קונוטציה שלילית, אבל לפעמים היא מועילה, במיוחד אם אי אפשר להחליף אותה בחדשנות אמתית.
חדשנות אמתית נוצרת כדי לפתור בעיה קיימת בצורה טובה יותר. היא לא נוצרת לצורך עצמה ("חדשנות לשם חדשנות").
אם אין פתרון חדשני שהוא טוב יותר מהקיים, עדיף להשתמש בקיים (הוא לפחות מוכר יותר).
Things that are different in order simply to be different are seldom better, but that which is made to be better is almost always different
Dieter Rams
או בעברית מדוברת- חדשנות עושים בחוכמה, או לא עושים בכלל
אורן, ההרגשה שלי היא שבנקים שבויים בדילמה לא פשוטה מכיוון שמצד אחד הם חייבים במידה מסויימת להיות שמרנים ועקביים כדי לא לבלבל חס וחלילה משתמשים, אך מצד שני הם פועלים בסביבה מאוד תחרותית וחשוב להם להציע ממשקים ואפשרויות שיקנו להם יתרון תחרותי.
זה מזכיר לי אפיון שעשיתי עבור הממשלה הקנדית
שם הדרישה היא לעמידה בכללי נגישות
(בדומה ל- 508 למי שמכיר) והם היו מאד נוקשים בענין
בהתחלה שמחתי על כך אבל מצד שני זה מאד מגביל ובהחלט מעורר סימני שאלה מבחינתי. הפתרון הוא באמת לאפשר שתי אופציות תפעול במקומות שזה ממש כואב (למשל עם ובלי javascript) ובשאר הזמן לעשות את המיטב.
הבעיה לפעמים עם הכללים האלו היא לא רק שמרנות – אורן מאד אהבתי את ההתיחסות שלך לענין הזה וגם את הציטוט! – אלא התיישנות, כלומר האם באמת מעדכנים את הכללים הללו בתדירות מספקת? אין לי תשובה חד משמעית כי זה משהו שצריך לבדוק כמובן מול משתמשים.
לגבי טקסטים, אני יודעת שבאמריקאית יש מספר דרכים לדרג קריאות טקסט לפי "הכיתה" שהוא מתאים לה ויש דרישות שמסמכים מסוימים צריכים לעמוד בהם. זה לא קיים גם באנגליה?
האם הרגולטור הישראלי קורא פה? הלוואי…
[...] פרסמתי באתר UXI מאמר תחת הכותרת "שמישות ממשק כדרישה של רגולטור בתכנון מערכות בנקאיות". אתם מוזמנים לקרוא. פורסם במדור תהליכים [...]