——ארכיטקטים הם לא מאפייני UI. גם מפתחים, או ראשי צוותים הם לא מאפייני UI.
בכל זאת, מאפייני UI בעלי ניסיון אמיתי ב Mobile הוא מצרך נדיר למדי בימים אלה. רוב פרויקטי המובייל שיפותחו בשנה-שנתיים הקרובות יעוצבו ללא איש UI בעל ניסיון במובייל.
כיוון שבמקרים רבים מבצעים “פרויקט התאמה” (התאמת אפליקציית Desktop קיימת למובייל) בעזרת איש ה-UI שתכנן את אפליקציית ה-Desktop, אנחנו נתקלים בתופעה של התאהבות או קבעון של איש ה-UI ברעיונות שלו שעובדים היטב באפליקציית ה-Desktop ובקושי שלו לבצע שינויים דרמטיים עבור ההתאמה למובייל – עולם שהוא אולי לא רגיל אליו.
ראיתי ניסיון להתמודד עם בעיה זו ע”י “הצרחה” של אנשי UI, כך שיתאימו למובייל פרויקטים שלא הם יצרו. נראה עוד שנה כיצד זה הוכיח את עצמו בפועל.
בפוסט הבא אנסה לספק כמה כלים, לאנשים טכניים, שיכולים לסייע בערכה של שיקולים בעיצוב UI לאפליקציית מובייל. אנא זכרו שכמה טיפים לא הופכים אותנו למומחים, אני לא רוצה לעודד אתכם לפסול את איש ה UI במחשבה שאתם “כבר מבינים יותר”. נסו להשתמש בדוגמאות אלה על מנת לנמק מה נראה לכם שגוי ולמה, או לסייע ולשפר את הקיים. לא פחות חשוב: נסו גם להקשיב. מדוע איש ה UI חושב שדרך מסוימת עדיפה…
ה UI של אפליקציית מובייל הוא חשוב יותר.
זה נובע משני גורמים: הציפיות של המשתמשים גבוהות יותר, והצורך העמוק בשימושיות טובה – אף הוא גבוה יותר.
לעתים במסדרונות הפיתוח נשמעים טיעונים כנגד ההשקעה הגבוהה בשימושיות “היו לנו הרבה מוצרים עם UI לא-משהו בעבר – אך הם מצליחים. שימושיות זה יופי, אבל יש דברים יותר חשובים”.
אני לא טוען ש UI הוא הדבר היחיד שיש לשים לב אליו, רק דבר שכדאי לשים עליו דגש גדול מבעבר.

בעוד ב Desktop יש עכבר שהוא כלי הצבעה דיי מדויק, במובייל אזורים לחיצים צריכים להיות גדולים בהרבה – מה שמותיר מקום מועט אפילו יותר לתוכן שעל המסך.
- לוותר על 4 השדות הפחות קריטיים – לשפר את חווית החיפוש על חשבון השלמות. גם במידה וחלק מהחיפושים יוכלו להתבצע רק מהגרסה השולחנית של האפליקציה.
- להציע השלמה אוטומטית, או לפחות לנחש ולהציב ערכי ברירת מחדל אינטליגנטים בחיפוש.
- לשמור היסטוריה של החיפושים האחרונים – על מנת לחסוך הקלדה בפעמים הבאות. תחת ההנחה שאנשים שונים חוזרים על חיפושים דומים.
ככלל אצבע, לאפליקציית מובייל טובה לרוב יהיו:
- הרבה פחות פונקציות זמינות מאשר האפליקציה השולחנית. השאירו משימות “כבדות” לטאבלט או למחשב השולחני. שינוי סיסמה, הגדרות רישום, הקלדת טפסים ועוד – יכולים לחלוטין לא להופיע על אפליקציה לסמארטפון (בהנחה שיש אפליקציה משלימה).
- צפיפות נתונים פחותה – גם על חשבון כמות המידע הזמין למשתמש.חשבו שוב: האם בזמן נסיעה במונית המשתמש זקוק לכל השדות הזמינים? באפליקציה שולחנית המסך רחב ואנו נוטים “לזרוק למסך” נתונים שקיימים בבסיס הנתונים, גם כאלו שברור שהצורך בהם יהיה נדיר למדי. המאמץ “לוותר” על נתונים הוא לא קל, במיוחד למנהלי המוצר שרוצים לדקלם ללקוח “זה – יש, וזה – גם יש”, אך זו הדרך ליצור אפליקציות שיזכו להצלחה בשטח.
- פונקציות חדשות ייחודיות למובייל. לעתים קרובות ניתוח השימוש במובייל מוביל לצרכים שלא היו קיימים באפליקציה השולחנית. שימוש במצלמה כתחליף להקלדה על מנת למלא דו”ח, השלמה של שדה מבוסס על המיקום שלכם, היסטוריה ו “Favorites” על מנת לחסוך הקלדה או ניווט מייגע. זכרו שהמשתמש באפליקציית המובייל לרוב יהיה בשטח. אפילו אם הוא במשרד – הוא כנראה בזמן תנועה (או הקלדה מתחת לשולחן בזמן ישיבה משעמעמת). זהו אותו אדם – אך לא אותו משתמש. עליכם לספק לא רק את פונקציות הבסיס של המערכת – אלא גם פונקציות חדשות בהתאם למצבו החדש.
דוגמה נוספת: חשבו על המקלדת של המובייל מול מקלדת של Desktop, איפה כל כפתורי ה F-masheu? כיצד ביטלו את כפתור ה del (מחיקה ימנה) וניתן להסתדר רק עם מחיקה שמאלה[ב]?
להלן עוד כמה נקודות שימושיות, שאין טעם לחפור בהן יותר מדי.
חזור ושמור – פעמים רבות משתמשים לוחצים על הכפתור “אחורה” בגלל שהם לא בטוחים איפה הם. כשהם יבינו שהם בסדר ויחזרו לדף, הם ישמחו אם תשמרו את מה שהקלידו כבר. בכלל, שימו לב שדפים רבים במובייל לא כוללים את הכפתור “Save”. אתם פשוט ממשיכים הלאה ומה ששיניתם – נשמר.
היסטוריה – אם אתם לא יודעים לנחש, לפחות זכרו מה המשתמש הקיש בעבר בשדה זה (dropdown list).
חיפוש – הוא סוג הניווט המועדף. ללא פירורי לחם (breadcrumbs) ובטח ללא עץ ניווט. רשימת הפריטים האחרונים / הנפוצים יכולה להיות גם נקודת פתיחה טובה (חשבו על ה App Store).
אלו אלמנטים שקצת יותר קשורים למימוש הטכני מאשר להגדרת השימושיות per se.
אם אין רשת, נסה שוב – במשרד, הרשת יציבה. בשטח, היא קופצת. נעלמת וחוזרת. אל תהרסו את כל חווית השימוש אם קריאה כלשהי לשרת לא הצליחה. אם תעשו כן, המשתמשים עשויים להתעצבן ממש מהר. ככלל, כדאי לנסות קריאה שנכשלה פעם נוספת ואם היא נכשלה – אולי להודיע למשתמש (שהוא יבצע רענון, או ינסה שוב). רק אל תכשילו את האפליקציה בצורה מוזרה על כישלון רשת בודד.
סיכום
בקיצור: כל אלו הן נקודות שכדאי לשים לב אליהן. סוג חשיבה שכדאי לאמץ במובייל.
נסו לשים לב כיצד אפליקציית המובייל שאתם מפתחים משתלבת בחשיבה זו ונסו לעבוד עם מאפיין ה UI על מנת לשפר את השימושיות שלה. הימים בהם מפתחי אפליקציות “לא צריכים להבין כלום בשימושיות” הולכים ונמוגים…
בהצלחה!
—-
[א] יחסי ציבור. אם לא ידעתם זאת, הרשו לי להניח שאתם מתכנתים צעירים.
[ב] בעברית, כמובן, הכיוונים הפוכים.
תגובה זו הוסרה על ידי מנהל הבלוג.