עיצוב שמיש

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

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

בדיקת מומחה (Expert review, Heuristic Evaluation) היא אחת השיטות המקובלות ביותר לביצוע הערכת שמישות ללא משתמשים. הרעיון פשוט – מומחה שמישות משתמש ברשימה של כללים מנחים והנחיות שמישות בכדי לאתר היכן הממשק מפר אותן. הבסיס לבדיקת מומחה הן לרוב ההיוריסטיקות הקלאסיות של ג'ייקוב נילסן שנוסחו לראשונה ב-1990. למרות שהן עדיין מאוד רלוונטיות ושימושיות, בבדיקת מומחה שערכתי בעבודה הרגשתי שאני לא יכול להתעלם מפיצ'רים חברתיים ו-SEO שלוקחים את הבדיקה מבדיקת שמישות למשהו רחב ואקטואלי יותר. עד כמה בדיקות המתמקדות אך ורק בשמישות הממשק מספקות ללקוחות באמת את מה שהם צריכים לדעת ואיפה אתם שמים את הגבול?

אלכס ריינט כתב אתמול על פיצ'ר פשוט ומעניין באתר של הניו-יורק פוסט שמוסיף באופן אוטומטי קישור למאמר ממנו הועתק קטע טקסט מסויים. לעיתים כאשר אנו מעתיקים פסקה מכתבה למייל או תגובה בבלוג אנו מעתיקים את הלינק ידנית ומפנים אליו למי שמעוניין לקרוא מעבר. זה לא קורה תמיד ואפשר להתווכח האם מדובר בפתרון לבעיה שלא ממש קיימת כי להעתיק קטע טקסט ואז להעתיק שוב את הקישור אליו זאת לא בדיוק פעולה שמזיעים בגללה. מה שאותי יותר מעניין זה האם זה חכם להתערב בפעולת המשתמש ולהשחיל לינק כאשר הפעולה היתה רק העתקה של קטע טקסט? מתי התערבות כזאת מבורכת ונחוצה ומתי היא יכולה להציק?

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

היום לאחר המתנה שבוע וחצי לחיבור אינטרנט קיבלתי את הודעת ה-SMS המיוחלת שהטכנאי של חברת הטלפון חיבר את מה שצריך וכל מה שנותר לי לעשות הוא להכניס את הסידי ולעקוב אחר ההוראות. הכל כבר היה מחובר מבעוד מועד ואת הסידי חיש מהר השחלתי למחשב וכשנפתחה תוכנת ההתקנה עקבתי אחר ההוראות בצייתנות. הכל הלך חלק עד שהתבקשתי להזין סיסמא (Your account password). סיסמא? איזו סיסמא?

מאז החשיפה של Google Wave בחודש מאי השנה אחד הדברים שעניינו אותי מעבר לקונספט ותכנון הממשק היתה ההחלטה לקרוא למוצר ולאלמנט הממשק המרכזי בו בשם Wave. המונחים בהם אנו בוחרים להשתמש בממשק קריטים לשמישות שלו משום שהם עוזרים למשתמש להבין מה הוא אמור ויכול לעשות. כאשר אנו לא מבינים או לא בטוחים לגבי המונחים בהם אנו נתקלים בממשק (שמות של כפתורים, כותרות, פקודות וכו') אנו מתקשים להבין את הממשק ולכך יש השפעה על תחושת הסיפוק שלנו, תדירות הטעויות שאנו מבצעים והיכולת שלנו לבצע פעולות במהירות מתוך תחושת שליטה. הגדרת טרמינולוגיה שמישה היא מטלה לא פשוטה בכלל והיא מבטאת את ההיוריסטיקה הבסיסית – Match Between System and the Real World או בעברית – "המערכת צריכה לדבר בשפה שהמשתמש מבין". האם זה המקרה עם הגלים ב-Google Wave?

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

בכנס האקדמאי, שנערך תחת הכותרת Research & Practice באופסלה (Uppsala) ליד סטוקהולם, הוצגו עשרות מחקרים בנושא אינטראקציית אדם-מחשב. אחד מהם היה מקרה מבחן בנושא שימוש בפרסונות שכתבתי עם קולגות והצגתי ביום הראשון של הכנס. במאמר תיארתי כיצד השתמשנו בפרסונות בזמן סדנת עיצוב מחדש של APOSDLE אשר נמשכה יומיים והשתתפו בה עשרים ואחד חברי פרוייקט מרקעים מקצועיים ותרבותיים שונים. אחרי שנתיים וחצי של עבודה על הפרוייקט ולאור הממצאים של בדיקות שונות הגענו למסקנה שבשביל סדנת העיצוב חשוב שחברי הפרוייקט יכירו מחדש את האנשים שאמורים להשתמש במערכת ויחשבו עליה בצורה אקטיבית מנקודת המבט שלהם תוך התחשבות בשיגרת העבודה, המגבלות, האילוצים והצרכים שלהם. הפרסונות לא היוו פתרון קסמים (והן לא אמורות להיות כזה) אך הן היו מאוד אפקטיביות לדעתי לעומת חשיבה על "המשתמש" המופשט שלא אומר לנו שום דבר.

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