היי,
לרגל פתיחת הבלוג החדש UXE ע"י לירן אלבוים, קולגה וחבר משכבר הימים, אני מארח אותו כאן ביואקסטזי הרדום. ללירן רקורד מרשים בתור מנהל UX בארגונים גדולים, והוא הגיע לספר על אחד ההיבטים המעניינים של עבודה בסביבה מרובת מוצרים (או שמא מדובר במוצר אחד?). אז תנו לו יד גדולה (כי באנטרפרייז מקובל לדבר בתרגומים מילוליים מאמריקאית): לירן אלבוים.
UX לסוויטה
במאמר הזה נדבר על האתגרים המקצועיים הכרוכים באפיון UX לסוויטה של מוצרים. אבל לפני שנדבר על סוויטה, בואו נדבר קודם על אפליקציה, כי אם אי פעם התחבטם בשאלה איך מגדירים אפליקציה אתם ודאי יודעים שהתשובה אינה תמיד מובנת מאליה ודורשת חשיבה –
- האם עולם התוכן מובחן מספיק?
- כיצד ועד כמה הוא מובחן מעוד מודול בתוך אותה מערכת?
- מתי העושר הפונקציונאלי מצדיק זאת?
- האם המודל העסקי והשיווקי מחייב ליצור מסגרת אפליקטיבית נפרדת?
כפי שחלקכם ודאי זוכרים, עד 2014 אפליקציית המסרים המיידיים של Facebook היתה מוטמעת באפליקציית Facebook המרכזית עד שהם החליטו להפריד אותה מכל מני סיבות שלא נכנס אליהן כעת. אז אומנם הן מוזנקות בנפרד ואולי הן נראות קצת שונה, אבל ברור לכולנו שיש בינהן קשר – שתיהן מחוברות לאותן הגדרות משתמש, ואחת "יודעת" לקרוא לשניה. על פי עולם המושגים שלי, גם אם ניתן להתקינן בנפרד, הן חלק מאותו מערך של אפליקציות.
כך גם האפליקציות השונות של Google – בסוף כולן מקושרות לאותו שם משתמש וברוב המקרים המעבר בינהן פשוט וקל – ניתן לשמור תמונות מתוך Google Photos ל- Google Drive, לפתוח מסמכים ב- Google Docs ישירות מה- Google Drive, ולקבל ב- Gmail או ב- Inbox הודעות מאפקליציית לוח השנה Google Calendar, ואף לבצע פעולות ישירות משם.
גם בעולם אפליקציות ה- Desktop, נוכל בקלות לראות את חשיבות הקשר בין האפליקציות השונות באותה סוויטה. הדוגמא הקלאסית היא כמובן Microsoft Office Suite שלקחה את הקשר בין האפליקציות השונות לדרגת אומנות ממש. לדוגמא, לא רק שניתן ליצור גרף באמצעות Excel ישירות ב- PowerPoint ו- Word, ניתן אפילו לשמור על קשר "חי" בינהם כך שכל שינוי בנתונים ב- Excel מייד יבוא לידי ביטוי באפליקציה המארחת.
ובכן, לחברות גדולות יש הרבה פעמים סיבות עסקיות רבות לאגד לפחות חלק מהמוצרים בפורטפוליו שלהם לסוויטה, ולהחלטה הזאת יש השלכות רבות עלינו בתור אנשי UX בארגון. ראשית, החלטה כזאת ממש מחייבת יצירת Design System, אחרת לא יהיה לנו סיכוי לעמוד באתגר ה- Alignment בין המוצרים. שנית, זה מחייב פרקטיקות תקשורת מעולות בין צוותי העבודה השונים, בין אם הם מבוזרים, ובין אם לא. אבל במאמר הנוכחי אני רוצה לדבר על האתגר השלישי – האתגר המקצועי. בואו נפרוט אותו לפרטים:
- ארכיטקטורת המידע – כפי שראינו בדוגמאות לעיל, גם כאשר יש לנו מספר עולמות תוכן שכל אחד מיוצג ע"י אפליקציה אחרת, סביר להניח שהן חולקות מידע משותף ואף פונקציונאליות משותפת. בנוסף, יתכן שישנו מידע חוצה אפליקציות שתרצו להציף במקום אחד מרוכז כמו Dashboard. את כל הדברים האלה חשוב מאוד לקחת בחשבון כשמתכננים את מודל הניווט. האם למשל, עלינו לייצג אחרת, או אולי אף במקום אחר, את אותם אזורים משותפים? אולי הגישה אליהם תהיה בכלל מאזור משותף כגון ה- Header, או שבכל אחת מהאפליקציות השונות ניתן יהיה להזניק אותם מאותו מקום (למשל, ע"י כפתור בולט בפינה התחתונה של המסך)? אלה הם חלק מהשאלות שנידרש אליהם כאשר נתכנן את ארכיטקטורת המידע לסוויטה.
- הגדרות והעדפות משתמש – אפילו באפליקציות שהקשר ביניהם רופף יחסית, סביר להניח שהגדרות המשתמש והעדפותיו הכלליות הן משותפות לכולן – שם, פרטי התקשרות, שפה, יחידות מידה וכיו"ב. את ההגדרות האלה כדאי כמובן לשים במקום אחד במרוכז, למשל, מ- Header משותף, אם יש.
יחד עם זאת, ישנן גם הגדרות יותר ספציפיות שהן נכונות ברמת האפליקציה ולא ברמת הסוויטה. בהקשר זה חשוב מאוד לקחת בחשבון מי יהיו המשתמשים בסוויטה וכיצד הם יעשו שימוש באפקליציות השונות בה. למשל, אם אנחנו מצפים שרוב המשתמשים יבלו את רוב זמנם, ואולי אף כל זמנם, באחת האפליקציות, יתכן שכדאי לנו לפזר את ההגדרות הספציפיות באפליקציות השונות ולא במקום אחד מרוכז. לעומת זאת, אם חלק מהמשתמשים מבלים את רוב זמנם באפליקציה אחת, וחלק אחר של המשתמשים עוברים בתדירות גבוהה בין האפליקציות, אולי יהיה נכון למקם את כל ההגדרות, מכל האפליקציות, במקום אחד מרכזי.
יתכן שבמקרה כזה כדאי באותו הזמן לאפשר גישה להגדרות הספציפיות של כל אפליקציה גם ישירות מהאפליקציה עצמה – מהתפריט או מדפים רלוונטים. אפשר למשל להציף את ההגדרות הרלוונטיות באופן מקומי כפופ-אפ שמביא את המידע שלו מתוך המקום המרכזי. פתרון אחר, נכון יותר, אבל גם מסובך יותר למימוש, הוא לשים את כל ההגדרות המלאות מכל האפלקציות במקום אחד מרכזי, ולהציף נקודתית את ההגדרות המינימאליות הנדרשות בתהליכי העבודה השונים. למשל, אם אני רוצה להגדיר קבוצת משתמשים חדשה תוך כדי הגדרת משתמש חדש, אוכל לעשות זאת ישירות משם מבלי להיות חייב לצאת מתהליך הגדרת המשתמש החדש ולפתוח את מסך הגדרות הקבוצה המלא והמורכב. וכבונוס, כדאי במקרה כזה גם לנטר את הישויות שמוגדרות באופן חלקי ולהציע בשלב מאוחר יותר להשלים את ההגדרות במלואן. - מודל ניווט סקלבילי (Scalable) – באופן טבעי, הסיכוי שיותר אנשי מוצר עובדים בתוך סוויטה עם מספר אפליקציות, גבוה יותר מאשר באפליקציה אחת. זה אומר שסוויטה צריכה להיות גמישה יותר לשינויים ותוספות בארכיטקטורת המידע שלה מאשר באפקליקציה בודדת. לכן חשוב מאוד שתתכננו תפריט ניווט סקלבילי שקל להוסיף לו אלמנטים חדשים –
- חיקרו לעומק מהו מספר הרמות בכל אפליקציה ואפליקציה, וליתר ביטחון, אם זה עדיין הגיוני, אפשרו אפילו עוד אחת.
- דאגו ליכולת קלה לעבור בין אפליקציות – למשל, האם כל אפליקציה תיפתח בלשונית חדשה בדפדפן? לחילופין, האם בנוסף לבורר האפליקציות שכל פעם פותח אפליקציה אחת באותו חלון, תהיה יכול לחזור בלחיצת כפתור אחת לאפליקציה הקודמת ללא קשר מה היא היתה? (בקיצור, כפתור Back מובנה באפליקציה).
- במוצר SaaS חישבו כיצד המשתמש יעבור בין הדיירים (tenants) השונים בקלות.
- חיפוש – האם תהיה קיימת יכולת לחיפוש כללי מעבר לאפליקציות שנגישה מכל מקום בסוויטה, או שהחיפוש יהיה מקומי בהתאם לאפליקציה הבחורה (selected)? ואם תהיה יכולת כללית – האם צריך להצהיר מראש מה אנחנו מחפשים? אם כן, האם זה אומר שהחיפוש ייקח אותנו ישירות לאפליקציה הרלוונטית? ואם לא, איפה תוצגנה התוצאות הכלליות? איך דף התוצאות הזה משתלב בתוך מודל הניווט הכללי?
- הצפת מידע ופונקציונאליות חוצה אפליקציות – כיצד "מארחים" מידע מאפליקציה אחרת וכיצד מבצעים פעולות השייכות לאפליקציה אחת מתוך אחרת? האם מזניקים את האפליקציה הזאת באופן מלא? אם כן, איך חוזרים? אם לא – האם בלשונית נפרדת? האם בפופאפ מודאלי? האם באופן מוטמע לחלוטין כך שהמשתמש אפילו לא מרגיש שמדובר באפקליקציה אחרת?
בקיצור, חשוב שתתייחסו לעומק לכל שאלות היסוד האלה, במיוחד אם אתם מאפיינים לסביבה של סוויטה. לתשובות לשאלות האלו תהיינה השלכות דרמטיות על תפישת ה- UX הכוללת בסוויטה שלכם.
